linux-next: kbuild tree build failure

linux-next: kbuild tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

Hi Sam,

Today's linux-next build (x86_64 allmodconfig) failed like this:

In file included from arch/x86/include/asm/processor.h:15,
                 from include/linux/prefetch.h:14,
                 from include/linux/list.h:6,
                 from include/linux/module.h:9,
                 from kernel/configs.mod.c:1:
arch/x86/include/asm/current.h:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'struct'

and went rapidly down hill from there.

I have dropped the kbuild tree again.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: kbuild tree build failure

[Sam Ravnborg]

On Wed, Nov 26, 2008 at 03:42:06PM +1100, Stephen Rothwell wrote:
> Hi Sam,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> In file included from arch/x86/include/asm/processor.h:15,
>                  from include/linux/prefetch.h:14,
>                  from include/linux/list.h:6,
>                  from include/linux/module.h:9,
>                  from kernel/configs.mod.c:1:
> arch/x86/include/asm/current.h:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'struct'
> 
> and went rapidly down hill from there.

This bug puzzeled me for a while...
It triggers only when we do make O=... builds (which I did not do for a total build myself)
But the flags are the same but in different order before/after my patch.

Moving -D__KERNEL__ to be present earlier on the commandline fixed the build but
it did not explain why it worked in the non O=... case.
So I had to look for something else.

I noticed that I had the following options in the O=... case:

-I/full/path/ -I -D__KERNEL__

And there I had the bug. There is an optional space between -I and the path,
so in this case gcc assume the path for the empty -I is "-D__KERNEL__"
and we looses the -D__KERNEL__ definition - not good.

But why had we not seen this before?
Before it looked like this:
-I/full/path/ -I -Wall
so in the old case we lost the "-Wall" option.

But as this bug only manifest itself when building the module.mod.o
file then it is of no importance and not something I need to go back
and fix in older kernels.

I will cook up a fix tomorrow if day-time job does not become night-time.

	Sam

Re: linux-next: kbuild tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 290 bytes --]

Hi Sam,

On Wed, 26 Nov 2008 22:06:57 +0100 Sam Ravnborg <sam@ravnborg.org> wrote:
>
> I will cook up a fix tomorrow if day-time job does not become night-time.

OK, thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: kbuild tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

Hi Sam,

On Wed, 26 Nov 2008 22:06:57 +0100 Sam Ravnborg <sam@ravnborg.org> wrote:
>
> On Wed, Nov 26, 2008 at 03:42:06PM +1100, Stephen Rothwell wrote:
> > Hi Sam,
> > 
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > 
> > In file included from arch/x86/include/asm/processor.h:15,
> >                  from include/linux/prefetch.h:14,
> >                  from include/linux/list.h:6,
> >                  from include/linux/module.h:9,
> >                  from kernel/configs.mod.c:1:
> > arch/x86/include/asm/current.h:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'struct'
> > 
> > and went rapidly down hill from there.
> 
> I will cook up a fix tomorrow if day-time job does not become night-time.

I am still getting the same errors ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: kbuild tree build failure

[Sam Ravnborg]

On Wed, Dec 03, 2008 at 11:36:50AM +1100, Stephen Rothwell wrote:
> Hi Sam,
> 
> On Wed, 26 Nov 2008 22:06:57 +0100 Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > On Wed, Nov 26, 2008 at 03:42:06PM +1100, Stephen Rothwell wrote:
> > > Hi Sam,
> > > 
> > > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > > 
> > > In file included from arch/x86/include/asm/processor.h:15,
> > >                  from include/linux/prefetch.h:14,
> > >                  from include/linux/list.h:6,
> > >                  from include/linux/module.h:9,
> > >                  from kernel/configs.mod.c:1:
> > > arch/x86/include/asm/current.h:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'struct'
> > > 
> > > and went rapidly down hill from there.
> > 
> > I will cook up a fix tomorrow if day-time job does not become night-time.
> 
> I am still getting the same errors ...
I have been concentrating (used all my spare time) on sparc unification.
Will fix this soonish.

I need to reshuffle a few patches nothing major. But it will
take me a few hours.

	Sam

linux-next: kbuild tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]

Hi Sam,

Today's linux-next build (x86_64 allmodconfig) failed like this:

In file included from arch/x86/kernel/syscall_64.c:28:
arch/x86/include/asm/unistd_64.h:665: error: array index in initializer exceeds array bounds
arch/x86/include/asm/unistd_64.h:665: error: (near initialization for 'sys_call_table')
arch/x86/include/asm/unistd_64.h:665: warning: excess elements in array initializer
arch/x86/include/asm/unistd_64.h:665: warning: (near initialization for 'sys_call_table')

Exposed by commit a2e2725541fad72416326798c2d7fa4dafb7d337 ("net:
Introduce recvmmsg socket syscall").  include/asm/asm-offsets.h did not
get updated even though arch/x86/kernel/asm-offsets.s did.  Ah,
generated/asm-offsets.h has been updated but my build tree still has the
(generated in a previous build) include/asm/asm-offsets.h which is
presumably found before the new arch/x86/include/asm/asm-offsets.h
introduced by commit fe5ff47a5d79ca99ec7e3155eb19469b44905b2c ("kbuild:
move asm-offsets.h to include/generated").

Sam, can you think of a better migration path?

I removed include/asm/asm_offsets.h from my object tree and everything
builds ok.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: kbuild tree build failure

[Sam Ravnborg]

On Wed, Oct 14, 2009 at 12:20:24PM +1100, Stephen Rothwell wrote:
> Hi Sam,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> In file included from arch/x86/kernel/syscall_64.c:28:
> arch/x86/include/asm/unistd_64.h:665: error: array index in initializer exceeds array bounds
> arch/x86/include/asm/unistd_64.h:665: error: (near initialization for 'sys_call_table')
> arch/x86/include/asm/unistd_64.h:665: warning: excess elements in array initializer
> arch/x86/include/asm/unistd_64.h:665: warning: (near initialization for 'sys_call_table')
> 
> Exposed by commit a2e2725541fad72416326798c2d7fa4dafb7d337 ("net:
> Introduce recvmmsg socket syscall").  include/asm/asm-offsets.h did not
> get updated even though arch/x86/kernel/asm-offsets.s did.  Ah,
> generated/asm-offsets.h has been updated but my build tree still has the
> (generated in a previous build) include/asm/asm-offsets.h which is
> presumably found before the new arch/x86/include/asm/asm-offsets.h
> introduced by commit fe5ff47a5d79ca99ec7e3155eb19469b44905b2c ("kbuild:
> move asm-offsets.h to include/generated").
> 
> Sam, can you think of a better migration path?

I once thought of forefully removing include/asm to avoid this.
Maybe we could let "make clean" remove include/asm -
I expect this would have helped in this situation?

I'm planning to redo the serie within the next couple of weeks anyway.

	Sam

linux-next: kbuild tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

Hi Sam,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

powerpc-linux-ld:arch/powerpc/kernel/vmlinux.lds:190: syntax error

Caused by commit 59d59d97e34c6593bec43666679b28da5d583958 ("Improve
vmlinux.lds.h support for arch specific linker scripts") which was
clearly not build tested - don't do that! There is a missing \ at the end
of a line in the definition of the HEAD_SECTION macro.

I have used the version of the kbuild tree from next-20090605.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: kbuild tree build failure

[Sam Ravnborg]

On Tue, Jun 09, 2009 at 11:48:20AM +1000, Stephen Rothwell wrote:
> Hi Sam,
> 
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> powerpc-linux-ld:arch/powerpc/kernel/vmlinux.lds:190: syntax error
> 
> Caused by commit 59d59d97e34c6593bec43666679b28da5d583958 ("Improve
> vmlinux.lds.h support for arch specific linker scripts") which was
> clearly not build tested - don't do that! There is a missing \ at the end
> of a line in the definition of the HEAD_SECTION macro.
> 
> I have used the version of the kbuild tree from next-20090605.

My bad - obviously.
I will fix when the kids are sleeping (as in a few hours from now).

	Sam

Re: linux-next: kbuild tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 321 bytes --]

Hi Sam,

On Tue, 9 Jun 2009 18:15:12 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:
>
> I will fix when the kids are sleeping (as in a few hours from now).

Thanks.  I won't be needing it for about 7 hours.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: kbuild tree build failure

[Sam Ravnborg]

On Wed, Jun 10, 2009 at 02:19:59AM +1000, Stephen Rothwell wrote:
> Hi Sam,
> 
> On Tue, 9 Jun 2009 18:15:12 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > I will fix when the kids are sleeping (as in a few hours from now).
> 
> Thanks.  I won't be needing it for about 7 hours.

Fixed now (and build tested all changes this time).

Thanks,
	Sam

Re: linux-next: kbuild tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 266 bytes --]

Hi Sam,

On Tue, 9 Jun 2009 23:04:27 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Fixed now (and build tested all changes this time).

Excellent!

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: kbuild tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

Hi Sam,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

fs/nfs/nfsroot.c:400: error: __setup_str_nfs_root_setup causes a section type conflict
fs/nfs/nfsroot.c:400: error: __setup_str_nfs_root_setup causes a section type conflict

We get these occasionally on powerpc builds - Usually from
EXPORT_SYMBOLS.  Though I was hoping that using a newer compiler would
fix that (I am now compiling with gcc 4.4.0).

Direct cause is commit efbe795f5f63b74ed642e196518907355aa94bd7
("initconst adjustments").

OK, looking at the preprocessor output, I see we have a previous variable
(static match_table_t __initconst tokens) with __attribute__ ((__section__
(".init.rodata"))) but it is not const ... (This came from commit
a447c0932445f92ce6f4c1bd020f62c5097a7842 "vfs: Use const for kernel
parser table" which changed "tokens" from __initdata to __initconst.  Not
using "const" seems deliberate, but the changelog does not include enough
information as to why.)

So, I will revert the above commit for today to allow it to be "improved"
by also fixing the tokens variable definition above.  Of course there may
be other places where such mixed definitions exist.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: kbuild tree build failure

[Jan Beulich]

>>> Stephen Rothwell <sfr@canb.auug.org.au> 05.05.09 03:17 >>>
>OK, looking at the preprocessor output, I see we have a previous variable
>(static match_table_t __initconst tokens) with __attribute__ ((__section__
>(".init.rodata"))) but it is not const ... (This came from commit
>a447c0932445f92ce6f4c1bd020f62c5097a7842 "vfs: Use const for kernel
>parser table" which changed "tokens" from __initdata to __initconst.  Not
>using "const" seems deliberate, but the changelog does not include enough
>information as to why.)
>
>So, I will revert the above commit for today to allow it to be "improved"
>by also fixing the tokens variable definition above.  Of course there may
>be other places where such mixed definitions exist.

That is the downside of not folding the 'const' modifier into the __initconst
annotation. It is *always* an error to annotate something __initconst but
not also make it const.

Jan

Re: linux-next: kbuild tree build failure

[Sam Ravnborg]

On Tue, May 05, 2009 at 07:35:02AM +0100, Jan Beulich wrote:
> >>> Stephen Rothwell <sfr@canb.auug.org.au> 05.05.09 03:17 >>>
> >OK, looking at the preprocessor output, I see we have a previous variable
> >(static match_table_t __initconst tokens) with __attribute__ ((__section__
> >(".init.rodata"))) but it is not const ... (This came from commit
> >a447c0932445f92ce6f4c1bd020f62c5097a7842 "vfs: Use const for kernel
> >parser table" which changed "tokens" from __initdata to __initconst.  Not
> >using "const" seems deliberate, but the changelog does not include enough
> >information as to why.)
> >
> >So, I will revert the above commit for today to allow it to be "improved"
> >by also fixing the tokens variable definition above.  Of course there may
> >be other places where such mixed definitions exist.
> 
> That is the downside of not folding the 'const' modifier into the __initconst
> annotation. It is *always* an error to annotate something __initconst but
> not also make it const.

But if we folded const in __initconst would this be correct:

drivers/net/eql.c:static const char version[] __initconst =

?

It is now:
static const char version[] = ...

And will become:
static char version[] const =

gcc does not like the latter:
$ cat jan.c:
static const char version[]  = "oldstuff";
static char version2[] const = "newstuff";

void foo(const char bar[])
{
}

void baz()
{
        foo(version);
        foo(version2);
}
$ gcc jan.c:
jan.c:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'const'
jan.c: In function 'baz':
jan.c:11: error: 'version2' undeclared (first use in this function)
jan.c:11: error: (Each undeclared identifier is reported only once
jan.c:11: error: for each function it appears in.)

	Sam

Re: linux-next: kbuild tree build failure

[Jan Beulich]

>>> Sam Ravnborg <sam@ravnborg.org> 05.05.09 08:43 >>>
>On Tue, May 05, 2009 at 07:35:02AM +0100, Jan Beulich wrote:
>> That is the downside of not folding the 'const' modifier into the __initconst
>> annotation. It is *always* an error to annotate something __initconst but
>> not also make it const.
>
>But if we folded const in __initconst would this be correct:
>
>drivers/net/eql.c:static const char version[] __initconst =

No, of course not. __initconst would need to go in the place where const
is now. My original patch (from really long ago) did this, but you didn't like
that combination. Changing to such a model now (where we already have
quite a number of uses of __initconst) is certainly going to be painful, so
I'm not sure it's worth it. And if you would think now we should
nevertheless convert, we'd have to first check whether declarations of
more than one variable with a single declaration works with all supported
gcc versions (since there are a number of caveats with how __attribute__()
annotations are handled depending on their placement) - it may well be
that there would need to be a one-variable-per-declaration constraint on
users of __initconst & Co.

Jan

linux-next: kbuild tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]

Hi Sam,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

WARNING: modpost: Found 11 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
.tmp_kallsyms1.S:1:23: error: asm/types.h: No such file or directory

I have dropped the kbuild tree for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: kbuild tree build failure

[Sam Ravnborg]

On Tue, Nov 25, 2008 at 03:47:05PM +1100, Stephen Rothwell wrote:
> Hi Sam,
> 
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> WARNING: modpost: Found 11 section mismatch(es).
> To see full details build your kernel with:
> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> .tmp_kallsyms1.S:1:23: error: asm/types.h: No such file or directory
> 
> I have dropped the kbuild tree for today.

Fixed.

	Sam

Re: linux-next: kbuild tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 652 bytes --]

Hi Sam,

On Tue, 25 Nov 2008 09:42:26 +0100 Sam Ravnborg <sam@ravnborg.org> wrote:
>
> On Tue, Nov 25, 2008 at 03:47:05PM +1100, Stephen Rothwell wrote:
> > 
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > 
> > WARNING: modpost: Found 11 section mismatch(es).
> > To see full details build your kernel with:
> > 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> > .tmp_kallsyms1.S:1:23: error: asm/types.h: No such file or directory
> > 
> > I have dropped the kbuild tree for today.
> 
> Fixed.

Thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: kbuild tree build failure

[Milton Miller]

In-Reply-To: <Pine.LNX.4.64.0807101654080.6791@localhost.localdomain>

On Fri Jul 11 00:59:25 EST 2008, Roman Zippel wrote:
> On Thu, 10 Jul 2008, Michael Ellerman wrote:
>
> > Well yes :)  But I think that's because you're thinking of
> > "end-users" and I'm thinking of "users" like myself - ie. _I_ use
> > Kconfig and I do expect myself to be able to type a 64-bit address.
>
> That doesn't really answer my question, why you need this.
>
> > > > --- .config.orig  2008-07-08 09:30:00.000000000 +1000
> > > > +++ .config       2008-07-08 09:30:43.000000000 +1000
> > > > @@ -370,9 +370,8 @@
> > > >  CONFIG_HOTPLUG_PCI_RPA=m
> > > >  CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
> > > >  # CONFIG_HAS_RAPIDIO is not set
> > > > -CONFIG_PAGE_OFFSET=0xc000000000000000
> > > > -CONFIG_KERNEL_START=0xc000000002000000
> > > > -CONFIG_PHYSICAL_START=0x02000000
> > > > +CONFIG_PAGE_OFFSET=0xc0000000
> > > > +CONFIG_PHYSICAL_START=0x2000000
> > >
> > > Why is this worse? These are constants, you're not supposed to 
> change them
> > > anyway.
> > > The remaining values are generated in page.h and should be the 
> same as
> > > before. If that isn't the case and this patch produces a nonworking
> > > kernel, I'd like to hear about it.
> >
> > You're right the built kernel is fine. So it's not a bug,
>

But its horrible code.

> Good, could someone please ack whether the powerpc changes are 
> acceptable?
>

Well, since no one else has said it,
NAK

The primary reason I object is this:
>>>> Index: linux-2.6/include/asm-powerpc/page.h
>>>> ===================================================================
>>>> --- linux-2.6.orig/include/asm-powerpc/page.h
>>>> +++ linux-2.6/include/asm-powerpc/page.h
>>>> @@ -67,9 +67,15 @@
>>>>   * If you want to test if something's a kernel address, use 
>>>> is_kernel_addr().
>>>>   */
>>>>
>>>> -#define KERNELBASE      ASM_CONST(CONFIG_KERNEL_START)
>>>> +#ifdef CONFIG_PPC64
>>>> +#define PAGE_OFFSET    (ASM_CONST(CONFIG_PAGE_OFFSET) << 32)
>>>> +#define KERNELBASE     
>>>> (PAGE_OFFSET+ASM_CONST(CONFIG_PHYSICAL_START))
>>>> +#define LOAD_OFFSET    PAGE_OFFSET
>>>> +#else
>>>> +#define KERNELBASE     ASM_CONST(CONFIG_KERNEL_START)
>>>>  #define PAGE_OFFSET    ASM_CONST(CONFIG_PAGE_OFFSET)
>>>> -#define LOAD_OFFSET    
>>>> ASM_CONST((CONFIG_KERNEL_START-CONFIG_PHYSICAL_START))
>>>> +#define LOAD_OFFSET    
>>>> (ASM_CONST(CONFIG_KERNEL_START)-ASM_CONST(CONFIG_PHYSICAL_START))
>>>> +#endif
>>>>
>>>>  #if defined(CONFIG_RELOCATABLE) && defined(CONFIG_FLATMEM)
>>>>  #ifndef __ASSEMBLY__

(1) #define PAGE_OFFSET    (ASM_CONST(CONFIG_PAGE_OFFSET) << 32)

It creates unreadable code, where two defines with almost the same name 
(the only difference being
the CONFIG_ prefix, which is often ignored when scanning) contains 
radically different values.

(2)  #define PAGE_OFFSET    ASM_CONST(CONFIG_PAGE_OFFSET)

It creates config variables that mean different things depending on 
other config variables
The 32 and 64 bit powerpc kernel share a common source, a config 
variable should be used for
only one purpose.



> > but I think it is nicer to have the real values in the .config.
>
> Why?

Mostly consistency between the different portions of the archticture.

As I remember, this code was adjusted and some of the defines moved 
from page.h
as part of the 32 bit relocatable kernel for 85xx booke ASMP support.

The 32 bit kernel has advanced options to change the VMA split, which 
enable
direct user input when explicitly defined.  That allows us to not need 
patches
for the embedded boards who need some other split than 3G/1G.  So there
is the reason that we have this directly specified in Kconfig at all.

While the 64 bit kernel doesn't need to actually change the page 
offset, as we
don't support the full 64 bits of the real address anyways (in fact, the
archtiecture prevents us from doing so) and therefore don't need to 
adjust
the effective address spilt between user and kernel.

But introducing config variables that mean different things is 
UNMAINTAINABLE.

Also, I remember, CONFIG_PAGE_OFFSET is used by the linker script and 
previously
page.h was conditionally included.   Does it always include page.h now?



On a seperate note,
>>>>  config PINT3_ASSIGN
>>>>         hex "PINT3_ASSIGN"
>>>>         depends on PINTx_REASSIGN
>>>> -       default 0x02020303
>>>> +       default 0x2020303

