Re: mainline build failure of powerpc allmodconfig for prom_init_check

[Linus Torvalds]

On Mon, Jul 18, 2022 at 3:12 PM Segher Boessenkool
 wrote:
>
> Assembler language is unforgiving.  It isn't easy to write, and most
> mistakes will not be diagnosed.  If the assmbler language makes it
> easier to read the code, that makes it more likely correct code will be
> written, and that correct code will be written in less time.

What's your argument? That it's unforgiving, so it has to be
unreadable and easy to make mistakes in too?

You can get the order of operands wrong, and it will still build -
just to completely the wrong thing.

> > Oddities, yes ("$" as a prefix for register? Alpha asm is also very
> > odd), but nothing *quite* as broken as "simple constants have entirely
> > different meanings depending on the exact instruction and argument
> > position".
>
> What is broken about that?  It makes everything very consistent, and
> very readable.  Sigils are just nasty, and having the register names the
> same as valid symbol names is also problematic.

Oh, I agree that sigils are good to make the type clear. So '%r4' is
better than 'r4' because the latter could be ambiguous and you could
have a symbol 'r4'.

But just '4' is plain garbage.  There's no "could be ambiguous" about it.

Type checking matters. Not just in C. In asm too.

The reason '$0' is odd because it's *just* a sigil and a number.

Which certainly is not unusual in itself, but it reads like it's a
number to me. Not just because of x86 gas ('$' means 'immediate'), but
Z80 ('$' means HEX), or at least 'Nth argument' (shell).

And yeah, alpha got it from MIPS, afaik.

And presumably MIPS got it from "we're hacking up the simplest
assembler we can".

> > The human-written asm files have those #define's in headers just to
> > make things slightly more legible, because apparently the assembler
> > doesn't even *accept* the sane names.
>
> That was true a long time ago.  And the "#define r0 0" thing caused
> quite a few bugs itself btw.

Those #define's still exist. Look it up.

And yes, they are horrible, and they are wrong, and they shouldn't exist.

   Linus

Re: mainline build failure of powerpc allmodconfig for prom_init_check

[Segher Boessenkool]

On Mon, Jul 18, 2022 at 12:06:52PM -0700, Linus Torvalds wrote:
> On Sun, Jul 17, 2022 at 9:41 PM Michael Ellerman  wrote:
> > > li 4,254 #,
> >
> > Here we load 254 into r4, which is the 2nd parameter to memset (c).
> 
> I love how even powerpc people know that "4" is bogus, and have to
> make it clear that it means "r4".

This is compiler output.  Compiler output is mainly meant for the
assembler to produce object code from.  It isn't meant to be readable
(and e.g. -fverbose-asm didn't help much here, that's the "#," ;-) ).

The mnemonic determines what the operands mean.  It is much easier to
read and write "li 4,254" than "li r4,254" or "li %r4,254", all of which
are valid.  You can also write "li 3+1,2*127", but not with the other
forms (this is useful if you use assembler macros, which are way more
powerful and appropriate than abusing the C preprocessor, when writing
assembler code).

It matters more if you have three or four or five or six operands to an
assembler instruction, all the extra line noise makes things illegible.

The "%r4" variant hails from winnt.  It is a bit problematic in inline
assembler, because you need to escape the % in extended inline asm, but
not in basic inline asm.  It also is pure line noise to read.

The "r4" variant is problematic if you have symbols named the same.
When you use the -mregnames assembler option it is taken to mean the
register; you can write "(r6)" to mean the symbol.  (There also are "sp"
and "rtos" and "xer" and whatnot, not just "r4").

> I don't understand why the powerpc assembler is so messed up, and uses
> random integer constants for register "names".

360 was the same.  370 was the same.  390 is the same.  801 was the
same.  RIOS (aka POWER) was the same.  So yes, PowerPC inherited it, I
don't know how much thought was put into this, don't change a winning
team etc.

> And it gets even worse, when you start mixing FP, vector and integer "names".

It is clear from the mnemonic what the operands are: some register, an
immediate, a constant, etc.  An expression (which can include object
symbols) can be any of those.

Assembler language is unforgiving.  It isn't easy to write, and most
mistakes will not be diagnosed.  If the assmbler language makes it
easier to read the code, that makes it more likely correct code will be
written, and that correct code will be written in less time.

> I've seen many bad assemblers (in fact, I have *written* a couple of
> bad assemblers myself), but I have never seen anything quite that
> broken on any other architecture.
> 
> Oddities, yes ("$" as a prefix for register? Alpha asm is also very
> odd), but nothing *quite* as broken as "simple constants have entirely
> different meanings depending on the exact instruction and argument
> position".

What is broken about that?  It makes everything very consistent, and
very readable.  Sigils are just nasty, and having the register names the
same as valid symbol names is also problematic.

> It's not even an IBM thing. S390 uses perfectly sane register syntax,
> and calls things '%r4" etc.

s390 has the same syntax, and even inherited the GAS code for this from
the ppc port.

> The human-written asm files have those #define's in headers just to
> make things slightly more legible, because apparently the assembler
> doesn't even *accept* the sane names.

That was true a long time ago.  And the "#define r0 0" thing caused
quite a few bugs itself btw.

> So it's not even a "the compiler
> generates this abbreviated illegible mess". It's literally that the
> assembler is so horrid.

The disassembler has shown "r4" etc. by default since ages.  The
assembler needs -mregnames to accept it; enabling this by default would
be a compatibility break, not acceptable.

> Why do people put up with that?

Why are people misinformed?

Is there anything in particular in the documentation we could improve?


Hope this helps,


Segher

Re: mainline build failure of powerpc allmodconfig for prom_init_check

[Linus Torvalds]

On Sun, Jul 17, 2022 at 9:41 PM Michael Ellerman  wrote:
>
> > li 4,254 #,
>
> Here we load 254 into r4, which is the 2nd parameter to memset (c).

I love how even powerpc people know that "4" is bogus, and have to
make it clear that it means "r4".

I don't understand why the powerpc assembler is so messed up, and uses
random integer constants for register "names".

And it gets even worse, when you start mixing FP, vector and integer "names".

I've seen many bad assemblers (in fact, I have *written* a couple of
bad assemblers myself), but I have never seen anything quite that
broken on any other architecture.

Oddities, yes ("$" as a prefix for register? Alpha asm is also very
odd), but nothing *quite* as broken as "simple constants have entirely
different meanings depending on the exact instruction and argument
position".

It's not even an IBM thing. S390 uses perfectly sane register syntax,
and calls things '%r4" etc.

The human-written asm files have those #define's in headers just to
make things slightly more legible, because apparently the assembler
doesn't even *accept* the sane names. So it's not even a "the compiler
generates this abbreviated illegible mess". It's literally that the
assembler is so horrid.

Why do people put up with that?

   Linus

Re: mainline build failure of powerpc allmodconfig for prom_init_check

[Segher Boessenkool]

On Mon, Jul 18, 2022 at 01:52:38PM +1000, Michael Ellerman wrote:
> Segher Boessenkool  writes:
> > Can't we simply have a small simple implementation of these functions in
> > arch/powerpc/boot/?  This stuff is not performance-critical, and this is
> > not the first time we hit these problems.
> 
> prom_init.c isn't in arch/powerpc/boot :)

Ah duh :-)

> It's linked into the kernel proper, but we want it to behave like a
> pre-boot environment (because not all boot paths run it) which is why we
> restrict what symbols it can call.
> 
> We could have a prom_memset() etc. but we'd need to do some tricks to
> rewrite references to memset() to prom_memset() before linking.

You can do it in its linker script?


Segher

RE: mainline build failure of powerpc allmodconfig for prom_init_check

[David Laight]

From: Michael Ellerman
> Sent: 18 July 2022 05:41
...
> So we're memsetting all of args to 254, not zero.
> 
> That's happening because allmodconfig with gcc 12 enables
> CONFIG_INIT_STACK_ALL_PATTERN, whereas gcc 11 doesn't.

I can't help feeling it would be better if that generated
a call to a memset64() function.
Saving loads of tests at the top of the function,
and (most of?) the constant expansion to 64bit.

Although and explicit 'stack clear' function would be better
for the kernel - since it would give the option of patching
it away at startup.

I really can't help feeling that initialising on-stack
arrays will kill performance.
While kernel stack frames have to be relatively small,
in userspace very large on-stack arrays can be allocated
(and correctly bound checked) knowing that the cost is
minimal (maybe a TLB miss).

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

Re: mainline build failure of powerpc allmodconfig for prom_init_check

[Michael Ellerman]

Sudip Mukherjee  writes:
> On Thu, Jul 14, 2022 at 9:55 AM Sudip Mukherjee (Codethink)
>  wrote:
>>
>> Hi All,
>>
>> Not sure if it has been reported before but the latest mainline kernel
>> branch fails to build for powerpc allmodconfig with gcc-12 and the error is:
>>
>> Error: External symbol 'memset' referenced from prom_init.c
>> make[2]: *** [arch/powerpc/kernel/Makefile:204: 
>> arch/powerpc/kernel/prom_init_check] Error 1
>
> I was trying to check it. With gcc-11 the assembly code generated is
> not using memset, but using __memset.
> But with gcc-12, I can see the assembly code is using memset. One
> example from the assembly:
>
> call_prom:
> .quad   .call_prom,.TOC.@tocbase,0
> .previous
> .size   call_prom,24
> .type   .call_prom,@function
> .call_prom:
> mflr 0   #,
> std 29,-24(1)#,
> std 30,-16(1)#,
> std 31,-8(1) #,
> mr 29,3  # tmp166, service
> mr 31,4  # nargs, tmp167
> mr 30,5  # tmp168, nret
>  # arch/powerpc/kernel/prom_init.c:396: struct prom_args args;
> li 4,254 #,

Here we load 254 into r4, which is the 2nd parameter to memset (c).

> li 5,52  #,

This is r5, the 3rd parameter (n), ie. the size of the structure.

That tells us we're memsetting the entire structure, ie. the 10 x 4
bytes of args.args plus 3 x 4 bytes for the other members.

