linux-mips
[Top] [All Lists]

Re: [MIPS] Resolve compile issues with msp71xx configuration

To: Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [MIPS] Resolve compile issues with msp71xx configuration
From: Shane McDonald <mcdonald.shane@gmail.com>
Date: Tue, 28 Apr 2009 00:21:09 -0600
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=9aWA6ERNdm7KKDDVA/kxQK+n9Mi+a63m1eMgmzu8mCk=; b=hdPQnzKHdo/ox+Ua4dDbeMEaR1jTbXPwVF8y0T3W1ytiXtDcj6iRWZ6kI6N4IEW63k Ue7m8MUbj3Q2kJlVBfpNjGeOF4CGJJlE3Oq2TNkfSe+gbkNs7X8MHmqnX6y6U/yCWeIG nlZ5lL3z1MTv1fmdDhkwVVVT78UlbQ+yyviwI=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XoaTVSXSBvc/zfgABy6IMgwkTcAFqxWhc8W7P6PkXvrkz2s5cdOOrztr+GaUMx+gel pbSxqr9P3ioOXjA795RLYOj+5a7J89hSMVICr4/EzmmkzB396xURXZEa07jaH6vWmtSc 8J3zEh/xAWN8WkVG/ccy3u1UkobWmJkPqu9DU=
In-reply-to: <10f740e80904270622u730ba067g660257847dc526de@mail.gmail.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <E1LyQQX-00047N-6E@localhost> <20090427130952.GA30817@linux-mips.org> <10f740e80904270622u730ba067g660257847dc526de@mail.gmail.com>
Sender: linux-mips-bounce@linux-mips.org
Hello:

On Mon, Apr 27, 2009 at 7:22 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
On Mon, Apr 27, 2009 at 15:09, Ralf Baechle <ralf@linux-mips.org> wrote:
> On Mon, Apr 27, 2009 at 06:59:17AM -0600, Shane McDonald wrote:
>
>> There have been a number of compile problems with the msp71xx
>> configuration ever since it was included in the linux-mips.org
>> repository.  This patch resolves these problems:
>>  - proper files are included when using a squashfs rootfs
>>  - resetting the board no longer uses non-existent GPIO routines
>>  - create the required plat_timer_setup function
>>
>> This patch has been compile-tested against the current HEAD.
>>
>> Signed-off-by: Shane McDonald <mcdonald.shane@gmail.com>
>> ---
>>  arch/mips/pmc-sierra/msp71xx/msp_prom.c  |    3 ++-
>>  arch/mips/pmc-sierra/msp71xx/msp_setup.c |    8 ++------
>>  arch/mips/pmc-sierra/msp71xx/msp_time.c  |    7 ++-----
>>  3 files changed, 6 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/mips/pmc-sierra/msp71xx/msp_prom.c b/arch/mips/pmc-sierra/msp71xx/msp_prom.c
>> index e5bd548..1e2d984 100644
>> --- a/arch/mips/pmc-sierra/msp71xx/msp_prom.c
>> +++ b/arch/mips/pmc-sierra/msp71xx/msp_prom.c
>> @@ -44,7 +44,8 @@
>>  #include <linux/cramfs_fs.h>
>>  #endif
>>  #ifdef CONFIG_SQUASHFS
>> -#include <linux/squashfs_fs.h>
>> +#include <linux/magic.h>
>> +#include "../../../../fs/squashfs/squashfs_fs.h"
>
> No way.  You're reaching deep into the internals of squashfs for no good
> reason.  The only use of anything from squashfs_fs.h is a cast and casting
> to void * would work just as well.

He needs the definition of struct squashfs_super_block to access the .bytes_used
field. Alternatively, the offset of that field must be hardcoded.

BTW, the magic is __le32, and bytes_used is __le64, so there are some
le{32,64}_to_cpu()
missing.

I am not sure how to proceed here.  My main purpose in providing this patch was to get the msp71xx platform compiling again, but I stumbled into some pre-existing code ugliness, which I must confess I was ultimately responsible for.

As Geert said, I need to reach deep into the squashfs internals to access the bytes_used field of struct squashfs_super_block; the code just previous to this line works similar for the cramfs filesystem, where it accesses the size field of the struct cramfs_super field.  The cramfs code doesn't look as bad, because its superblock structure is defined in an easier-to-access file (linux/cramfs_fs.h).

I can see a number of possible paths here:

1. Fix up the existing patch with le{32,64}_to_cpu() as Geert suggested, and leave everything else as-is.
2. Approach the squashfs maintainers to move the squashfs_fs.h file to a more public location, and still do 1.
3. Pull the squashfs code entirely.
4. Remove the entire get_ramroot() code, both squashfs and cramfs, as Christoph has suggested.  I am hesitant to do this as it also affects code in the MTD subsystem (file maps/pmcmsp-ramroot.c), and it also loses some functionality on the PMC boards (putting the rootfs in RAM immediately following the kernel).  Perhaps there's a better way to handle this?

I am open to suggestions on how to proceed.



Gr{oetje,eeting}s,

                                               Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                                           -- Linus Torvalds

Shane

<Prev in Thread] Current Thread [Next in Thread>