is harder to read.   The value is a list of 4 1 byte values, but you 
have hidden the first nibble making parsing the rest of the value hard.

>>>>
>>>>  config IRAM_SIZE
>>>>         hex "Internal memory size (hex)"
>>>>         depends on (CHIP_M32700 || CHIP_M32102 || CHIP_VDEC2 || 
>>>> CHIP_OPSP || CHIP_M32104) && DISCONTIGMEM
>>>> -       default "00080000" if CHIP_M32700
>>>> -       default "00010000" if CHIP_M32102 || CHIP_OPSP || 
>>>> CHIP_M32104
>>>> -       default "00008000" if CHIP_VDEC2
>>>> +       default "0x80000" if CHIP_M32700
>>>> +       default "0x10000" if CHIP_M32102 || CHIP_OPSP || CHIP_M32104
>>>> +       default "0x8000" if CHIP_VDEC2

Likewize, I find it easier to mentally check the order of magnitude and 
compare sizes when they have
leading zeros and are right aligned.


Going to another email in the thread,

On Fri Jul 11 00:52:25 EST 2008, Roman Zippel wrpte:
> On Tue, 8 Jul 2008, Sam Ravnborg wrote:
> > We use Kconfig for a mixture of user editable values and fixed
> > configuration values.
> > And I agree that asking the user to input a 64 bit number is not 
> usefull.
> >
> > But keeping support for 64 bit values is what I would consider
> > expected functionality.
...
> > > This would also ease on any portability issues
> > > (kconfig is compiled with the host compiler not the target 
> compiler).
> >
> > We use strtol() in a few places in symbol.c already where we do an
> > implicit conversion to int. Why did this not cause us problems 
> before?
> >
> > Is it because these code paths are only triggered when we deal with 
> ranges?
> > If so we could 'fix' strdup_type() to not use strto{,u}l() so it
> > is 64 bit clean and we are back to old behaviour.
>
> Ranges are the primary reason I made it consistent with this.
> If we really wanted to support 64bit numbers, it would create only more
> problems. First you have to make sure that on every build host (i.e 
> also
> non-Linux) strtoll() is available. Then how it should these numbers be
> represented? On 32bit these may need a 'll' postfix, but the powerpc
> example already shows, that there are different requirements, so they 
> use
> ASM_CONST for that. How should this postprecessing be integrated into
> kconfig?

I think the architectures will already do something like ASM_CONST in
their C code when its needed.  This should not be the responsibility of
kbuild.

If you are worried about users tring to set values that are too high,
then make the types be hex8, hex16, hex32, and hex64.

milton

Re: linux-next: kbuild tree build failure

[Milton Miller]

In-Reply-To: <Pine.LNX.4.64.0807101654080.6791@localhost.localdomain>

On Fri Jul 11 00:59:25 EST 2008, Roman Zippel wrote:
> On Thu, 10 Jul 2008, Michael Ellerman wrote:
>
> > Well yes :)  But I think that's because you're thinking of
> > "end-users" and I'm thinking of "users" like myself - ie. _I_ use
> > Kconfig and I do expect myself to be able to type a 64-bit address.
>
> That doesn't really answer my question, why you need this.
>
> > > > --- .config.orig  2008-07-08 09:30:00.000000000 +1000
> > > > +++ .config       2008-07-08 09:30:43.000000000 +1000
> > > > @@ -370,9 +370,8 @@
> > > >  CONFIG_HOTPLUG_PCI_RPA=m
> > > >  CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
> > > >  # CONFIG_HAS_RAPIDIO is not set
> > > > -CONFIG_PAGE_OFFSET=0xc000000000000000
> > > > -CONFIG_KERNEL_START=0xc000000002000000
> > > > -CONFIG_PHYSICAL_START=0x02000000
> > > > +CONFIG_PAGE_OFFSET=0xc0000000
> > > > +CONFIG_PHYSICAL_START=0x2000000
> > >
> > > Why is this worse? These are constants, you're not supposed to 
> change them
> > > anyway.
> > > The remaining values are generated in page.h and should be the 
> same as
> > > before. If that isn't the case and this patch produces a nonworking
> > > kernel, I'd like to hear about it.
> >
> > You're right the built kernel is fine. So it's not a bug,
>

But its horrible code.

> Good, could someone please ack whether the powerpc changes are 
> acceptable?
>

Well, since no one else has said it,
NAK

The primary reason I object is this:
>>>> Index: linux-2.6/include/asm-powerpc/page.h
>>>> ===================================================================
>>>> --- linux-2.6.orig/include/asm-powerpc/page.h
>>>> +++ linux-2.6/include/asm-powerpc/page.h
>>>> @@ -67,9 +67,15 @@
>>>>   * If you want to test if something's a kernel address, use 
>>>> is_kernel_addr().
>>>>   */
>>>>
>>>> -#define KERNELBASE      ASM_CONST(CONFIG_KERNEL_START)
>>>> +#ifdef CONFIG_PPC64
>>>> +#define PAGE_OFFSET    (ASM_CONST(CONFIG_PAGE_OFFSET) << 32)
>>>> +#define KERNELBASE     
>>>> (PAGE_OFFSET+ASM_CONST(CONFIG_PHYSICAL_START))
>>>> +#define LOAD_OFFSET    PAGE_OFFSET
>>>> +#else
>>>> +#define KERNELBASE     ASM_CONST(CONFIG_KERNEL_START)
>>>>  #define PAGE_OFFSET    ASM_CONST(CONFIG_PAGE_OFFSET)
>>>> -#define LOAD_OFFSET    
>>>> ASM_CONST((CONFIG_KERNEL_START-CONFIG_PHYSICAL_START))
>>>> +#define LOAD_OFFSET    
>>>> (ASM_CONST(CONFIG_KERNEL_START)-ASM_CONST(CONFIG_PHYSICAL_START))
>>>> +#endif
>>>>
>>>>  #if defined(CONFIG_RELOCATABLE) && defined(CONFIG_FLATMEM)
>>>>  #ifndef __ASSEMBLY__

(1) #define PAGE_OFFSET    (ASM_CONST(CONFIG_PAGE_OFFSET) << 32)

It creates unreadable code, where two defines with almost the same name 
(the only difference being
the CONFIG_ prefix, which is often ignored when scanning) contains 
radically different values.

(2)  #define PAGE_OFFSET    ASM_CONST(CONFIG_PAGE_OFFSET)

It creates config variables that mean different things depending on 
other config variables
The 32 and 64 bit powerpc kernel share a common source, a config 
variable should be used for
only one purpose.



> > but I think it is nicer to have the real values in the .config.
>
> Why?

Mostly consistency between the different portions of the archticture.

As I remember, this code was adjusted and some of the defines moved 
from page.h
as part of the 32 bit relocatable kernel for 85xx booke ASMP support.

The 32 bit kernel has advanced options to change the VMA split, which 
enable
direct user input when explicitly defined.  That allows us to not need 
patches
for the embedded boards who need some other split than 3G/1G.  So there
is the reason that we have this directly specified in Kconfig at all.

While the 64 bit kernel doesn't need to actually change the page 
offset, as we
don't support the full 64 bits of the real address anyways (in fact, the
archtiecture prevents us from doing so) and therefore don't need to 
adjust
the effective address spilt between user and kernel.

But introducing config variables that mean different things is 
UNMAINTAINABLE.

Also, I remember, CONFIG_PAGE_OFFSET is used by the linker script and 
previously
page.h was conditionally included.   Does it always include page.h now?



On a seperate note,
>>>>  config PINT3_ASSIGN
>>>>         hex "PINT3_ASSIGN"
>>>>         depends on PINTx_REASSIGN
>>>> -       default 0x02020303
>>>> +       default 0x2020303

is harder to read.   The value is a list of 4 1 byte values, but you 
have hidden the first nibble making parsing the rest of the value hard.

>>>>
>>>>  config IRAM_SIZE
>>>>         hex "Internal memory size (hex)"
>>>>         depends on (CHIP_M32700 || CHIP_M32102 || CHIP_VDEC2 || 
>>>> CHIP_OPSP || CHIP_M32104) && DISCONTIGMEM
>>>> -       default "00080000" if CHIP_M32700
>>>> -       default "00010000" if CHIP_M32102 || CHIP_OPSP || 
>>>> CHIP_M32104
>>>> -       default "00008000" if CHIP_VDEC2
>>>> +       default "0x80000" if CHIP_M32700
>>>> +       default "0x10000" if CHIP_M32102 || CHIP_OPSP || CHIP_M32104
>>>> +       default "0x8000" if CHIP_VDEC2

Likewize, I find it easier to mentally check the order of magnitude and 
compare sizes when they have
leading zeros and are right aligned.


Going to another email in the thread,

On Fri Jul 11 00:52:25 EST 2008, Roman Zippel wrpte:
> On Tue, 8 Jul 2008, Sam Ravnborg wrote:
> > We use Kconfig for a mixture of user editable values and fixed
> > configuration values.
> > And I agree that asking the user to input a 64 bit number is not 
> usefull.
> >
> > But keeping support for 64 bit values is what I would consider
> > expected functionality.
...
> > > This would also ease on any portability issues
> > > (kconfig is compiled with the host compiler not the target 
> compiler).
> >
> > We use strtol() in a few places in symbol.c already where we do an
> > implicit conversion to int. Why did this not cause us problems 
> before?
> >
> > Is it because these code paths are only triggered when we deal with 
> ranges?
> > If so we could 'fix' strdup_type() to not use strto{,u}l() so it
> > is 64 bit clean and we are back to old behaviour.
>
> Ranges are the primary reason I made it consistent with this.
> If we really wanted to support 64bit numbers, it would create only more
> problems. First you have to make sure that on every build host (i.e 
> also
> non-Linux) strtoll() is available. Then how it should these numbers be
> represented? On 32bit these may need a 'll' postfix, but the powerpc
> example already shows, that there are different requirements, so they 
> use
> ASM_CONST for that. How should this postprecessing be integrated into
> kconfig?

I think the architectures will already do something like ASM_CONST in
their C code when its needed.  This should not be the responsibility of
kbuild.

If you are worried about users tring to set values that are too high,
then make the types be hex8, hex16, hex32, and hex64.

milton

Re: linux-next: kbuild tree build failure

[Roman Zippel]

Hi,

On Sat, 12 Jul 2008, Milton Miller wrote:

> (1) #define PAGE_OFFSET    (ASM_CONST(CONFIG_PAGE_OFFSET) << 32)
> 
> It creates unreadable code, where two defines with almost the same name (the
> only difference being
> the CONFIG_ prefix, which is often ignored when scanning) contains radically
> different values.
> 
> (2)  #define PAGE_OFFSET    ASM_CONST(CONFIG_PAGE_OFFSET)

Giving it different names is not really difficult. Any objections to 
CONFIG_PAGE_HIGH_OFFSET?

> On a seperate note,
> > > > >  config PINT3_ASSIGN
> > > > >         hex "PINT3_ASSIGN"
> > > > >         depends on PINTx_REASSIGN
> > > > > -       default 0x02020303
> > > > > +       default 0x2020303
> 
> is harder to read.   The value is a list of 4 1 byte values, but you have
> hidden the first nibble making parsing the rest of the value hard.

Sam mentioned that already, but that's a situation where the warning can 
be relaxed.

> If you are worried about users tring to set values that are too high,
> then make the types be hex8, hex16, hex32, and hex64.

It's not this, I value consistency as much as you and the values are 
sometimes used as integers, so a working range is needed. Using simple 
integers keeps things much simpler and as the ASM_CONST example shows any 
bigger values are not necessarily directly usable anyway.

bye, Roman

Re: linux-next: kbuild tree build failure

[Roman Zippel]

Hi,

On Sat, 12 Jul 2008, Milton Miller wrote:

> (1) #define PAGE_OFFSET    (ASM_CONST(CONFIG_PAGE_OFFSET) << 32)
> 
> It creates unreadable code, where two defines with almost the same name (the
> only difference being
> the CONFIG_ prefix, which is often ignored when scanning) contains radically
> different values.
> 
> (2)  #define PAGE_OFFSET    ASM_CONST(CONFIG_PAGE_OFFSET)

Giving it different names is not really difficult. Any objections to 
CONFIG_PAGE_HIGH_OFFSET?

> On a seperate note,
> > > > >  config PINT3_ASSIGN
> > > > >         hex "PINT3_ASSIGN"
> > > > >         depends on PINTx_REASSIGN
> > > > > -       default 0x02020303
> > > > > +       default 0x2020303
> 
> is harder to read.   The value is a list of 4 1 byte values, but you have
> hidden the first nibble making parsing the rest of the value hard.

Sam mentioned that already, but that's a situation where the warning can 
be relaxed.

> If you are worried about users tring to set values that are too high,
> then make the types be hex8, hex16, hex32, and hex64.

It's not this, I value consistency as much as you and the values are 
sometimes used as integers, so a working range is needed. Using simple 
integers keeps things much simpler and as the ASM_CONST example shows any 
bigger values are not necessarily directly usable anyway.

bye, Roman

linux-next: kbuild tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]

Hi Sam,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

arch/powerpc/platforms/cell/spu_base.c: In function '__spu_trap_data_seg':
arch/powerpc/platforms/cell/spu_base.c:194: error: duplicate case value
arch/powerpc/platforms/cell/spu_base.c:177: error: previously used here

This means that USER_REGION_ID (line 177) is the same as KERNEL_REGION_ID
(line 194).

>From include/asm-powerpc/pgtable-ppc64.h:

#define REGION_SHIFT            60UL
#define REGION_MASK             (0xfUL << REGION_SHIFT)
#define REGION_ID(ea)           (((unsigned long)(ea)) >> REGION_SHIFT)

#define VMALLOC_REGION_ID       (REGION_ID(VMALLOC_START))
#define KERNEL_REGION_ID        (REGION_ID(PAGE_OFFSET))
#define VMEMMAP_REGION_ID       (0xfUL)
#define USER_REGION_ID          (0UL)

>From include/asm-powerpc/page.h:

#define PAGE_OFFSET     ASM_CONST(CONFIG_PAGE_OFFSET)

>From .config:

CONFIG_PAGE_OFFSET=0xffffffff

Not good.

>From arch/powerpc/Kconfig (ADVANCED_OPTIONS is not set):

config PAGE_OFFSET_BOOL
        bool "Set custom page offset address"
        depends on ADVANCED_OPTIONS

config PAGE_OFFSET
        hex "Virtual address of memory base" if PAGE_OFFSET_BOOL
        default "0xc0000000"

if PPC64
config PAGE_OFFSET
        hex
        default "0xc000000000000000"
endif

Reverting commit 9ba4ff5059e1a26698786373c8c71321c37ef7f9 ("kconfig:
normalize int/hex values") seems to have fixed it.

>From .config:

CONFIG_PAGE_OFFSET=0xc000000000000000

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: kbuild tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]

Hi Sam,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

arch/powerpc/platforms/cell/spu_base.c: In function '__spu_trap_data_seg':
arch/powerpc/platforms/cell/spu_base.c:194: error: duplicate case value
arch/powerpc/platforms/cell/spu_base.c:177: error: previously used here

This means that USER_REGION_ID (line 177) is the same as KERNEL_REGION_ID
(line 194).

>From include/asm-powerpc/pgtable-ppc64.h:

#define REGION_SHIFT            60UL
#define REGION_MASK             (0xfUL << REGION_SHIFT)
#define REGION_ID(ea)           (((unsigned long)(ea)) >> REGION_SHIFT)

#define VMALLOC_REGION_ID       (REGION_ID(VMALLOC_START))
#define KERNEL_REGION_ID        (REGION_ID(PAGE_OFFSET))
#define VMEMMAP_REGION_ID       (0xfUL)
#define USER_REGION_ID          (0UL)

>From include/asm-powerpc/page.h:

#define PAGE_OFFSET     ASM_CONST(CONFIG_PAGE_OFFSET)

>From .config:

CONFIG_PAGE_OFFSET=0xffffffff

Not good.

>From arch/powerpc/Kconfig (ADVANCED_OPTIONS is not set):

config PAGE_OFFSET_BOOL
        bool "Set custom page offset address"
        depends on ADVANCED_OPTIONS

config PAGE_OFFSET
        hex "Virtual address of memory base" if PAGE_OFFSET_BOOL
        default "0xc0000000"

if PPC64
config PAGE_OFFSET
        hex
        default "0xc000000000000000"
endif

Reverting commit 9ba4ff5059e1a26698786373c8c71321c37ef7f9 ("kconfig:
normalize int/hex values") seems to have fixed it.

>From .config:

CONFIG_PAGE_OFFSET=0xc000000000000000

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: kbuild tree build failure

[Sam Ravnborg]

On Mon, Jul 07, 2008 at 06:40:38PM +1000, Stephen Rothwell wrote:
> Hi Sam,
> 
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> arch/powerpc/platforms/cell/spu_base.c: In function '__spu_trap_data_seg':
> arch/powerpc/platforms/cell/spu_base.c:194: error: duplicate case value
> arch/powerpc/platforms/cell/spu_base.c:177: error: previously used here
> 
> This means that USER_REGION_ID (line 177) is the same as KERNEL_REGION_ID
> (line 194).
> 
> From include/asm-powerpc/pgtable-ppc64.h:
> 
> #define REGION_SHIFT            60UL
> #define REGION_MASK             (0xfUL << REGION_SHIFT)
> #define REGION_ID(ea)           (((unsigned long)(ea)) >> REGION_SHIFT)
> 
> #define VMALLOC_REGION_ID       (REGION_ID(VMALLOC_START))
> #define KERNEL_REGION_ID        (REGION_ID(PAGE_OFFSET))
> #define VMEMMAP_REGION_ID       (0xfUL)
> #define USER_REGION_ID          (0UL)
> 
> From include/asm-powerpc/page.h:
> 
> #define PAGE_OFFSET     ASM_CONST(CONFIG_PAGE_OFFSET)
> 
> From .config:
> 
> CONFIG_PAGE_OFFSET=0xffffffff
> 
> Not good.
> 
> From arch/powerpc/Kconfig (ADVANCED_OPTIONS is not set):
> 
> config PAGE_OFFSET_BOOL
>         bool "Set custom page offset address"
>         depends on ADVANCED_OPTIONS
> 
> config PAGE_OFFSET
>         hex "Virtual address of memory base" if PAGE_OFFSET_BOOL
>         default "0xc0000000"
> 
> if PPC64
> config PAGE_OFFSET
>         hex
>         default "0xc000000000000000"
> endif
> 
> Reverting commit 9ba4ff5059e1a26698786373c8c71321c37ef7f9 ("kconfig:
> normalize int/hex values") seems to have fixed it.
> 
> From .config:
> 
> CONFIG_PAGE_OFFSET=0xc000000000000000

I see what is wrong - we use a int to hold the value above
and it does not fit.

Will fix tonight or tomorrow.

	Sam

Re: linux-next: kbuild tree build failure

[Sam Ravnborg]

On Mon, Jul 07, 2008 at 06:40:38PM +1000, Stephen Rothwell wrote:
> Hi Sam,
> 
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> arch/powerpc/platforms/cell/spu_base.c: In function '__spu_trap_data_seg':
> arch/powerpc/platforms/cell/spu_base.c:194: error: duplicate case value
> arch/powerpc/platforms/cell/spu_base.c:177: error: previously used here
> 
> This means that USER_REGION_ID (line 177) is the same as KERNEL_REGION_ID
> (line 194).
> 
> From include/asm-powerpc/pgtable-ppc64.h:
> 
> #define REGION_SHIFT            60UL
> #define REGION_MASK             (0xfUL << REGION_SHIFT)
> #define REGION_ID(ea)           (((unsigned long)(ea)) >> REGION_SHIFT)
> 
> #define VMALLOC_REGION_ID       (REGION_ID(VMALLOC_START))
> #define KERNEL_REGION_ID        (REGION_ID(PAGE_OFFSET))
> #define VMEMMAP_REGION_ID       (0xfUL)
> #define USER_REGION_ID          (0UL)
> 
> From include/asm-powerpc/page.h:
> 
> #define PAGE_OFFSET     ASM_CONST(CONFIG_PAGE_OFFSET)
> 
> From .config:
> 
> CONFIG_PAGE_OFFSET=0xffffffff
> 
> Not good.
> 
> From arch/powerpc/Kconfig (ADVANCED_OPTIONS is not set):
> 
> config PAGE_OFFSET_BOOL
>         bool "Set custom page offset address"
>         depends on ADVANCED_OPTIONS
> 
> config PAGE_OFFSET
>         hex "Virtual address of memory base" if PAGE_OFFSET_BOOL
>         default "0xc0000000"
> 
> if PPC64
> config PAGE_OFFSET
>         hex
>         default "0xc000000000000000"
> endif
> 
> Reverting commit 9ba4ff5059e1a26698786373c8c71321c37ef7f9 ("kconfig:
> normalize int/hex values") seems to have fixed it.
> 
> From .config:
> 
> CONFIG_PAGE_OFFSET=0xc000000000000000

I see what is wrong - we use a int to hold the value above
and it does not fit.

Will fix tonight or tomorrow.

	Sam

Re: linux-next: kbuild tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 331 bytes --]

Hi Sam,

On Mon, 7 Jul 2008 14:51:38 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:
>
> I see what is wrong - we use a int to hold the value above
> and it does not fit.
> 
> Will fix tonight or tomorrow.

Thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: kbuild tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 331 bytes --]

Hi Sam,

On Mon, 7 Jul 2008 14:51:38 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:
>
> I see what is wrong - we use a int to hold the value above
> and it does not fit.
> 
> Will fix tonight or tomorrow.

Thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: kbuild tree build failure

[Roman Zippel]

Hi,

On Mon, 7 Jul 2008, Stephen Rothwell wrote:

> Hi Sam,
> 
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> arch/powerpc/platforms/cell/spu_base.c: In function '__spu_trap_data_seg':
> arch/powerpc/platforms/cell/spu_base.c:194: error: duplicate case value
> arch/powerpc/platforms/cell/spu_base.c:177: error: previously used here

I guess there also has been a kconfig warning somewhere. :)
I should have gone through all archs to test this, sorry about that.
Luckily it's only powerpc that uses 64bit values. I would prefer to 
standardize on 32bit values, as it doesn't really make sense to expect 
from the user to input full 64bit values and it's easy to generate the 
full value in a header. This would also ease on any portability issues 
(kconfig is compiled with the host compiler not the target compiler).