>  # arch/powerpc/kernel/prom_init.c:394: {
> std 0,16(1)  #,
> stdu 1,-208(1)   #,,
>  # arch/powerpc/kernel/prom_init.c:396: struct prom_args args;
> addi 3,1,112 # tmp174,,

Here we load (calculate) the address of "args" into r3, the first
parameter to memset.

>  # arch/powerpc/kernel/prom_init.c:394: {
> std 9,304(1) #,
> std 10,312(1)#,
> std 6,280(1) #,
> std 7,288(1) #,
> std 8,296(1) #,
>  # arch/powerpc/kernel/prom_init.c:396: struct prom_args args;
> bl .memset   #

So we're memsetting all of args to 254, not zero.

That's happening because allmodconfig with gcc 12 enables
CONFIG_INIT_STACK_ALL_PATTERN, whereas gcc 11 doesn't.

I think the simplest fix in the short term is to just disable stack
initialisation for prom_init.c. It only runs at boot so there's no real
security impact to disabling it.

cheers

Re: mainline build failure of powerpc allmodconfig for prom_init_check

[Michael Ellerman]

Segher Boessenkool  writes:
> On Sun, Jul 17, 2022 at 07:44:22AM -0700, Linus Torvalds wrote:
>> On Sun, Jul 17, 2022 at 2:13 AM Sudip Mukherjee
>>  wrote:
>> > I was trying to check it. With gcc-11 the assembly code generated is
>> > not using memset, but using __memset.
>> > But with gcc-12, I can see the assembly code is using memset. One
>> > example from the assembly:
>> 
>> You could try making the 'args' array in 'struct prom_args' be marked
>> 'volatile'.
>> 
>> Ie something like this:
>> 
>>   --- a/arch/powerpc/kernel/prom_init.c
>>   +++ b/arch/powerpc/kernel/prom_init.c
>>   @@ -115,6 +115,6 @@ struct prom_args {
>>__be32 service;
>>__be32 nargs;
>>__be32 nret;
>>   -  __be32 args[10];
>>   +volatile __be32 args[10];
>>};
>> 
>> because I think it's just the compilers turning the small loop over
>> those fields into a "memset()".
>
> Yes.  See 
> near the end:
>   Most of the compiler support routines used by GCC are present in
>   libgcc, but there are a few exceptions. GCC requires the freestanding
>   environment provide memcpy, memmove, memset and memcmp. Finally, if
>   __builtin_trap is used, and the target does not implement the trap
>   pattern, then GCC emits a call to abort.
>
> Can't we simply have a small simple implementation of these functions in
> arch/powerpc/boot/?  This stuff is not performance-critical, and this is
> not the first time we hit these problems.

prom_init.c isn't in arch/powerpc/boot :)

It's linked into the kernel proper, but we want it to behave like a
pre-boot environment (because not all boot paths run it) which is why we
restrict what symbols it can call.

We could have a prom_memset() etc. but we'd need to do some tricks to
rewrite references to memset() to prom_memset() before linking.

cheers

Re: mainline build failure of powerpc allmodconfig for prom_init_check

[Linus Torvalds]

On Sun, Jul 17, 2022 at 2:49 PM Segher Boessenkool
 wrote:
>
> > I can *kind of* see the logic that when you do a whole struct
> > assignment, it turns into a "memcpy" without regard for volatile
> > members. You're not actually accessing the volatile members in some
> > particular order, so the struct assignment arguably does not really
> > have an access ordering that needs to be preserved.
>
> The order is not defined, correct.  But a "volatile int" can only be
> accessed as an int, and an external memcpy will typically use different
> size accesses, and can even access some fields more than once (or
> partially); all not okay for a volatile object.

That is not actually a valid or realistic argument in the general case.

The thing is, an operation on an aggregate type in C is fundamentally
different from the "do the same operation on the individual parts of
the struct".

Just to make a very concrete example of that, it's not at all
unreasonable to have a struct like this:

