* linux-next: kbuild tree build failure
@ 2009-05-05 1:17 Stephen Rothwell
2009-05-05 6:35 ` Jan Beulich
2009-05-05 11:11 ` [PATCH] nfs: fix build error in nfsroot with initconst Sam Ravnborg
0 siblings, 2 replies; 56+ messages in thread
From: Stephen Rothwell @ 2009-05-05 1:17 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-next, Jan Beulich, Steven Whitehouse
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2009-05-05 1:17 linux-next: kbuild tree build failure Stephen Rothwell
@ 2009-05-05 6:35 ` Jan Beulich
2009-05-05 6:43 ` Sam Ravnborg
2009-05-05 11:11 ` [PATCH] nfs: fix build error in nfsroot with initconst Sam Ravnborg
1 sibling, 1 reply; 56+ messages in thread
From: Jan Beulich @ 2009-05-05 6:35 UTC (permalink / raw)
To: Stephen Rothwell, Sam Ravnborg; +Cc: StevenWhitehouse, linux-next
>>> 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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2009-05-05 6:35 ` Jan Beulich
@ 2009-05-05 6:43 ` Sam Ravnborg
2009-05-05 7:04 ` Jan Beulich
0 siblings, 1 reply; 56+ messages in thread
From: Sam Ravnborg @ 2009-05-05 6:43 UTC (permalink / raw)
To: Jan Beulich; +Cc: Stephen Rothwell, StevenWhitehouse, linux-next
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2009-05-05 6:43 ` Sam Ravnborg
@ 2009-05-05 7:04 ` Jan Beulich
0 siblings, 0 replies; 56+ messages in thread
From: Jan Beulich @ 2009-05-05 7:04 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Stephen Rothwell, StevenWhitehouse, linux-next
>>> 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
^ permalink raw reply [flat|nested] 56+ messages in thread
* [PATCH] nfs: fix build error in nfsroot with initconst
2009-05-05 1:17 linux-next: kbuild tree build failure Stephen Rothwell
2009-05-05 6:35 ` Jan Beulich
@ 2009-05-05 11:11 ` Sam Ravnborg
2009-05-05 12:48 ` Jan Beulich
2009-05-06 3:32 ` Stephen Rothwell
1 sibling, 2 replies; 56+ messages in thread
From: Sam Ravnborg @ 2009-05-05 11:11 UTC (permalink / raw)
To: Stephen Rothwell, Trond Myklebust
Cc: linux-next, Jan Beulich, Steven Whitehouse
fix build error with latest kbuild adjustments to initconst.
The commit a447c0932445f92ce6f4c1bd020f62c5097a7842 ("vfs: Use
const for kernel parser table") changed:
static match_table_t __initdata tokens = {
to
static match_table_t __initconst tokens = {
But the missing const causes popwerpc to fail with latest
updates to __initconst 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
The bug is only present with kbuild-next.
Following patch has been build tested.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
---
Please apply this either to your -next tree or preferably upstream.
Sam
diff --git a/fs/nfs/nfsroot.c b/fs/nfs/nfsroot.c
index d9ef602..e3ed590 100644
--- a/fs/nfs/nfsroot.c
+++ b/fs/nfs/nfsroot.c
@@ -129,7 +129,7 @@ enum {
Opt_err
};
-static match_table_t __initconst tokens = {
+static const match_table_t tokens __initconst = {
{Opt_port, "port=%u"},
{Opt_rsize, "rsize=%u"},
{Opt_wsize, "wsize=%u"},
^ permalink raw reply related [flat|nested] 56+ messages in thread
* Re: [PATCH] nfs: fix build error in nfsroot with initconst
2009-05-05 11:11 ` [PATCH] nfs: fix build error in nfsroot with initconst Sam Ravnborg
@ 2009-05-05 12:48 ` Jan Beulich
2009-05-06 3:32 ` Stephen Rothwell
1 sibling, 0 replies; 56+ messages in thread
From: Jan Beulich @ 2009-05-05 12:48 UTC (permalink / raw)
To: Stephen Rothwell, Trond Myklebust, Sam Ravnborg
Cc: Steven Whitehouse, linux-next
Acked-by: Jan Beulich <jbeulich@novell.com>
>>> Sam Ravnborg <sam@ravnborg.org> 05.05.09 13:11 >>>
fix build error with latest kbuild adjustments to initconst.
The commit a447c0932445f92ce6f4c1bd020f62c5097a7842 ("vfs: Use
const for kernel parser table") changed:
static match_table_t __initdata tokens = {
to
static match_table_t __initconst tokens = {
But the missing const causes popwerpc to fail with latest
updates to __initconst 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
The bug is only present with kbuild-next.
Following patch has been build tested.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
---
Please apply this either to your -next tree or preferably upstream.
Sam
diff --git a/fs/nfs/nfsroot.c b/fs/nfs/nfsroot.c
index d9ef602..e3ed590 100644
--- a/fs/nfs/nfsroot.c
+++ b/fs/nfs/nfsroot.c
@@ -129,7 +129,7 @@ enum {
Opt_err
};
-static match_table_t __initconst tokens = {
+static const match_table_t tokens __initconst = {
{Opt_port, "port=%u"},
{Opt_rsize, "rsize=%u"},
{Opt_wsize, "wsize=%u"},
^ permalink raw reply related [flat|nested] 56+ messages in thread
* Re: [PATCH] nfs: fix build error in nfsroot with initconst
2009-05-05 11:11 ` [PATCH] nfs: fix build error in nfsroot with initconst Sam Ravnborg
2009-05-05 12:48 ` Jan Beulich
@ 2009-05-06 3:32 ` Stephen Rothwell
2009-05-06 4:40 ` Sam Ravnborg
2009-05-20 1:30 ` Stephen Rothwell
1 sibling, 2 replies; 56+ messages in thread
From: Stephen Rothwell @ 2009-05-06 3:32 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Trond Myklebust, linux-next, Jan Beulich, Steven Whitehouse
[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]
Hi Sam,
On Tue, 5 May 2009 13:11:14 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:
>
> fix build error with latest kbuild adjustments to initconst.
>
> The commit a447c0932445f92ce6f4c1bd020f62c5097a7842 ("vfs: Use
> const for kernel parser table") changed:
>
> static match_table_t __initdata tokens = {
> to
> static match_table_t __initconst tokens = {
>
> But the missing const causes popwerpc to fail with latest
> updates to __initconst 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
>
> The bug is only present with kbuild-next.
> Following patch has been build tested.
>
> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> Cc: Steven Whitehouse <swhiteho@redhat.com>
> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
I build tested this with the offending compilers, so
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
I also build tested with the updates to __initconst as well.
> Please apply this either to your -next tree or preferably upstream.
If you want to keep the __initconst changes in your tree, then you need
the above in your tree as well ... (preferably before the __initconst
changes).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH] nfs: fix build error in nfsroot with initconst
2009-05-06 3:32 ` Stephen Rothwell
@ 2009-05-06 4:40 ` Sam Ravnborg
2009-05-06 13:45 ` Trond Myklebust
2009-05-20 1:30 ` Stephen Rothwell
1 sibling, 1 reply; 56+ messages in thread
From: Sam Ravnborg @ 2009-05-06 4:40 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Trond Myklebust, linux-next, Jan Beulich, Steven Whitehouse
On Wed, May 06, 2009 at 01:32:53PM +1000, Stephen Rothwell wrote:
> Hi Sam,
>
> On Tue, 5 May 2009 13:11:14 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > fix build error with latest kbuild adjustments to initconst.
> >
> > The commit a447c0932445f92ce6f4c1bd020f62c5097a7842 ("vfs: Use
> > const for kernel parser table") changed:
> >
> > static match_table_t __initdata tokens = {
> > to
> > static match_table_t __initconst tokens = {
> >
> > But the missing const causes popwerpc to fail with latest
> > updates to __initconst 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
> >
> > The bug is only present with kbuild-next.
> > Following patch has been build tested.
> >
> > Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Steven Whitehouse <swhiteho@redhat.com>
> > Cc: Stephen Rothwell <sfr@canb.auug.org.au>
>
> I build tested this with the offending compilers, so
>
> Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
>
> I also build tested with the updates to __initconst as well.
>
> > Please apply this either to your -next tree or preferably upstream.
>
> If you want to keep the __initconst changes in your tree, then you need
> the above in your tree as well ... (preferably before the __initconst
> changes).
I hope that Trond would pull it into his tree and get it
upstream.
But if this does not happen within a few days (or Trond says I should do so),
I will add it to the kbuild-next.git.
Sam
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH] nfs: fix build error in nfsroot with initconst
2009-05-06 4:40 ` Sam Ravnborg
@ 2009-05-06 13:45 ` Trond Myklebust
0 siblings, 0 replies; 56+ messages in thread
From: Trond Myklebust @ 2009-05-06 13:45 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Stephen Rothwell, linux-next, Jan Beulich, Steven Whitehouse
On Wed, 2009-05-06 at 06:40 +0200, Sam Ravnborg wrote:
> On Wed, May 06, 2009 at 01:32:53PM +1000, Stephen Rothwell wrote:
> > Hi Sam,
> >
> > On Tue, 5 May 2009 13:11:14 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:
> > >
> > > fix build error with latest kbuild adjustments to initconst.
> > >
> > > The commit a447c0932445f92ce6f4c1bd020f62c5097a7842 ("vfs: Use
> > > const for kernel parser table") changed:
> > >
> > > static match_table_t __initdata tokens = {
> > > to
> > > static match_table_t __initconst tokens = {
> > >
> > > But the missing const causes popwerpc to fail with latest
> > > updates to __initconst 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
> > >
> > > The bug is only present with kbuild-next.
> > > Following patch has been build tested.
> > >
> > > Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> > > Cc: Steven Whitehouse <swhiteho@redhat.com>
> > > Cc: Stephen Rothwell <sfr@canb.auug.org.au>
> >
> > I build tested this with the offending compilers, so
> >
> > Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
> >
> > I also build tested with the updates to __initconst as well.
> >
> > > Please apply this either to your -next tree or preferably upstream.
> >
> > If you want to keep the __initconst changes in your tree, then you need
> > the above in your tree as well ... (preferably before the __initconst
> > changes).
> I hope that Trond would pull it into his tree and get it
> upstream.
>
> But if this does not happen within a few days (or Trond says I should do so),
> I will add it to the kbuild-next.git.
>
> Sam
I've got some stuff from Chuck that I need to send upstream too, so I
expect to send it in the next couple of days...
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [PATCH] nfs: fix build error in nfsroot with initconst
2009-05-06 3:32 ` Stephen Rothwell
2009-05-06 4:40 ` Sam Ravnborg
@ 2009-05-20 1:30 ` Stephen Rothwell
1 sibling, 0 replies; 56+ messages in thread
From: Stephen Rothwell @ 2009-05-20 1:30 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Sam Ravnborg, linux-next, Jan Beulich, Steven Whitehouse
[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]
Hi Trond,
On Wed, 6 May 2009 13:32:53 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Tue, 5 May 2009 13:11:14 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > fix build error with latest kbuild adjustments to initconst.
> >
> > The commit a447c0932445f92ce6f4c1bd020f62c5097a7842 ("vfs: Use
> > const for kernel parser table") changed:
> >
> > static match_table_t __initdata tokens = {
> > to
> > static match_table_t __initconst tokens = {
> >
> > But the missing const causes popwerpc to fail with latest
> > updates to __initconst 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
> >
> > The bug is only present with kbuild-next.
> > Following patch has been build tested.
> >
> > Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Steven Whitehouse <swhiteho@redhat.com>
> > Cc: Stephen Rothwell <sfr@canb.auug.org.au>
>
> I build tested this with the offending compilers, so
>
> Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
Any reason this has not appeared in the nfs (or Linus') tree yet?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2009-10-14 1:20 linux-next: kbuild tree build failure Stephen Rothwell
@ 2009-10-14 7:43 ` Sam Ravnborg
0 siblings, 0 replies; 56+ messages in thread
From: Sam Ravnborg @ 2009-10-14 7:43 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, David S. Miller, Arnaldo Carvalho de Melo
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* linux-next: kbuild tree build failure
@ 2009-10-14 1:20 Stephen Rothwell
2009-10-14 7:43 ` Sam Ravnborg
0 siblings, 1 reply; 56+ messages in thread
From: Stephen Rothwell @ 2009-10-14 1:20 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-next, linux-kernel, David S. Miller, Arnaldo Carvalho de Melo
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2009-06-09 21:04 ` Sam Ravnborg
@ 2009-06-09 23:27 ` Stephen Rothwell
0 siblings, 0 replies; 56+ messages in thread
From: Stephen Rothwell @ 2009-06-09 23:27 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-next, linux-kernel
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2009-06-09 16:19 ` Stephen Rothwell
@ 2009-06-09 21:04 ` Sam Ravnborg
2009-06-09 23:27 ` Stephen Rothwell
0 siblings, 1 reply; 56+ messages in thread
From: Sam Ravnborg @ 2009-06-09 21:04 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2009-06-09 16:15 ` Sam Ravnborg
@ 2009-06-09 16:19 ` Stephen Rothwell
2009-06-09 21:04 ` Sam Ravnborg
0 siblings, 1 reply; 56+ messages in thread
From: Stephen Rothwell @ 2009-06-09 16:19 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-next, linux-kernel
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2009-06-09 1:48 Stephen Rothwell
@ 2009-06-09 16:15 ` Sam Ravnborg
2009-06-09 16:19 ` Stephen Rothwell
0 siblings, 1 reply; 56+ messages in thread
From: Sam Ravnborg @ 2009-06-09 16:15 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* linux-next: kbuild tree build failure
@ 2009-06-09 1:48 Stephen Rothwell
2009-06-09 16:15 ` Sam Ravnborg
0 siblings, 1 reply; 56+ messages in thread
From: Stephen Rothwell @ 2009-06-09 1:48 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-next, linux-kernel
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2008-12-03 0:36 ` Stephen Rothwell
@ 2008-12-03 9:46 ` Sam Ravnborg
0 siblings, 0 replies; 56+ messages in thread
From: Sam Ravnborg @ 2008-12-03 9:46 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2008-11-26 21:06 ` Sam Ravnborg
2008-11-26 23:49 ` Stephen Rothwell
@ 2008-12-03 0:36 ` Stephen Rothwell
2008-12-03 9:46 ` Sam Ravnborg
1 sibling, 1 reply; 56+ messages in thread
From: Stephen Rothwell @ 2008-12-03 0:36 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-next
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2008-11-26 21:06 ` Sam Ravnborg
@ 2008-11-26 23:49 ` Stephen Rothwell
2008-12-03 0:36 ` Stephen Rothwell
1 sibling, 0 replies; 56+ messages in thread
From: Stephen Rothwell @ 2008-11-26 23:49 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-next
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2008-11-26 4:42 Stephen Rothwell
@ 2008-11-26 21:06 ` Sam Ravnborg
2008-11-26 23:49 ` Stephen Rothwell
2008-12-03 0:36 ` Stephen Rothwell
0 siblings, 2 replies; 56+ messages in thread
From: Sam Ravnborg @ 2008-11-26 21:06 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* linux-next: kbuild tree build failure
@ 2008-11-26 4:42 Stephen Rothwell
2008-11-26 21:06 ` Sam Ravnborg
0 siblings, 1 reply; 56+ messages in thread
From: Stephen Rothwell @ 2008-11-26 4:42 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-next
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2008-11-25 8:42 ` Sam Ravnborg
@ 2008-11-25 8:58 ` Stephen Rothwell
0 siblings, 0 replies; 56+ messages in thread
From: Stephen Rothwell @ 2008-11-25 8:58 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-next
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2008-11-25 4:47 Stephen Rothwell
@ 2008-11-25 8:42 ` Sam Ravnborg
2008-11-25 8:58 ` Stephen Rothwell
0 siblings, 1 reply; 56+ messages in thread
From: Sam Ravnborg @ 2008-11-25 8:42 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* linux-next: kbuild tree build failure
@ 2008-11-25 4:47 Stephen Rothwell
2008-11-25 8:42 ` Sam Ravnborg
0 siblings, 1 reply; 56+ messages in thread
From: Stephen Rothwell @ 2008-11-25 4:47 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-next
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2008-07-26 10:06 ` Sam Ravnborg
@ 2008-07-26 12:40 ` Stephen Rothwell
-1 siblings, 0 replies; 56+ messages in thread
From: Stephen Rothwell @ 2008-07-26 12:40 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-next, Roman Zippel, Paul Mackerras, linuxppc-dev,
Benjamin Herrenschmidt, Milton Miller, Michael Ellerman
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
@ 2008-07-26 12:40 ` Stephen Rothwell
0 siblings, 0 replies; 56+ messages in thread
From: Stephen Rothwell @ 2008-07-26 12:40 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Benjamin, Milton Miller, linuxppc-dev, linux-next, Mackerras, Paul
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2008-07-25 4:13 ` Stephen Rothwell
@ 2008-07-26 10:06 ` Sam Ravnborg
-1 siblings, 0 replies; 56+ messages in thread
From: Sam Ravnborg @ 2008-07-26 10:06 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, Roman Zippel, Paul Mackerras, linuxppc-dev,
Benjamin Herrenschmidt, Milton Miller, Michael Ellerman
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
@ 2008-07-26 10:06 ` Sam Ravnborg
0 siblings, 0 replies; 56+ messages in thread
From: Sam Ravnborg @ 2008-07-26 10:06 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Milton Miller, linuxppc-dev, linux-next, Paul Mackerras
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2008-07-07 8:40 ` Stephen Rothwell
@ 2008-07-25 4:13 ` Stephen Rothwell
-1 siblings, 0 replies; 56+ messages in thread
From: Stephen Rothwell @ 2008-07-25 4:13 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-next, Roman Zippel, Paul Mackerras, linuxppc-dev,
Benjamin Herrenschmidt, Milton Miller, Michael Ellerman
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
@ 2008-07-25 4:13 ` Stephen Rothwell
0 siblings, 0 replies; 56+ messages in thread
From: Stephen Rothwell @ 2008-07-25 4:13 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Benjamin, Milton Miller, linuxppc-dev, linux-next, Mackerras, Paul
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2008-07-10 14:59 ` Roman Zippel
@ 2008-07-14 16:53 ` Milton Miller
-1 siblings, 0 replies; 56+ messages in thread
From: Milton Miller @ 2008-07-14 16:53 UTC (permalink / raw)
To: Roman Zippel
Cc: ppcdev, Stephen Rothwell, linux-kernel, Michael Ellerman,
Paul Mackerras, Benjamin Herrenschmidt, Sam Ravnborg
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
@ 2008-07-14 16:53 ` Milton Miller
0 siblings, 0 replies; 56+ messages in thread
From: Milton Miller @ 2008-07-14 16:53 UTC (permalink / raw)
To: Roman Zippel
Cc: Stephen Rothwell, linux-kernel, ppcdev, Paul Mackerras, Sam Ravnborg
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2008-07-12 22:32 ` Milton Miller
@ 2008-07-12 23:21 ` Roman Zippel
-1 siblings, 0 replies; 56+ messages in thread
From: Roman Zippel @ 2008-07-12 23:21 UTC (permalink / raw)
To: Milton Miller
Cc: ppcdev, Stephen Rothwell, linux-kernel, Michael Ellerman,
Paul Mackerras, Sam Ravnborg, Benjamin Herrenschmidt
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
@ 2008-07-12 23:21 ` Roman Zippel
0 siblings, 0 replies; 56+ messages in thread
From: Roman Zippel @ 2008-07-12 23:21 UTC (permalink / raw)
To: Milton Miller
Cc: Stephen Rothwell, linux-kernel, ppcdev, Paul Mackerras, Sam Ravnborg
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
@ 2008-07-12 22:32 ` Milton Miller
0 siblings, 0 replies; 56+ messages in thread
From: Milton Miller @ 2008-07-12 22:32 UTC (permalink / raw)
To: Roman Zippel
Cc: ppcdev, Stephen Rothwell, linux-kernel, Michael Ellerman,
Paul Mackerras, Sam Ravnborg, Benjamin Herrenschmidt
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
@ 2008-07-12 22:32 ` Milton Miller
0 siblings, 0 replies; 56+ messages in thread
From: Milton Miller @ 2008-07-12 22:32 UTC (permalink / raw)
To: Roman Zippel
Cc: Stephen Rothwell, linux-kernel, ppcdev, Paul Mackerras, Sam Ravnborg
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2008-07-10 0:51 ` Michael Ellerman
@ 2008-07-10 14:59 ` Roman Zippel
-1 siblings, 0 replies; 56+ messages in thread
From: Roman Zippel @ 2008-07-10 14:59 UTC (permalink / raw)
To: Michael Ellerman
Cc: Stephen Rothwell, Paul Mackerras, linux-next, Sam Ravnborg, linuxppc-dev
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
@ 2008-07-10 14:59 ` Roman Zippel
0 siblings, 0 replies; 56+ messages in thread
From: Roman Zippel @ 2008-07-10 14:59 UTC (permalink / raw)
To: Michael Ellerman
Cc: Stephen Rothwell, linux-next, Paul Mackerras, Sam Ravnborg, linuxppc-dev
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2008-07-08 21:19 ` Sam Ravnborg
@ 2008-07-10 14:52 ` Roman Zippel
0 siblings, 0 replies; 56+ messages in thread
From: Roman Zippel @ 2008-07-10 14:52 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Stephen Rothwell, linux-next, Paul Mackerras, linuxppc-dev
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2008-07-08 2:55 ` Roman Zippel
@ 2008-07-10 0:51 ` Michael Ellerman
-1 siblings, 0 replies; 56+ messages in thread
From: Michael Ellerman @ 2008-07-10 0:51 UTC (permalink / raw)
To: Roman Zippel
Cc: Stephen Rothwell, Paul Mackerras, linux-next, Sam Ravnborg, linuxppc-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
@ 2008-07-10 0:51 ` Michael Ellerman
0 siblings, 0 replies; 56+ messages in thread
From: Michael Ellerman @ 2008-07-10 0:51 UTC (permalink / raw)
To: Roman Zippel
Cc: Stephen Rothwell, linux-next, Paul Mackerras, Sam Ravnborg, linuxppc-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2008-07-07 16:13 ` Roman Zippel
` (2 preceding siblings ...)
(?)
@ 2008-07-08 21:19 ` Sam Ravnborg
2008-07-10 14:52 ` Roman Zippel
-1 siblings, 1 reply; 56+ messages in thread
From: Sam Ravnborg @ 2008-07-08 21:19 UTC (permalink / raw)
To: Roman Zippel; +Cc: Stephen Rothwell, linux-next, Paul Mackerras, linuxppc-dev
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2008-07-07 23:36 ` Michael Ellerman
@ 2008-07-08 2:55 ` Roman Zippel
-1 siblings, 0 replies; 56+ messages in thread
From: Roman Zippel @ 2008-07-08 2:55 UTC (permalink / raw)
To: Michael Ellerman
Cc: Stephen Rothwell, Paul Mackerras, linux-next, Sam Ravnborg, linuxppc-dev
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
@ 2008-07-08 2:55 ` Roman Zippel
0 siblings, 0 replies; 56+ messages in thread
From: Roman Zippel @ 2008-07-08 2:55 UTC (permalink / raw)
To: Michael Ellerman
Cc: Stephen Rothwell, linux-next, Paul Mackerras, Sam Ravnborg, linuxppc-dev
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2008-07-07 16:13 ` Roman Zippel
@ 2008-07-07 23:36 ` Michael Ellerman
-1 siblings, 0 replies; 56+ messages in thread
From: Michael Ellerman @ 2008-07-07 23:36 UTC (permalink / raw)
To: Roman Zippel
Cc: Stephen Rothwell, Paul Mackerras, linux-next, Sam Ravnborg, linuxppc-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
@ 2008-07-07 23:36 ` Michael Ellerman
0 siblings, 0 replies; 56+ messages in thread
From: Michael Ellerman @ 2008-07-07 23:36 UTC (permalink / raw)
To: Roman Zippel
Cc: Stephen Rothwell, linux-next, Paul Mackerras, Sam Ravnborg, linuxppc-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2008-07-07 16:13 ` Roman Zippel
(?)
@ 2008-07-07 21:01 ` Sam Ravnborg
-1 siblings, 0 replies; 56+ messages in thread
From: Sam Ravnborg @ 2008-07-07 21:01 UTC (permalink / raw)
To: Roman Zippel; +Cc: Stephen Rothwell, linux-next, Paul Mackerras, linuxppc-dev
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2008-07-07 8:40 ` Stephen Rothwell
@ 2008-07-07 16:13 ` Roman Zippel
-1 siblings, 0 replies; 56+ messages in thread
From: Roman Zippel @ 2008-07-07 16:13 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Sam Ravnborg, linux-next, Paul Mackerras, linuxppc-dev
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__
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
@ 2008-07-07 16:13 ` Roman Zippel
0 siblings, 0 replies; 56+ messages in thread
From: Roman Zippel @ 2008-07-07 16:13 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Paul Mackerras, linux-next, Sam Ravnborg, linuxppc-dev
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__
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2008-07-07 12:51 ` Sam Ravnborg
@ 2008-07-07 13:08 ` Stephen Rothwell
-1 siblings, 0 replies; 56+ messages in thread
From: Stephen Rothwell @ 2008-07-07 13:08 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-next, Roman Zippel, Paul Mackerras, linuxppc-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
@ 2008-07-07 13:08 ` Stephen Rothwell
0 siblings, 0 replies; 56+ messages in thread
From: Stephen Rothwell @ 2008-07-07 13:08 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linuxppc-dev, Paul, linux-next, Mackerras
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
2008-07-07 8:40 ` Stephen Rothwell
@ 2008-07-07 12:51 ` Sam Ravnborg
-1 siblings, 0 replies; 56+ messages in thread
From: Sam Ravnborg @ 2008-07-07 12:51 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Roman Zippel, Paul Mackerras, linuxppc-dev
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: linux-next: kbuild tree build failure
@ 2008-07-07 12:51 ` Sam Ravnborg
0 siblings, 0 replies; 56+ messages in thread
From: Sam Ravnborg @ 2008-07-07 12:51 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, linux-next, Paul Mackerras
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* linux-next: kbuild tree build failure
@ 2008-07-07 8:40 ` Stephen Rothwell
0 siblings, 0 replies; 56+ messages in thread
From: Stephen Rothwell @ 2008-07-07 8:40 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-next, Roman Zippel, Paul Mackerras, linuxppc-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* linux-next: kbuild tree build failure
@ 2008-07-07 8:40 ` Stephen Rothwell
0 siblings, 0 replies; 56+ messages in thread
From: Stephen Rothwell @ 2008-07-07 8:40 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linuxppc-dev, Paul, linux-next, Mackerras
[-- 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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
end of thread, other threads:[~2009-10-14 7:44 UTC | newest]
Thread overview: 56+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-05 1:17 linux-next: kbuild tree build failure Stephen Rothwell
2009-05-05 6:35 ` Jan Beulich
2009-05-05 6:43 ` Sam Ravnborg
2009-05-05 7:04 ` Jan Beulich
2009-05-05 11:11 ` [PATCH] nfs: fix build error in nfsroot with initconst Sam Ravnborg
2009-05-05 12:48 ` Jan Beulich
2009-05-06 3:32 ` Stephen Rothwell
2009-05-06 4:40 ` Sam Ravnborg
2009-05-06 13:45 ` Trond Myklebust
2009-05-20 1:30 ` Stephen Rothwell
-- strict thread matches above, loose matches on Subject: below --
2009-10-14 1:20 linux-next: kbuild tree build failure Stephen Rothwell
2009-10-14 7:43 ` Sam Ravnborg
2009-06-09 1:48 Stephen Rothwell
2009-06-09 16:15 ` Sam Ravnborg
2009-06-09 16:19 ` Stephen Rothwell
2009-06-09 21:04 ` Sam Ravnborg
2009-06-09 23:27 ` Stephen Rothwell
2008-11-26 4:42 Stephen Rothwell
2008-11-26 21:06 ` Sam Ravnborg
2008-11-26 23:49 ` Stephen Rothwell
2008-12-03 0:36 ` Stephen Rothwell
2008-12-03 9:46 ` Sam Ravnborg
2008-11-25 4:47 Stephen Rothwell
2008-11-25 8:42 ` Sam Ravnborg
2008-11-25 8:58 ` Stephen Rothwell
2008-07-12 22:32 Milton Miller
2008-07-12 22:32 ` Milton Miller
2008-07-12 23:21 ` Roman Zippel
2008-07-12 23:21 ` Roman Zippel
2008-07-07 8:40 Stephen Rothwell
2008-07-07 8:40 ` Stephen Rothwell
2008-07-07 12:51 ` Sam Ravnborg
2008-07-07 12:51 ` Sam Ravnborg
2008-07-07 13:08 ` Stephen Rothwell
2008-07-07 13:08 ` Stephen Rothwell
2008-07-07 16:13 ` Roman Zippel
2008-07-07 16:13 ` Roman Zippel
2008-07-07 21:01 ` Sam Ravnborg
2008-07-07 23:36 ` Michael Ellerman
2008-07-07 23:36 ` Michael Ellerman
2008-07-08 2:55 ` Roman Zippel
2008-07-08 2:55 ` Roman Zippel
2008-07-10 0:51 ` Michael Ellerman
2008-07-10 0:51 ` Michael Ellerman
2008-07-10 14:59 ` Roman Zippel
2008-07-10 14:59 ` Roman Zippel
2008-07-14 16:53 ` Milton Miller
2008-07-14 16:53 ` Milton Miller
2008-07-08 21:19 ` Sam Ravnborg
2008-07-10 14:52 ` Roman Zippel
2008-07-25 4:13 ` Stephen Rothwell
2008-07-25 4:13 ` Stephen Rothwell
2008-07-26 10:06 ` Sam Ravnborg
2008-07-26 10:06 ` Sam Ravnborg
2008-07-26 12:40 ` Stephen Rothwell
2008-07-26 12:40 ` Stephen Rothwell
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.