Below is a patch that fixes this for all archs (generated against the git 
tree). The powerpc parts need a more careful review, the rest isn't really 
critical.

bye, Roman

Fix remaining warnings generated kconfig to normalize all constant values.
Generate powerpc 64bit page offset via header instead of kconfig.

Signed-off-by: Roman Zippel <zippel@linux-m68k.org>

---
 arch/arm/Kconfig                   |    4 ++--
 arch/arm/Kconfig-nommu             |   10 +++++-----
 arch/arm/mm/Kconfig                |    4 ++--
 arch/blackfin/Kconfig              |   12 ++++++------
 arch/blackfin/mach-bf548/Kconfig   |    8 ++++----
 arch/cris/arch-v10/Kconfig         |   26 +++++++++++++-------------
 arch/cris/arch-v10/drivers/Kconfig |   14 +++++++-------
 arch/cris/arch-v32/Kconfig         |   28 ++++++++++++++--------------
 arch/cris/arch-v32/drivers/Kconfig |   30 ++++++++++++------------------
 arch/cris/arch-v32/mach-a3/Kconfig |   14 +++++++-------
 arch/cris/arch-v32/mach-fs/Kconfig |   32 ++++++++++++++++----------------
 arch/frv/Kconfig                   |    4 ++--
 arch/m32r/Kconfig                  |   36 ++++++++++++++++++------------------
 arch/powerpc/Kconfig               |   16 ++++++----------
 arch/ppc/Kconfig                   |    8 ++++----
 arch/sh/Kconfig                    |   10 +++++-----
 arch/sh/Kconfig.debug              |    2 +-
 arch/sh/mm/Kconfig                 |    6 +++---
 include/asm-powerpc/page.h         |   10 ++++++++--
 19 files changed, 135 insertions(+), 139 deletions(-)

Index: linux-2.6/arch/arm/Kconfig
===================================================================
--- linux-2.6.orig/arch/arm/Kconfig
+++ linux-2.6/arch/arm/Kconfig
@@ -168,7 +168,7 @@ config VECTORS_BASE
 	hex
 	default 0xffff0000 if MMU || CPU_HIGH_VECTOR
 	default DRAM_BASE if REMAP_VECTORS_TO_RAM
-	default 0x00000000
+	default 0
 	help
 	  The base address of exception vectors.
 
@@ -924,7 +924,7 @@ config XIP_KERNEL
 config XIP_PHYS_ADDR
 	hex "XIP Kernel Physical Location"
 	depends on XIP_KERNEL
-	default "0x00080000"
+	default "0x80000"
 	help
 	  This is the physical address in your flash memory the kernel will
 	  be linked for and stored to.  This address is dependent on your
Index: linux-2.6/arch/arm/Kconfig-nommu
===================================================================
--- linux-2.6.orig/arch/arm/Kconfig-nommu
+++ linux-2.6/arch/arm/Kconfig-nommu
@@ -11,23 +11,23 @@ config SET_MEM_PARAM
 
 config DRAM_BASE
 	hex '(S)DRAM Base Address' if SET_MEM_PARAM
-	default 0x00800000
+	default 0x800000
 
 config DRAM_SIZE
 	hex '(S)DRAM SIZE' if SET_MEM_PARAM
-	default 0x00800000
+	default 0x800000
 
 config FLASH_MEM_BASE
 	hex 'FLASH Base Address' if SET_MEM_PARAM
-	default 0x00400000
+	default 0x400000
 
 config FLASH_SIZE
 	hex 'FLASH Size' if SET_MEM_PARAM
-	default 0x00400000
+	default 0x400000
 
 config PROCESSOR_ID
 	hex 'Hard wire the processor ID'
-	default 0x00007700
+	default 0x7700
 	depends on !CPU_CP15
 	help
 	  If processor has no CP15 register, this processor ID is
Index: linux-2.6/arch/arm/mm/Kconfig
===================================================================
--- linux-2.6.orig/arch/arm/mm/Kconfig
+++ linux-2.6/arch/arm/mm/Kconfig
@@ -649,8 +649,8 @@ config CPU_DCACHE_DISABLE
 config CPU_DCACHE_SIZE
 	hex
 	depends on CPU_ARM740T || CPU_ARM946E
-	default 0x00001000 if CPU_ARM740T
-	default 0x00002000 # default size for ARM946E-S
+	default 0x1000 if CPU_ARM740T
+	default 0x2000 # default size for ARM946E-S
 	help
 	  Some cores are synthesizable to have various sized cache. For
 	  ARM946E-S case, it can vary from 0KB to 1MB.
Index: linux-2.6/arch/blackfin/Kconfig
===================================================================
--- linux-2.6.orig/arch/blackfin/Kconfig
+++ linux-2.6/arch/blackfin/Kconfig
@@ -819,20 +819,20 @@ endmenu
 menu "EBIU_AMBCTL Control"
 config BANK_0
 	hex "Bank 0"
-	default 0x7BB0
+	default 0x7bb0
 
 config BANK_1
 	hex "Bank 1"
-	default 0x7BB0
+	default 0x7bb0
 	default 0x5558 if BF54x
 
 config BANK_2
 	hex "Bank 2"
-	default 0x7BB0
+	default 0x7bb0
 
 config BANK_3
 	hex "Bank 3"
-	default 0x99B3
+	default 0x99b3
 endmenu
 
 config EBIU_MBSCTLVAL
@@ -843,12 +843,12 @@ config EBIU_MBSCTLVAL
 config EBIU_MODEVAL
 	hex "Flash Memory Mode Control Register"
 	depends on BF54x
-	default 1
+	default 0x1
 
 config EBIU_FCTLVAL
 	hex "Flash Memory Bank Control Register"
 	depends on BF54x
-	default 6
+	default 0x6
 endmenu
 
 #############################################################################
Index: linux-2.6/arch/blackfin/mach-bf548/Kconfig
===================================================================
--- linux-2.6.orig/arch/blackfin/mach-bf548/Kconfig
+++ linux-2.6/arch/blackfin/mach-bf548/Kconfig
@@ -304,19 +304,19 @@ config PINTx_REASSIGN
 config PINT0_ASSIGN
 	hex "PINT0_ASSIGN"
 	depends on PINTx_REASSIGN
-	default 0x00000101
+	default 0x101
 config PINT1_ASSIGN
 	hex "PINT1_ASSIGN"
 	depends on PINTx_REASSIGN
-	default 0x01010000
+	default 0x1010000
 config PINT2_ASSIGN
 	hex "PINT2_ASSIGN"
 	depends on PINTx_REASSIGN
-	default 0x07000101
+	default 0x7000101
 config PINT3_ASSIGN
 	hex "PINT3_ASSIGN"
 	depends on PINTx_REASSIGN
-	default 0x02020303
+	default 0x2020303
 
 endmenu
 
Index: linux-2.6/arch/cris/arch-v10/Kconfig
===================================================================
--- linux-2.6.orig/arch/cris/arch-v10/Kconfig
+++ linux-2.6/arch/cris/arch-v10/Kconfig
@@ -11,8 +11,8 @@ config CRIS_LOW_MAP
 config ETRAX_DRAM_VIRTUAL_BASE
 	hex
 	depends on ETRAX_ARCH_V10
-	default "c0000000" if !ETRAX100LX
-	default "60000000" if ETRAX100LX
+	default "0xc0000000" if !ETRAX100LX
+	default "0x60000000" if ETRAX100LX
 
 choice
 	prompt "Product LED port"
@@ -262,7 +262,7 @@ endchoice
 config ETRAX_DEF_R_WAITSTATES
 	hex "R_WAITSTATES"
 	depends on ETRAX_ARCH_V10
-	default "95a6"
+	default "0x95a6"
 	help
 	  Waitstates for SRAM, Flash and peripherals (not DRAM).  95f8 is a
 	  good choice for most Axis products...
@@ -270,7 +270,7 @@ config ETRAX_DEF_R_WAITSTATES
 config ETRAX_DEF_R_BUS_CONFIG
 	hex "R_BUS_CONFIG"
 	depends on ETRAX_ARCH_V10
-	default "104"
+	default "0x104"
 	help
 	  Assorted bits controlling write mode, DMA burst length etc.  104 is
 	  a good choice for most Axis products...
@@ -285,7 +285,7 @@ config ETRAX_SDRAM
 config ETRAX_DEF_R_DRAM_CONFIG
 	hex "R_DRAM_CONFIG"
 	depends on ETRAX_ARCH_V10 && !ETRAX_SDRAM
-	default "1a200040"
+	default "0x1a200040"
 	help
 	  The R_DRAM_CONFIG register specifies everything on how the DRAM
 	  chips in the system are connected to the ETRAX CPU.  This is
@@ -296,7 +296,7 @@ config ETRAX_DEF_R_DRAM_CONFIG
 config ETRAX_DEF_R_DRAM_TIMING
 	hex "R_DRAM_TIMING"
 	depends on ETRAX_ARCH_V10 && !ETRAX_SDRAM
-	default "5611"
+	default "0x5611"
 	help
 	  Different DRAM chips have different speeds.  Current Axis products
 	  use 50ns DRAM chips which can use the timing: 5611.
@@ -304,7 +304,7 @@ config ETRAX_DEF_R_DRAM_TIMING
 config ETRAX_DEF_R_SDRAM_CONFIG
 	hex "R_SDRAM_CONFIG"
 	depends on ETRAX_ARCH_V10 && ETRAX_SDRAM
-	default "d2fa7878"
+	default "0xd2fa7878"
 	help
 	  The R_SDRAM_CONFIG register specifies everything on how the SDRAM
 	  chips in the system are connected to the ETRAX CPU.  This is
@@ -315,14 +315,14 @@ config ETRAX_DEF_R_SDRAM_CONFIG
 config ETRAX_DEF_R_SDRAM_TIMING
 	hex "R_SDRAM_TIMING"
 	depends on ETRAX_ARCH_V10 && ETRAX_SDRAM
-	default "80004801"
+	default "0x80004801"
 	help
 	  Different SDRAM chips have different timing.
 
 config ETRAX_DEF_R_PORT_PA_DIR
 	hex "R_PORT_PA_DIR"
 	depends on ETRAX_ARCH_V10
-	default "1c"
+	default "0x1c"
 	help
 	  Configures the direction of general port A bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -336,7 +336,7 @@ config ETRAX_DEF_R_PORT_PA_DIR
 config ETRAX_DEF_R_PORT_PA_DATA
 	hex "R_PORT_PA_DATA"
 	depends on ETRAX_ARCH_V10
-	default "00"
+	default "0"
 	help
 	  Configures the initial data for the general port A bits.  Most
 	  products should use 00 here.
@@ -344,7 +344,7 @@ config ETRAX_DEF_R_PORT_PA_DATA
 config ETRAX_DEF_R_PORT_PB_CONFIG
 	hex "R_PORT_PB_CONFIG"
 	depends on ETRAX_ARCH_V10
-	default "00"
+	default "0"
 	help
 	  Configures the type of the general port B bits.  1 is chip select,
 	  0 is port.  Most products should use 00 here.
@@ -352,7 +352,7 @@ config ETRAX_DEF_R_PORT_PB_CONFIG
 config ETRAX_DEF_R_PORT_PB_DIR
 	hex "R_PORT_PB_DIR"
 	depends on ETRAX_ARCH_V10
-	default "00"
+	default "0"
 	help
 	  Configures the direction of general port B bits. 1 is out, 0 is in.
 	  This is often totally different depending on the product used.  Bits
@@ -365,7 +365,7 @@ config ETRAX_DEF_R_PORT_PB_DIR
 config ETRAX_DEF_R_PORT_PB_DATA
 	hex "R_PORT_PB_DATA"
 	depends on ETRAX_ARCH_V10
-	default "ff"
+	default "0xff"
 	help
 	  Configures the initial data for the general port A bits.  Most
 	  products should use FF here.
Index: linux-2.6/arch/cris/arch-v10/drivers/Kconfig
===================================================================
--- linux-2.6.orig/arch/cris/arch-v10/drivers/Kconfig
+++ linux-2.6/arch/cris/arch-v10/drivers/Kconfig
@@ -531,20 +531,20 @@ config ETRAX_GPIO
 config ETRAX_PA_BUTTON_BITMASK
 	hex "PA-buttons bitmask"
 	depends on ETRAX_GPIO
-	default "02"
+	default "0x2"
 	help
 	  This is a bitmask with information about what bits on PA that
 	  are used for buttons.
 	  Most products has a so called TEST button on PA1, if that's true
-	  use 02 here.
-	  Use 00 if there are no buttons on PA.
+	  use 0x2 here.
+	  Use 0x0 if there are no buttons on PA.
 	  If the bitmask is <> 00 a button driver will be included in the gpio
 	  driver. ETRAX general I/O support must be enabled.
 
 config ETRAX_PA_CHANGEABLE_DIR
 	hex "PA user changeable dir mask"
 	depends on ETRAX_GPIO
-	default "00"
+	default "0"
 	help
 	  This is a bitmask with information of what bits in PA that a user
 	  can change direction on using ioctl's.
@@ -554,7 +554,7 @@ config ETRAX_PA_CHANGEABLE_DIR
 config ETRAX_PA_CHANGEABLE_BITS
 	hex "PA user changeable bits mask"
 	depends on ETRAX_GPIO
-	default "FF"
+	default "0xff"
 	help
 	  This is a bitmask with information of what bits in PA that a user
 	  can change the value on using ioctl's.
@@ -564,7 +564,7 @@ config ETRAX_PA_CHANGEABLE_BITS
 config ETRAX_PB_CHANGEABLE_DIR
 	hex "PB user changeable dir mask"
 	depends on ETRAX_GPIO
-	default "00"
+	default "0"
 	help
 	  This is a bitmask with information of what bits in PB that a user
 	  can change direction on using ioctl's.
@@ -574,7 +574,7 @@ config ETRAX_PB_CHANGEABLE_DIR
 config ETRAX_PB_CHANGEABLE_BITS
 	hex "PB user changeable bits mask"
 	depends on ETRAX_GPIO
-	default "FF"
+	default "0xff"
 	help
 	  This is a bitmask with information of what bits in PB that a user
 	  can change the value on using ioctl's.
Index: linux-2.6/arch/cris/arch-v32/Kconfig
===================================================================
--- linux-2.6.orig/arch/cris/arch-v32/Kconfig
+++ linux-2.6/arch/cris/arch-v32/Kconfig
@@ -8,7 +8,7 @@ source drivers/cpufreq/Kconfig
 config ETRAX_DRAM_VIRTUAL_BASE
 	hex
 	depends on ETRAX_ARCH_V32
-	default "c0000000"
+	default "0xc0000000"
 
 choice
 	prompt "Nbr of Ethernet LED groups"
@@ -119,7 +119,7 @@ endchoice
 config ETRAX_MEM_GRP1_CONFIG
 	hex "MEM_GRP1_CONFIG"
 	depends on ETRAX_ARCH_V32
-	default "4044a"
+	default "0x4044a"
 	help
 	  Waitstates for flash. The default value is suitable for the
 	  standard flashes used in axis products (120 ns).
@@ -150,7 +150,7 @@ config ETRAX_MEM_GRP4_CONFIG
 config ETRAX_SDRAM_GRP0_CONFIG
 	hex "SDRAM_GRP0_CONFIG"
 	depends on ETRAX_ARCH_V32
-	default "336"
+	default "0x336"
 	help
 	  SDRAM configuration for group 0. The value depends on the
 	  hardware configuration. The default value is suitable
@@ -170,7 +170,7 @@ config ETRAX_SDRAM_GRP1_CONFIG
 config ETRAX_SDRAM_TIMING
 	hex "SDRAM_TIMING"
 	depends on ETRAX_ARCH_V32
-	default "104a"
+	default "0x104a"
 	help
 	  SDRAM timing parameters. The default value is ok for
 	  most hardwares but large SDRAMs may require a faster
@@ -189,7 +189,7 @@ config ETRAX_SDRAM_COMMAND
 config ETRAX_DEF_GIO_PA_OE
 	hex "GIO_PA_OE"
 	depends on ETRAX_ARCH_V32
-	default "1c"
+	default "0x1c"
 	help
 	  Configures the direction of general port A bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -203,7 +203,7 @@ config ETRAX_DEF_GIO_PA_OE
 config ETRAX_DEF_GIO_PA_OUT
 	hex "GIO_PA_OUT"
 	depends on ETRAX_ARCH_V32
-	default "00"
+	default "0"
 	help
 	  Configures the initial data for the general port A bits.  Most
 	  products should use 00 here.
@@ -211,7 +211,7 @@ config ETRAX_DEF_GIO_PA_OUT
 config ETRAX_DEF_GIO_PB_OE
 	hex "GIO_PB_OE"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the direction of general port B bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -225,7 +225,7 @@ config ETRAX_DEF_GIO_PB_OE
 config ETRAX_DEF_GIO_PB_OUT
 	hex "GIO_PB_OUT"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the initial data for the general port B bits.  Most
 	  products should use 00000 here.
@@ -233,7 +233,7 @@ config ETRAX_DEF_GIO_PB_OUT
 config ETRAX_DEF_GIO_PC_OE
 	hex "GIO_PC_OE"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the direction of general port C bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -247,7 +247,7 @@ config ETRAX_DEF_GIO_PC_OE
 config ETRAX_DEF_GIO_PC_OUT
 	hex "GIO_PC_OUT"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the initial data for the general port C bits.  Most
 	  products should use 00000 here.