struct io_accessor {
union {
volatile unsigned char byte[8];
volatile unsigned short word[4];
...

and while that wasn't the example here, it's not completely insane as
a concept to use as a helper type so that you can do volatile accesses
of different sizes.

And while you'd be right to say that "assigning that kind of struct is
probably insane", and I wouldn't argue against it, I also think that
basically *any* union member is basically an argument that a structure
assignment is *NOT* about "assign all the individual members", and
never really can be.

In the above union, make one union member be a non-volatile type, and
suddenly it actually *can* be ok to copy the struct. Even though it
also has volatile bytes.

So once you start doing structure assignments but argue about
individual fields being volatile, I think you're on very shaky ground.

And I think "memcpy" is a reasonable way to say "we don't care - and
in the general case we CANNOT know - what the individual members are,
so we'll just copy it as one thing".

So the compiler emitting a "memcpy()" to assign a structure sounds
fine. Even in theory. Because the "but individual fields.." argument
just cannot work in general.

In contrast, when you access the members individually (like the kernel
does in this powerpc case), there is no such ambiguity.

There is no way in hell that it is ever ok to do a "memcpy()" when the
user has done the assignments one volatile member at a time.

So that's why I don't think your test-case with the struct assignment
is very good. I think it's very reasonable for a compiler person to
say "you assigned the whole struct, you get what you asked for, you
get a memcpy".

But when you do a loop that assigns individual volatile fields? No
such problem. Completely unambiguous that you need to do them one at a
time as individual accesses.

Linus

Re: mainline build failure of powerpc allmodconfig for prom_init_check

[Segher Boessenkool]

On Sun, Jul 17, 2022 at 02:11:52PM -0700, Linus Torvalds wrote:
> On Sun, Jul 17, 2022 at 2:00 PM Segher Boessenkool
>  wrote:
> > Calling mem* on a volatile object (or a struct containing one) is not
> > valid.  I opened gcc.gnu.org/PR106335.
> 
> Well, that very quickly got marked as a duplicate of a decade-old bug.
> 
> So I guess we shouldn't expect this to be fixed any time soon.

It shouldn't be all that hard to implement.  GCC wants all ports to
define their own mem* because these functions are so critical for
performance, but it isn't hard to do a straightforward by-field copy
for assignments if using memcpy would not be valid at all.  Also, if
we would have this we could make a compiler flag saying to always
open-code this, getting rid of this annoyance (namely, that extetnal
mem* are required) for -ffreestanding.

> That said, your test-case of copying the whole structure is very
> different from the one in the kernel that works on them one structure
> member at a time.
> 
> I can *kind of* see the logic that when you do a whole struct
> assignment, it turns into a "memcpy" without regard for volatile
> members. You're not actually accessing the volatile members in some
> particular order, so the struct assignment arguably does not really
> have an access ordering that needs to be preserved.

The order is not defined, correct.  But a "volatile int" can only be
accessed as an int, and an external memcpy will typically use different
size accesses, and can even access some fields more than once (or
partially); all not okay for a volatile object.

> But the kernel code in question very much does access the members
> individually, and so I think that the compiler quite unequivocally did
> something horribly horribly bad by turning them into a memset.
> 
> So I don't think your test-case is really particularly good, and maybe
> that's why that old bug has languished for over a decade - people
> didn't realize just *how* incredibly broken it was.

People haven't looked at my test case for all that time, it sprouted
from my demented mind just minutes ago ;-)  The purpose of writing it
this way was to make sure that memcpy will be called for this (on any
target etc.), not some shorter and/or smarter thing.

I don't know what the real reason is that this bugs hasn't been fixed
yet.  It should be quite easy to make this more correct.  In

Richard suggested doing it in the frontend, which seems reasonable (but
more work than the patch there).

There have been no follow-up patches as far as I can see :-(


Segher

Re: mainline build failure of powerpc allmodconfig for prom_init_check

[Linus Torvalds]

On Sun, Jul 17, 2022 at 2:00 PM Segher Boessenkool
 wrote:
>
> Calling mem* on a volatile object (or a struct containing one) is not
> valid.  I opened gcc.gnu.org/PR106335.

Well, that very quickly got marked as a duplicate of a decade-old bug.

So I guess we shouldn't expect this to be fixed any time soon.

That said, your test-case of copying the whole structure is very
different from the one in the kernel that works on them one structure
member at a time.

I can *kind of* see the logic that when you do a whole struct
assignment, it turns into a "memcpy" without regard for volatile
members. You're not actually accessing the volatile members in some
particular order, so the struct assignment arguably does not really
have an access ordering that needs to be preserved.

But the kernel code in question very much does access the members
individually, and so I think that the compiler quite unequivocally did
something horribly horribly bad by turning them into a memset.

So I don't think your test-case is really particularly good, and maybe
that's why that old bug has languished for over a decade - people
didn't realize just *how* incredibly broken it was.

 Linus

Re: mainline build failure of powerpc allmodconfig for prom_init_check

[Segher Boessenkool]

On Sun, Jul 17, 2022 at 01:29:07PM -0700, Linus Torvalds wrote:
> On Sun, Jul 17, 2022 at 1:25 PM Sudip Mukherjee
>  wrote:
> >
> > And the generated assembly still has the memset for "struct prom_args".
> 
> Strange. That smells like a compiler bug to me.
> 
> But I can't read powerpc assembly code - it's been too many years, and
> even back when I did read it I hated how the register "names" worked.
> 
> Maybe it was never the args array, and it was about the other fields.
> Not that that makes any sense either, but it makes more sense than the
> compiler turning a series of volatile accesses into a memset.

Calling mem* on a volatile object (or a struct containing one) is not
valid.  I opened gcc.gnu.org/PR106335.  Thanks for bringing this up!


Segher

Re: mainline build failure of powerpc allmodconfig for prom_init_check

[Linus Torvalds]

On Sun, Jul 17, 2022 at 1:38 PM Sudip Mukherjee
 wrote:
>
> I have also tried adding volatile to all the members of that struct.  :(

Can you read the code to figure otu what the memcpy is all about?

Or maybe there is something that disables 'volatile' with pre-processor hackery.

Because a compiler that turns a loop over volatile members into
'memset()' isn't a C compiler, it's just a random noise generator.
'volatile' is fundamental enough that I really doubt both gcc and
clang can be that broken.

I just tested this

struct hello {
volatile int array[100];
};

void test(void)
{
int i;
struct hello hello;
for (i = 0; i < 100; i++)
hello.array[i] = 0;
}

on x86-64, and sure enough, gcc-12 turns turns it into a memset
without the volatile (in fact, the above will just be optimized away
entirely since it has no user), but with the volatile it's a proper
regular loop that does 32-byte accesses one by one (and in the proper
ascending oder). Something that memset() most definitely does not
guarantee:

.L2:
movslq  %eax, %rdx
addl$1, %eax
movl$0, -120(%rsp,%rdx,4)
cmpl$100, %eax
jne .L2

and honestly, anything else sounds completely unacceptable.

So I suspect there is something wrong with your testing, because gcc
simply isn't that incredibly broken. Clang is interesting in that it
seems to unroll the loop five times, but it still does the proper
"write individual 32-bit entities in ascending order".

The other alternative is that it's something else than that 'struct
prom_args'. Again, I don't read powerpc asm good.

  Linus

Re: mainline build failure of powerpc allmodconfig for prom_init_check

[Sudip Mukherjee]

On Sun, Jul 17, 2022 at 9:29 PM Linus Torvalds
 wrote:
>
> On Sun, Jul 17, 2022 at 1:25 PM Sudip Mukherjee
>  wrote:
> >
> > And the generated assembly still has the memset for "struct prom_args".
>
> Strange. That smells like a compiler bug to me.

Both gcc-12 and clang gives this error.

>
> But I can't read powerpc assembly code - it's been too many years, and
> even back when I did read it I hated how the register "names" worked.
>
> Maybe it was never the args array, and it was about the other fields.
> Not that that makes any sense either, but it makes more sense than the
> compiler turning a series of volatile accesses into a memset.

I have also tried adding volatile to all the members of that struct.  :(


-- 
Regards
Sudip

Re: mainline build failure of powerpc allmodconfig for prom_init_check

[Linus Torvalds]

On Sun, Jul 17, 2022 at 1:25 PM Sudip Mukherjee
 wrote:
>
> And the generated assembly still has the memset for "struct prom_args".

Strange. That smells like a compiler bug to me.

But I can't read powerpc assembly code - it's been too many years, and
even back when I did read it I hated how the register "names" worked.

Maybe it was never the args array, and it was about the other fields.
Not that that makes any sense either, but it makes more sense than the
compiler turning a series of volatile accesses into a memset.

  Linus

Re: mainline build failure of powerpc allmodconfig for prom_init_check

[Sudip Mukherjee]

On Sun, Jul 17, 2022 at 3:44 PM Linus Torvalds
 wrote:
>
> On Sun, Jul 17, 2022 at 2:13 AM Sudip Mukherjee
>  wrote:
> >
> > I was trying to check it. With gcc-11 the assembly code generated is
> > not using memset, but using __memset.
> > But with gcc-12, I can see the assembly code is using memset. One
> > example from the assembly:
>
> You could try making the 'args' array in 'struct prom_args' be marked
> 'volatile'.
>
> Ie something like this:
>
>   --- a/arch/powerpc/kernel/prom_init.c
>   +++ b/arch/powerpc/kernel/prom_init.c
>   @@ -115,6 +115,6 @@ struct prom_args {
>__be32 service;
>__be32 nargs;
>__be32 nret;
>   -  __be32 args[10];
>   +volatile __be32 args[10];
>};
>
> because I think it's just the compilers turning the small loop over
> those fields into a "memset()".

That didn't work.
"Error: External symbol 'memset' referenced from prom_init.c" is still
there with this change.
And the generated assembly still has the memset for "struct prom_args".


-- 
Regards
Sudip

Re: mainline build failure of powerpc allmodconfig for prom_init_check

[Segher Boessenkool]

On Sun, Jul 17, 2022 at 07:44:22AM -0700, Linus Torvalds wrote:
> On Sun, Jul 17, 2022 at 2:13 AM Sudip Mukherjee
>  wrote:
> > I was trying to check it. With gcc-11 the assembly code generated is
> > not using memset, but using __memset.
> > But with gcc-12, I can see the assembly code is using memset. One
> > example from the assembly:
> 
> You could try making the 'args' array in 'struct prom_args' be marked
> 'volatile'.
> 
> Ie something like this:
> 
>   --- a/arch/powerpc/kernel/prom_init.c
>   +++ b/arch/powerpc/kernel/prom_init.c
>   @@ -115,6 +115,6 @@ struct prom_args {
>__be32 service;
>__be32 nargs;
>__be32 nret;
>   -  __be32 args[10];
>   +volatile __be32 args[10];
>};
> 
> because I think it's just the compilers turning the small loop over
> those fields into a "memset()".

Yes.  See 
near the end:
  Most of the compiler support routines used by GCC are present in
  libgcc, but there are a few exceptions. GCC requires the freestanding
  environment provide memcpy, memmove, memset and memcmp. Finally, if
  __builtin_trap is used, and the target does not implement the trap
  pattern, then GCC emits a call to abort.

Can't we simply have a small simple implementation of these functions in
arch/powerpc/boot/?  This stuff is not performance-critical, and this is
not the first time we hit these problems.


Segher

Re: mainline build failure of powerpc allmodconfig for prom_init_check

[Linus Torvalds]

On Sun, Jul 17, 2022 at 2:13 AM Sudip Mukherjee
 wrote:
>
> I was trying to check it. With gcc-11 the assembly code generated is
> not using memset, but using __memset.
> But with gcc-12, I can see the assembly code is using memset. One
> example from the assembly:

You could try making the 'args' array in 'struct prom_args' be marked
'volatile'.

Ie something like this:

  --- a/arch/powerpc/kernel/prom_init.c
  +++ b/arch/powerpc/kernel/prom_init.c
  @@ -115,6 +115,6 @@ struct prom_args {
   __be32 service;
   __be32 nargs;
   __be32 nret;
  -  __be32 args[10];
  +volatile __be32 args[10];
   };

because I think it's just the compilers turning the small loop over
those fields into a "memset()".

  Linus

Re: mainline build failure of powerpc allmodconfig for prom_init_check

[Sudip Mukherjee]

On Thu, Jul 14, 2022 at 9:55 AM Sudip Mukherjee (Codethink)
 wrote:
>
> Hi All,
>
> Not sure if it has been reported before but the latest mainline kernel
> branch fails to build for powerpc allmodconfig with gcc-12 and the error is:
>
> Error: External symbol 'memset' referenced from prom_init.c
> make[2]: *** [arch/powerpc/kernel/Makefile:204: 
> arch/powerpc/kernel/prom_init_check] Error 1

I was trying to check it. With gcc-11 the assembly code generated is
not using memset, but using __memset.
But with gcc-12, I can see the assembly code is using memset. One
example from the assembly:

call_prom:
.quad   .call_prom,.TOC.@tocbase,0
.previous
.size   call_prom,24
.type   .call_prom,@function
.call_prom:
mflr 0   #,
std 29,-24(1)#,
std 30,-16(1)#,
std 31,-8(1) #,
mr 29,3  # tmp166, service
mr 31,4  # nargs, tmp167
mr 30,5  # tmp168, nret
 # arch/powerpc/kernel/prom_init.c:396: struct prom_args args;
li 4,254 #,
li 5,52  #,
 # arch/powerpc/kernel/prom_init.c:394: {
std 0,16(1)  #,
stdu 1,-208(1)   #,,
 # arch/powerpc/kernel/prom_init.c:396: struct prom_args args;
addi 3,1,112 # tmp174,,
 # arch/powerpc/kernel/prom_init.c:394: {
std 9,304(1) #,
std 10,312(1)#,
std 6,280(1) #,
std 7,288(1) #,
std 8,296(1) #,
 # arch/powerpc/kernel/prom_init.c:396: struct prom_args args;
bl .memset   #
nop
rldicl 9,31,0,32 # nargs, nargs
addi 9,9,1   # tmp163, nargs,
mtctr 9  # tmp163, tmp163



-- 
Regards
Sudip

mainline build failure of powerpc allmodconfig for prom_init_check

[Sudip Mukherjee (Codethink)]

Hi All,

Not sure if it has been reported before but the latest mainline kernel
branch fails to build for powerpc allmodconfig with gcc-12 and the error is:

Error: External symbol 'memset' referenced from prom_init.c
make[2]: *** [arch/powerpc/kernel/Makefile:204: 
arch/powerpc/kernel/prom_init_check] Error 1

The commit ca5dabcff1df ("powerpc/prom_init: Fix build failure with
GCC_PLUGIN_STRUCTLEAK_BYREF_ALL and KASAN") looks similar but the error
is still there with gcc-12.

Note: I don't see this error with gcc-11.


I will be happy to test any patch or provide any extra log if needed.

--
Regards
Sudip

Re: powerpc allmodconfig build broken due to commit 15863ff3b (powerpc: Make chip-id information available to userspace)

[Vasant Hegde]

On 09/11/2013 04:20 AM, Guenter Roeck wrote:

On Wed, Sep 11, 2013 at 08:02:49AM +1000, Benjamin Herrenschmidt wrote:

On Mon, 2013-09-09 at 16:55 -0700, Asai Thambi S P wrote:

On 09/08/2013 5:28 PM, Guenter Roeck wrote:

Hi all,



Guenter, Ben,

Sorry for the inconvenience. I never realized my patch could break somewhere :-(

Thanks you very much for identifying and fixing this issue. Other patch looks 
good to me.


-Vasant



powerpc allmodconfig build on the latest upstream kernel results in:

ERROR: .cpu_to_chip_id [drivers/block/mtip32xx/mtip32xx.ko] undefined!

This is due to commit 15863ff3b (powerpc: Make chip-id information
available to userspace).
Not surprising, as cpu_to_chip_id() is not exported.


Apart from the above error, I have a concern on the patch, purely based on the 
commit message.
(to be honest, I am not familiar with the ppc architecture)

Commit message of 15863ff3b has the following text.

**
So far /sys/devices/system/cpu/cpuX/topology/physical_package_id
was always default (-1) on ppc64 architecture.

Now, some systems have an ibm,chip-id property in the cpu nodes in
the device tree. On these systems, we now use this information to
display physical_package_id
**

Shouldn't the new definition of topology_physical_package_id apply only to 
those systems supporting ibm,chip-id property?


There should be no negative side effect (appart from the missing
EXPORT_SYMBOL of course). If the property is not found in the
device-tree, the new function returns -1, so it should work fine on all
systems.


Good. I submitted a patch doing just that yesterday or so.
Hope you'll accept it ;).

Thanks,
Guenter
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: powerpc allmodconfig build broken due to commit 15863ff3b (powerpc: Make chip-id information available to userspace)

[Benjamin Herrenschmidt]

On Mon, 2013-09-09 at 16:55 -0700, Asai Thambi S P wrote:
 On 09/08/2013 5:28 PM, Guenter Roeck wrote:
  Hi all,
 
  powerpc allmodconfig build on the latest upstream kernel results in:
 
  ERROR: .cpu_to_chip_id [drivers/block/mtip32xx/mtip32xx.ko] undefined!
 
  This is due to commit 15863ff3b (powerpc: Make chip-id information 
  available to userspace).
  Not surprising, as cpu_to_chip_id() is not exported.
 
 Apart from the above error, I have a concern on the patch, purely based on 
 the commit message.
 (to be honest, I am not familiar with the ppc architecture)
 
 Commit message of 15863ff3b has the following text.
 
 **
 So far /sys/devices/system/cpu/cpuX/topology/physical_package_id
 was always default (-1) on ppc64 architecture.
 
 Now, some systems have an ibm,chip-id property in the cpu nodes in
 the device tree. On these systems, we now use this information to
 display physical_package_id
 **
 
 Shouldn't the new definition of topology_physical_package_id apply only to 
 those systems supporting ibm,chip-id property?

There should be no negative side effect (appart from the missing
EXPORT_SYMBOL of course). If the property is not found in the
device-tree, the new function returns -1, so it should work fine on all
systems.

Cheers,
Ben.

 
  Reverting this commit fixes the problem. Any good idea how to fix it 
  for real ?
 
  Guenter
  -- 
  To unsubscribe from this list: send the line unsubscribe 
  linux-kernel in
  the body of a message to majord...@vger.kernel.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
  Please read the FAQ at  http://www.tux.org/lkml/


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: powerpc allmodconfig build broken due to commit 15863ff3b (powerpc: Make chip-id information available to userspace)

[Guenter Roeck]

On Wed, Sep 11, 2013 at 08:02:49AM +1000, Benjamin Herrenschmidt wrote:
 On Mon, 2013-09-09 at 16:55 -0700, Asai Thambi S P wrote:
  On 09/08/2013 5:28 PM, Guenter Roeck wrote:
   Hi all,
  
   powerpc allmodconfig build on the latest upstream kernel results in:
  
   ERROR: .cpu_to_chip_id [drivers/block/mtip32xx/mtip32xx.ko] undefined!
  
   This is due to commit 15863ff3b (powerpc: Make chip-id information 
   available to userspace).
   Not surprising, as cpu_to_chip_id() is not exported.
  
  Apart from the above error, I have a concern on the patch, purely based on 
  the commit message.
  (to be honest, I am not familiar with the ppc architecture)
  
  Commit message of 15863ff3b has the following text.
  
  **
  So far /sys/devices/system/cpu/cpuX/topology/physical_package_id
  was always default (-1) on ppc64 architecture.
  
  Now, some systems have an ibm,chip-id property in the cpu nodes in
  the device tree. On these systems, we now use this information to
  display physical_package_id
  **
  
  Shouldn't the new definition of topology_physical_package_id apply only 
  to those systems supporting ibm,chip-id property?
 
 There should be no negative side effect (appart from the missing
 EXPORT_SYMBOL of course). If the property is not found in the
 device-tree, the new function returns -1, so it should work fine on all
 systems.
 
Good. I submitted a patch doing just that yesterday or so.
Hope you'll accept it ;).

Thanks,
Guenter
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: powerpc allmodconfig build broken due to commit 15863ff3b (powerpc: Make chip-id information available to userspace)

[Asai Thambi S P]

On 09/08/2013 5:28 PM, Guenter Roeck wrote:

Hi all,

powerpc allmodconfig build on the latest upstream kernel results in:

ERROR: .cpu_to_chip_id [drivers/block/mtip32xx/mtip32xx.ko] undefined!

This is due to commit 15863ff3b (powerpc: Make chip-id information 
available to userspace).

Not surprising, as cpu_to_chip_id() is not exported.


Apart from the above error, I have a concern on the patch, purely based on the 
commit message.
(to be honest, I am not familiar with the ppc architecture)

Commit message of 15863ff3b has the following text.

**
So far /sys/devices/system/cpu/cpuX/topology/physical_package_id
was always default (-1) on ppc64 architecture.

Now, some systems have an ibm,chip-id property in the cpu nodes in
the device tree. On these systems, we now use this information to
display physical_package_id
**

Shouldn't the new definition of topology_physical_package_id apply only to 
those systems supporting ibm,chip-id property?


Reverting this commit fixes the problem. Any good idea how to fix it 
for real ?


Guenter
--
To unsubscribe from this list: send the line unsubscribe 
linux-kernel in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: powerpc allmodconfig build broken due to commit 15863ff3b (powerpc: Make chip-id information available to userspace)

[Guenter Roeck]

On 09/09/2013 04:55 PM, Asai Thambi S P wrote:

On 09/08/2013 5:28 PM, Guenter Roeck wrote:

Hi all,

powerpc allmodconfig build on the latest upstream kernel results in:

ERROR: .cpu_to_chip_id [drivers/block/mtip32xx/mtip32xx.ko] undefined!

This is due to commit 15863ff3b (powerpc: Make chip-id information available to 
userspace).
Not surprising, as cpu_to_chip_id() is not exported.


Apart from the above error, I have a concern on the patch, purely based on the 
commit message.
(to be honest, I am not familiar with the ppc architecture)

Commit message of 15863ff3b has the following text.

**
So far /sys/devices/system/cpu/cpuX/topology/physical_package_id
was always default (-1) on ppc64 architecture.

Now, some systems have an ibm,chip-id property in the cpu nodes in
the device tree. On these systems, we now use this information to
display physical_package_id
**

Shouldn't the new definition of topology_physical_package_id apply only to 
those systems supporting ibm,chip-id property?


Looking into the code, I think that is what it does. For other platforms
(ie if there is no ibm,chip-id property) it still returns -1.

Question for the fix is what path to take to fix the problem.
Exporting cpu_to_chip_id() might be the easiest solution. Other
platforms export the respective data, so it should not be a problem.

I might submit a patch and see where it goes.

Guenter




Reverting this commit fixes the problem. Any good idea how to fix it for real ?

Guenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/






___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

powerpc allmodconfig build broken due to commit 15863ff3b (powerpc: Make chip-id information available to userspace)

[Guenter Roeck]

Hi all,

powerpc allmodconfig build on the latest upstream kernel results in:

ERROR: .cpu_to_chip_id [drivers/block/mtip32xx/mtip32xx.ko] undefined!

This is due to commit 15863ff3b (powerpc: Make chip-id information available to 
userspace).
Not surprising, as cpu_to_chip_id() is not exported.

Reverting this commit fixes the problem. Any good idea how to fix it for real ?

Guenter
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[git pull] powerpc allmodconfig build fix and missed 5200 audio drivers (Was: [PATCH] powerpc: fix i8042 module build error)

[Grant Likely]

Hi Ben,  Here's the promised pull request:

Let me know if this is okay, or if you would like to respin it.

The 2 mpc5200 patches are in here (and not in my previous request)
because of a breakdown in coordination between me and the ASoC folks.
Turns out the (potentially) conflicting patches weren't ready for
2.6.36, so Mark asked me to pick them back up[1].  It also has the
powerpc allmodconfig build failure fix.

[1]http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg45616.html

Cheers,
g.

The following changes since commit 17879857821adad4e180c5d6457c3b8bbf1d0c0c:
  Linus Torvalds (1):
Merge branch 'irq-core-for-linus' of
git://git.kernel.org/.../tip/linux-2.6-tip

are available in the git repository at:

  git://git.secretlab.ca/git/linux-2.6 next

Eric Millbrandt (2):
  powerpc/5200: add mpc5200_psc_ac97_gpio_reset
  sound/soc: mpc5200_psc_ac97: Use gpio pins for cold reset

Grant Likely (1):
  powerpc: fix i8042 module build error

 arch/powerpc/include/asm/mpc52xx.h   |1 +
 arch/powerpc/include/asm/mpc52xx_psc.h   |1 +
 arch/powerpc/kernel/setup-common.c   |2 +
 arch/powerpc/platforms/52xx/mpc52xx_common.c |  106 ++
 sound/soc/fsl/mpc5200_psc_ac97.c |   22 +-
 5 files changed, 128 insertions(+), 4 deletions(-)

On Fri, Aug 6, 2010 at 8:54 PM, Grant Likely grant.lik...@secretlab.ca wrote:
 On Fri, Aug 6, 2010 at 6:01 PM, Stephen Rothwell s...@canb.auug.org.au 
 wrote:
 Hi Grant,

 On Fri, 06 Aug 2010 12:42:12 -0600 Grant Likely grant.lik...@secretlab.ca 
 wrote:

 of_i8042_{kbd,aux}_irq needs to be exported

 Signed-off-by: Grant Likely grant.lik...@secretlab.ca
 ---

 Stephen and Ben, this fixes up the build error in linux-next.  If you 
 prefer,
 I can stuff this patch into my next-powerpc branch.  Ben, I've got other
 commits in that branch that I'll be sending to you early next week anyway.

 This failure also exists in Linus' tree, so the earlier this goes to
 Linus the better.

 Okay then.  Ben, I'll send out my pull request out right away so
 you've got it if you want to use it.

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




 --
 Grant Likely, B.Sc., P.Eng.
 Secret Lab Technologies Ltd.




-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Johannes Berg]

On Thu, 2008-10-16 at 13:02 -0700, Arjan van de Ven wrote:
 On Thu, 16 Oct 2008 12:49:23 -0700 (PDT)
 David Miller [EMAIL PROTECTED] wrote:
  #endif
  #define __WARN() warn_on_slowpath(__FILE__, __LINE__)
  #define __WARN_printf(arg...) warn_slowpath(__FILE__, __LINE__, arg)
  #else
  #define __WARN_printf(arg...) __WARN()
 
 the easiest way I suppose would be to do
 
 #define __WARN_printf(arg..) do { printk(arg); __WARN(); } while (0)
 
 any obvious problems with this ?

No, not really. You won't get it on kerneloops, but I guess that's not
an easily tractable problem.

johannes


signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Ingo Molnar]

* David Miller [EMAIL PROTECTED] wrote:

  net/dccp/options.c: In function 'dccp_parse_options': 
  net/dccp/options.c:67: warning: 'value' may be used uninitialized in 
  this function
 
 Known issue, not trivial to fix, gcc is just being incredibly silly 
 here as it can't see all of the control flow.

i just ran into this - do you have any objection against the patch 
below?

Should we have a cleaner annotation perhaps instead of 
uninitialized_var()? Something like:

 #define __used  __attribute__((used))

?

Ingo

--
From d917af0bd043eab40d57f79cba9cf7a7b265a205 Mon Sep 17 00:00:00 2001
From: Ingo Molnar [EMAIL PROTECTED]
Date: Fri, 17 Oct 2008 12:41:30 +0200
Subject: [PATCH] fix warning in net/dccp/options.c
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

fix this warning:

  net/dccp/options.c: In function ‘dccp_parse_options’:
  net/dccp/options.c:67: warning: ‘value’ may be used uninitialized in this 
function

This is a bogus GCC warning. The compiler does not recognize the relation
between value and mandatory variables: the code flow can ever reach
the out_invalid_option: label if 'mandatory' is set to 1, and when
'mandatory' is non-zero, we'll always have 'value' initialized.

Help out the compiler by annotating the variable.

Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
---
 net/dccp/options.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/dccp/options.c b/net/dccp/options.c
index 0809b63..18dcfb9 100644
--- a/net/dccp/options.c
+++ b/net/dccp/options.c
@@ -64,7 +64,7 @@ int dccp_parse_options(struct sock *sk, struct 
dccp_request_sock *dreq,
(dh-dccph_doff * 4);
struct dccp_options_received *opt_recv = dp-dccps_options_received;
unsigned char opt, len;
-   unsigned char *value;
+   unsigned char *uninitialized_var(value);
u32 elapsed_time;
__be32 opt_val;
int rc;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Dan Williams]

On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
  drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios':
  drivers/dma/ioat_dca.c:81: error: implicit declaration of function 
  'cpuid_eax'
  drivers/dma/ioat_dca.c: In function 'system_has_dca_enabled':
  drivers/dma/ioat_dca.c:91: error: implicit declaration of function 
  'boot_cpu_has'
  drivers/dma/ioat_dca.c:91: error: 'X86_FEATURE_DCA' undeclared (first use 
  in this function)
  drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported 
  only once
  drivers/dma/ioat_dca.c:91: error: for each function it appears in.)
  drivers/dma/ioat_dca.c: In function 'ioat_dca_get_tag':
  drivers/dma/ioat_dca.c:190: error: implicit declaration of function 
  'cpu_physical_id'
 
 Known issue.  I tried to ping Jeff Garzik about doing a driver bug fix run in
 order to fix this, but he hasn't shown any signs of life.
 
 So I'll do it myself later tonight. :-/
 
The following seems to fix this up...

---snip---
ixgbe, myri10ge: INTEL_IOATDMA can only be selected when X86=y

From: Dan Williams [EMAIL PROTECTED]

The INTEL_IOATDMA symbol depends on x86. 'select' ignores this
dependency.

Cc: Brice Goglin [EMAIL PROTECTED]
Cc: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Dan Williams [EMAIL PROTECTED]
---

 drivers/net/Kconfig |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 1d8af33..84983f8 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2410,7 +2410,7 @@ config IXGBE
tristate Intel(R) 10GbE PCI Express adapters support
depends on PCI  INET
select INET_LRO
-   select INTEL_IOATDMA
+   select INTEL_IOATDMA if X86
---help---
  This driver supports Intel(R) 10GbE PCI Express family of
  adapters.  For more information on how to identify your adapter, go
@@ -2462,7 +2462,7 @@ config MYRI10GE
select FW_LOADER
select CRC32
select INET_LRO
-   select INTEL_IOATDMA
+   select INTEL_IOATDMA if X86
---help---
  This driver supports Myricom Myri-10G Dual Protocol interface in
  Ethernet mode. If the eeprom on your board is not recent enough,


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Brice Goglin]

Dan Williams wrote:
 On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
   
 drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios':
 drivers/dma/ioat_dca.c:81: error: implicit declaration of function 
 'cpuid_eax'
 drivers/dma/ioat_dca.c: In function 'system_has_dca_enabled':
 drivers/dma/ioat_dca.c:91: error: implicit declaration of function 
 'boot_cpu_has'
 drivers/dma/ioat_dca.c:91: error: 'X86_FEATURE_DCA' undeclared (first use 
 in this function)
 drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported 
 only once
 drivers/dma/ioat_dca.c:91: error: for each function it appears in.)
 drivers/dma/ioat_dca.c: In function 'ioat_dca_get_tag':
 drivers/dma/ioat_dca.c:190: error: implicit declaration of function 
 'cpu_physical_id'
   
 Known issue.  I tried to ping Jeff Garzik about doing a driver bug fix run in
 order to fix this, but he hasn't shown any signs of life.

 So I'll do it myself later tonight. :-/

 
 The following seems to fix this up...

 ---snip---
 ixgbe, myri10ge: INTEL_IOATDMA can only be selected when X86=y
   

There's already a completely different fix queued in netdev patchworks
(for myri10ge only right now, to be duplicated for Intel drivers). The
idea is to stop having almost-unrelated drivers select each other
directly, let people select which drivers they really want, and have
Kconfig handle modules/builtin-stuff correctly. See
http://patchwork.ozlabs.org/patch/4506/

Brice

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[David Miller]

From: Brice Goglin [EMAIL PROTECTED]
Date: Thu, 16 Oct 2008 08:55:08 +0200

 Dan Williams wrote:
  On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:

  drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios':
  drivers/dma/ioat_dca.c:81: error: implicit declaration of function 
  'cpuid_eax'
  drivers/dma/ioat_dca.c: In function 'system_has_dca_enabled':
  drivers/dma/ioat_dca.c:91: error: implicit declaration of function 
  'boot_cpu_has'
  drivers/dma/ioat_dca.c:91: error: 'X86_FEATURE_DCA' undeclared (first use 
  in this function)
  drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported 
  only once
  drivers/dma/ioat_dca.c:91: error: for each function it appears in.)
  drivers/dma/ioat_dca.c: In function 'ioat_dca_get_tag':
  drivers/dma/ioat_dca.c:190: error: implicit declaration of function 
  'cpu_physical_id'

  Known issue.  I tried to ping Jeff Garzik about doing a driver bug fix run 
  in
  order to fix this, but he hasn't shown any signs of life.
 
  So I'll do it myself later tonight. :-/
 
  
  The following seems to fix this up...
 
  ---snip---
  ixgbe, myri10ge: INTEL_IOATDMA can only be selected when X86=y

 
 There's already a completely different fix queued in netdev patchworks
 (for myri10ge only right now, to be duplicated for Intel drivers). The
 idea is to stop having almost-unrelated drivers select each other
 directly, let people select which drivers they really want, and have
 Kconfig handle modules/builtin-stuff correctly. See
 http://patchwork.ozlabs.org/patch/4506/