@@ -255,7 +255,7 @@ config ETRAX_DEF_GIO_PC_OUT
 config ETRAX_DEF_GIO_PD_OE
 	hex "GIO_PD_OE"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the direction of general port D bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -269,7 +269,7 @@ config ETRAX_DEF_GIO_PD_OE
 config ETRAX_DEF_GIO_PD_OUT
 	hex "GIO_PD_OUT"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the initial data for the general port D bits.  Most
 	  products should use 00000 here.
@@ -277,7 +277,7 @@ config ETRAX_DEF_GIO_PD_OUT
 config ETRAX_DEF_GIO_PE_OE
 	hex "GIO_PE_OE"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the direction of general port E bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -291,7 +291,7 @@ config ETRAX_DEF_GIO_PE_OE
 config ETRAX_DEF_GIO_PE_OUT
 	hex "GIO_PE_OUT"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the initial data for the general port E bits.  Most
 	  products should use 00000 here.
Index: linux-2.6/arch/cris/arch-v32/drivers/Kconfig
===================================================================
--- linux-2.6.orig/arch/cris/arch-v32/drivers/Kconfig
+++ linux-2.6/arch/cris/arch-v32/drivers/Kconfig
@@ -513,8 +513,7 @@ config ETRAX_VIRTUAL_GPIO_INTERRUPT_PA_P
 config ETRAX_PA_CHANGEABLE_DIR
 	hex "PA user changeable dir mask"
 	depends on ETRAX_GPIO
-	default "0x00" if ETRAXFS
-	default "0x00000000" if !ETRAXFS
+	default "0"
 	help
 	  This is a bitmask (8 bits) with information of what bits in PA that a
 	  user can change direction on using ioctl's.
@@ -524,8 +523,7 @@ config ETRAX_PA_CHANGEABLE_DIR
 config ETRAX_PA_CHANGEABLE_BITS
 	hex "PA user changeable bits mask"
 	depends on ETRAX_GPIO
-	default "0x00" if ETRAXFS
-	default "0x00000000" if !ETRAXFS
+	default "0"
 	help
 	  This is a bitmask (8 bits) with information of what bits in PA
 	  that a user can change the value on using ioctl's.
@@ -534,8 +532,7 @@ config ETRAX_PA_CHANGEABLE_BITS
 config ETRAX_PB_CHANGEABLE_DIR
 	hex "PB user changeable dir mask"
 	depends on ETRAX_GPIO
-	default "0x00000" if ETRAXFS
-	default "0x00000000" if !ETRAXFS
+	default "0"
 	help
 	  This is a bitmask (18 bits) with information of what bits in PB
 	  that a user can change direction on using ioctl's.
@@ -545,8 +542,7 @@ config ETRAX_PB_CHANGEABLE_DIR
 config ETRAX_PB_CHANGEABLE_BITS
 	hex "PB user changeable bits mask"
 	depends on ETRAX_GPIO
-	default "0x00000" if ETRAXFS
-	default "0x00000000" if !ETRAXFS
+	default "0"
 	help
 	  This is a bitmask (18 bits) with information of what bits in PB
 	  that a user can change the value on using ioctl's.
@@ -555,8 +551,7 @@ config ETRAX_PB_CHANGEABLE_BITS
 config ETRAX_PC_CHANGEABLE_DIR
 	hex "PC user changeable dir mask"
 	depends on ETRAX_GPIO
-	default "0x00000" if ETRAXFS
-	default "0x00000000" if !ETRAXFS
+	default "0"
 	help
 	  This is a bitmask (18 bits) with information of what bits in PC
 	  that a user can change direction on using ioctl's.
@@ -566,8 +561,7 @@ config ETRAX_PC_CHANGEABLE_DIR
 config ETRAX_PC_CHANGEABLE_BITS
 	hex "PC user changeable bits mask"
 	depends on ETRAX_GPIO
-	default "0x00000" if ETRAXFS
-	default "0x00000000" if ETRAXFS
+	default "0"
 	help
 	  This is a bitmask (18 bits) with information of what bits in PC
 	  that a user can change the value on using ioctl's.
@@ -576,7 +570,7 @@ config ETRAX_PC_CHANGEABLE_BITS
 config ETRAX_PD_CHANGEABLE_DIR
 	hex "PD user changeable dir mask"
 	depends on ETRAX_GPIO && ETRAXFS
-	default "0x00000"
+	default "0"
 	help
 	  This is a bitmask (18 bits) with information of what bits in PD
 	  that a user can change direction on using ioctl's.
@@ -586,7 +580,7 @@ config ETRAX_PD_CHANGEABLE_DIR
 config ETRAX_PD_CHANGEABLE_BITS
 	hex "PD user changeable bits mask"
 	depends on ETRAX_GPIO && ETRAXFS
-	default "0x00000"
+	default "0"
 	help
 	  This is a bitmask (18 bits) with information of what bits in PD
 	  that a user can change the value on using ioctl's.
@@ -595,7 +589,7 @@ config ETRAX_PD_CHANGEABLE_BITS
 config ETRAX_PE_CHANGEABLE_DIR
 	hex "PE user changeable dir mask"
 	depends on ETRAX_GPIO && ETRAXFS
-	default "0x00000"
+	default "0"
 	help
 	  This is a bitmask (18 bits) with information of what bits in PE
 	  that a user can change direction on using ioctl's.
@@ -605,7 +599,7 @@ config ETRAX_PE_CHANGEABLE_DIR
 config ETRAX_PE_CHANGEABLE_BITS
 	hex "PE user changeable bits mask"
  	depends on ETRAX_GPIO && ETRAXFS
-	default "0x00000"
+	default "0"
 	help
 	  This is a bitmask (18 bits) with information of what bits in PE
 	  that a user can change the value on using ioctl's.
@@ -614,7 +608,7 @@ config ETRAX_PE_CHANGEABLE_BITS
 config ETRAX_PV_CHANGEABLE_DIR
 	hex "PV user changeable dir mask"
 	depends on ETRAX_VIRTUAL_GPIO
-	default "0x0000"
+	default "0"
 	help
 	  This is a bitmask (16 bits) with information of what bits in PV
 	  that a user can change direction on using ioctl's.
@@ -624,7 +618,7 @@ config ETRAX_PV_CHANGEABLE_DIR
 config ETRAX_PV_CHANGEABLE_BITS
 	hex "PV user changeable bits mask"
 	depends on ETRAX_VIRTUAL_GPIO
-	default "0x0000"
+	default "0"
 	help
 	  This is a bitmask (16 bits) with information of what bits in PV
 	  that a user can change the value on using ioctl's.
Index: linux-2.6/arch/cris/arch-v32/mach-a3/Kconfig
===================================================================
--- linux-2.6.orig/arch/cris/arch-v32/mach-a3/Kconfig
+++ linux-2.6/arch/cris/arch-v32/mach-a3/Kconfig
@@ -5,7 +5,7 @@ menu "Artpec-3 options"
 
 config ETRAX_DRAM_VIRTUAL_BASE
 	hex
-	default "c0000000"
+	default "0xc0000000"
 
 config ETRAX_L2CACHE
        bool
@@ -47,7 +47,7 @@ config ETRAX_PIO_CE2_CFG
 
 config ETRAX_DEF_GIO_PA_OE
 	hex "GIO_PA_OE"
-	default "00000000"
+	default "0"
 	help
 	  Configures the direction of general port A bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -60,14 +60,14 @@ config ETRAX_DEF_GIO_PA_OE
 
 config ETRAX_DEF_GIO_PA_OUT
 	hex "GIO_PA_OUT"
-	default "00000000"
+	default "0"
 	help
 	  Configures the initial data for the general port A bits.  Most
 	  products should use 00 here.
 
 config ETRAX_DEF_GIO_PB_OE
 	hex "GIO_PB_OE"
-	default "000000000"
+	default "0"
 	help
 	  Configures the direction of general port B bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -80,14 +80,14 @@ config ETRAX_DEF_GIO_PB_OE
 
 config ETRAX_DEF_GIO_PB_OUT
 	hex "GIO_PB_OUT"
-	default "000000000"
+	default "0"
 	help
 	  Configures the initial data for the general port B bits.  Most
 	  products should use 00000 here.
 
 config ETRAX_DEF_GIO_PC_OE
 	hex "GIO_PC_OE"
-	default "00000"
+	default "0"
 	help
 	  Configures the direction of general port C bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -100,7 +100,7 @@ config ETRAX_DEF_GIO_PC_OE
 
 config ETRAX_DEF_GIO_PC_OUT
 	hex "GIO_PC_OUT"
-	default "00000"
+	default "0"
 	help
 	  Configures the initial data for the general port C bits.  Most
 	  products should use 00000 here.
Index: linux-2.6/arch/cris/arch-v32/mach-fs/Kconfig
===================================================================
--- linux-2.6.orig/arch/cris/arch-v32/mach-fs/Kconfig
+++ linux-2.6/arch/cris/arch-v32/mach-fs/Kconfig
@@ -6,7 +6,7 @@ menu "ETRAX FS options"
 config ETRAX_DRAM_VIRTUAL_BASE
 	hex
 	depends on ETRAX_ARCH_V32
-	default "c0000000"
+	default "0xc0000000"
 
 config ETRAX_SERIAL_PORTS
        int
@@ -15,7 +15,7 @@ config ETRAX_SERIAL_PORTS
 config ETRAX_MEM_GRP1_CONFIG
 	hex "MEM_GRP1_CONFIG"
 	depends on ETRAX_ARCH_V32
-	default "4044a"
+	default "0x4044a"
 	help
 	  Waitstates for flash. The default value is suitable for the
 	  standard flashes used in axis products (120 ns).
@@ -46,7 +46,7 @@ config ETRAX_MEM_GRP4_CONFIG
 config ETRAX_SDRAM_GRP0_CONFIG
 	hex "SDRAM_GRP0_CONFIG"
 	depends on ETRAX_ARCH_V32
-	default "336"
+	default "0x336"
 	help
 	  SDRAM configuration for group 0. The value depends on the
 	  hardware configuration. The default value is suitable
@@ -66,7 +66,7 @@ config ETRAX_SDRAM_GRP1_CONFIG
 config ETRAX_SDRAM_TIMING
 	hex "SDRAM_TIMING"
 	depends on ETRAX_ARCH_V32
-	default "104a"
+	default "0x104a"
 	help
 	  SDRAM timing parameters. The default value is ok for
 	  most hardwares but large SDRAMs may require a faster
@@ -85,7 +85,7 @@ config ETRAX_SDRAM_COMMAND
 config ETRAX_DEF_GIO_PA_OE
 	hex "GIO_PA_OE"
 	depends on ETRAX_ARCH_V32
-	default "1c"
+	default "0x1c"
 	help
 	  Configures the direction of general port A bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -99,7 +99,7 @@ config ETRAX_DEF_GIO_PA_OE
 config ETRAX_DEF_GIO_PA_OUT
 	hex "GIO_PA_OUT"
 	depends on ETRAX_ARCH_V32
-	default "00"
+	default "0"
 	help
 	  Configures the initial data for the general port A bits.  Most
 	  products should use 00 here.
@@ -107,7 +107,7 @@ config ETRAX_DEF_GIO_PA_OUT
 config ETRAX_DEF_GIO_PB_OE
 	hex "GIO_PB_OE"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the direction of general port B bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -121,7 +121,7 @@ config ETRAX_DEF_GIO_PB_OE
 config ETRAX_DEF_GIO_PB_OUT
 	hex "GIO_PB_OUT"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the initial data for the general port B bits.  Most
 	  products should use 00000 here.
@@ -129,7 +129,7 @@ config ETRAX_DEF_GIO_PB_OUT
 config ETRAX_DEF_GIO_PC_OE
 	hex "GIO_PC_OE"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the direction of general port C bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -143,7 +143,7 @@ config ETRAX_DEF_GIO_PC_OE
 config ETRAX_DEF_GIO_PC_OUT
 	hex "GIO_PC_OUT"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the initial data for the general port C bits.  Most
 	  products should use 00000 here.
@@ -151,7 +151,7 @@ config ETRAX_DEF_GIO_PC_OUT
 config ETRAX_DEF_GIO_PD_OE
 	hex "GIO_PD_OE"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the direction of general port D bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -165,7 +165,7 @@ config ETRAX_DEF_GIO_PD_OE
 config ETRAX_DEF_GIO_PD_OUT
 	hex "GIO_PD_OUT"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the initial data for the general port D bits.  Most
 	  products should use 00000 here.
@@ -173,7 +173,7 @@ config ETRAX_DEF_GIO_PD_OUT
 config ETRAX_DEF_GIO_PE_OE
 	hex "GIO_PE_OE"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the direction of general port E bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -187,7 +187,7 @@ config ETRAX_DEF_GIO_PE_OE
 config ETRAX_DEF_GIO_PE_OUT
 	hex "GIO_PE_OUT"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the initial data for the general port E bits.  Most
 	  products should use 00000 here.
@@ -195,7 +195,7 @@ config ETRAX_DEF_GIO_PE_OUT
 config ETRAX_DEF_GIO_PV_OE
 	hex "GIO_PV_OE"
 	depends on ETRAX_VIRTUAL_GPIO
-	default "0000"
+	default "0"
 	help
 	  Configures the direction of virtual general port V bits. 1 is out,
 	  0 is in. This is often totally different depending on the product
@@ -206,7 +206,7 @@ config ETRAX_DEF_GIO_PV_OE
 config ETRAX_DEF_GIO_PV_OUT
 	hex "GIO_PV_OUT"
 	depends on ETRAX_VIRTUAL_GPIO
-	default "0000"
+	default "0"
 	help
 	  Configures the initial data for the virtual general port V bits.
 	  Most products should use 0000 here.
Index: linux-2.6/arch/frv/Kconfig
===================================================================
--- linux-2.6.orig/arch/frv/Kconfig
+++ linux-2.6/arch/frv/Kconfig
@@ -149,8 +149,8 @@ config PAGE_OFFSET
 	default 0x40000000 if UCPAGE_OFFSET_40000000
 	default 0x60000000 if UCPAGE_OFFSET_60000000
 	default 0x80000000 if UCPAGE_OFFSET_80000000
-	default 0xA0000000 if UCPAGE_OFFSET_A0000000
-	default 0xC0000000
+	default 0xa0000000 if UCPAGE_OFFSET_A0000000
+	default 0xc0000000
 
 config PROTECT_KERNEL
 	bool "Protect core kernel against userspace"
Index: linux-2.6/arch/m32r/Kconfig
===================================================================
--- linux-2.6.orig/arch/m32r/Kconfig
+++ linux-2.6/arch/m32r/Kconfig
@@ -199,22 +199,22 @@ config CPU_LITTLE_ENDIAN
 
 config MEMORY_START
 	hex "Physical memory start address (hex)"
-	default "08000000" if PLAT_MAPPI || PLAT_MAPPI2 || PLAT_MAPPI3
-	default "08000000" if PLAT_USRV
-	default "08000000" if PLAT_M32700UT
-	default "08000000" if PLAT_OPSPUT
-	default "04000000" if PLAT_M32104UT
-	default "01000000" if PLAT_OAKS32R
+	default "0x8000000" if PLAT_MAPPI || PLAT_MAPPI2 || PLAT_MAPPI3
+	default "0x8000000" if PLAT_USRV
+	default "0x8000000" if PLAT_M32700UT
+	default "0x8000000" if PLAT_OPSPUT
+	default "0x4000000" if PLAT_M32104UT
+	default "0x1000000" if PLAT_OAKS32R
 
 config MEMORY_SIZE
 	hex "Physical memory size (hex)"
-	default "08000000" if PLAT_MAPPI3
-	default "04000000" if PLAT_MAPPI || PLAT_MAPPI2
-	default "02000000" if PLAT_USRV
-	default "01000000" if PLAT_M32700UT
-	default "01000000" if PLAT_OPSPUT
-	default "01000000" if PLAT_M32104UT
-	default "00800000" if PLAT_OAKS32R
+	default "0x8000000" if PLAT_MAPPI3
+	default "0x4000000" if PLAT_MAPPI || PLAT_MAPPI2
+	default "0x2000000" if PLAT_USRV
+	default "0x1000000" if PLAT_M32700UT
+	default "0x1000000" if PLAT_OPSPUT
+	default "0x1000000" if PLAT_M32104UT
+	default "0x800000" if PLAT_OAKS32R
 
 config NOHIGHMEM
 	bool
@@ -229,16 +229,16 @@ source "mm/Kconfig"
 
 config IRAM_START
 	hex "Internal memory start address (hex)"
-	default "00f00000" if !CHIP_M32104
-	default "00700000" if CHIP_M32104
+	default "0xf00000" if !CHIP_M32104
+	default "0x700000" if CHIP_M32104
 	depends on (CHIP_M32700 || CHIP_M32102 || CHIP_VDEC2 || CHIP_OPSP || CHIP_M32104) && DISCONTIGMEM
 
 config IRAM_SIZE
 	hex "Internal memory size (hex)"
 	depends on (CHIP_M32700 || CHIP_M32102 || CHIP_VDEC2 || CHIP_OPSP || CHIP_M32104) && DISCONTIGMEM
-	default "00080000" if CHIP_M32700
-	default "00010000" if CHIP_M32102 || CHIP_OPSP || CHIP_M32104
-	default "00008000" if CHIP_VDEC2
+	default "0x80000" if CHIP_M32700
+	default "0x10000" if CHIP_M32102 || CHIP_OPSP || CHIP_M32104
+	default "0x8000" if CHIP_VDEC2
 
 #
 # Define implied options from the CPU selection here
Index: linux-2.6/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/Kconfig
+++ linux-2.6/arch/powerpc/Kconfig
@@ -714,8 +714,8 @@ config PHYSICAL_START_BOOL
 
 config PHYSICAL_START
 	hex "Physical address where the kernel is loaded" if PHYSICAL_START_BOOL
-	default "0x02000000" if PPC_STD_MMU && CRASH_DUMP
-	default "0x00000000"
+	default "0x2000000" if PPC_STD_MMU && CRASH_DUMP
+	default "0"
 
 config PHYSICAL_ALIGN
 	hex
@@ -763,7 +763,7 @@ config CONSISTENT_SIZE_BOOL
 
 config CONSISTENT_SIZE
 	hex "Size of consistent memory pool" if CONSISTENT_SIZE_BOOL
-	default "0x00200000" if NOT_COHERENT_CACHE
+	default "0x200000" if NOT_COHERENT_CACHE
 
 config PIN_TLB
 	bool "Pinned Kernel TLBs (860 ONLY)"
@@ -773,15 +773,11 @@ endmenu
 if PPC64
 config PAGE_OFFSET
 	hex
-	default "0xc000000000000000"
-config KERNEL_START
-	hex
-	default "0xc000000002000000" if CRASH_DUMP
-	default "0xc000000000000000"
+	default "0xc0000000"
 config PHYSICAL_START
 	hex
-	default "0x02000000" if CRASH_DUMP
-	default "0x00000000"
+	default "0x2000000" if CRASH_DUMP
+	default "0"
 endif
 
 source "net/Kconfig"
Index: linux-2.6/arch/ppc/Kconfig
===================================================================
--- linux-2.6.orig/arch/ppc/Kconfig
+++ linux-2.6/arch/ppc/Kconfig
@@ -1120,7 +1120,7 @@ config CONSISTENT_SIZE_BOOL
 
 config CONSISTENT_SIZE
 	hex "Size of consistent memory pool" if CONSISTENT_SIZE_BOOL
-	default "0x00200000" if NOT_COHERENT_CACHE
+	default "0x200000" if NOT_COHERENT_CACHE
 
 config BOOT_LOAD_BOOL
 	bool "Set the boot link/load address"