Right, my plan was to duplicate this for the other drivers.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Takashi Iwai]

At Thu, 16 Oct 2008 10:38:36 +0300,
Adrian Bunk wrote:
 
 On Thu, Oct 16, 2008 at 07:57:29AM +0200, Takashi Iwai wrote:
  At Wed, 15 Oct 2008 21:33:37 -0700,
  Andrew Morton wrote:
   
   sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
   deprecated (declared at sound/soc/soc-dapm.c:1026)
   sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
   deprecated (declared at sound/soc/soc-dapm.c:1026)
  
  These are definitions of deprecated interfaces.
  We can remove it in 2.6.29.  If we don't want to be conservative, it
  can be removed in 2.6.28, too.
 ...
 
 Since it's an in-kernel API there's no reason to keep it once there are 
 no users left.

Right.  But, IMO, now is no suitable time.
A thing like API removal should have been tested in linux-next, and we
had plenty of time indeed for 2.6.28.

 But currently sound/soc/at32/playpaq_wm8510.c still seems to use it.

Yep, but don't be bothered to try to create a patch for that.
There will be a unification patch for both at32 and at91, so clean-ups
will be applied anyway later.


thanks,

Takashi
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Geert Uytterhoeven]

On Wed, 15 Oct 2008, David Miller wrote:
  kernel/resource.c: In function '__reserve_region_with_split':
  kernel/resource.c:554: warning: format '%llx' expects type 'long long 
  unsigned int', but argument 3 has type 'resource_size_t'
  kernel/resource.c:554: warning: format '%llx' expects type 'long long 
  unsigned int', but argument 4 has type 'resource_size_t'
  kernel/resource.c:554: warning: format '%llx' expects type 'long long 
  unsigned int', but argument 6 has type 'resource_size_t'
  kernel/resource.c:554: warning: format '%llx' expects type 'long long 
  unsigned int', but argument 7 has type 'resource_size_t'
 
 Known issue, Ben wants to add a new variant of %pX in order to print 
 resources so that
 resource_size_t vs. unsigned long stuff doesn't matter like this any more.

Will still give a warning, as resource_size_t is not a pointer.

  drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_read':
  drivers/rtc/rtc-ds1286.c:33: error: implicit declaration of function 
  '__raw_readl'
  drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_write':
  drivers/rtc/rtc-ds1286.c:38: error: implicit declaration of function 
  '__raw_writel'
  drivers/rtc/rtc-ds1286.c: In function 'ds1286_probe':
  drivers/rtc/rtc-ds1286.c:345: error: implicit declaration of function 
  'ioremap'
  drivers/rtc/rtc-ds1286.c:345: warning: assignment makes pointer from 
  integer without a cast
  drivers/rtc/rtc-ds1286.c:365: error: implicit declaration of function 
  'iounmap'
 
 Missing asm/io.h include.