@@ -1134,9 +1134,9 @@ config BOOT_LOAD_BOOL
 
 config BOOT_LOAD
 	hex "Link/load address for booting" if BOOT_LOAD_BOOL
-	default "0x00400000" if 40x || 8xx || 8260
-	default "0x01000000" if 44x
-	default "0x00800000"
+	default "0x400000" if 40x || 8xx || 8260
+	default "0x1000000" if 44x
+	default "0x800000"
 
 config PIN_TLB
 	bool "Pinned Kernel TLBs (860 ONLY)"
Index: linux-2.6/arch/sh/Kconfig
===================================================================
--- linux-2.6.orig/arch/sh/Kconfig
+++ linux-2.6/arch/sh/Kconfig
@@ -753,16 +753,16 @@ menu "Boot options"
 
 config ZERO_PAGE_OFFSET
 	hex "Zero page offset"
-	default "0x00004000" if SH_SH03
-	default "0x00010000" if PAGE_SIZE_64KB
-	default "0x00002000" if PAGE_SIZE_8KB
-	default "0x00001000"
+	default "0x4000" if SH_SH03
+	default "0x10000" if PAGE_SIZE_64KB
+	default "0x2000" if PAGE_SIZE_8KB
+	default "0x1000"
 	help
 	  This sets the default offset of zero page.
 
 config BOOT_LINK_OFFSET
 	hex "Link address offset for booting"
-	default "0x00800000"
+	default "0x800000"
 	help
 	  This option allows you to set the link address offset of the zImage.
 	  This can be useful if you are on a board which has a small amount of
Index: linux-2.6/arch/sh/Kconfig.debug
===================================================================
--- linux-2.6.orig/arch/sh/Kconfig.debug
+++ linux-2.6/arch/sh/Kconfig.debug
@@ -41,7 +41,7 @@ config EARLY_SCIF_CONSOLE_PORT
 	default "0xffea0000" if CPU_SUBTYPE_SH7785
 	default "0xfffe8000" if CPU_SUBTYPE_SH7203
 	default "0xfffe9800" if CPU_SUBTYPE_SH7206 || CPU_SUBTYPE_SH7263
-	default "0x00000000"
+	default "0"
 
 config EARLY_PRINTK
 	bool "Early printk support"
Index: linux-2.6/arch/sh/mm/Kconfig
===================================================================
--- linux-2.6.orig/arch/sh/mm/Kconfig
+++ linux-2.6/arch/sh/mm/Kconfig
@@ -19,11 +19,11 @@ config PAGE_OFFSET
 	hex
 	default "0x80000000" if MMU && SUPERH32
 	default "0x20000000" if MMU && SUPERH64
-	default "0x00000000"
+	default "0"
 
 config MEMORY_START
 	hex "Physical memory start address"
-	default "0x08000000"
+	default "0x8000000"
 	---help---
 	  Computers built with Hitachi SuperH processors always
 	  map the ROM starting at address zero.  But the processor
@@ -39,7 +39,7 @@ config MEMORY_START
 
 config MEMORY_SIZE
 	hex "Physical memory size"
-	default "0x04000000"
+	default "0x4000000"
 	help
 	  This sets the default memory size assumed by your SH kernel. It can
 	  be overridden as normal by the 'mem=' argument on the kernel command
Index: linux-2.6/include/asm-powerpc/page.h
===================================================================
--- linux-2.6.orig/include/asm-powerpc/page.h
+++ linux-2.6/include/asm-powerpc/page.h
@@ -67,9 +67,15 @@
  * If you want to test if something's a kernel address, use is_kernel_addr().
  */
 
-#define KERNELBASE      ASM_CONST(CONFIG_KERNEL_START)
+#ifdef CONFIG_PPC64
+#define PAGE_OFFSET	(ASM_CONST(CONFIG_PAGE_OFFSET) << 32)
+#define KERNELBASE	(PAGE_OFFSET+ASM_CONST(CONFIG_PHYSICAL_START))
+#define LOAD_OFFSET	PAGE_OFFSET
+#else
+#define KERNELBASE	ASM_CONST(CONFIG_KERNEL_START)
 #define PAGE_OFFSET	ASM_CONST(CONFIG_PAGE_OFFSET)
-#define LOAD_OFFSET	ASM_CONST((CONFIG_KERNEL_START-CONFIG_PHYSICAL_START))
+#define LOAD_OFFSET	(ASM_CONST(CONFIG_KERNEL_START)-ASM_CONST(CONFIG_PHYSICAL_START))
+#endif
 
 #if defined(CONFIG_RELOCATABLE) && defined(CONFIG_FLATMEM)
 #ifndef __ASSEMBLY__

Re: linux-next: kbuild tree build failure

[Roman Zippel]

Hi,

On Mon, 7 Jul 2008, Stephen Rothwell wrote:

> Hi Sam,
> 
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> arch/powerpc/platforms/cell/spu_base.c: In function '__spu_trap_data_seg':
> arch/powerpc/platforms/cell/spu_base.c:194: error: duplicate case value
> arch/powerpc/platforms/cell/spu_base.c:177: error: previously used here

I guess there also has been a kconfig warning somewhere. :)
I should have gone through all archs to test this, sorry about that.
Luckily it's only powerpc that uses 64bit values. I would prefer to 
standardize on 32bit values, as it doesn't really make sense to expect 
from the user to input full 64bit values and it's easy to generate the 
full value in a header. This would also ease on any portability issues 
(kconfig is compiled with the host compiler not the target compiler).

Below is a patch that fixes this for all archs (generated against the git 
tree). The powerpc parts need a more careful review, the rest isn't really 
critical.

bye, Roman

Fix remaining warnings generated kconfig to normalize all constant values.
Generate powerpc 64bit page offset via header instead of kconfig.

Signed-off-by: Roman Zippel <zippel@linux-m68k.org>

---
 arch/arm/Kconfig                   |    4 ++--
 arch/arm/Kconfig-nommu             |   10 +++++-----
 arch/arm/mm/Kconfig                |    4 ++--
 arch/blackfin/Kconfig              |   12 ++++++------
 arch/blackfin/mach-bf548/Kconfig   |    8 ++++----
 arch/cris/arch-v10/Kconfig         |   26 +++++++++++++-------------
 arch/cris/arch-v10/drivers/Kconfig |   14 +++++++-------
 arch/cris/arch-v32/Kconfig         |   28 ++++++++++++++--------------
 arch/cris/arch-v32/drivers/Kconfig |   30 ++++++++++++------------------
 arch/cris/arch-v32/mach-a3/Kconfig |   14 +++++++-------
 arch/cris/arch-v32/mach-fs/Kconfig |   32 ++++++++++++++++----------------
 arch/frv/Kconfig                   |    4 ++--
 arch/m32r/Kconfig                  |   36 ++++++++++++++++++------------------
 arch/powerpc/Kconfig               |   16 ++++++----------
 arch/ppc/Kconfig                   |    8 ++++----
 arch/sh/Kconfig                    |   10 +++++-----
 arch/sh/Kconfig.debug              |    2 +-
 arch/sh/mm/Kconfig                 |    6 +++---
 include/asm-powerpc/page.h         |   10 ++++++++--
 19 files changed, 135 insertions(+), 139 deletions(-)

Index: linux-2.6/arch/arm/Kconfig
===================================================================
--- linux-2.6.orig/arch/arm/Kconfig
+++ linux-2.6/arch/arm/Kconfig
@@ -168,7 +168,7 @@ config VECTORS_BASE
 	hex
 	default 0xffff0000 if MMU || CPU_HIGH_VECTOR
 	default DRAM_BASE if REMAP_VECTORS_TO_RAM
-	default 0x00000000
+	default 0
 	help
 	  The base address of exception vectors.
 
@@ -924,7 +924,7 @@ config XIP_KERNEL
 config XIP_PHYS_ADDR
 	hex "XIP Kernel Physical Location"
 	depends on XIP_KERNEL
-	default "0x00080000"
+	default "0x80000"
 	help
 	  This is the physical address in your flash memory the kernel will
 	  be linked for and stored to.  This address is dependent on your
Index: linux-2.6/arch/arm/Kconfig-nommu
===================================================================
--- linux-2.6.orig/arch/arm/Kconfig-nommu
+++ linux-2.6/arch/arm/Kconfig-nommu
@@ -11,23 +11,23 @@ config SET_MEM_PARAM
 
 config DRAM_BASE
 	hex '(S)DRAM Base Address' if SET_MEM_PARAM
-	default 0x00800000
+	default 0x800000
 
 config DRAM_SIZE
 	hex '(S)DRAM SIZE' if SET_MEM_PARAM
-	default 0x00800000
+	default 0x800000
 
 config FLASH_MEM_BASE
 	hex 'FLASH Base Address' if SET_MEM_PARAM
-	default 0x00400000
+	default 0x400000
 
 config FLASH_SIZE
 	hex 'FLASH Size' if SET_MEM_PARAM
-	default 0x00400000
+	default 0x400000
 
 config PROCESSOR_ID
 	hex 'Hard wire the processor ID'
-	default 0x00007700
+	default 0x7700
 	depends on !CPU_CP15
 	help
 	  If processor has no CP15 register, this processor ID is
Index: linux-2.6/arch/arm/mm/Kconfig
===================================================================
--- linux-2.6.orig/arch/arm/mm/Kconfig
+++ linux-2.6/arch/arm/mm/Kconfig
@@ -649,8 +649,8 @@ config CPU_DCACHE_DISABLE
 config CPU_DCACHE_SIZE
 	hex
 	depends on CPU_ARM740T || CPU_ARM946E
-	default 0x00001000 if CPU_ARM740T
-	default 0x00002000 # default size for ARM946E-S
+	default 0x1000 if CPU_ARM740T
+	default 0x2000 # default size for ARM946E-S
 	help
 	  Some cores are synthesizable to have various sized cache. For
 	  ARM946E-S case, it can vary from 0KB to 1MB.
Index: linux-2.6/arch/blackfin/Kconfig
===================================================================
--- linux-2.6.orig/arch/blackfin/Kconfig
+++ linux-2.6/arch/blackfin/Kconfig
@@ -819,20 +819,20 @@ endmenu
 menu "EBIU_AMBCTL Control"
 config BANK_0
 	hex "Bank 0"
-	default 0x7BB0
+	default 0x7bb0
 
 config BANK_1
 	hex "Bank 1"
-	default 0x7BB0
+	default 0x7bb0
 	default 0x5558 if BF54x
 
 config BANK_2
 	hex "Bank 2"
-	default 0x7BB0
+	default 0x7bb0
 
 config BANK_3
 	hex "Bank 3"
-	default 0x99B3
+	default 0x99b3
 endmenu
 
 config EBIU_MBSCTLVAL
@@ -843,12 +843,12 @@ config EBIU_MBSCTLVAL
 config EBIU_MODEVAL
 	hex "Flash Memory Mode Control Register"
 	depends on BF54x
-	default 1
+	default 0x1
 
 config EBIU_FCTLVAL
 	hex "Flash Memory Bank Control Register"
 	depends on BF54x
-	default 6
+	default 0x6
 endmenu
 
 #############################################################################
Index: linux-2.6/arch/blackfin/mach-bf548/Kconfig
===================================================================
--- linux-2.6.orig/arch/blackfin/mach-bf548/Kconfig
+++ linux-2.6/arch/blackfin/mach-bf548/Kconfig
@@ -304,19 +304,19 @@ config PINTx_REASSIGN
 config PINT0_ASSIGN
 	hex "PINT0_ASSIGN"
 	depends on PINTx_REASSIGN
-	default 0x00000101
+	default 0x101
 config PINT1_ASSIGN
 	hex "PINT1_ASSIGN"
 	depends on PINTx_REASSIGN
-	default 0x01010000
+	default 0x1010000
 config PINT2_ASSIGN
 	hex "PINT2_ASSIGN"
 	depends on PINTx_REASSIGN
-	default 0x07000101
+	default 0x7000101
 config PINT3_ASSIGN
 	hex "PINT3_ASSIGN"
 	depends on PINTx_REASSIGN
-	default 0x02020303
+	default 0x2020303
 
 endmenu
 
Index: linux-2.6/arch/cris/arch-v10/Kconfig
===================================================================
--- linux-2.6.orig/arch/cris/arch-v10/Kconfig
+++ linux-2.6/arch/cris/arch-v10/Kconfig
@@ -11,8 +11,8 @@ config CRIS_LOW_MAP
 config ETRAX_DRAM_VIRTUAL_BASE
 	hex
 	depends on ETRAX_ARCH_V10
-	default "c0000000" if !ETRAX100LX
-	default "60000000" if ETRAX100LX
+	default "0xc0000000" if !ETRAX100LX
+	default "0x60000000" if ETRAX100LX
 
 choice
 	prompt "Product LED port"
@@ -262,7 +262,7 @@ endchoice
 config ETRAX_DEF_R_WAITSTATES
 	hex "R_WAITSTATES"
 	depends on ETRAX_ARCH_V10
-	default "95a6"
+	default "0x95a6"
 	help
 	  Waitstates for SRAM, Flash and peripherals (not DRAM).  95f8 is a
 	  good choice for most Axis products...
@@ -270,7 +270,7 @@ config ETRAX_DEF_R_WAITSTATES
 config ETRAX_DEF_R_BUS_CONFIG
 	hex "R_BUS_CONFIG"
 	depends on ETRAX_ARCH_V10
-	default "104"
+	default "0x104"
 	help
 	  Assorted bits controlling write mode, DMA burst length etc.  104 is
 	  a good choice for most Axis products...
@@ -285,7 +285,7 @@ config ETRAX_SDRAM
 config ETRAX_DEF_R_DRAM_CONFIG
 	hex "R_DRAM_CONFIG"
 	depends on ETRAX_ARCH_V10 && !ETRAX_SDRAM
-	default "1a200040"
+	default "0x1a200040"
 	help
 	  The R_DRAM_CONFIG register specifies everything on how the DRAM
 	  chips in the system are connected to the ETRAX CPU.  This is
@@ -296,7 +296,7 @@ config ETRAX_DEF_R_DRAM_CONFIG
 config ETRAX_DEF_R_DRAM_TIMING
 	hex "R_DRAM_TIMING"
 	depends on ETRAX_ARCH_V10 && !ETRAX_SDRAM
-	default "5611"
+	default "0x5611"
 	help
 	  Different DRAM chips have different speeds.  Current Axis products
 	  use 50ns DRAM chips which can use the timing: 5611.
@@ -304,7 +304,7 @@ config ETRAX_DEF_R_DRAM_TIMING
 config ETRAX_DEF_R_SDRAM_CONFIG
 	hex "R_SDRAM_CONFIG"
 	depends on ETRAX_ARCH_V10 && ETRAX_SDRAM
-	default "d2fa7878"
+	default "0xd2fa7878"
 	help
 	  The R_SDRAM_CONFIG register specifies everything on how the SDRAM
 	  chips in the system are connected to the ETRAX CPU.  This is
@@ -315,14 +315,14 @@ config ETRAX_DEF_R_SDRAM_CONFIG
 config ETRAX_DEF_R_SDRAM_TIMING
 	hex "R_SDRAM_TIMING"
 	depends on ETRAX_ARCH_V10 && ETRAX_SDRAM
-	default "80004801"
+	default "0x80004801"
 	help
 	  Different SDRAM chips have different timing.
 
 config ETRAX_DEF_R_PORT_PA_DIR
 	hex "R_PORT_PA_DIR"
 	depends on ETRAX_ARCH_V10
-	default "1c"
+	default "0x1c"
 	help
 	  Configures the direction of general port A bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -336,7 +336,7 @@ config ETRAX_DEF_R_PORT_PA_DIR
 config ETRAX_DEF_R_PORT_PA_DATA
 	hex "R_PORT_PA_DATA"
 	depends on ETRAX_ARCH_V10
-	default "00"
+	default "0"
 	help
 	  Configures the initial data for the general port A bits.  Most
 	  products should use 00 here.
@@ -344,7 +344,7 @@ config ETRAX_DEF_R_PORT_PA_DATA
 config ETRAX_DEF_R_PORT_PB_CONFIG
 	hex "R_PORT_PB_CONFIG"
 	depends on ETRAX_ARCH_V10
-	default "00"
+	default "0"
 	help
 	  Configures the type of the general port B bits.  1 is chip select,
 	  0 is port.  Most products should use 00 here.
@@ -352,7 +352,7 @@ config ETRAX_DEF_R_PORT_PB_CONFIG
 config ETRAX_DEF_R_PORT_PB_DIR
 	hex "R_PORT_PB_DIR"
 	depends on ETRAX_ARCH_V10
-	default "00"
+	default "0"
 	help
 	  Configures the direction of general port B bits. 1 is out, 0 is in.
 	  This is often totally different depending on the product used.  Bits
@@ -365,7 +365,7 @@ config ETRAX_DEF_R_PORT_PB_DIR
 config ETRAX_DEF_R_PORT_PB_DATA
 	hex "R_PORT_PB_DATA"
 	depends on ETRAX_ARCH_V10
-	default "ff"
+	default "0xff"
 	help
 	  Configures the initial data for the general port A bits.  Most
 	  products should use FF here.
Index: linux-2.6/arch/cris/arch-v10/drivers/Kconfig
===================================================================
--- linux-2.6.orig/arch/cris/arch-v10/drivers/Kconfig
+++ linux-2.6/arch/cris/arch-v10/drivers/Kconfig
@@ -531,20 +531,20 @@ config ETRAX_GPIO
 config ETRAX_PA_BUTTON_BITMASK
 	hex "PA-buttons bitmask"
 	depends on ETRAX_GPIO
-	default "02"
+	default "0x2"
 	help
 	  This is a bitmask with information about what bits on PA that
 	  are used for buttons.
 	  Most products has a so called TEST button on PA1, if that's true
-	  use 02 here.
-	  Use 00 if there are no buttons on PA.
+	  use 0x2 here.
+	  Use 0x0 if there are no buttons on PA.
 	  If the bitmask is <> 00 a button driver will be included in the gpio
 	  driver. ETRAX general I/O support must be enabled.
 
 config ETRAX_PA_CHANGEABLE_DIR
 	hex "PA user changeable dir mask"
 	depends on ETRAX_GPIO
-	default "00"
+	default "0"
 	help
 	  This is a bitmask with information of what bits in PA that a user
 	  can change direction on using ioctl's.
@@ -554,7 +554,7 @@ config ETRAX_PA_CHANGEABLE_DIR
 config ETRAX_PA_CHANGEABLE_BITS
 	hex "PA user changeable bits mask"
 	depends on ETRAX_GPIO
-	default "FF"
+	default "0xff"
 	help
 	  This is a bitmask with information of what bits in PA that a user
 	  can change the value on using ioctl's.
@@ -564,7 +564,7 @@ config ETRAX_PA_CHANGEABLE_BITS
 config ETRAX_PB_CHANGEABLE_DIR
 	hex "PB user changeable dir mask"
 	depends on ETRAX_GPIO
-	default "00"
+	default "0"
 	help
 	  This is a bitmask with information of what bits in PB that a user
 	  can change direction on using ioctl's.
@@ -574,7 +574,7 @@ config ETRAX_PB_CHANGEABLE_DIR
 config ETRAX_PB_CHANGEABLE_BITS
 	hex "PB user changeable bits mask"
 	depends on ETRAX_GPIO
-	default "FF"
+	default "0xff"
 	help
 	  This is a bitmask with information of what bits in PB that a user
 	  can change the value on using ioctl's.
Index: linux-2.6/arch/cris/arch-v32/Kconfig
===================================================================
--- linux-2.6.orig/arch/cris/arch-v32/Kconfig
+++ linux-2.6/arch/cris/arch-v32/Kconfig
@@ -8,7 +8,7 @@ source drivers/cpufreq/Kconfig
 config ETRAX_DRAM_VIRTUAL_BASE
 	hex
 	depends on ETRAX_ARCH_V32