Nah, linux/io.h ;-)

  drivers/rtc/rtc-m48t35.c: In function 'm48t35_read_time':
  drivers/rtc/rtc-m48t35.c:59: error: implicit declaration of function 'readb'
  drivers/rtc/rtc-m48t35.c:60: error: implicit declaration of function 
  'writeb'
  drivers/rtc/rtc-m48t35.c: In function 'm48t35_probe':
  drivers/rtc/rtc-m48t35.c:168: error: implicit declaration of function 
  'ioremap'
  drivers/rtc/rtc-m48t35.c:168: warning: assignment makes pointer from 
  integer without a cast
  drivers/rtc/rtc-m48t35.c:188: error: implicit declaration of function 
  'iounmap'
 
 Likewise.

Already sent a patch for these two...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Geert Uytterhoeven]

On Thu, 16 Oct 2008, David Miller wrote:
 From: Geert Uytterhoeven [EMAIL PROTECTED]
 Date: Thu, 16 Oct 2008 09:31:29 +0200 (CEST)
 
  On Wed, 15 Oct 2008, David Miller wrote:
kernel/resource.c: In function '__reserve_region_with_split':
kernel/resource.c:554: warning: format '%llx' expects type 'long long 
unsigned int', but argument 3 has type 'resource_size_t'
kernel/resource.c:554: warning: format '%llx' expects type 'long long 
unsigned int', but argument 4 has type 'resource_size_t'
kernel/resource.c:554: warning: format '%llx' expects type 'long long 
unsigned int', but argument 6 has type 'resource_size_t'
kernel/resource.c:554: warning: format '%llx' expects type 'long long 
unsigned int', but argument 7 has type 'resource_size_t'
   
   Known issue, Ben wants to add a new variant of %pX in order to print 
   resources so that
   resource_size_t vs. unsigned long stuff doesn't matter like this any more.
  
  Will still give a warning, as resource_size_t is not a pointer.
 
 The idea is to pass in a pointer to the resource struct,
 and the %pX variant specified says what part to print.

Neat! So we can also have a separate variant to print the resource
range.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Adrian Bunk]

On Thu, Oct 16, 2008 at 09:57:11AM +0200, Takashi Iwai wrote:
 At Thu, 16 Oct 2008 10:38:36 +0300,
 Adrian Bunk wrote:
  
  On Thu, Oct 16, 2008 at 07:57:29AM +0200, Takashi Iwai wrote:
   At Wed, 15 Oct 2008 21:33:37 -0700,
   Andrew Morton wrote:

sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
deprecated (declared at sound/soc/soc-dapm.c:1026)
sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
deprecated (declared at sound/soc/soc-dapm.c:1026)
   
   These are definitions of deprecated interfaces.
   We can remove it in 2.6.29.  If we don't want to be conservative, it
   can be removed in 2.6.28, too.
  ...
  
  Since it's an in-kernel API there's no reason to keep it once there are 
  no users left.
 
 Right.  But, IMO, now is no suitable time.
 A thing like API removal should have been tested in linux-next, and we
 had plenty of time indeed for 2.6.28.
...

A grep through the tree and one test compile that covers 
sound/soc/soc-dapm.c should be enough testing.

And having it then in -next once should be enough to discover if someone 
wrongly added a new user.

I have removed many functions in the kernel, and there isn't much that 
can go wrong - even adding a PCI ID to a driver has a bigger risk of 
introducing a regression.

 thanks,
 
 Takashi

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Andreas Schwab]

David Miller [EMAIL PROTECTED] writes:

 net/dccp/options.c: In function 'dccp_parse_options':
 net/dccp/options.c:67: warning: 'value' may be used uninitialized in this 
 function

 Known issue, not trivial to fix, gcc is just being incredibly silly here as it
 can't see all of the control flow.

Seems to be fixed in gcc 4.3.  It actually needs a pretty complete value
tracking to get right.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Takashi Iwai]

At Thu, 16 Oct 2008 11:21:57 +0300,
Adrian Bunk wrote:
 
 On Thu, Oct 16, 2008 at 09:57:11AM +0200, Takashi Iwai wrote:
  At Thu, 16 Oct 2008 10:38:36 +0300,
  Adrian Bunk wrote:
   
   On Thu, Oct 16, 2008 at 07:57:29AM +0200, Takashi Iwai wrote:
At Wed, 15 Oct 2008 21:33:37 -0700,
Andrew Morton wrote:
 
 sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
 deprecated (declared at sound/soc/soc-dapm.c:1026)
 sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
 deprecated (declared at sound/soc/soc-dapm.c:1026)

These are definitions of deprecated interfaces.
We can remove it in 2.6.29.  If we don't want to be conservative, it
can be removed in 2.6.28, too.
   ...
   
   Since it's an in-kernel API there's no reason to keep it once there are 
   no users left.
  
  Right.  But, IMO, now is no suitable time.
  A thing like API removal should have been tested in linux-next, and we
  had plenty of time indeed for 2.6.28.
 ...
 
 A grep through the tree and one test compile that covers 
 sound/soc/soc-dapm.c should be enough testing.
 
 And having it then in -next once should be enough to discover if someone 
 wrongly added a new user.

My point is the time for removal.  The API changes should have been
done in the merge window, and it should have been tested *before* the
merge window.

 I have removed many functions in the kernel, and there isn't much that 
 can go wrong - even adding a PCI ID to a driver has a bigger risk of 
 introducing a regression.

Yeah, IMHO, adding PCI IDs blindly at the late stage should be
avoided, too, although many people love that.


thanks,

Takashi
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Adrian Bunk]

On Thu, Oct 16, 2008 at 10:43:33AM +0200, Takashi Iwai wrote:
 At Thu, 16 Oct 2008 11:21:57 +0300,
 Adrian Bunk wrote:
  
  On Thu, Oct 16, 2008 at 09:57:11AM +0200, Takashi Iwai wrote:
   At Thu, 16 Oct 2008 10:38:36 +0300,
   Adrian Bunk wrote:

On Thu, Oct 16, 2008 at 07:57:29AM +0200, Takashi Iwai wrote:
 At Wed, 15 Oct 2008 21:33:37 -0700,
 Andrew Morton wrote:
  
  sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
  deprecated (declared at sound/soc/soc-dapm.c:1026)
  sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
  deprecated (declared at sound/soc/soc-dapm.c:1026)
 
 These are definitions of deprecated interfaces.
 We can remove it in 2.6.29.  If we don't want to be conservative, it
 can be removed in 2.6.28, too.
...

Since it's an in-kernel API there's no reason to keep it once there are 
no users left.
   
   Right.  But, IMO, now is no suitable time.
   A thing like API removal should have been tested in linux-next, and we
   had plenty of time indeed for 2.6.28.
  ...
  
  A grep through the tree and one test compile that covers 
  sound/soc/soc-dapm.c should be enough testing.
  
  And having it then in -next once should be enough to discover if someone 
  wrongly added a new user.
 
 My point is the time for removal.  The API changes should have been
 done in the merge window, and it should have been tested *before* the
 merge window.
...

My point is simply that compared to many other patches that weren't 
tested before the merge window, and that still get (for various reasons) 
into the tree, the removal of unused functions is extremely low-risk 
(assuming the patch creator knows what grep is and does a test compile 
of the changed code).

 thanks,
 
 Takashi

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Johannes Berg]

On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
 
 
  net/sched/sch_generic.c: In function 'dev_watchdog':
  net/sched/sch_generic.c:224: warning: unused variable 'drivername'
 
 Sucky, if WARN_ONCE() evaluates to nothing the sprintf() string buffer
 on the stack looks unused.

I've complained about this to Arjan before, we actually lose all
messages passed to WARN() or WARN_ONCE() on platforms that use bug traps
for warnings too.

johannes


signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Mark Brown]

On Wed, Oct 15, 2008 at 09:33:37PM -0700, Andrew Morton wrote:

 sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
 deprecated (declared at sound/soc/soc-dapm.c:1026)
 sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
 deprecated (declared at sound/soc/soc-dapm.c:1026)

I should submit the patch to remove this now that 2.6.27 is out - the
warnings are generated by EXPORT_SYMBOL_GPL() - I couldn't see a way to
mark the function as deprecated without removing the export.

 sound/soc/codecs/tlv320aic23.c: In function 'tlv320aic23_write':
 sound/soc/codecs/tlv320aic23.c:104: warning: passing argument 2 of 
 'codec-hw_write' makes pointer from integer without a cast
 sound/soc/codecs/tlv320aic23.c: In function 'tlv320aic23_set_dai_sysclk':
 sound/soc/codecs/tlv320aic23.c:424: warning: unused variable 'codec'

The author already provided a patch to fix these.  Takashi has sent a
pull request to Linus including that already, IIRC.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[David Miller]

From: Johannes Berg [EMAIL PROTECTED]
Date: Thu, 16 Oct 2008 16:57:19 +0200

 On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
  
  
   net/sched/sch_generic.c: In function 'dev_watchdog':
   net/sched/sch_generic.c:224: warning: unused variable 'drivername'
  
  Sucky, if WARN_ONCE() evaluates to nothing the sprintf() string buffer
  on the stack looks unused.
 
 I've complained about this to Arjan before, we actually lose all
 messages passed to WARN() or WARN_ONCE() on platforms that use bug traps
 for warnings too.

Ok I see how that works, yes, it should be fixed.

If the platform defines a __WARN (which powerpc does) the
whole format string and printf args go unevaluated, it's
because of the following sequence in asm-generic/bug.h:

#ifndef __WARN
#ifndef __ASSEMBLY__
extern void warn_on_slowpath(const char *file, const int line);
extern void warn_slowpath(const char *file, const int line,
const char *fmt, ...) __attribute__((format(printf, 3, 4)));
#define WANT_WARN_ON_SLOWPATH
#endif
#define __WARN() warn_on_slowpath(__FILE__, __LINE__)
#define __WARN_printf(arg...) warn_slowpath(__FILE__, __LINE__, arg)
#else
#define __WARN_printf(arg...) __WARN()
#endif
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Arjan van de Ven]