-	default "c0000000"
+	default "0xc0000000"
 
 choice
 	prompt "Nbr of Ethernet LED groups"
@@ -119,7 +119,7 @@ endchoice
 config ETRAX_MEM_GRP1_CONFIG
 	hex "MEM_GRP1_CONFIG"
 	depends on ETRAX_ARCH_V32
-	default "4044a"
+	default "0x4044a"
 	help
 	  Waitstates for flash. The default value is suitable for the
 	  standard flashes used in axis products (120 ns).
@@ -150,7 +150,7 @@ config ETRAX_MEM_GRP4_CONFIG
 config ETRAX_SDRAM_GRP0_CONFIG
 	hex "SDRAM_GRP0_CONFIG"
 	depends on ETRAX_ARCH_V32
-	default "336"
+	default "0x336"
 	help
 	  SDRAM configuration for group 0. The value depends on the
 	  hardware configuration. The default value is suitable
@@ -170,7 +170,7 @@ config ETRAX_SDRAM_GRP1_CONFIG
 config ETRAX_SDRAM_TIMING
 	hex "SDRAM_TIMING"
 	depends on ETRAX_ARCH_V32
-	default "104a"
+	default "0x104a"
 	help
 	  SDRAM timing parameters. The default value is ok for
 	  most hardwares but large SDRAMs may require a faster
@@ -189,7 +189,7 @@ config ETRAX_SDRAM_COMMAND
 config ETRAX_DEF_GIO_PA_OE
 	hex "GIO_PA_OE"
 	depends on ETRAX_ARCH_V32
-	default "1c"
+	default "0x1c"
 	help
 	  Configures the direction of general port A bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -203,7 +203,7 @@ config ETRAX_DEF_GIO_PA_OE
 config ETRAX_DEF_GIO_PA_OUT
 	hex "GIO_PA_OUT"
 	depends on ETRAX_ARCH_V32
-	default "00"
+	default "0"
 	help
 	  Configures the initial data for the general port A bits.  Most
 	  products should use 00 here.
@@ -211,7 +211,7 @@ config ETRAX_DEF_GIO_PA_OUT
 config ETRAX_DEF_GIO_PB_OE
 	hex "GIO_PB_OE"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the direction of general port B bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -225,7 +225,7 @@ config ETRAX_DEF_GIO_PB_OE
 config ETRAX_DEF_GIO_PB_OUT
 	hex "GIO_PB_OUT"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the initial data for the general port B bits.  Most
 	  products should use 00000 here.
@@ -233,7 +233,7 @@ config ETRAX_DEF_GIO_PB_OUT
 config ETRAX_DEF_GIO_PC_OE
 	hex "GIO_PC_OE"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the direction of general port C bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -247,7 +247,7 @@ config ETRAX_DEF_GIO_PC_OE
 config ETRAX_DEF_GIO_PC_OUT
 	hex "GIO_PC_OUT"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the initial data for the general port C bits.  Most
 	  products should use 00000 here.
@@ -255,7 +255,7 @@ config ETRAX_DEF_GIO_PC_OUT
 config ETRAX_DEF_GIO_PD_OE
 	hex "GIO_PD_OE"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the direction of general port D bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -269,7 +269,7 @@ config ETRAX_DEF_GIO_PD_OE
 config ETRAX_DEF_GIO_PD_OUT
 	hex "GIO_PD_OUT"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the initial data for the general port D bits.  Most
 	  products should use 00000 here.
@@ -277,7 +277,7 @@ config ETRAX_DEF_GIO_PD_OUT
 config ETRAX_DEF_GIO_PE_OE
 	hex "GIO_PE_OE"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the direction of general port E bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -291,7 +291,7 @@ config ETRAX_DEF_GIO_PE_OE
 config ETRAX_DEF_GIO_PE_OUT
 	hex "GIO_PE_OUT"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the initial data for the general port E bits.  Most
 	  products should use 00000 here.
Index: linux-2.6/arch/cris/arch-v32/drivers/Kconfig
===================================================================
--- linux-2.6.orig/arch/cris/arch-v32/drivers/Kconfig
+++ linux-2.6/arch/cris/arch-v32/drivers/Kconfig
@@ -513,8 +513,7 @@ config ETRAX_VIRTUAL_GPIO_INTERRUPT_PA_P
 config ETRAX_PA_CHANGEABLE_DIR
 	hex "PA user changeable dir mask"
 	depends on ETRAX_GPIO
-	default "0x00" if ETRAXFS
-	default "0x00000000" if !ETRAXFS
+	default "0"
 	help
 	  This is a bitmask (8 bits) with information of what bits in PA that a
 	  user can change direction on using ioctl's.
@@ -524,8 +523,7 @@ config ETRAX_PA_CHANGEABLE_DIR
 config ETRAX_PA_CHANGEABLE_BITS
 	hex "PA user changeable bits mask"
 	depends on ETRAX_GPIO
-	default "0x00" if ETRAXFS
-	default "0x00000000" if !ETRAXFS
+	default "0"
 	help
 	  This is a bitmask (8 bits) with information of what bits in PA
 	  that a user can change the value on using ioctl's.
@@ -534,8 +532,7 @@ config ETRAX_PA_CHANGEABLE_BITS
 config ETRAX_PB_CHANGEABLE_DIR
 	hex "PB user changeable dir mask"
 	depends on ETRAX_GPIO
-	default "0x00000" if ETRAXFS
-	default "0x00000000" if !ETRAXFS
+	default "0"
 	help
 	  This is a bitmask (18 bits) with information of what bits in PB
 	  that a user can change direction on using ioctl's.
@@ -545,8 +542,7 @@ config ETRAX_PB_CHANGEABLE_DIR
 config ETRAX_PB_CHANGEABLE_BITS
 	hex "PB user changeable bits mask"
 	depends on ETRAX_GPIO
-	default "0x00000" if ETRAXFS
-	default "0x00000000" if !ETRAXFS
+	default "0"
 	help
 	  This is a bitmask (18 bits) with information of what bits in PB
 	  that a user can change the value on using ioctl's.
@@ -555,8 +551,7 @@ config ETRAX_PB_CHANGEABLE_BITS
 config ETRAX_PC_CHANGEABLE_DIR
 	hex "PC user changeable dir mask"
 	depends on ETRAX_GPIO
-	default "0x00000" if ETRAXFS
-	default "0x00000000" if !ETRAXFS
+	default "0"
 	help
 	  This is a bitmask (18 bits) with information of what bits in PC
 	  that a user can change direction on using ioctl's.
@@ -566,8 +561,7 @@ config ETRAX_PC_CHANGEABLE_DIR
 config ETRAX_PC_CHANGEABLE_BITS
 	hex "PC user changeable bits mask"
 	depends on ETRAX_GPIO
-	default "0x00000" if ETRAXFS
-	default "0x00000000" if ETRAXFS
+	default "0"
 	help
 	  This is a bitmask (18 bits) with information of what bits in PC
 	  that a user can change the value on using ioctl's.
@@ -576,7 +570,7 @@ config ETRAX_PC_CHANGEABLE_BITS
 config ETRAX_PD_CHANGEABLE_DIR
 	hex "PD user changeable dir mask"
 	depends on ETRAX_GPIO && ETRAXFS
-	default "0x00000"
+	default "0"
 	help
 	  This is a bitmask (18 bits) with information of what bits in PD
 	  that a user can change direction on using ioctl's.
@@ -586,7 +580,7 @@ config ETRAX_PD_CHANGEABLE_DIR
 config ETRAX_PD_CHANGEABLE_BITS
 	hex "PD user changeable bits mask"
 	depends on ETRAX_GPIO && ETRAXFS
-	default "0x00000"
+	default "0"
 	help
 	  This is a bitmask (18 bits) with information of what bits in PD
 	  that a user can change the value on using ioctl's.
@@ -595,7 +589,7 @@ config ETRAX_PD_CHANGEABLE_BITS
 config ETRAX_PE_CHANGEABLE_DIR
 	hex "PE user changeable dir mask"
 	depends on ETRAX_GPIO && ETRAXFS
-	default "0x00000"
+	default "0"
 	help
 	  This is a bitmask (18 bits) with information of what bits in PE
 	  that a user can change direction on using ioctl's.
@@ -605,7 +599,7 @@ config ETRAX_PE_CHANGEABLE_DIR
 config ETRAX_PE_CHANGEABLE_BITS
 	hex "PE user changeable bits mask"
  	depends on ETRAX_GPIO && ETRAXFS
-	default "0x00000"
+	default "0"
 	help
 	  This is a bitmask (18 bits) with information of what bits in PE
 	  that a user can change the value on using ioctl's.
@@ -614,7 +608,7 @@ config ETRAX_PE_CHANGEABLE_BITS
 config ETRAX_PV_CHANGEABLE_DIR
 	hex "PV user changeable dir mask"
 	depends on ETRAX_VIRTUAL_GPIO
-	default "0x0000"
+	default "0"
 	help
 	  This is a bitmask (16 bits) with information of what bits in PV
 	  that a user can change direction on using ioctl's.
@@ -624,7 +618,7 @@ config ETRAX_PV_CHANGEABLE_DIR
 config ETRAX_PV_CHANGEABLE_BITS
 	hex "PV user changeable bits mask"
 	depends on ETRAX_VIRTUAL_GPIO
-	default "0x0000"
+	default "0"
 	help
 	  This is a bitmask (16 bits) with information of what bits in PV
 	  that a user can change the value on using ioctl's.
Index: linux-2.6/arch/cris/arch-v32/mach-a3/Kconfig
===================================================================
--- linux-2.6.orig/arch/cris/arch-v32/mach-a3/Kconfig
+++ linux-2.6/arch/cris/arch-v32/mach-a3/Kconfig
@@ -5,7 +5,7 @@ menu "Artpec-3 options"
 
 config ETRAX_DRAM_VIRTUAL_BASE
 	hex
-	default "c0000000"
+	default "0xc0000000"
 
 config ETRAX_L2CACHE
        bool
@@ -47,7 +47,7 @@ config ETRAX_PIO_CE2_CFG
 
 config ETRAX_DEF_GIO_PA_OE
 	hex "GIO_PA_OE"
-	default "00000000"
+	default "0"
 	help
 	  Configures the direction of general port A bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -60,14 +60,14 @@ config ETRAX_DEF_GIO_PA_OE
 
 config ETRAX_DEF_GIO_PA_OUT
 	hex "GIO_PA_OUT"
-	default "00000000"
+	default "0"
 	help
 	  Configures the initial data for the general port A bits.  Most
 	  products should use 00 here.
 
 config ETRAX_DEF_GIO_PB_OE
 	hex "GIO_PB_OE"
-	default "000000000"
+	default "0"
 	help
 	  Configures the direction of general port B bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -80,14 +80,14 @@ config ETRAX_DEF_GIO_PB_OE
 
 config ETRAX_DEF_GIO_PB_OUT
 	hex "GIO_PB_OUT"
-	default "000000000"
+	default "0"
 	help
 	  Configures the initial data for the general port B bits.  Most
 	  products should use 00000 here.
 
 config ETRAX_DEF_GIO_PC_OE
 	hex "GIO_PC_OE"
-	default "00000"
+	default "0"
 	help
 	  Configures the direction of general port C bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -100,7 +100,7 @@ config ETRAX_DEF_GIO_PC_OE
 
 config ETRAX_DEF_GIO_PC_OUT
 	hex "GIO_PC_OUT"
-	default "00000"
+	default "0"
 	help
 	  Configures the initial data for the general port C bits.  Most
 	  products should use 00000 here.
Index: linux-2.6/arch/cris/arch-v32/mach-fs/Kconfig
===================================================================
--- linux-2.6.orig/arch/cris/arch-v32/mach-fs/Kconfig
+++ linux-2.6/arch/cris/arch-v32/mach-fs/Kconfig
@@ -6,7 +6,7 @@ menu "ETRAX FS options"
 config ETRAX_DRAM_VIRTUAL_BASE
 	hex
 	depends on ETRAX_ARCH_V32
-	default "c0000000"
+	default "0xc0000000"
 
 config ETRAX_SERIAL_PORTS
        int
@@ -15,7 +15,7 @@ config ETRAX_SERIAL_PORTS
 config ETRAX_MEM_GRP1_CONFIG
 	hex "MEM_GRP1_CONFIG"
 	depends on ETRAX_ARCH_V32
-	default "4044a"
+	default "0x4044a"
 	help
 	  Waitstates for flash. The default value is suitable for the
 	  standard flashes used in axis products (120 ns).
@@ -46,7 +46,7 @@ config ETRAX_MEM_GRP4_CONFIG
 config ETRAX_SDRAM_GRP0_CONFIG
 	hex "SDRAM_GRP0_CONFIG"
 	depends on ETRAX_ARCH_V32
-	default "336"
+	default "0x336"
 	help
 	  SDRAM configuration for group 0. The value depends on the
 	  hardware configuration. The default value is suitable
@@ -66,7 +66,7 @@ config ETRAX_SDRAM_GRP1_CONFIG
 config ETRAX_SDRAM_TIMING
 	hex "SDRAM_TIMING"
 	depends on ETRAX_ARCH_V32
-	default "104a"
+	default "0x104a"
 	help
 	  SDRAM timing parameters. The default value is ok for
 	  most hardwares but large SDRAMs may require a faster
@@ -85,7 +85,7 @@ config ETRAX_SDRAM_COMMAND
 config ETRAX_DEF_GIO_PA_OE
 	hex "GIO_PA_OE"
 	depends on ETRAX_ARCH_V32
-	default "1c"
+	default "0x1c"
 	help
 	  Configures the direction of general port A bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -99,7 +99,7 @@ config ETRAX_DEF_GIO_PA_OE
 config ETRAX_DEF_GIO_PA_OUT
 	hex "GIO_PA_OUT"
 	depends on ETRAX_ARCH_V32
-	default "00"
+	default "0"
 	help
 	  Configures the initial data for the general port A bits.  Most
 	  products should use 00 here.
@@ -107,7 +107,7 @@ config ETRAX_DEF_GIO_PA_OUT
 config ETRAX_DEF_GIO_PB_OE
 	hex "GIO_PB_OE"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the direction of general port B bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -121,7 +121,7 @@ config ETRAX_DEF_GIO_PB_OE
 config ETRAX_DEF_GIO_PB_OUT
 	hex "GIO_PB_OUT"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the initial data for the general port B bits.  Most
 	  products should use 00000 here.
@@ -129,7 +129,7 @@ config ETRAX_DEF_GIO_PB_OUT
 config ETRAX_DEF_GIO_PC_OE
 	hex "GIO_PC_OE"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the direction of general port C bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -143,7 +143,7 @@ config ETRAX_DEF_GIO_PC_OE
 config ETRAX_DEF_GIO_PC_OUT
 	hex "GIO_PC_OUT"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the initial data for the general port C bits.  Most
 	  products should use 00000 here.
@@ -151,7 +151,7 @@ config ETRAX_DEF_GIO_PC_OUT
 config ETRAX_DEF_GIO_PD_OE
 	hex "GIO_PD_OE"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the direction of general port D bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -165,7 +165,7 @@ config ETRAX_DEF_GIO_PD_OE
 config ETRAX_DEF_GIO_PD_OUT
 	hex "GIO_PD_OUT"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the initial data for the general port D bits.  Most
 	  products should use 00000 here.
@@ -173,7 +173,7 @@ config ETRAX_DEF_GIO_PD_OUT
 config ETRAX_DEF_GIO_PE_OE
 	hex "GIO_PE_OE"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the direction of general port E bits.  1 is out, 0 is in.
 	  This is often totally different depending on the product used.
@@ -187,7 +187,7 @@ config ETRAX_DEF_GIO_PE_OE
 config ETRAX_DEF_GIO_PE_OUT
 	hex "GIO_PE_OUT"
 	depends on ETRAX_ARCH_V32
-	default "00000"
+	default "0"
 	help
 	  Configures the initial data for the general port E bits.  Most
 	  products should use 00000 here.
@@ -195,7 +195,7 @@ config ETRAX_DEF_GIO_PE_OUT
 config ETRAX_DEF_GIO_PV_OE
 	hex "GIO_PV_OE"
 	depends on ETRAX_VIRTUAL_GPIO
-	default "0000"
+	default "0"
 	help
 	  Configures the direction of virtual general port V bits. 1 is out,
 	  0 is in. This is often totally different depending on the product
@@ -206,7 +206,7 @@ config ETRAX_DEF_GIO_PV_OE
 config ETRAX_DEF_GIO_PV_OUT
 	hex "GIO_PV_OUT"
 	depends on ETRAX_VIRTUAL_GPIO
-	default "0000"
+	default "0"
 	help
 	  Configures the initial data for the virtual general port V bits.
 	  Most products should use 0000 here.
Index: linux-2.6/arch/frv/Kconfig
===================================================================
--- linux-2.6.orig/arch/frv/Kconfig
+++ linux-2.6/arch/frv/Kconfig
@@ -149,8 +149,8 @@ config PAGE_OFFSET
 	default 0x40000000 if UCPAGE_OFFSET_40000000
 	default 0x60000000 if UCPAGE_OFFSET_60000000
 	default 0x80000000 if UCPAGE_OFFSET_80000000
-	default 0xA0000000 if UCPAGE_OFFSET_A0000000
-	default 0xC0000000
+	default 0xa0000000 if UCPAGE_OFFSET_A0000000
+	default 0xc0000000
 
 config PROTECT_KERNEL
 	bool "Protect core kernel against userspace"
Index: linux-2.6/arch/m32r/Kconfig
===================================================================
--- linux-2.6.orig/arch/m32r/Kconfig
+++ linux-2.6/arch/m32r/Kconfig
@@ -199,22 +199,22 @@ config CPU_LITTLE_ENDIAN
 
 config MEMORY_START
 	hex "Physical memory start address (hex)"
-	default "08000000" if PLAT_MAPPI || PLAT_MAPPI2 || PLAT_MAPPI3
-	default "08000000" if PLAT_USRV
-	default "08000000" if PLAT_M32700UT
-	default "08000000" if PLAT_OPSPUT
-	default "04000000" if PLAT_M32104UT
-	default "01000000" if PLAT_OAKS32R
+	default "0x8000000" if PLAT_MAPPI || PLAT_MAPPI2 || PLAT_MAPPI3
+	default "0x8000000" if PLAT_USRV
+	default "0x8000000" if PLAT_M32700UT
+	default "0x8000000" if PLAT_OPSPUT
+	default "0x4000000" if PLAT_M32104UT
+	default "0x1000000" if PLAT_OAKS32R
 
 config MEMORY_SIZE
 	hex "Physical memory size (hex)"
-	default "08000000" if PLAT_MAPPI3
-	default "04000000" if PLAT_MAPPI || PLAT_MAPPI2
-	default "02000000" if PLAT_USRV
-	default "01000000" if PLAT_M32700UT
-	default "01000000" if PLAT_OPSPUT
-	default "01000000" if PLAT_M32104UT
-	default "00800000" if PLAT_OAKS32R
+	default "0x8000000" if PLAT_MAPPI3
+	default "0x4000000" if PLAT_MAPPI || PLAT_MAPPI2
+	default "0x2000000" if PLAT_USRV
+	default "0x1000000" if PLAT_M32700UT
+	default "0x1000000" if PLAT_OPSPUT
+	default "0x1000000" if PLAT_M32104UT
+	default "0x800000" if PLAT_OAKS32R
 
 config NOHIGHMEM
 	bool
@@ -229,16 +229,16 @@ source "mm/Kconfig"
 
 config IRAM_START
 	hex "Internal memory start address (hex)"
-	default "00f00000" if !CHIP_M32104
-	default "00700000" if CHIP_M32104
+	default "0xf00000" if !CHIP_M32104
+	default "0x700000" if CHIP_M32104
 	depends on (CHIP_M32700 || CHIP_M32102 || CHIP_VDEC2 || CHIP_OPSP || CHIP_M32104) && DISCONTIGMEM
 
 config IRAM_SIZE
 	hex "Internal memory size (hex)"
 	depends on (CHIP_M32700 || CHIP_M32102 || CHIP_VDEC2 || CHIP_OPSP || CHIP_M32104) && DISCONTIGMEM
-	default "00080000" if CHIP_M32700
-	default "00010000" if CHIP_M32102 || CHIP_OPSP || CHIP_M32104
-	default "00008000" if CHIP_VDEC2
+	default "0x80000" if CHIP_M32700
+	default "0x10000" if CHIP_M32102 || CHIP_OPSP || CHIP_M32104
+	default "0x8000" if CHIP_VDEC2
 
 #
 # Define implied options from the CPU selection here
Index: linux-2.6/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/Kconfig
+++ linux-2.6/arch/powerpc/Kconfig
@@ -714,8 +714,8 @@ config PHYSICAL_START_BOOL
 
 config PHYSICAL_START
 	hex "Physical address where the kernel is loaded" if PHYSICAL_START_BOOL
-	default "0x02000000" if PPC_STD_MMU && CRASH_DUMP
-	default "0x00000000"
+	default "0x2000000" if PPC_STD_MMU && CRASH_DUMP
+	default "0"
 
 config PHYSICAL_ALIGN
 	hex
@@ -763,7 +763,7 @@ config CONSISTENT_SIZE_BOOL
 
 config CONSISTENT_SIZE
 	hex "Size of consistent memory pool" if CONSISTENT_SIZE_BOOL
-	default "0x00200000" if NOT_COHERENT_CACHE
+	default "0x200000" if NOT_COHERENT_CACHE
 
 config PIN_TLB
 	bool "Pinned Kernel TLBs (860 ONLY)"
@@ -773,15 +773,11 @@ endmenu
 if PPC64
 config PAGE_OFFSET
 	hex
-	default "0xc000000000000000"
-config KERNEL_START
-	hex
-	default "0xc000000002000000" if CRASH_DUMP
-	default "0xc000000000000000"
+	default "0xc0000000"
 config PHYSICAL_START
 	hex
-	default "0x02000000" if CRASH_DUMP
-	default "0x00000000"
+	default "0x2000000" if CRASH_DUMP
+	default "0"
 endif
 
 source "net/Kconfig"
Index: linux-2.6/arch/ppc/Kconfig
===================================================================
--- linux-2.6.orig/arch/ppc/Kconfig
+++ linux-2.6/arch/ppc/Kconfig
@@ -1120,7 +1120,7 @@ config CONSISTENT_SIZE_BOOL
 
 config CONSISTENT_SIZE
 	hex "Size of consistent memory pool" if CONSISTENT_SIZE_BOOL
-	default "0x00200000" if NOT_COHERENT_CACHE
+	default "0x200000" if NOT_COHERENT_CACHE
 
 config BOOT_LOAD_BOOL
 	bool "Set the boot link/load address"
@@ -1134,9 +1134,9 @@ config BOOT_LOAD_BOOL
 
 config BOOT_LOAD
 	hex "Link/load address for booting" if BOOT_LOAD_BOOL
-	default "0x00400000" if 40x || 8xx || 8260
-	default "0x01000000" if 44x
-	default "0x00800000"
+	default "0x400000" if 40x || 8xx || 8260
+	default "0x1000000" if 44x
+	default "0x800000"
 
 config PIN_TLB
 	bool "Pinned Kernel TLBs (860 ONLY)"
Index: linux-2.6/arch/sh/Kconfig
===================================================================
--- linux-2.6.orig/arch/sh/Kconfig
+++ linux-2.6/arch/sh/Kconfig
@@ -753,16 +753,16 @@ menu "Boot options"
 
 config ZERO_PAGE_OFFSET
 	hex "Zero page offset"
-	default "0x00004000" if SH_SH03
-	default "0x00010000" if PAGE_SIZE_64KB
-	default "0x00002000" if PAGE_SIZE_8KB
-	default "0x00001000"
+	default "0x4000" if SH_SH03
+	default "0x10000" if PAGE_SIZE_64KB
+	default "0x2000" if PAGE_SIZE_8KB
+	default "0x1000"
 	help
 	  This sets the default offset of zero page.
 
 config BOOT_LINK_OFFSET
 	hex "Link address offset for booting"
-	default "0x00800000"
+	default "0x800000"
 	help
 	  This option allows you to set the link address offset of the zImage.
 	  This can be useful if you are on a board which has a small amount of
Index: linux-2.6/arch/sh/Kconfig.debug
===================================================================
--- linux-2.6.orig/arch/sh/Kconfig.debug
+++ linux-2.6/arch/sh/Kconfig.debug
@@ -41,7 +41,7 @@ config EARLY_SCIF_CONSOLE_PORT
 	default "0xffea0000" if CPU_SUBTYPE_SH7785
 	default "0xfffe8000" if CPU_SUBTYPE_SH7203
 	default "0xfffe9800" if CPU_SUBTYPE_SH7206 || CPU_SUBTYPE_SH7263
-	default "0x00000000"
+	default "0"
 
 config EARLY_PRINTK
 	bool "Early printk support"
Index: linux-2.6/arch/sh/mm/Kconfig
===================================================================
--- linux-2.6.orig/arch/sh/mm/Kconfig
+++ linux-2.6/arch/sh/mm/Kconfig
@@ -19,11 +19,11 @@ config PAGE_OFFSET
 	hex
 	default "0x80000000" if MMU && SUPERH32
 	default "0x20000000" if MMU && SUPERH64
-	default "0x00000000"
+	default "0"
 
 config MEMORY_START
 	hex "Physical memory start address"
-	default "0x08000000"
+	default "0x8000000"
 	---help---
 	  Computers built with Hitachi SuperH processors always
 	  map the ROM starting at address zero.  But the processor
@@ -39,7 +39,7 @@ config MEMORY_START
 
 config MEMORY_SIZE
 	hex "Physical memory size"
-	default "0x04000000"
+	default "0x4000000"
 	help
 	  This sets the default memory size assumed by your SH kernel. It can
 	  be overridden as normal by the 'mem=' argument on the kernel command
Index: linux-2.6/include/asm-powerpc/page.h
===================================================================
--- linux-2.6.orig/include/asm-powerpc/page.h
+++ linux-2.6/include/asm-powerpc/page.h
@@ -67,9 +67,15 @@
  * If you want to test if something's a kernel address, use is_kernel_addr().
  */
 
-#define KERNELBASE      ASM_CONST(CONFIG_KERNEL_START)
+#ifdef CONFIG_PPC64
+#define PAGE_OFFSET	(ASM_CONST(CONFIG_PAGE_OFFSET) << 32)
+#define KERNELBASE	(PAGE_OFFSET+ASM_CONST(CONFIG_PHYSICAL_START))
+#define LOAD_OFFSET	PAGE_OFFSET
+#else
+#define KERNELBASE	ASM_CONST(CONFIG_KERNEL_START)
 #define PAGE_OFFSET	ASM_CONST(CONFIG_PAGE_OFFSET)
-#define LOAD_OFFSET	ASM_CONST((CONFIG_KERNEL_START-CONFIG_PHYSICAL_START))
+#define LOAD_OFFSET	(ASM_CONST(CONFIG_KERNEL_START)-ASM_CONST(CONFIG_PHYSICAL_START))
+#endif
 
 #if defined(CONFIG_RELOCATABLE) && defined(CONFIG_FLATMEM)
 #ifndef __ASSEMBLY__

Re: linux-next: kbuild tree build failure

[Sam Ravnborg]

On Mon, Jul 07, 2008 at 06:13:55PM +0200, Roman Zippel wrote:
> Hi,
> 
> On Mon, 7 Jul 2008, Stephen Rothwell wrote:
> 
> > Hi Sam,
> > 
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > 
> > arch/powerpc/platforms/cell/spu_base.c: In function '__spu_trap_data_seg':
> > arch/powerpc/platforms/cell/spu_base.c:194: error: duplicate case value
> > arch/powerpc/platforms/cell/spu_base.c:177: error: previously used here
> 
> I guess there also has been a kconfig warning somewhere. :)
> I should have gone through all archs to test this, sorry about that.
> Luckily it's only powerpc that uses 64bit values. I would prefer to 
> standardize on 32bit values, as it doesn't really make sense to expect 
> from the user to input full 64bit values and it's easy to generate the 
> full value in a header. This would also ease on any portability issues 
> (kconfig is compiled with the host compiler not the target compiler).
> 
> Below is a patch that fixes this for all archs (generated against the git 
> tree). The powerpc parts need a more careful review, the rest isn't really 
> critical.
> 
> bye, Roman

Hi Roman.

>From your patch:

>  config PINT3_ASSIGN
>  	hex "PINT3_ASSIGN"
>  	depends on PINTx_REASSIGN
> -	default 0x02020303
> +	default 0x2020303


But ths change actually decrease readability of the
value. Before we had 4x2 hex characters. But now we have 3x2 + 1x1.
Does this check really by us enough to warrant this?

I am aware that the check is implmented by:

+                       str = strdup_type(def_sym->name, sym->type);
+                       if (strcmp(str, def_sym->name)) {
+                               prop_warn(prop,
+                                       "default for config symbol '%s'"
+                                       " should be %s", sym->name, str);
+                               prop->expr->left.sym = sym_lookup(str, SYMBOL_CO
+                       }
+                       free(str);
                        break;

Could we soften this check a little maybe?
At least so we accept leading null's.

As for the patch in general I will await an ack from powerpc
before applying it.

	Sam

Re: linux-next: kbuild tree build failure

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 3231 bytes --]

On Mon, 2008-07-07 at 18:13 +0200, Roman Zippel wrote:
> Hi,
> 
> On Mon, 7 Jul 2008, Stephen Rothwell wrote:
> 
> > Hi Sam,
> > 
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > 
> > arch/powerpc/platforms/cell/spu_base.c: In function '__spu_trap_data_seg':
> > arch/powerpc/platforms/cell/spu_base.c:194: error: duplicate case value
> > arch/powerpc/platforms/cell/spu_base.c:177: error: previously used here
> 
> I guess there also has been a kconfig warning somewhere. :)
> I should have gone through all archs to test this, sorry about that.
> Luckily it's only powerpc that uses 64bit values. I would prefer to 
> standardize on 32bit values, as it doesn't really make sense to expect 
> from the user to input full 64bit values and it's easy to generate the 
> full value in a header. This would also ease on any portability issues 
> (kconfig is compiled with the host compiler not the target compiler).

Hi Roman,

I don't really see why it "doesn't make sense" for users to input 64-bit
values, they're configuring addresses for a 64-bit kernel, so some of
the values are going to be 64 bit.

Perhaps all the current values can be generated by shifting 32-bit
constants, but that seems like a hack to me.

Another comment below ..

> Index: linux-2.6/arch/powerpc/Kconfig
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/Kconfig
> +++ linux-2.6/arch/powerpc/Kconfig
> @@ -714,8 +714,8 @@ config PHYSICAL_START_BOOL
>  
>  config PHYSICAL_START
>  	hex "Physical address where the kernel is loaded" if PHYSICAL_START_BOOL
> -	default "0x02000000" if PPC_STD_MMU && CRASH_DUMP
> -	default "0x00000000"
> +	default "0x2000000" if PPC_STD_MMU && CRASH_DUMP
> +	default "0"
>  
>  config PHYSICAL_ALIGN
>  	hex
> @@ -763,7 +763,7 @@ config CONSISTENT_SIZE_BOOL
>  
>  config CONSISTENT_SIZE
>  	hex "Size of consistent memory pool" if CONSISTENT_SIZE_BOOL
> -	default "0x00200000" if NOT_COHERENT_CACHE
> +	default "0x200000" if NOT_COHERENT_CACHE
>  
>  config PIN_TLB
>  	bool "Pinned Kernel TLBs (860 ONLY)"
> @@ -773,15 +773,11 @@ endmenu
>  if PPC64
>  config PAGE_OFFSET
>  	hex
> -	default "0xc000000000000000"
> -config KERNEL_START
> -	hex
> -	default "0xc000000002000000" if CRASH_DUMP
> -	default "0xc000000000000000"
> +	default "0xc0000000"

I don't see where you cope with the "if CRASH_DUMP" case, and in fact my
config changes for the worse when I apply your patch and regenerate my
config:

--- .config.orig	2008-07-08 09:30:00.000000000 +1000
+++ .config	2008-07-08 09:30:43.000000000 +1000
@@ -370,9 +370,8 @@
 CONFIG_HOTPLUG_PCI_RPA=m
 CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
 # CONFIG_HAS_RAPIDIO is not set
-CONFIG_PAGE_OFFSET=0xc000000000000000
-CONFIG_KERNEL_START=0xc000000002000000
-CONFIG_PHYSICAL_START=0x02000000
+CONFIG_PAGE_OFFSET=0xc0000000
+CONFIG_PHYSICAL_START=0x2000000
 

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: linux-next: kbuild tree build failure

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 3231 bytes --]

On Mon, 2008-07-07 at 18:13 +0200, Roman Zippel wrote:
> Hi,
> 
> On Mon, 7 Jul 2008, Stephen Rothwell wrote:
> 
> > Hi Sam,
> > 
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > 
> > arch/powerpc/platforms/cell/spu_base.c: In function '__spu_trap_data_seg':
> > arch/powerpc/platforms/cell/spu_base.c:194: error: duplicate case value
> > arch/powerpc/platforms/cell/spu_base.c:177: error: previously used here
> 
> I guess there also has been a kconfig warning somewhere. :)
> I should have gone through all archs to test this, sorry about that.
> Luckily it's only powerpc that uses 64bit values. I would prefer to 
> standardize on 32bit values, as it doesn't really make sense to expect 
> from the user to input full 64bit values and it's easy to generate the 
> full value in a header. This would also ease on any portability issues 
> (kconfig is compiled with the host compiler not the target compiler).

Hi Roman,

I don't really see why it "doesn't make sense" for users to input 64-bit
values, they're configuring addresses for a 64-bit kernel, so some of
the values are going to be 64 bit.

Perhaps all the current values can be generated by shifting 32-bit
constants, but that seems like a hack to me.

Another comment below ..

> Index: linux-2.6/arch/powerpc/Kconfig
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/Kconfig
> +++ linux-2.6/arch/powerpc/Kconfig
> @@ -714,8 +714,8 @@ config PHYSICAL_START_BOOL
>  
>  config PHYSICAL_START
>  	hex "Physical address where the kernel is loaded" if PHYSICAL_START_BOOL
> -	default "0x02000000" if PPC_STD_MMU && CRASH_DUMP
> -	default "0x00000000"
> +	default "0x2000000" if PPC_STD_MMU && CRASH_DUMP
> +	default "0"
>  
>  config PHYSICAL_ALIGN
>  	hex
> @@ -763,7 +763,7 @@ config CONSISTENT_SIZE_BOOL
>  
>  config CONSISTENT_SIZE
>  	hex "Size of consistent memory pool" if CONSISTENT_SIZE_BOOL
> -	default "0x00200000" if NOT_COHERENT_CACHE
> +	default "0x200000" if NOT_COHERENT_CACHE
>  
>  config PIN_TLB
>  	bool "Pinned Kernel TLBs (860 ONLY)"
> @@ -773,15 +773,11 @@ endmenu
>  if PPC64
>  config PAGE_OFFSET
>  	hex
> -	default "0xc000000000000000"
> -config KERNEL_START
> -	hex
> -	default "0xc000000002000000" if CRASH_DUMP
> -	default "0xc000000000000000"
> +	default "0xc0000000"

I don't see where you cope with the "if CRASH_DUMP" case, and in fact my
config changes for the worse when I apply your patch and regenerate my
config:

--- .config.orig	2008-07-08 09:30:00.000000000 +1000
+++ .config	2008-07-08 09:30:43.000000000 +1000
@@ -370,9 +370,8 @@
 CONFIG_HOTPLUG_PCI_RPA=m
 CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
 # CONFIG_HAS_RAPIDIO is not set
-CONFIG_PAGE_OFFSET=0xc000000000000000
-CONFIG_KERNEL_START=0xc000000002000000
-CONFIG_PHYSICAL_START=0x02000000
+CONFIG_PAGE_OFFSET=0xc0000000
+CONFIG_PHYSICAL_START=0x2000000
 

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: linux-next: kbuild tree build failure

[Roman Zippel]

Hi,

On Tue, 8 Jul 2008, Michael Ellerman wrote:

> I don't really see why it "doesn't make sense" for users to input 64-bit
> values, they're configuring addresses for a 64-bit kernel, so some of
> the values are going to be 64 bit.

Do you really expect users to insert random 64bit addresses without making 
a mistake?
Please make a realistic case, where the user input of a full 64bit value 
is required (i.e. where it's not easier to just offer the user a few 
choices).
Currently there is simply no need for this, as even powerpc only used them 
as constants here.

> > Index: linux-2.6/arch/powerpc/Kconfig
> > ===================================================================
> > --- linux-2.6.orig/arch/powerpc/Kconfig
> > +++ linux-2.6/arch/powerpc/Kconfig
> > @@ -714,8 +714,8 @@ config PHYSICAL_START_BOOL
> >  
> >  config PHYSICAL_START
> >  	hex "Physical address where the kernel is loaded" if PHYSICAL_START_BOOL
> > -	default "0x02000000" if PPC_STD_MMU && CRASH_DUMP
> > -	default "0x00000000"
> > +	default "0x2000000" if PPC_STD_MMU && CRASH_DUMP
> > +	default "0"
> >  
> >  config PHYSICAL_ALIGN
> >  	hex
> > @@ -763,7 +763,7 @@ config CONSISTENT_SIZE_BOOL
> >  
> >  config CONSISTENT_SIZE
> >  	hex "Size of consistent memory pool" if CONSISTENT_SIZE_BOOL
> > -	default "0x00200000" if NOT_COHERENT_CACHE
> > +	default "0x200000" if NOT_COHERENT_CACHE
> >  
> >  config PIN_TLB
> >  	bool "Pinned Kernel TLBs (860 ONLY)"
> > @@ -773,15 +773,11 @@ endmenu
> >  if PPC64
> >  config PAGE_OFFSET
> >  	hex
> > -	default "0xc000000000000000"
> > -config KERNEL_START
> > -	hex
> > -	default "0xc000000002000000" if CRASH_DUMP
> > -	default "0xc000000000000000"
> > +	default "0xc0000000"
> 
> I don't see where you cope with the "if CRASH_DUMP" case, and in fact my
> config changes for the worse when I apply your patch and regenerate my
> config:
> 
> --- .config.orig	2008-07-08 09:30:00.000000000 +1000
> +++ .config	2008-07-08 09:30:43.000000000 +1000
> @@ -370,9 +370,8 @@
>  CONFIG_HOTPLUG_PCI_RPA=m
>  CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
>  # CONFIG_HAS_RAPIDIO is not set
> -CONFIG_PAGE_OFFSET=0xc000000000000000
> -CONFIG_KERNEL_START=0xc000000002000000
> -CONFIG_PHYSICAL_START=0x02000000
> +CONFIG_PAGE_OFFSET=0xc0000000
> +CONFIG_PHYSICAL_START=0x2000000

Why is this worse? These are constants, you're not supposed to change them 
anyway.
The remaining values are generated in page.h and should be the same as 
before. If that isn't the case and this patch produces a nonworking 
kernel, I'd like to hear about it.

bye, Roman

Re: linux-next: kbuild tree build failure

[Roman Zippel]

Hi,

On Tue, 8 Jul 2008, Michael Ellerman wrote:

> I don't really see why it "doesn't make sense" for users to input 64-bit
> values, they're configuring addresses for a 64-bit kernel, so some of
> the values are going to be 64 bit.