On Thu, 16 Oct 2008 12:49:23 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
 #endif
 #define __WARN() warn_on_slowpath(__FILE__, __LINE__)
 #define __WARN_printf(arg...) warn_slowpath(__FILE__, __LINE__, arg)
 #else
 #define __WARN_printf(arg...) __WARN()

the easiest way I suppose would be to do

#define __WARN_printf(arg..) do { printk(arg); __WARN(); } while (0)

any obvious problems with this ?


-- 
Arjan van de VenIntel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Jesse Brandeburg]

On Wed, Oct 15, 2008 at 11:58 PM, David Miller [EMAIL PROTECTED] wrote:
 There's already a completely different fix queued in netdev patchworks
 (for myri10ge only right now, to be duplicated for Intel drivers). The
 idea is to stop having almost-unrelated drivers select each other
 directly, let people select which drivers they really want, and have
 Kconfig handle modules/builtin-stuff correctly. See
 http://patchwork.ozlabs.org/patch/4506/

 Right, my plan was to duplicate this for the other drivers.

The work is already done for ixgbe and igb, and we have it in testing.
 It should be in your inbox today or tomorrow.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

powerpc allmodconfig

[Andrew Morton]

arch/powerpc/kernel/setup_64.c:447:5: warning: kernstart_addr is not defined
arch/powerpc/kernel/setup_64.c:447:5: warning: kernstart_addr is not defined


kernel/resource.c: In function '__reserve_region_with_split':
kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned 
int', but argument 3 has type 'resource_size_t'
kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned 
int', but argument 4 has type 'resource_size_t'
kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned 
int', but argument 6 has type 'resource_size_t'
kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned 
int', but argument 7 has type 'resource_size_t'


sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated 
(declared at sound/soc/soc-dapm.c:1026)
sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated 
(declared at sound/soc/soc-dapm.c:1026)
lib/debugobjects.c:58: warning: 'obj_states' defined but not used
net/dccp/options.c: In function 'dccp_parse_options':
net/dccp/options.c:67: warning: 'value' may be used uninitialized in this 
function


sound/soc/codecs/tlv320aic23.c: In function 'tlv320aic23_write':
sound/soc/codecs/tlv320aic23.c:104: warning: passing argument 2 of 
'codec-hw_write' makes pointer from integer without a cast
sound/soc/codecs/tlv320aic23.c: In function 'tlv320aic23_set_dai_sysclk':
sound/soc/codecs/tlv320aic23.c:424: warning: unused variable 'codec'


drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios':
drivers/dma/ioat_dca.c:81: error: implicit declaration of function 'cpuid_eax'
drivers/dma/ioat_dca.c: In function 'system_has_dca_enabled':
drivers/dma/ioat_dca.c:91: error: implicit declaration of function 
'boot_cpu_has'
drivers/dma/ioat_dca.c:91: error: 'X86_FEATURE_DCA' undeclared (first use in 
this function)
drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported only 
once
drivers/dma/ioat_dca.c:91: error: for each function it appears in.)
drivers/dma/ioat_dca.c: In function 'ioat_dca_get_tag':
drivers/dma/ioat_dca.c:190: error: implicit declaration of function 
'cpu_physical_id'

fs/ext4/balloc.c: In function 'ext4_claim_free_blocks':
fs/ext4/balloc.c:607: warning: format '%lld' expects type 'long long int', but 
argument 2 has type 's64'
fs/ext4/inode.c: In function 'ext4_print_free_blocks':
fs/ext4/inode.c:1822: warning: format '%lld' expects type 'long long int', but 
argument 2 has type 's64'
fs/ext4/inode.c:1824: warning: format '%lld' expects type 'long long int', but 
argument 2 has type 's64'

net/sched/sch_generic.c: In function 'dev_watchdog':
net/sched/sch_generic.c:224: warning: unused variable 'drivername'


net/mac80211/rc80211_minstrel_debugfs.c: In function 'minstrel_stats_open':
net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects 
type 'long long unsigned int', but argument 11 has type 'u64'
net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects 
type 'long long unsigned int', but argument 12 has type 'u64'
net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects 
type 'long long unsigned int', but argument 11 has type 'u64'
net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects 
type 'long long unsigned int', but argument 12 has type 'u64'
net/mac80211/rc80211_minstrel_debugfs.c: At top level:
net/mac80211/rc80211_minstrel_debugfs.c:145: warning: initialization from 
incompatible pointer type

drivers/ide/pci/scc_pata.c: In function 'init_hwif_scc':
drivers/ide/pci/scc_pata.c:846: warning: unused variable 'ports'
drivers/ide/pci/hpt366.c: In function 'init_hwif_hpt366':
drivers/ide/pci/hpt366.c:1292: warning: unused variable 'dev'

include/linux/ucb1400.h:139: warning: 'ucb1400_adc_read' defined but not used

drivers/mtd/devices/docprobe.c:80:2: warning: #warning Unknown architecture for 
DiskOnChip. No default probe locations defined

fs/ocfs2/xattr.c: In function 'ocfs2_xattr_index_block_find':
fs/ocfs2/xattr.c:2400: warning: format '%llu' expects type 'long long unsigned 
int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c:2400: warning: format '%llu' expects type 'long long unsigned 
int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c:2400: warning: format '%llu' expects type 'long long unsigned 
int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c: In function 'ocfs2_iterate_xattr_buckets':
fs/ocfs2/xattr.c:2424: warning: format '%llu' expects type 'long long unsigned 
int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c:2424: warning: format '%llu' expects type 'long long unsigned 
int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c:2424: warning: format '%llu' expects type 'long long unsigned 
int', but argument 7 has type 'u64'
fs/ocfs2/xattr.c:2443: warning: format '%llu' expects type 'long long unsigned 
int', but argument 6 has type 'u64'
fs/ocfs2/xattr.c:2443: warning: format '%llu' expects type 'long long unsigned 

Re: powerpc allmodconfig

[Benjamin Herrenschmidt]

Some comments for some of these...

On Wed, 2008-10-15 at 21:33 -0700, Andrew Morton wrote:

 kernel/resource.c: In function '__reserve_region_with_split':
 kernel/resource.c:554: warning: format '%llx' expects type 'long long 
 unsigned int', but argument 3 has type 'resource_size_t'
 kernel/resource.c:554: warning: format '%llx' expects type 'long long 
 unsigned int', but argument 4 has type 'resource_size_t'
 kernel/resource.c:554: warning: format '%llx' expects type 'long long 
 unsigned int', but argument 6 has type 'resource_size_t'
 kernel/resource.c:554: warning: format '%llx' expects type 'long long 
 unsigned int', but argument 7 has type 'resource_size_t'

This is a generic code bug, I sent a patch for it a day or two ago. (ie
those are real bugs on 32-bit resource_size_t)

 drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios':
 drivers/dma/ioat_dca.c:81: error: implicit declaration of function 'cpuid_eax'
 drivers/dma/ioat_dca.c: In function 'system_has_dca_enabled':
 drivers/dma/ioat_dca.c:91: error: implicit declaration of function 
 'boot_cpu_has'
 drivers/dma/ioat_dca.c:91: error: 'X86_FEATURE_DCA' undeclared (first use in 
 this function)
 drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported 
 only once
 drivers/dma/ioat_dca.c:91: error: for each function it appears in.)
 drivers/dma/ioat_dca.c: In function 'ioat_dca_get_tag':
 drivers/dma/ioat_dca.c:190: error: implicit declaration of function 
 'cpu_physical_id'

Looks like this driver should depend on X86 :-)

 fs/ext4/balloc.c: In function 'ext4_claim_free_blocks':
 fs/ext4/balloc.c:607: warning: format '%lld' expects type 'long long int', 
 but argument 2 has type 's64'
 fs/ext4/inode.c: In function 'ext4_print_free_blocks':
 fs/ext4/inode.c:1822: warning: format '%lld' expects type 'long long int', 
 but argument 2 has type 's64'
 fs/ext4/inode.c:1824: warning: format '%lld' expects type 'long long int', 
 but argument 2 has type 's64'

The above are unfortunate but at least aren't bugs per-se, just
annoying. Should be fixable with casts. Ted ?

 net/mac80211/rc80211_minstrel_debugfs.c: In function 'minstrel_stats_open':
 net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects 
 type 'long long unsigned int', but argument 11 has type 'u64'
 net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects 
 type 'long long unsigned int', but argument 12 has type 'u64'
 net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects 
 type 'long long unsigned int', but argument 11 has type 'u64'
 net/mac80211/rc80211_minstrel_debugfs.c:98: warning: format '%8llu' expects 
 type 'long long unsigned int', but argument 12 has type 'u64'
 net/mac80211/rc80211_minstrel_debugfs.c: At top level:
 net/mac80211/rc80211_minstrel_debugfs.c:145: warning: initialization from 
 incompatible pointer type

Same.

 fs/ocfs2/xattr.c: In function 'ocfs2_xattr_index_block_find':
 fs/ocfs2/xattr.c:2400: warning: format '%llu' expects type 'long long 
 unsigned int', but argument 7 has type 'u64'
 fs/ocfs2/xattr.c:2400: warning: format '%llu' expects type 'long long 
 unsigned int', but argument 7 has type 'u64'

 .../...

same

 
 sound/pci/hda/patch_sigmatel.c: In function 'stac92xx_parse_auto_config':
 sound/pci/hda/patch_sigmatel.c:2819: warning: 'nid' may be used uninitialized 
 in this function
 
 drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_read':
 drivers/rtc/rtc-ds1286.c:33: error: implicit declaration of function 
 '__raw_readl'
 drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_write':
 drivers/rtc/rtc-ds1286.c:38: error: implicit declaration of function 
 '__raw_writel'
 drivers/rtc/rtc-ds1286.c: In function 'ds1286_probe':
 drivers/rtc/rtc-ds1286.c:345: error: implicit declaration of function 
 'ioremap'
 drivers/rtc/rtc-ds1286.c:345: warning: assignment makes pointer from integer 
 without a cast
 drivers/rtc/rtc-ds1286.c:365: error: implicit declaration of function 
 'iounmap'
 make[2]: [drivers/rtc/rtc-ds1286.o] Error 1 (ignored)