Do you really expect users to insert random 64bit addresses without making 
a mistake?
Please make a realistic case, where the user input of a full 64bit value 
is required (i.e. where it's not easier to just offer the user a few 
choices).
Currently there is simply no need for this, as even powerpc only used them 
as constants here.

> > Index: linux-2.6/arch/powerpc/Kconfig
> > ===================================================================
> > --- linux-2.6.orig/arch/powerpc/Kconfig
> > +++ linux-2.6/arch/powerpc/Kconfig
> > @@ -714,8 +714,8 @@ config PHYSICAL_START_BOOL
> >  
> >  config PHYSICAL_START
> >  	hex "Physical address where the kernel is loaded" if PHYSICAL_START_BOOL
> > -	default "0x02000000" if PPC_STD_MMU && CRASH_DUMP
> > -	default "0x00000000"
> > +	default "0x2000000" if PPC_STD_MMU && CRASH_DUMP
> > +	default "0"
> >  
> >  config PHYSICAL_ALIGN
> >  	hex
> > @@ -763,7 +763,7 @@ config CONSISTENT_SIZE_BOOL
> >  
> >  config CONSISTENT_SIZE
> >  	hex "Size of consistent memory pool" if CONSISTENT_SIZE_BOOL
> > -	default "0x00200000" if NOT_COHERENT_CACHE
> > +	default "0x200000" if NOT_COHERENT_CACHE
> >  
> >  config PIN_TLB
> >  	bool "Pinned Kernel TLBs (860 ONLY)"
> > @@ -773,15 +773,11 @@ endmenu
> >  if PPC64
> >  config PAGE_OFFSET
> >  	hex
> > -	default "0xc000000000000000"
> > -config KERNEL_START
> > -	hex
> > -	default "0xc000000002000000" if CRASH_DUMP
> > -	default "0xc000000000000000"
> > +	default "0xc0000000"
> 
> I don't see where you cope with the "if CRASH_DUMP" case, and in fact my
> config changes for the worse when I apply your patch and regenerate my
> config:
> 
> --- .config.orig	2008-07-08 09:30:00.000000000 +1000
> +++ .config	2008-07-08 09:30:43.000000000 +1000
> @@ -370,9 +370,8 @@
>  CONFIG_HOTPLUG_PCI_RPA=m
>  CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
>  # CONFIG_HAS_RAPIDIO is not set
> -CONFIG_PAGE_OFFSET=0xc000000000000000
> -CONFIG_KERNEL_START=0xc000000002000000
> -CONFIG_PHYSICAL_START=0x02000000
> +CONFIG_PAGE_OFFSET=0xc0000000
> +CONFIG_PHYSICAL_START=0x2000000

Why is this worse? These are constants, you're not supposed to change them 
anyway.
The remaining values are generated in page.h and should be the same as 
before. If that isn't the case and this patch produces a nonworking 
kernel, I'd like to hear about it.

bye, Roman

Re: linux-next: kbuild tree build failure

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]

On Tue, 2008-07-08 at 04:55 +0200, Roman Zippel wrote:
> Hi,
> 
> On Tue, 8 Jul 2008, Michael Ellerman wrote:
> 
> > I don't really see why it "doesn't make sense" for users to input 64-bit
> > values, they're configuring addresses for a 64-bit kernel, so some of
> > the values are going to be 64 bit.
> 
> Do you really expect users to insert random 64bit addresses without making 
> a mistake?

Well yes :)  But I think that's because you're thinking of 
"end-users" and I'm thinking of "users" like myself - ie. _I_ use
Kconfig and I do expect myself to be able to type a 64-bit address.


> > --- .config.orig	2008-07-08 09:30:00.000000000 +1000
> > +++ .config	2008-07-08 09:30:43.000000000 +1000
> > @@ -370,9 +370,8 @@
> >  CONFIG_HOTPLUG_PCI_RPA=m
> >  CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
> >  # CONFIG_HAS_RAPIDIO is not set
> > -CONFIG_PAGE_OFFSET=0xc000000000000000
> > -CONFIG_KERNEL_START=0xc000000002000000
> > -CONFIG_PHYSICAL_START=0x02000000
> > +CONFIG_PAGE_OFFSET=0xc0000000
> > +CONFIG_PHYSICAL_START=0x2000000
> 
> Why is this worse? These are constants, you're not supposed to change them 
> anyway.
> The remaining values are generated in page.h and should be the same as 
> before. If that isn't the case and this patch produces a nonworking 
> kernel, I'd like to hear about it.

You're right the built kernel is fine. So it's not a bug, but I think it
is nicer to have the real values in the .config.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: linux-next: kbuild tree build failure

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]

On Tue, 2008-07-08 at 04:55 +0200, Roman Zippel wrote:
> Hi,
> 
> On Tue, 8 Jul 2008, Michael Ellerman wrote:
> 
> > I don't really see why it "doesn't make sense" for users to input 64-bit
> > values, they're configuring addresses for a 64-bit kernel, so some of
> > the values are going to be 64 bit.
> 
> Do you really expect users to insert random 64bit addresses without making 
> a mistake?

Well yes :)  But I think that's because you're thinking of 
"end-users" and I'm thinking of "users" like myself - ie. _I_ use
Kconfig and I do expect myself to be able to type a 64-bit address.


> > --- .config.orig	2008-07-08 09:30:00.000000000 +1000
> > +++ .config	2008-07-08 09:30:43.000000000 +1000
> > @@ -370,9 +370,8 @@
> >  CONFIG_HOTPLUG_PCI_RPA=m
> >  CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
> >  # CONFIG_HAS_RAPIDIO is not set
> > -CONFIG_PAGE_OFFSET=0xc000000000000000
> > -CONFIG_KERNEL_START=0xc000000002000000
> > -CONFIG_PHYSICAL_START=0x02000000
> > +CONFIG_PAGE_OFFSET=0xc0000000
> > +CONFIG_PHYSICAL_START=0x2000000
> 
> Why is this worse? These are constants, you're not supposed to change them 
> anyway.
> The remaining values are generated in page.h and should be the same as 
> before. If that isn't the case and this patch produces a nonworking 
> kernel, I'd like to hear about it.

You're right the built kernel is fine. So it's not a bug, but I think it
is nicer to have the real values in the .config.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: linux-next: kbuild tree build failure

[Roman Zippel]

Hi,

On Thu, 10 Jul 2008, Michael Ellerman wrote:

> Well yes :)  But I think that's because you're thinking of 
> "end-users" and I'm thinking of "users" like myself - ie. _I_ use
> Kconfig and I do expect myself to be able to type a 64-bit address.

That doesn't really answer my question, why you need this.

> > > --- .config.orig	2008-07-08 09:30:00.000000000 +1000
> > > +++ .config	2008-07-08 09:30:43.000000000 +1000
> > > @@ -370,9 +370,8 @@
> > >  CONFIG_HOTPLUG_PCI_RPA=m
> > >  CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
> > >  # CONFIG_HAS_RAPIDIO is not set
> > > -CONFIG_PAGE_OFFSET=0xc000000000000000
> > > -CONFIG_KERNEL_START=0xc000000002000000
> > > -CONFIG_PHYSICAL_START=0x02000000
> > > +CONFIG_PAGE_OFFSET=0xc0000000
> > > +CONFIG_PHYSICAL_START=0x2000000
> > 
> > Why is this worse? These are constants, you're not supposed to change them 
> > anyway.
> > The remaining values are generated in page.h and should be the same as 
> > before. If that isn't the case and this patch produces a nonworking 
> > kernel, I'd like to hear about it.
> 
> You're right the built kernel is fine. So it's not a bug,

Good, could someone please ack whether the powerpc changes are acceptable?

> but I think it is nicer to have the real values in the .config.

Why?

bye, Roman

Re: linux-next: kbuild tree build failure

[Roman Zippel]

Hi,

On Thu, 10 Jul 2008, Michael Ellerman wrote:

> Well yes :)  But I think that's because you're thinking of 
> "end-users" and I'm thinking of "users" like myself - ie. _I_ use
> Kconfig and I do expect myself to be able to type a 64-bit address.

That doesn't really answer my question, why you need this.

> > > --- .config.orig	2008-07-08 09:30:00.000000000 +1000
> > > +++ .config	2008-07-08 09:30:43.000000000 +1000
> > > @@ -370,9 +370,8 @@
> > >  CONFIG_HOTPLUG_PCI_RPA=m
> > >  CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
> > >  # CONFIG_HAS_RAPIDIO is not set
> > > -CONFIG_PAGE_OFFSET=0xc000000000000000
> > > -CONFIG_KERNEL_START=0xc000000002000000
> > > -CONFIG_PHYSICAL_START=0x02000000
> > > +CONFIG_PAGE_OFFSET=0xc0000000
> > > +CONFIG_PHYSICAL_START=0x2000000
> > 
> > Why is this worse? These are constants, you're not supposed to change them 
> > anyway.
> > The remaining values are generated in page.h and should be the same as 
> > before. If that isn't the case and this patch produces a nonworking 
> > kernel, I'd like to hear about it.
> 
> You're right the built kernel is fine. So it's not a bug,

Good, could someone please ack whether the powerpc changes are acceptable?

> but I think it is nicer to have the real values in the .config.

Why?

bye, Roman

Re: linux-next: kbuild tree build failure

[Milton Miller]

Hi Roman.

I saw your reply on the list archives but can not find
it in my inbox.

On Sun Jul 13 at 09:21:08 EST 2008, Roman Zippel wrote:
> On Sat, 12 Jul 2008, Milton Miller wrote:
>
>> (1) #define PAGE_OFFSET    (ASM_CONST(CONFIG_PAGE_OFFSET) << 32)
>>
>> It creates unreadable code, where two defines with almost the same
> name (the
>> only difference being
>> the CONFIG_ prefix, which is often ignored when scanning) contains
> radically
>> different values.
>>
>> (2)  #define PAGE_OFFSET    ASM_CONST(CONFIG_PAGE_OFFSET)
>
> Giving it different names is not really difficult. Any objections to
> CONFIG_PAGE_HIGH_OFFSET?

Once you remove the symmetry and add the ifdef to page.h, we need to
reevaluate its presence in Kconfig.   I can't think of a reason to
have a partial value, and therefore would instead say take out the
config variable on PPC64 as the PPC32 address split reason is moot.

>
>> On a seperate note,
>>>>>>  config PINT3_ASSIGN
>>>>>>         hex "PINT3_ASSIGN"
>>>>>>         depends on PINTx_REASSIGN
>>>>>> -       default 0x02020303
>>>>>> +       default 0x2020303
>>
>> is harder to read.   The value is a list of 4 1 byte values, but you
>> have hidden the first nibble making parsing the rest of the value 
>> hard.
>
> Sam mentioned that already, but that's a situation where the warning 
> can
> be relaxed.

The warning can be relaxed?   What are you talking about?

I was trying to make a case for leading zeros without actually stating
what I was asking for.

You changes did s/(0x)?0*/0x/, y/A-F/a-f/ -- that is you made all hex
constants conform to "0x%x".   I was arguing for 0x%8.8x, or just 
leaving
them as formatted.

>
>> If you are worried about users tring to set values that are too high,
>> then make the types be hex8, hex16, hex32, and hex64.
>
> It's not this, I value consistency as much as you and the values are
> sometimes used as integers, so a working range is needed. Using simple
> integers keeps things much simpler and as the ASM_CONST example shows 
> any
> bigger values are not necessarily directly usable anyway.

How many places want to range check hex numbers?   Is it just setting
the number of digits input?  If strtoull is to hard, can we just do
the check as strings of digits?

If we keep this new restriction on hex numbers, it needs to be in
the Documentation, even if its prefixed by "currently".

milton

Re: linux-next: kbuild tree build failure

[Milton Miller]

Hi Roman.

I saw your reply on the list archives but can not find
it in my inbox.

On Sun Jul 13 at 09:21:08 EST 2008, Roman Zippel wrote:
> On Sat, 12 Jul 2008, Milton Miller wrote:
>
>> (1) #define PAGE_OFFSET    (ASM_CONST(CONFIG_PAGE_OFFSET) << 32)
>>
>> It creates unreadable code, where two defines with almost the same
> name (the
>> only difference being
>> the CONFIG_ prefix, which is often ignored when scanning) contains
> radically
>> different values.
>>
>> (2)  #define PAGE_OFFSET    ASM_CONST(CONFIG_PAGE_OFFSET)
>
> Giving it different names is not really difficult. Any objections to
> CONFIG_PAGE_HIGH_OFFSET?

Once you remove the symmetry and add the ifdef to page.h, we need to
reevaluate its presence in Kconfig.   I can't think of a reason to
have a partial value, and therefore would instead say take out the
config variable on PPC64 as the PPC32 address split reason is moot.

>
>> On a seperate note,
>>>>>>  config PINT3_ASSIGN
>>>>>>         hex "PINT3_ASSIGN"
>>>>>>         depends on PINTx_REASSIGN
>>>>>> -       default 0x02020303
>>>>>> +       default 0x2020303
>>
>> is harder to read.   The value is a list of 4 1 byte values, but you
>> have hidden the first nibble making parsing the rest of the value 
>> hard.
>
> Sam mentioned that already, but that's a situation where the warning 
> can
> be relaxed.

The warning can be relaxed?   What are you talking about?

I was trying to make a case for leading zeros without actually stating
what I was asking for.

You changes did s/(0x)?0*/0x/, y/A-F/a-f/ -- that is you made all hex
constants conform to "0x%x".   I was arguing for 0x%8.8x, or just 
leaving
them as formatted.

>
>> If you are worried about users tring to set values that are too high,
>> then make the types be hex8, hex16, hex32, and hex64.
>
> It's not this, I value consistency as much as you and the values are
> sometimes used as integers, so a working range is needed. Using simple
> integers keeps things much simpler and as the ASM_CONST example shows 
> any
> bigger values are not necessarily directly usable anyway.

How many places want to range check hex numbers?   Is it just setting
the number of digits input?  If strtoull is to hard, can we just do
the check as strings of digits?

If we keep this new restriction on hex numbers, it needs to be in
the Documentation, even if its prefixed by "currently".

milton

Re: linux-next: kbuild tree build failure

[Sam Ravnborg]

Hi Roman.

I thought a bit more about this.

> I should have gone through all archs to test this, sorry about that.
> Luckily it's only powerpc that uses 64bit values. I would prefer to 
> standardize on 32bit values, as it doesn't really make sense to expect 
> from the user to input full 64bit values and it's easy to generate the 
> full value in a header.

We use Kconfig for a mixture of user editable values and fixed
configuration values.
And I agree that asking the user to input a 64 bit number is not usefull.

But keeping support for 64 bit values is what I would consider
expected functionality.
So removing support for 64 bit is not good IMO.

> This would also ease on any portability issues 
> (kconfig is compiled with the host compiler not the target compiler).

We use strtol() in a few places in symbol.c already where we do an
implicit conversion to int. Why did this not cause us problems before?

Is it because these code paths are only triggered when we deal with ranges?
If so we could 'fix' strdup_type() to not use strto{,u}l() so it
is 64 bit clean and we are back to old behaviour.

	Sam

Re: linux-next: kbuild tree build failure

[Roman Zippel]

Hi,

On Tue, 8 Jul 2008, Sam Ravnborg wrote:

> We use Kconfig for a mixture of user editable values and fixed
> configuration values.
> And I agree that asking the user to input a 64 bit number is not usefull.
> 
> But keeping support for 64 bit values is what I would consider
> expected functionality.

Isn't that a bit of a stretch? That's a rather generic argument, do we 
really have to keep everything, because someone _might_ want to use it?
I'd rather look at how useful it really is to keep that functionality and 
so far we exactly one user, which doesn't strictly require it.
So far it's more a convenience feature rather than a required feature. We 
don't lose any functionality, it's just shifted from kconfig to the header 
file.

> > This would also ease on any portability issues 
> > (kconfig is compiled with the host compiler not the target compiler).
> 
> We use strtol() in a few places in symbol.c already where we do an
> implicit conversion to int. Why did this not cause us problems before?
> 
> Is it because these code paths are only triggered when we deal with ranges?
> If so we could 'fix' strdup_type() to not use strto{,u}l() so it
> is 64 bit clean and we are back to old behaviour.

Ranges are the primary reason I made it consistent with this.
If we really wanted to support 64bit numbers, it would create only more 
problems. First you have to make sure that on every build host (i.e also 
non-Linux) strtoll() is available. Then how it should these numbers be 
represented? On 32bit these may need a 'll' postfix, but the powerpc 
example already shows, that there are different requirements, so they use 
ASM_CONST for that. How should this postprecessing be integrated into 
kconfig?
I would seriously prefer to keep things as simple as possible, unless 
there is a real requirement for it, but so far there isn't any.
If we really needed something like this, I'd rather introduce a new 
expression type, which works more like an unquoted string (e.g. you 
could define something like (1l<<$PAGE_SHIFT)), where things like ranges 
wouldn't work, but it also wouldn't have any content restrictions.

bye, Roman

Re: linux-next: kbuild tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

Hi Sam,

On Mon, 7 Jul 2008 18:40:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> arch/powerpc/platforms/cell/spu_base.c: In function '__spu_trap_data_seg':
> arch/powerpc/platforms/cell/spu_base.c:194: error: duplicate case value
> arch/powerpc/platforms/cell/spu_base.c:177: error: previously used here

This still fails in linux-next today.  We need some solution before you
send these commits to Linus.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: kbuild tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

Hi Sam,

On Mon, 7 Jul 2008 18:40:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> arch/powerpc/platforms/cell/spu_base.c: In function '__spu_trap_data_seg':
> arch/powerpc/platforms/cell/spu_base.c:194: error: duplicate case value
> arch/powerpc/platforms/cell/spu_base.c:177: error: previously used here

This still fails in linux-next today.  We need some solution before you
send these commits to Linus.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: kbuild tree build failure

[Sam Ravnborg]

On Fri, Jul 25, 2008 at 02:13:30PM +1000, Stephen Rothwell wrote:
> Hi Sam,
> 
> On Mon, 7 Jul 2008 18:40:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > 
> > arch/powerpc/platforms/cell/spu_base.c: In function '__spu_trap_data_seg':
> > arch/powerpc/platforms/cell/spu_base.c:194: error: duplicate case value
> > arch/powerpc/platforms/cell/spu_base.c:177: error: previously used here
> 
> This still fails in linux-next today.  We need some solution before you
> send these commits to Linus.
I removed the offending commits from kbuild-next before I
sent the pull request.
I will though revisit the issue after -rc1.

	Sam

Re: linux-next: kbuild tree build failure

[Sam Ravnborg]

On Fri, Jul 25, 2008 at 02:13:30PM +1000, Stephen Rothwell wrote:
> Hi Sam,
> 
> On Mon, 7 Jul 2008 18:40:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > 
> > arch/powerpc/platforms/cell/spu_base.c: In function '__spu_trap_data_seg':
> > arch/powerpc/platforms/cell/spu_base.c:194: error: duplicate case value
> > arch/powerpc/platforms/cell/spu_base.c:177: error: previously used here
> 
> This still fails in linux-next today.  We need some solution before you
> send these commits to Linus.
I removed the offending commits from kbuild-next before I
sent the pull request.
I will though revisit the issue after -rc1.

	Sam

Re: linux-next: kbuild tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 349 bytes --]

Hi Sam,

On Sat, 26 Jul 2008 12:06:32 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:
>
> I removed the offending commits from kbuild-next before I
> sent the pull request.
> I will though revisit the issue after -rc1.

Thanks again.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: kbuild tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 349 bytes --]

Hi Sam,

On Sat, 26 Jul 2008 12:06:32 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:
>
> I removed the offending commits from kbuild-next before I
> sent the pull request.
> I will though revisit the issue after -rc1.

Thanks again.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]