Missing #include asm/io.h ?

 drivers/rtc/rtc-m48t35.c: In function 'm48t35_read_time':
 drivers/rtc/rtc-m48t35.c:59: error: implicit declaration of function 'readb'
 drivers/rtc/rtc-m48t35.c:60: error: implicit declaration of function 'writeb'
 drivers/rtc/rtc-m48t35.c: In function 'm48t35_probe':
 drivers/rtc/rtc-m48t35.c:168: error: implicit declaration of function 
 'ioremap'
 drivers/rtc/rtc-m48t35.c:168: warning: assignment makes pointer from integer 
 without a cast
 drivers/rtc/rtc-m48t35.c:188: error: implicit declaration of function 
 'iounmap'

Same ?

 drivers/net/ibm_newemac/mal.c: In function 'mal_txeob':
 drivers/net/ibm_newemac/mal.c:284: error: implicit declaration of function 
 'mtdcri'
 drivers/net/ibm_newemac/mal.c:284: error: 'SDR0' undeclared (first use in 
 this function)
 drivers/net/ibm_newemac/mal.c:284: error: (Each undeclared identifier is 
 reported only once
 drivers/net/ibm_newemac/mal.c:284: error: for each 

Re: powerpc allmodconfig

[David Miller]

From: Andrew Morton [EMAIL PROTECTED]
Date: Wed, 15 Oct 2008 21:33:37 -0700

 kernel/resource.c: In function '__reserve_region_with_split':
 kernel/resource.c:554: warning: format '%llx' expects type 'long long 
 unsigned int', but argument 3 has type 'resource_size_t'
 kernel/resource.c:554: warning: format '%llx' expects type 'long long 
 unsigned int', but argument 4 has type 'resource_size_t'
 kernel/resource.c:554: warning: format '%llx' expects type 'long long 
 unsigned int', but argument 6 has type 'resource_size_t'
 kernel/resource.c:554: warning: format '%llx' expects type 'long long 
 unsigned int', but argument 7 has type 'resource_size_t'

Known issue, Ben wants to add a new variant of %pX in order to print resources 
so that
resource_size_t vs. unsigned long stuff doesn't matter like this any more.

 net/dccp/options.c: In function 'dccp_parse_options':
 net/dccp/options.c:67: warning: 'value' may be used uninitialized in this 
 function

Known issue, not trivial to fix, gcc is just being incredibly silly here as it
can't see all of the control flow.

 drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios':
 drivers/dma/ioat_dca.c:81: error: implicit declaration of function 'cpuid_eax'
 drivers/dma/ioat_dca.c: In function 'system_has_dca_enabled':
 drivers/dma/ioat_dca.c:91: error: implicit declaration of function 
 'boot_cpu_has'
 drivers/dma/ioat_dca.c:91: error: 'X86_FEATURE_DCA' undeclared (first use in 
 this function)
 drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported 
 only once
 drivers/dma/ioat_dca.c:91: error: for each function it appears in.)
 drivers/dma/ioat_dca.c: In function 'ioat_dca_get_tag':
 drivers/dma/ioat_dca.c:190: error: implicit declaration of function 
 'cpu_physical_id'

Known issue.  I tried to ping Jeff Garzik about doing a driver bug fix run in
order to fix this, but he hasn't shown any signs of life.

So I'll do it myself later tonight. :-/

 net/sched/sch_generic.c: In function 'dev_watchdog':
 net/sched/sch_generic.c:224: warning: unused variable 'drivername'

Sucky, if WARN_ONCE() evaluates to nothing the sprintf() string buffer
on the stack looks unused.

 drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_read':
 drivers/rtc/rtc-ds1286.c:33: error: implicit declaration of function 
 '__raw_readl'
 drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_write':
 drivers/rtc/rtc-ds1286.c:38: error: implicit declaration of function 
 '__raw_writel'
 drivers/rtc/rtc-ds1286.c: In function 'ds1286_probe':
 drivers/rtc/rtc-ds1286.c:345: error: implicit declaration of function 
 'ioremap'
 drivers/rtc/rtc-ds1286.c:345: warning: assignment makes pointer from integer 
 without a cast
 drivers/rtc/rtc-ds1286.c:365: error: implicit declaration of function 
 'iounmap'

Missing asm/io.h include.

 drivers/rtc/rtc-m48t35.c: In function 'm48t35_read_time':
 drivers/rtc/rtc-m48t35.c:59: error: implicit declaration of function 'readb'
 drivers/rtc/rtc-m48t35.c:60: error: implicit declaration of function 'writeb'
 drivers/rtc/rtc-m48t35.c: In function 'm48t35_probe':
 drivers/rtc/rtc-m48t35.c:168: error: implicit declaration of function 
 'ioremap'
 drivers/rtc/rtc-m48t35.c:168: warning: assignment makes pointer from integer 
 without a cast
 drivers/rtc/rtc-m48t35.c:188: error: implicit declaration of function 
 'iounmap'

Likewise.

 drivers/net/wireless/libertas_tf/if_usb.c: In function 
 '__if_usb_submit_rx_urb':
 drivers/net/wireless/libertas_tf/if_usb.c:334: warning: cast to pointer from 
 integer of different size

I've seen this one on sparc64 too, I think the arg is totally unused in the end
for this callback control flow and we can just use NULL or zero instead.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Benjamin Herrenschmidt]

On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
 From: Andrew Morton [EMAIL PROTECTED]
 Date: Wed, 15 Oct 2008 21:33:37 -0700
 
  kernel/resource.c: In function '__reserve_region_with_split':
  kernel/resource.c:554: warning: format '%llx' expects type 'long long 
  unsigned int', but argument 3 has type 'resource_size_t'
  kernel/resource.c:554: warning: format '%llx' expects type 'long long 
  unsigned int', but argument 4 has type 'resource_size_t'
  kernel/resource.c:554: warning: format '%llx' expects type 'long long 
  unsigned int', but argument 6 has type 'resource_size_t'
  kernel/resource.c:554: warning: format '%llx' expects type 'long long 
  unsigned int', but argument 7 has type 'resource_size_t'
 
 Known issue, Ben wants to add a new variant of %pX in order to print 
 resources so that
 resource_size_t vs. unsigned long stuff doesn't matter like this any more.

Actually, I was told Linus had one and I've been trying to dig it out...

Oh well, I may as well dig my own old one.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Takashi Iwai]

At Wed, 15 Oct 2008 21:33:37 -0700,
Andrew Morton wrote:
 
 sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
 deprecated (declared at sound/soc/soc-dapm.c:1026)
 sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
 deprecated (declared at sound/soc/soc-dapm.c:1026)

These are definitions of deprecated interfaces.
We can remove it in 2.6.29.  If we don't want to be conservative, it
can be removed in 2.6.28, too.

 sound/soc/codecs/tlv320aic23.c: In function 'tlv320aic23_write':
 sound/soc/codecs/tlv320aic23.c:104: warning: passing argument 2 of 
 'codec-hw_write' makes pointer from integer without a cast
 sound/soc/codecs/tlv320aic23.c: In function 'tlv320aic23_set_dai_sysclk':
 sound/soc/codecs/tlv320aic23.c:424: warning: unused variable 'codec'

The fix was in the pending pull request.

 sound/pci/hda/patch_sigmatel.c: In function 'stac92xx_parse_auto_config':
 sound/pci/hda/patch_sigmatel.c:2819: warning: 'nid' may be used uninitialized 
 in this function

Ditto.


thanks,

Takashi
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig in current -mm

[Stephen Rothwell]

Hi Andrew,

On Wed, 20 Aug 2008 18:16:26 -0700 Andrew Morton [EMAIL PROTECTED] wrote:

 From: Andrew Morton [EMAIL PROTECTED]
 
 powerpc allmodconfig:
 
 ERROR: CMO_PageSize [arch/powerpc/platforms/pseries/cmm.ko] undefined!
 
 (needed for 2.6.27)
 
 Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
 Signed-off-by: Andrew Morton [EMAIL PROTECTED]
 ---
 
  arch/powerpc/platforms/pseries/setup.c |1 +
  1 file changed, 1 insertion(+)
 
 diff -puN arch/powerpc/platforms/pseries/setup.c~powerpc-export-cmo_pagesize 
 arch/powerpc/platforms/pseries/setup.c
 --- a/arch/powerpc/platforms/pseries/setup.c~powerpc-export-cmo_pagesize
 +++ a/arch/powerpc/platforms/pseries/setup.c
 @@ -71,6 +71,7 @@
  int CMO_PrPSP = -1;
  int CMO_SecPSP = -1;
  unsigned long CMO_PageSize = (ASM_CONST(1)  IOMMU_PAGE_SHIFT);
 +EXPORT_SYMBOL(CMO_PageSize);
  
  int fwnmi_active;  /* TRUE if an FWNMI handler is present */
  

Added to linux-next for today.

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpF3X337Pc4e.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig in current -mm

[Stephen Rothwell]

Hi Paul,

On Thu, 21 Aug 2008 15:01:43 +1000 Paul Mackerras [EMAIL PROTECTED] wrote:

 OK.  I think we need to export CMO_PrPSP and CMO_SecPSP as well.
 (Lovely names. :()

These are only used (indirectly) in lparcfg.c which is never a module, so
should be OK.

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpfRPR65Sm1x.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig in current -mm

[Paul Mackerras]

Andrew Morton writes:

 /opt/crosstool/gcc-4.1.0-glibc-2.3.6/powerpc64-unknown-linux-gnu/bin/powerpc64-unknown-linux-gnu-ld:
  .tmp_vmlinux1: section .data.gcov lma 0xc2c2bb78 overlaps previous 
 sections

I suspect your binutils are too old, and the stress that the gcov
stuff puts on the toolchain is showing up a bug in ld.

 powerpc allmodconfig:
 
 ERROR: CMO_PageSize [arch/powerpc/platforms/pseries/cmm.ko] undefined!
 
 (needed for 2.6.27)

OK.  I think we need to export CMO_PrPSP and CMO_SecPSP as well.
(Lovely names. :()

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev