Re: linux-next: build failure after merge of the powerpc tree

[Michael Ellerman]

Xiongwei Song  writes:
> Thank you so much Stephen. Sorry for my negligence.

My fault. I forgot to run allyesconfig.

> Should I fix this myself on powerpc tree?

I'll fix it up.

cheers

Re: linux-next: build failure after merge of the powerpc tree

[Xiongwei Song]

Thank you so much Stephen. Sorry for my negligence.

Should I fix this myself on powerpc tree?

Regards,
Xiongwei

On Mon, Apr 19, 2021 at 5:14 PM Stephen Rothwell  wrote:
>
> Hi all,
>
> After merging the powerpc tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> arch/powerpc/kernel/fadump.c: In function 'crash_fadump':
> arch/powerpc/kernel/fadump.c:731:28: error: 'INTERRUPT_SYSTEM_RESET' 
> undeclared (first use in this function)
>   731 |  if (TRAP(&(fdh->regs)) == INTERRUPT_SYSTEM_RESET) {
>   |^~
> arch/powerpc/kernel/fadump.c:731:28: note: each undeclared identifier is 
> reported only once for each function it appears in
>
> Caused by commit
>
>   7153d4bf0b37 ("powerpc/traps: Enhance readability for trap types")
>
> I have applied the following patch for today.
>
> From: Stephen Rothwell 
> Date: Mon, 19 Apr 2021 19:05:05 +1000
> Subject: [PATCH] fix up for "powerpc/traps: Enhance readability for trap 
> types"
>
> Signed-off-by: Stephen Rothwell 
> ---
>  arch/powerpc/kernel/fadump.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index b55b4c23f3b6..000e3b7f3fca 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  /*
>   * The CPU who acquired the lock to trigger the fadump crash should
> --
> 2.30.2
>
> --
> Cheers,
> Stephen Rothwell

Re: linux-next: build failure after merge of the powerpc tree

[Stephen Rothwell]

Hi Nick,

On Wed, 10 Feb 2021 18:20:54 +1000 Nicholas Piggin  wrote:
>
> Thanks for that, it's due to .noinstr section being put on the other 
> side of .text, so all our interrupt handler asm code can't reach them 
> directly anymore since the ppc interrupt wrappers patch added noinstr
> attribute.
> 
> That's not strictly required though, we've used NOKPROBE_SYMBOL okay
> until now. If you can take this patch for now, it should get 
> allyesconfig to build again. I'll fix it in the powerpc tree before the 
> merge window.
> 
> --
> 
> diff --git a/arch/powerpc/include/asm/interrupt.h 
> b/arch/powerpc/include/asm/interrupt.h
> index 4badb3e51c19..fee1e4dd1e84 100644
> --- a/arch/powerpc/include/asm/interrupt.h
> +++ b/arch/powerpc/include/asm/interrupt.h
> @@ -172,6 +172,8 @@ static inline void interrupt_nmi_exit_prepare(struct 
> pt_regs *regs, struct inter
>  #define DECLARE_INTERRUPT_HANDLER_RAW(func)  \
>   __visible long func(struct pt_regs *regs)
>  
> +#define ppc_noinstr noinline notrace __no_kcsan __no_sanitize_address
> +
>  /**
>   * DEFINE_INTERRUPT_HANDLER_RAW - Define raw interrupt handler function
>   * @func:Function name of the entry point
> @@ -198,7 +200,7 @@ static inline void interrupt_nmi_exit_prepare(struct 
> pt_regs *regs, struct inter
>  #define DEFINE_INTERRUPT_HANDLER_RAW(func)   \
>  static __always_inline long ##func(struct pt_regs *regs);
> \
>   \
> -__visible noinstr long func(struct pt_regs *regs)\
> +__visible ppc_noinstr long func(struct pt_regs *regs)
> \
>  {\
>   long ret;   \
>   \
> @@ -228,7 +230,7 @@ static __always_inline long ##func(struct pt_regs 
> *regs)
>  #define DEFINE_INTERRUPT_HANDLER(func)   
> \
>  static __always_inline void ##func(struct pt_regs *regs);
> \
>   \
> -__visible noinstr void func(struct pt_regs *regs)\
> +__visible ppc_noinstr void func(struct pt_regs *regs)
> \
>  {\
>   struct interrupt_state state;   \
>   \
> @@ -262,7 +264,7 @@ static __always_inline void ##func(struct pt_regs 
> *regs)
>  #define DEFINE_INTERRUPT_HANDLER_RET(func)   \
>  static __always_inline long ##func(struct pt_regs *regs);
> \
>   \
> -__visible noinstr long func(struct pt_regs *regs)\
> +__visible ppc_noinstr long func(struct pt_regs *regs)
> \
>  {\
>   struct interrupt_state state;   \
>   long ret;   \
> @@ -297,7 +299,7 @@ static __always_inline long ##func(struct pt_regs 
> *regs)
>  #define DEFINE_INTERRUPT_HANDLER_ASYNC(func) \
>  static __always_inline void ##func(struct pt_regs *regs);
> \
>   \
> -__visible noinstr void func(struct pt_regs *regs)\
> +__visible ppc_noinstr void func(struct pt_regs *regs)
> \
>  {\
>   struct interrupt_state state;   \
>   \
> @@ -331,7 +333,7 @@ static __always_inline void ##func(struct pt_regs 
> *regs)
>  #define DEFINE_INTERRUPT_HANDLER_NMI(func)   \
>  static __always_inline long ##func(struct pt_regs *regs);
> \
>   \
> -__visible noinstr long func(struct pt_regs *regs)\
> +__visible ppc_noinstr long func(struct pt_regs *regs)
> \
>  {\
>   struct interrupt_nmi_state state;   \
>   long ret;   \

Tested-by: Stephen Rothwell   # allyesconfig build

-- 
Cheers,
Stephen Rothwell


pgpcgf7WXx3w4.pgp
Description: OpenPGP digital signature

Re: linux-next: build failure after merge of the powerpc tree

[Nicholas Piggin]

Excerpts from Stephen Rothwell's message of February 9, 2021 8:19 pm:
> Hi all,
> 
> After merging the powerpc tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> arch/powerpc/kernel/head_64.o:(__ftr_alt_97+0x0): relocation truncated to 
> fit: R_PPC64_REL24 (OPD) against symbol `do_page_fault' defined in .opd 
> section in arch/powerpc/mm/fault.o
> arch/powerpc/kernel/head_64.o:(__ftr_alt_97+0x8): relocation truncated to 
> fit: R_PPC64_REL24 (OPD) against symbol `do_page_fault' defined in .opd 
> section in arch/powerpc/mm/fault.o
> arch/powerpc/kernel/head_64.o:(__ftr_alt_97+0x28): relocation truncated to 
> fit: R_PPC64_REL24 (OPD) against symbol `unknown_exception' defined in .opd 
> section in arch/powerpc/kernel/traps.o
> 
> Not sure exactly which commit caused this, but it is most likkely part
> of a series in the powerpc tree.
> 
> I have left the allyesconfig build broken for today.

Hey Stephen,

Thanks for that, it's due to .noinstr section being put on the other 
side of .text, so all our interrupt handler asm code can't reach them 
directly anymore since the ppc interrupt wrappers patch added noinstr
attribute.

That's not strictly required though, we've used NOKPROBE_SYMBOL okay
until now. If you can take this patch for now, it should get 
allyesconfig to build again. I'll fix it in the powerpc tree before the 
merge window.

Thanks,
Nick
--

diff --git a/arch/powerpc/include/asm/interrupt.h 
b/arch/powerpc/include/asm/interrupt.h
index 4badb3e51c19..fee1e4dd1e84 100644
--- a/arch/powerpc/include/asm/interrupt.h
+++ b/arch/powerpc/include/asm/interrupt.h
@@ -172,6 +172,8 @@ static inline void interrupt_nmi_exit_prepare(struct 
pt_regs *regs, struct inter
 #define DECLARE_INTERRUPT_HANDLER_RAW(func)\
__visible long func(struct pt_regs *regs)
 
+#define ppc_noinstr noinline notrace __no_kcsan __no_sanitize_address
+
 /**
  * DEFINE_INTERRUPT_HANDLER_RAW - Define raw interrupt handler function
  * @func:  Function name of the entry point
@@ -198,7 +200,7 @@ static inline void interrupt_nmi_exit_prepare(struct 
pt_regs *regs, struct inter
 #define DEFINE_INTERRUPT_HANDLER_RAW(func) \
 static __always_inline long ##func(struct pt_regs *regs);  \
\
-__visible noinstr long func(struct pt_regs *regs)  \
+__visible ppc_noinstr long func(struct pt_regs *regs)  \
 {  \
long ret;   \
\
@@ -228,7 +230,7 @@ static __always_inline long ##func(struct pt_regs *regs)
 #define DEFINE_INTERRUPT_HANDLER(func) \
 static __always_inline void ##func(struct pt_regs *regs);  \
\
-__visible noinstr void func(struct pt_regs *regs)  \
+__visible ppc_noinstr void func(struct pt_regs *regs)  \
 {  \
struct interrupt_state state;   \
\
@@ -262,7 +264,7 @@ static __always_inline void ##func(struct pt_regs *regs)
 #define DEFINE_INTERRUPT_HANDLER_RET(func) \
 static __always_inline long ##func(struct pt_regs *regs);  \
\
-__visible noinstr long func(struct pt_regs *regs)  \
+__visible ppc_noinstr long func(struct pt_regs *regs)  \
 {  \
struct interrupt_state state;   \
long ret;   \
@@ -297,7 +299,7 @@ static __always_inline long ##func(struct pt_regs *regs)
 #define DEFINE_INTERRUPT_HANDLER_ASYNC(func)   \
 static __always_inline void ##func(struct pt_regs *regs);  \
\
-__visible noinstr void func(struct pt_regs *regs)  \
+__visible ppc_noinstr void func(struct pt_regs *regs)  \
 {  \
struct interrupt_state state;   \
\
@@ -331,7 +333,7 @@ static __always_inline void ##func(struct pt_regs *regs)
 #define DEFINE_INTERRUPT_HANDLER_NMI(func) \
 static __always_inline long ##func(struct pt_regs *regs);  

Re: linux-next: build failure after merge of the powerpc tree

[Michael Ellerman]

On Mon, 2019-09-30 at 00:13:42 UTC, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the powerpc tree, today's linux-next build (powerpc64
> allnoconfig) failed like this:
> 
> arch/powerpc/mm/book3s64/pgtable.c: In function 'flush_partition':
> arch/powerpc/mm/book3s64/pgtable.c:216:3: error: implicit declaration of fu=
> nction 'radix__flush_all_lpid_guest'; did you mean 'radix__flush_all_lpid'?=
>  [-Werror=3Dimplicit-function-declaration]
>   216 |   radix__flush_all_lpid_guest(lpid);
>   |   ^~~
>   |   radix__flush_all_lpid
> 
> Caused by commit
> 
>   99161de3a283 ("powerpc/64s/radix: tidy up TLB flushing code")
> 
> radix__flush_all_lpid_guest() is only declared for CONFIG_PPC_RADIX_MMU
> which is not set for this build.
> 
> I am not sure why this did not show up earlier (maybe a Kconfig
> change?).
> 
> I added the following hack for today.
> 
> From: Stephen Rothwell 
> Date: Mon, 30 Sep 2019 10:09:17 +1000
> Subject: [PATCH] powerpc/64s/radix: fix for "tidy up TLB flushing code" and
>  !CONFIG_PPC_RADIX_MMU
> 
> Signed-off-by: Stephen Rothwell 

Reapplied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/18217da36103c25d87870624dfa569e6b9906a90

cheers

Re: linux-next: build failure after merge of the powerpc tree

[Michael Ellerman]

On Mon, 2019-09-30 at 00:13:42 UTC, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the powerpc tree, today's linux-next build (powerpc64
> allnoconfig) failed like this:
> 
> arch/powerpc/mm/book3s64/pgtable.c: In function 'flush_partition':
> arch/powerpc/mm/book3s64/pgtable.c:216:3: error: implicit declaration of fu=
> nction 'radix__flush_all_lpid_guest'; did you mean 'radix__flush_all_lpid'?=
>  [-Werror=3Dimplicit-function-declaration]
>   216 |   radix__flush_all_lpid_guest(lpid);
>   |   ^~~
>   |   radix__flush_all_lpid
> 
> Caused by commit
> 
>   99161de3a283 ("powerpc/64s/radix: tidy up TLB flushing code")
> 
> radix__flush_all_lpid_guest() is only declared for CONFIG_PPC_RADIX_MMU
> which is not set for this build.
> 
> I am not sure why this did not show up earlier (maybe a Kconfig
> change?).
> 
> I added the following hack for today.
> 
> From: Stephen Rothwell 
> Date: Mon, 30 Sep 2019 10:09:17 +1000
> Subject: [PATCH] powerpc/64s/radix: fix for "tidy up TLB flushing code" and
>  !CONFIG_PPC_RADIX_MMU
> 
> Signed-off-by: Stephen Rothwell 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/8996ae8f05a1cc5559120aaec36183edb9c68c50

cheers

Re: linux-next: build failure after merge of the powerpc tree

[Christoph Hellwig]

On Mon, Sep 02, 2019 at 09:40:11PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the powerpc tree, today's linux-next build (powerpc
> ppc44x_defconfig) failed like this:

Yes, this conflict is expected and we dicussed it before.  I'll make
sure Linus is in the loop when sending the pull request.

Re: linux-next: build failure after merge of the powerpc tree

[Michael Ellerman]

Christophe Leroy  writes:
> Le 22/02/2019 à 08:14, Stephen Rothwell a écrit :
>> Hi all,
>> 
>> After merging the powerpc tree, today's linux-next build (powerpc
>> allyesconfig) failed like this:
>> 
>> make[4]: *** No rule to make target 'arch/powerpc/mm/ptdump/core.o', needed 
>> by 'arch/powerpc/mm/ptdump/built-in.a'.
>> 
>> Caused by commit
>> 
>>5df1cfa43394 ("powerpc: Move page table dump files in a dedicated 
>> subdirectory")
>> 
>> I have reverted that commit for today.
>
> In the Makefile, replace core.o by ptdump.o (or rename the file ptdump.c 
> to core.c). Michael, what was your intention ?

To not break the build :}

I originally used core.c but then decided ptdump.c was clearer.

My jenkins was unhappy last night due to a distro upgrade so my builds
didn't run and catch the breakage.

I'll just fix it and force push.

cheers

Re: linux-next: build failure after merge of the powerpc tree

[Christophe Leroy]

Le 22/02/2019 à 08:14, Stephen Rothwell a écrit :

Hi all,

After merging the powerpc tree, today's linux-next build (powerpc
allyesconfig) failed like this:

make[4]: *** No rule to make target 'arch/powerpc/mm/ptdump/core.o', needed by 
'arch/powerpc/mm/ptdump/built-in.a'.

Caused by commit

   5df1cfa43394 ("powerpc: Move page table dump files in a dedicated 
subdirectory")

I have reverted that commit for today.



In the Makefile, replace core.o by ptdump.o (or rename the file ptdump.c 
to core.c). Michael, what was your intention ?


Christophe

Re: linux-next: build failure after merge of the powerpc tree

[Michael Ellerman]

On Thu, 2017-11-02 at 06:49:36 UTC, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the powerpc tree, today's linux-next build (powerpc64
> allnoconfig) failed like this:
> 
> arch/powerpc/kernel/irq.o: In function `.replay_system_reset':
> irq.c:(.text+0x10): undefined reference to `.ppc_save_regs'
> 
> Caused by commit
> 
>   78adf6c214f0 ("powerpc/64s: Implement system reset idle wakeup reason")
> 
> I have applied the following fix patch:
> 
> From: Stephen Rothwell 
> Date: Thu, 2 Nov 2017 17:45:18 +1100
> Subject: [PATCH] powerpc/64s: ppc_save_regs is now needed for all 64s builds
> 
> Fixes: 78adf6c214f0 ("powerpc/64s: Implement system reset idle wakeup reason")
> Signed-off-by: Stephen Rothwell 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/fc2a5a6161a26b386eb0936b74a852

cheers

Re: linux-next: build failure after merge of the powerpc tree

[Michael Ellerman]

On Thu, 2017-11-02 at 06:49:36 UTC, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the powerpc tree, today's linux-next build (powerpc64
> allnoconfig) failed like this:
> 
> arch/powerpc/kernel/irq.o: In function `.replay_system_reset':
> irq.c:(.text+0x10): undefined reference to `.ppc_save_regs'
> 
> Caused by commit
> 
>   78adf6c214f0 ("powerpc/64s: Implement system reset idle wakeup reason")
> 
> I have applied the following fix patch:
> 
> From: Stephen Rothwell 
> Date: Thu, 2 Nov 2017 17:45:18 +1100
> Subject: [PATCH] powerpc/64s: ppc_save_regs is now needed for all 64s builds
> 
> Fixes: 78adf6c214f0 ("powerpc/64s: Implement system reset idle wakeup reason")
> Signed-off-by: Stephen Rothwell 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/fc2a5a6161a26b386eb0936b74a852

cheers

Re: linux-next: build failure after merge of the powerpc tree

[Nicholas Piggin]

On Tue, 22 Nov 2016 21:21:14 +1100
Stephen Rothwell  wrote:

> Hi all,
> 
> On Tue, 22 Nov 2016 19:58:32 +1100 Stephen Rothwell  
> wrote:
> >
> > After merging the powerpc tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> > 
> > Inconsistent kallsyms data
> > Try make KALLSYMS_EXTRA_PASS=1 as a workaround
> > 
> > Which is a vast improvement.  I'll try adding 'KALLSYMS_EXTRA_PASS=1'
> > later and see how it goes.  It would be nice not to need it, though.  
> 
> It build with KALLSYMS_EXTRA_PASS=1 on the command line.
> 

Yay!

The inconsistent kallsyms data is not something we're doing wrong or
toolchain bug so much as an inherent flaw in how kallsyms are done.
Basically the allyesconfig kallsyms section expands the kernel so much
that a subsequent linking requires even more stubs, which adds more
symbols, which means the next kallsyms will be a different size, which
means or offsets will be wrong :)

In theory I think it could actually be triggered on smaller kernels if
the size was just right. I'm sort of looking at ways to fix it:

https://patchwork.ozlabs.org/patch/684910/

Hopefully will get something in 4.10. Worst case we could detect the
kallsyms size change and do another pass in response without slowing
down the case where it's not required. Hmm, that might be the best
thing to do for a first pass.

Thanks,
Nick

Re: linux-next: build failure after merge of the powerpc tree

[Nicholas Piggin]

On Tue, 22 Nov 2016 21:21:14 +1100
Stephen Rothwell  wrote:

> Hi all,
> 
> On Tue, 22 Nov 2016 19:58:32 +1100 Stephen Rothwell  
> wrote:
> >
> > After merging the powerpc tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> > 
> > Inconsistent kallsyms data
> > Try make KALLSYMS_EXTRA_PASS=1 as a workaround
> > 
> > Which is a vast improvement.  I'll try adding 'KALLSYMS_EXTRA_PASS=1'
> > later and see how it goes.  It would be nice not to need it, though.  
> 
> It build with KALLSYMS_EXTRA_PASS=1 on the command line.
> 

Yay!

The inconsistent kallsyms data is not something we're doing wrong or
toolchain bug so much as an inherent flaw in how kallsyms are done.
Basically the allyesconfig kallsyms section expands the kernel so much
that a subsequent linking requires even more stubs, which adds more
symbols, which means the next kallsyms will be a different size, which
means or offsets will be wrong :)

In theory I think it could actually be triggered on smaller kernels if
the size was just right. I'm sort of looking at ways to fix it:

https://patchwork.ozlabs.org/patch/684910/

Hopefully will get something in 4.10. Worst case we could detect the
kallsyms size change and do another pass in response without slowing
down the case where it's not required. Hmm, that might be the best
thing to do for a first pass.

Thanks,
Nick

Re: linux-next: build failure after merge of the powerpc tree

[Stephen Rothwell]

Hi all,

On Tue, 22 Nov 2016 19:58:32 +1100 Stephen Rothwell  
wrote:
>
> After merging the powerpc tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> Inconsistent kallsyms data
> Try make KALLSYMS_EXTRA_PASS=1 as a workaround
> 
> Which is a vast improvement.  I'll try adding 'KALLSYMS_EXTRA_PASS=1'
> later and see how it goes.  It would be nice not to need it, though.

It build with KALLSYMS_EXTRA_PASS=1 on the command line.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the powerpc tree

[Stephen Rothwell]

Hi all,

On Tue, 22 Nov 2016 19:58:32 +1100 Stephen Rothwell  
wrote:
>
> After merging the powerpc tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> Inconsistent kallsyms data
> Try make KALLSYMS_EXTRA_PASS=1 as a workaround
> 
> Which is a vast improvement.  I'll try adding 'KALLSYMS_EXTRA_PASS=1'
> later and see how it goes.  It would be nice not to need it, though.

It build with KALLSYMS_EXTRA_PASS=1 on the command line.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the powerpc tree

[Colin Ian King]

On 01/07/16 06:27, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the powerpc tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> arch/powerpc/kernel/fadump.c: In function 'fadump_invalidate_dump':
> arch/powerpc/kernel/fadump.c:1014:2: error: expected ';' before '}' token
>   }
>   ^
> 
> Caused by commit
> 
>   4a03749f140c ("powerpc/fadump: Trivial fix of spelling mistake, clean up 
> message")
> 
> I have added this fix patch for today:
> 
> From: Stephen Rothwell 
> Date: Fri, 1 Jul 2016 15:19:34 +1000
> Subject: [PATCH] powerpc/fadump: add missing semicolon
> 
> Fixes: 4a03749f140c ("powerpc/fadump: Trivial fix of spelling mistake, clean 
> up message")
> Signed-off-by: Stephen Rothwell 
> ---
>  arch/powerpc/kernel/fadump.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index f0664860753e..b3a66d36 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -1010,7 +1010,7 @@ static int fadump_invalidate_dump(struct 
> fadump_mem_struct *fdm)
>  
>   if (rc) {
>   pr_err("Failed to invalidate firmware-assisted dump 
> registration. Unexpected error (%d).\n", rc);
> - return rc
> + return rc;
>   }
>   fw_dump.dump_active = 0;
>   fdm_active = NULL;
> 

Apologies for that. Thanks for fixing it up.

Re: linux-next: build failure after merge of the powerpc tree

[Colin Ian King]

On 01/07/16 06:27, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the powerpc tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> arch/powerpc/kernel/fadump.c: In function 'fadump_invalidate_dump':
> arch/powerpc/kernel/fadump.c:1014:2: error: expected ';' before '}' token
>   }
>   ^
> 
> Caused by commit
> 
>   4a03749f140c ("powerpc/fadump: Trivial fix of spelling mistake, clean up 
> message")
> 
> I have added this fix patch for today:
> 
> From: Stephen Rothwell 
> Date: Fri, 1 Jul 2016 15:19:34 +1000
> Subject: [PATCH] powerpc/fadump: add missing semicolon
> 
> Fixes: 4a03749f140c ("powerpc/fadump: Trivial fix of spelling mistake, clean 
> up message")
> Signed-off-by: Stephen Rothwell 
> ---
>  arch/powerpc/kernel/fadump.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index f0664860753e..b3a66d36 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -1010,7 +1010,7 @@ static int fadump_invalidate_dump(struct 
> fadump_mem_struct *fdm)
>  
>   if (rc) {
>   pr_err("Failed to invalidate firmware-assisted dump 
> registration. Unexpected error (%d).\n", rc);
> - return rc
> + return rc;
>   }
>   fw_dump.dump_active = 0;
>   fdm_active = NULL;
> 

Apologies for that. Thanks for fixing it up.

Re: linux-next: build failure after merge of the powerpc tree

[Michael Ellerman]

On Thu, 2016-01-07 at 19:16 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the powerpc tree, today's linux-next build (powerpc64
> allnoconfig) failed like this:
> 
> arch/powerpc/mm/hash_utils_64.c: In function 'get_paca_psize':
> arch/powerpc/mm/hash_utils_64.c:869:19: error: 'struct paca_struct' has no 
> member named 'context'
>   return get_paca()->context.user_psize;
>^
> arch/powerpc/mm/hash_utils_64.c:870:1: error: control reaches end of non-void 
> function [-Werror=return-type]
>  }
>  ^
> 
> Caused by commit
> 
>   2fc251a8dda5 ("powerpc: Copy only required pieces of the mm_context_t to 
> the paca")

Well that's rather embarrassing, for Mikey ;D

> This build has CONFIG_PPC_MM_SLICES not set ...

Ugh, but it would seem none of our defconfigs do :/

> I have applied the following patch for today:

Thanks.

I'll merge it or something similar once I get a chance to test it.

cheers

--
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/

Re: linux-next: build failure after merge of the powerpc tree

[Michael Ellerman]

On Thu, 2016-01-07 at 19:16 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the powerpc tree, today's linux-next build (powerpc64
> allnoconfig) failed like this:
> 
> arch/powerpc/mm/hash_utils_64.c: In function 'get_paca_psize':
> arch/powerpc/mm/hash_utils_64.c:869:19: error: 'struct paca_struct' has no 
> member named 'context'
>   return get_paca()->context.user_psize;
>^
> arch/powerpc/mm/hash_utils_64.c:870:1: error: control reaches end of non-void 
> function [-Werror=return-type]
>  }
>  ^
> 
> Caused by commit
> 
>   2fc251a8dda5 ("powerpc: Copy only required pieces of the mm_context_t to 
> the paca")

Well that's rather embarrassing, for Mikey ;D

> This build has CONFIG_PPC_MM_SLICES not set ...

Ugh, but it would seem none of our defconfigs do :/

> I have applied the following patch for today:

Thanks.

I'll merge it or something similar once I get a chance to test it.

cheers

--
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/

Re: linux-next: build failure after merge of the powerpc tree

[Michael Ellerman]

On Sat, 2015-08-22 at 09:39 +0530, Vasant Hegde wrote:
> On 08/22/2015 05:10 AM, Michael Ellerman wrote:
> > On Fri, 2015-08-21 at 14:29 +0530, Vasant Hegde wrote:
> >> On 08/21/2015 01:55 PM, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> After merging the nvdimm tree, today's linux-next build (powerpc
> >>> allyesconfig) failed like this:
> >>
> >> Stephen,
> >>
> >> Thanks for reporting! I checked powerpc tree.. This is because of commit
> >> 8a8d9181 in powerpc tree.. Basically Michael missed one hunk (below hunk in
> >> opal-api.h)
> > 
> > Hmm, looks like it.
> > 
> > I do remember the patch didn't apply to my tree, so I guess I accidentally
> > dropped a hunk when I was forcing it to apply.
> 
> Hmmm yeah..My patchset was based on upstream tree (4.2-rc7) instead of powerpc
> next tree.

That's OK. Usually that works fine, and usually when there is a conflict I can
just fix it up. I'm not sure how I managed to drop that chunk, I'll have to go
back and look at what I did. I suspect I hand-edited the patch, and if you do
that wrong it can lead to patch just ignoring the rest of the patch.

I probably should have just asked you to rebase on my next, but given it was
already version 10 I didn't really feel like doing another revision :)

> > Also we're obviously not building this in any of our defconfigs. Can you 
> > please
> > send a patch to enable it for pseries_defconfig and ppc64_defconfig.
> 
> Sure.. Will send separate patch.

Thanks.

cheers


--
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/

Re: linux-next: build failure after merge of the powerpc tree

[Michael Ellerman]

On Sat, 2015-08-22 at 09:39 +0530, Vasant Hegde wrote:
 On 08/22/2015 05:10 AM, Michael Ellerman wrote:
  On Fri, 2015-08-21 at 14:29 +0530, Vasant Hegde wrote:
  On 08/21/2015 01:55 PM, Stephen Rothwell wrote:
  Hi all,
 
  After merging the nvdimm tree, today's linux-next build (powerpc
  allyesconfig) failed like this:
 
  Stephen,
 
  Thanks for reporting! I checked powerpc tree.. This is because of commit
  8a8d9181 in powerpc tree.. Basically Michael missed one hunk (below hunk in
  opal-api.h)
  
  Hmm, looks like it.
  
  I do remember the patch didn't apply to my tree, so I guess I accidentally
  dropped a hunk when I was forcing it to apply.
 
 Hmmm yeah..My patchset was based on upstream tree (4.2-rc7) instead of powerpc
 next tree.

That's OK. Usually that works fine, and usually when there is a conflict I can
just fix it up. I'm not sure how I managed to drop that chunk, I'll have to go
back and look at what I did. I suspect I hand-edited the patch, and if you do
that wrong it can lead to patch just ignoring the rest of the patch.

I probably should have just asked you to rebase on my next, but given it was
already version 10 I didn't really feel like doing another revision :)

  Also we're obviously not building this in any of our defconfigs. Can you 
  please
  send a patch to enable it for pseries_defconfig and ppc64_defconfig.
 
 Sure.. Will send separate patch.

Thanks.

cheers


--
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/

Re: linux-next: build failure after merge of the powerpc tree

[Vasant Hegde]

On 08/22/2015 05:10 AM, Michael Ellerman wrote:
> On Fri, 2015-08-21 at 14:29 +0530, Vasant Hegde wrote:
>> On 08/21/2015 01:55 PM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> After merging the nvdimm tree, today's linux-next build (powerpc
>>> allyesconfig) failed like this:
>>
>> Stephen,
>>
>> Thanks for reporting! I checked powerpc tree.. This is because of commit
>> 8a8d9181 in powerpc tree.. Basically Michael missed one hunk (below hunk in
>> opal-api.h)
> 
> Hmm, looks like it.
> 
> I do remember the patch didn't apply to my tree, so I guess I accidentally
> dropped a hunk when I was forcing it to apply.

Hmmm yeah..My patchset was based on pstream tree (4.2-rc7) instead of powerpc
next tree.


> 
> I also should have looked closer, as the following aren't in the skiboot
> version of opal-api.h. The skiboot and Linux versions of opal-api.h should be
> in sync as much as possible.
> 

As I mentioned in other thread I should have added all these macros to
opal-api.h in skiboot..


>> +/* LED Mode */
>> +#define POWERNV_LED_MODE_LIGHT_PATH"lightpath"
>> +#define POWERNV_LED_MODE_GUIDING_LIGHT "guidinglight"
>> +
>> +/* LED type */
>> +#define POWERNV_LED_TYPE_IDENTIFY  "identify"
>> +#define POWERNV_LED_TYPE_FAULT "fault"
>> +#define POWERNV_LED_TYPE_ATTENTION "attention"
> 
> Furthermore, I don't see the first two used at all, and the bottom three are
> only used in one place in the driver. So I've just sucked the values into the
> driver code and dropped the #defines. Patch coming shortly.
> 
> Also we're obviously not building this in any of our defconfigs. Can you 
> please
> send a patch to enable it for pseries_defconfig and ppc64_defconfig.

Sure.. Will send separate patch.

-Vasant

--
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/

Re: linux-next: build failure after merge of the powerpc tree

[Michael Ellerman]

On Fri, 2015-08-21 at 14:29 +0530, Vasant Hegde wrote:
> On 08/21/2015 01:55 PM, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the nvdimm tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> 
> Stephen,
> 
> Thanks for reporting! I checked powerpc tree.. This is because of commit
> 8a8d9181 in powerpc tree.. Basically Michael missed one hunk (below hunk in
> opal-api.h)

Hmm, looks like it.

I do remember the patch didn't apply to my tree, so I guess I accidentally
dropped a hunk when I was forcing it to apply.

I also should have looked closer, as the following aren't in the skiboot
version of opal-api.h. The skiboot and Linux versions of opal-api.h should be
in sync as much as possible.

> +/* LED Mode */
> +#define POWERNV_LED_MODE_LIGHT_PATH"lightpath"
> +#define POWERNV_LED_MODE_GUIDING_LIGHT "guidinglight"
> +
> +/* LED type */
> +#define POWERNV_LED_TYPE_IDENTIFY  "identify"
> +#define POWERNV_LED_TYPE_FAULT "fault"
> +#define POWERNV_LED_TYPE_ATTENTION "attention"

Furthermore, I don't see the first two used at all, and the bottom three are
only used in one place in the driver. So I've just sucked the values into the
driver code and dropped the #defines. Patch coming shortly.

Also we're obviously not building this in any of our defconfigs. Can you please
send a patch to enable it for pseries_defconfig and ppc64_defconfig.

cheers


--
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/

Re: linux-next: build failure after merge of the powerpc tree

[Vasant Hegde]

On 08/21/2015 01:55 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the nvdimm tree, today's linux-next build (powerpc
> allyesconfig) failed like this:

Stephen,

Thanks for reporting! I checked powerpc tree.. This is because of commit
8a8d9181 in powerpc tree.. Basically Michael missed one hunk (below hunk in
opal-api.h)

+/* LED Mode */
+#define POWERNV_LED_MODE_LIGHT_PATH"lightpath"
+#define POWERNV_LED_MODE_GUIDING_LIGHT "guidinglight"
+
+/* LED type */
+#define POWERNV_LED_TYPE_IDENTIFY  "identify"
+#define POWERNV_LED_TYPE_FAULT "fault"
+#define POWERNV_LED_TYPE_ATTENTION "attention"
+
+enum OpalSlotLedType {
+   OPAL_SLOT_LED_TYPE_ID = 0,  /* IDENTIFY LED */
+   OPAL_SLOT_LED_TYPE_FAULT = 1,   /* FAULT LED */
+   OPAL_SLOT_LED_TYPE_ATTN = 2,/* System Attention LED */
+   OPAL_SLOT_LED_TYPE_MAX = 3
+};
+
+enum OpalSlotLedState {
+   OPAL_SLOT_LED_STATE_OFF = 0,/* LED is OFF */
+   OPAL_SLOT_LED_STATE_ON = 1  /* LED is ON */
+};
+


@Michael,
  Will you be fixing it or you want me to send separate patch for this one ?

-Vasant




> 
> drivers/leds/leds-powernv.c:30:3: error: 'OPAL_SLOT_LED_TYPE_ID' undeclared 
> here (not in a function)
>   {OPAL_SLOT_LED_TYPE_ID,  POWERNV_LED_TYPE_IDENTIFY},
>^
> drivers/leds/leds-powernv.c:30:27: error: 'POWERNV_LED_TYPE_IDENTIFY' 
> undeclared here (not in a function)
>   {OPAL_SLOT_LED_TYPE_ID,  POWERNV_LED_TYPE_IDENTIFY},
>^
> drivers/leds/leds-powernv.c:31:3: error: 'OPAL_SLOT_LED_TYPE_FAULT' 
> undeclared here (not in a function)
>   {OPAL_SLOT_LED_TYPE_FAULT, POWERNV_LED_TYPE_FAULT},
>^
> drivers/leds/leds-powernv.c:31:29: error: 'POWERNV_LED_TYPE_FAULT' undeclared 
> here (not in a function)
>   {OPAL_SLOT_LED_TYPE_FAULT, POWERNV_LED_TYPE_FAULT},
>  ^
> drivers/leds/leds-powernv.c:32:3: error: 'OPAL_SLOT_LED_TYPE_ATTN' undeclared 
> here (not in a function)
>   {OPAL_SLOT_LED_TYPE_ATTN, POWERNV_LED_TYPE_ATTENTION},
>^
> drivers/leds/leds-powernv.c:32:28: error: 'POWERNV_LED_TYPE_ATTENTION' 
> undeclared here (not in a function)
>   {OPAL_SLOT_LED_TYPE_ATTN, POWERNV_LED_TYPE_ATTENTION},
> ^
> drivers/leds/leds-powernv.c: In function 'powernv_led_set':
> drivers/leds/leds-powernv.c:92:13: error: 'OPAL_SLOT_LED_STATE_ON' undeclared 
> (first use in this function)
>   led_mask = OPAL_SLOT_LED_STATE_ON << powernv_led->led_type;
>  ^
> drivers/leds/leds-powernv.c:92:13: note: each undeclared identifier is 
> reported only once for each function it appears in
> drivers/leds/leds-powernv.c:92:36: error: invalid operands to binary << (have 
> 'const struct led_type_map *' and 'int')
>   led_mask = OPAL_SLOT_LED_STATE_ON << powernv_led->led_type;
> ^
> drivers/leds/leds-powernv.c:92:11: warning: assignment makes integer from 
> pointer without a cast
>   led_mask = OPAL_SLOT_LED_STATE_ON << powernv_led->led_type;
>^
> drivers/leds/leds-powernv.c: In function 'powernv_led_get':
> drivers/leds/leds-powernv.c:159:46: error: 'OPAL_SLOT_LED_STATE_ON' 
> undeclared (first use in this function)
>   if (!((led_mask >> powernv_led->led_type) & OPAL_SLOT_LED_STATE_ON)) {
>   ^
> drivers/leds/leds-powernv.c:159:44: error: invalid operands to binary & (have 
> 'u64' and 'const struct led_type_map *')
>   if (!((led_mask >> powernv_led->led_type) & OPAL_SLOT_LED_STATE_ON)) {
> ^
> drivers/leds/leds-powernv.c:166:43: error: invalid operands to binary & (have 
> 'u64' and 'const struct led_type_map *')
>   if ((led_value >> powernv_led->led_type) & OPAL_SLOT_LED_STATE_ON)
>^
> In file included from include/linux/byteorder/big_endian.h:4:0,
>  from arch/powerpc/include/uapi/asm/byteorder.h:13,
>  from include/asm-generic/bitops/le.h:5,
>  from arch/powerpc/include/asm/bitops.h:279,
>  from include/linux/bitops.h:36,
>  from include/linux/kernel.h:10,
>  from include/linux/list.h:8,
>  from include/linux/kobject.h:20,
>  from include/linux/device.h:17,
>  from include/linux/leds.h:15,
>  from drivers/leds/leds-powernv.c:15:
> drivers/leds/leds-powernv.c: In function 'powernv_led_probe':
> drivers/leds/leds-powernv.c:300:49: error: 'OPAL_SLOT_LED_TYPE_MAX' 
> undeclared (first use in this function)
>   powernv_led_common->max_led_type = cpu_to_be64(OPAL_SLOT_LED_TYPE_MAX);
>  ^
> include/uapi/linux/byteorder/big_endian.h:36:51: note: in definition of macro 
> '__cpu_to_be64'
>  #define __cpu_to_be64(x) ((__force __be64)(__u64)(x))
>^
> drivers/leds/leds-powernv.c:300:37: note: 

Re: linux-next: build failure after merge of the powerpc tree

[Vasant Hegde]

On 08/22/2015 05:10 AM, Michael Ellerman wrote:
 On Fri, 2015-08-21 at 14:29 +0530, Vasant Hegde wrote:
 On 08/21/2015 01:55 PM, Stephen Rothwell wrote:
 Hi all,

 After merging the nvdimm tree, today's linux-next build (powerpc
 allyesconfig) failed like this:

 Stephen,

 Thanks for reporting! I checked powerpc tree.. This is because of commit
 8a8d9181 in powerpc tree.. Basically Michael missed one hunk (below hunk in
 opal-api.h)
 
 Hmm, looks like it.
 
 I do remember the patch didn't apply to my tree, so I guess I accidentally
 dropped a hunk when I was forcing it to apply.

Hmmm yeah..My patchset was based on pstream tree (4.2-rc7) instead of powerpc
next tree.


 
 I also should have looked closer, as the following aren't in the skiboot
 version of opal-api.h. The skiboot and Linux versions of opal-api.h should be
 in sync as much as possible.
 

As I mentioned in other thread I should have added all these macros to
opal-api.h in skiboot..


 +/* LED Mode */
 +#define POWERNV_LED_MODE_LIGHT_PATHlightpath
 +#define POWERNV_LED_MODE_GUIDING_LIGHT guidinglight
 +
 +/* LED type */
 +#define POWERNV_LED_TYPE_IDENTIFY  identify
 +#define POWERNV_LED_TYPE_FAULT fault
 +#define POWERNV_LED_TYPE_ATTENTION attention
 
 Furthermore, I don't see the first two used at all, and the bottom three are
 only used in one place in the driver. So I've just sucked the values into the
 driver code and dropped the #defines. Patch coming shortly.
 
 Also we're obviously not building this in any of our defconfigs. Can you 
 please
 send a patch to enable it for pseries_defconfig and ppc64_defconfig.

Sure.. Will send separate patch.

-Vasant

--
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/

Re: linux-next: build failure after merge of the powerpc tree

[Michael Ellerman]

On Fri, 2015-08-21 at 14:29 +0530, Vasant Hegde wrote:
 On 08/21/2015 01:55 PM, Stephen Rothwell wrote:
  Hi all,
  
  After merging the nvdimm tree, today's linux-next build (powerpc
  allyesconfig) failed like this:
 
 Stephen,
 
 Thanks for reporting! I checked powerpc tree.. This is because of commit
 8a8d9181 in powerpc tree.. Basically Michael missed one hunk (below hunk in
 opal-api.h)

Hmm, looks like it.

I do remember the patch didn't apply to my tree, so I guess I accidentally
dropped a hunk when I was forcing it to apply.

I also should have looked closer, as the following aren't in the skiboot
version of opal-api.h. The skiboot and Linux versions of opal-api.h should be
in sync as much as possible.

 +/* LED Mode */
 +#define POWERNV_LED_MODE_LIGHT_PATHlightpath
 +#define POWERNV_LED_MODE_GUIDING_LIGHT guidinglight
 +
 +/* LED type */
 +#define POWERNV_LED_TYPE_IDENTIFY  identify
 +#define POWERNV_LED_TYPE_FAULT fault
 +#define POWERNV_LED_TYPE_ATTENTION attention

Furthermore, I don't see the first two used at all, and the bottom three are
only used in one place in the driver. So I've just sucked the values into the
driver code and dropped the #defines. Patch coming shortly.

Also we're obviously not building this in any of our defconfigs. Can you please
send a patch to enable it for pseries_defconfig and ppc64_defconfig.

cheers


--
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/

Re: linux-next: build failure after merge of the powerpc tree

[Vasant Hegde]

On 08/21/2015 01:55 PM, Stephen Rothwell wrote:
 Hi all,
 
 After merging the nvdimm tree, today's linux-next build (powerpc
 allyesconfig) failed like this:

Stephen,

Thanks for reporting! I checked powerpc tree.. This is because of commit
8a8d9181 in powerpc tree.. Basically Michael missed one hunk (below hunk in
opal-api.h)

+/* LED Mode */
+#define POWERNV_LED_MODE_LIGHT_PATHlightpath
+#define POWERNV_LED_MODE_GUIDING_LIGHT guidinglight
+
+/* LED type */
+#define POWERNV_LED_TYPE_IDENTIFY  identify
+#define POWERNV_LED_TYPE_FAULT fault
+#define POWERNV_LED_TYPE_ATTENTION attention
+
+enum OpalSlotLedType {
+   OPAL_SLOT_LED_TYPE_ID = 0,  /* IDENTIFY LED */
+   OPAL_SLOT_LED_TYPE_FAULT = 1,   /* FAULT LED */
+   OPAL_SLOT_LED_TYPE_ATTN = 2,/* System Attention LED */
+   OPAL_SLOT_LED_TYPE_MAX = 3
+};
+
+enum OpalSlotLedState {
+   OPAL_SLOT_LED_STATE_OFF = 0,/* LED is OFF */
+   OPAL_SLOT_LED_STATE_ON = 1  /* LED is ON */
+};
+


@Michael,
  Will you be fixing it or you want me to send separate patch for this one ?

-Vasant




 
 drivers/leds/leds-powernv.c:30:3: error: 'OPAL_SLOT_LED_TYPE_ID' undeclared 
 here (not in a function)
   {OPAL_SLOT_LED_TYPE_ID,  POWERNV_LED_TYPE_IDENTIFY},
^
 drivers/leds/leds-powernv.c:30:27: error: 'POWERNV_LED_TYPE_IDENTIFY' 
 undeclared here (not in a function)
   {OPAL_SLOT_LED_TYPE_ID,  POWERNV_LED_TYPE_IDENTIFY},
^
 drivers/leds/leds-powernv.c:31:3: error: 'OPAL_SLOT_LED_TYPE_FAULT' 
 undeclared here (not in a function)
   {OPAL_SLOT_LED_TYPE_FAULT, POWERNV_LED_TYPE_FAULT},
^
 drivers/leds/leds-powernv.c:31:29: error: 'POWERNV_LED_TYPE_FAULT' undeclared 
 here (not in a function)
   {OPAL_SLOT_LED_TYPE_FAULT, POWERNV_LED_TYPE_FAULT},
  ^
 drivers/leds/leds-powernv.c:32:3: error: 'OPAL_SLOT_LED_TYPE_ATTN' undeclared 
 here (not in a function)
   {OPAL_SLOT_LED_TYPE_ATTN, POWERNV_LED_TYPE_ATTENTION},
^
 drivers/leds/leds-powernv.c:32:28: error: 'POWERNV_LED_TYPE_ATTENTION' 
 undeclared here (not in a function)
   {OPAL_SLOT_LED_TYPE_ATTN, POWERNV_LED_TYPE_ATTENTION},
 ^
 drivers/leds/leds-powernv.c: In function 'powernv_led_set':
 drivers/leds/leds-powernv.c:92:13: error: 'OPAL_SLOT_LED_STATE_ON' undeclared 
 (first use in this function)
   led_mask = OPAL_SLOT_LED_STATE_ON  powernv_led-led_type;
  ^
 drivers/leds/leds-powernv.c:92:13: note: each undeclared identifier is 
 reported only once for each function it appears in
 drivers/leds/leds-powernv.c:92:36: error: invalid operands to binary  (have 
 'const struct led_type_map *' and 'int')
   led_mask = OPAL_SLOT_LED_STATE_ON  powernv_led-led_type;
 ^
 drivers/leds/leds-powernv.c:92:11: warning: assignment makes integer from 
 pointer without a cast
   led_mask = OPAL_SLOT_LED_STATE_ON  powernv_led-led_type;
^
 drivers/leds/leds-powernv.c: In function 'powernv_led_get':
 drivers/leds/leds-powernv.c:159:46: error: 'OPAL_SLOT_LED_STATE_ON' 
 undeclared (first use in this function)
   if (!((led_mask  powernv_led-led_type)  OPAL_SLOT_LED_STATE_ON)) {
   ^
 drivers/leds/leds-powernv.c:159:44: error: invalid operands to binary  (have 
 'u64' and 'const struct led_type_map *')
   if (!((led_mask  powernv_led-led_type)  OPAL_SLOT_LED_STATE_ON)) {
 ^
 drivers/leds/leds-powernv.c:166:43: error: invalid operands to binary  (have 
 'u64' and 'const struct led_type_map *')
   if ((led_value  powernv_led-led_type)  OPAL_SLOT_LED_STATE_ON)
^
 In file included from include/linux/byteorder/big_endian.h:4:0,
  from arch/powerpc/include/uapi/asm/byteorder.h:13,
  from include/asm-generic/bitops/le.h:5,
  from arch/powerpc/include/asm/bitops.h:279,
  from include/linux/bitops.h:36,
  from include/linux/kernel.h:10,
  from include/linux/list.h:8,
  from include/linux/kobject.h:20,
  from include/linux/device.h:17,
  from include/linux/leds.h:15,
  from drivers/leds/leds-powernv.c:15:
 drivers/leds/leds-powernv.c: In function 'powernv_led_probe':
 drivers/leds/leds-powernv.c:300:49: error: 'OPAL_SLOT_LED_TYPE_MAX' 
 undeclared (first use in this function)
   powernv_led_common-max_led_type = cpu_to_be64(OPAL_SLOT_LED_TYPE_MAX);
  ^
 include/uapi/linux/byteorder/big_endian.h:36:51: note: in definition of macro 
 '__cpu_to_be64'
  #define __cpu_to_be64(x) ((__force __be64)(__u64)(x))
^
 drivers/leds/leds-powernv.c:300:37: note: in expansion of macro 'cpu_to_be64'
   powernv_led_common-max_led_type = cpu_to_be64(OPAL_SLOT_LED_TYPE_MAX);
  

Re: linux-next: build failure after merge of the powerpc tree

[Benjamin Herrenschmidt]

On Tue, 2013-07-02 at 10:54 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the powerpc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> fs/pstore/ftrace.c: In function 'pstore_ftrace_call':
> fs/pstore/ftrace.c:47:6: warning: passing argument 7 of 'psinfo->write_buf' 
> makes integer from pointer without a cast [enabled by default]
>   sizeof(rec), psinfo);
>   ^
> fs/pstore/ftrace.c:47:6: note: expected 'size_t' but argument is of type 
> 'struct pstore_info *'
> fs/pstore/ftrace.c:47:6: error: too few arguments to function 
> 'psinfo->write_buf'
> 
> Caused by commit 6bbbca735936 ("pstore: Pass header size in the pstore
> write callback").
> 
> I have used the version from next-20130701 for today.

Interestingly enough I didn't see that when testing a x86_64 build, I
might have failed to test with ftrace enabled.

Aruna, please send a fix ASAP.

Cheers,
Ben.


--
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/

Re: linux-next: build failure after merge of the powerpc tree

[Benjamin Herrenschmidt]

On Tue, 2013-07-02 at 10:54 +1000, Stephen Rothwell wrote:
 Hi all,
 
 After merging the powerpc tree, today's linux-next build (x86_64
 allmodconfig) failed like this:
 
 fs/pstore/ftrace.c: In function 'pstore_ftrace_call':
 fs/pstore/ftrace.c:47:6: warning: passing argument 7 of 'psinfo-write_buf' 
 makes integer from pointer without a cast [enabled by default]
   sizeof(rec), psinfo);
   ^
 fs/pstore/ftrace.c:47:6: note: expected 'size_t' but argument is of type 
 'struct pstore_info *'
 fs/pstore/ftrace.c:47:6: error: too few arguments to function 
 'psinfo-write_buf'
 
 Caused by commit 6bbbca735936 (pstore: Pass header size in the pstore
 write callback).
 
 I have used the version from next-20130701 for today.

Interestingly enough I didn't see that when testing a x86_64 build, I
might have failed to test with ftrace enabled.

Aruna, please send a fix ASAP.

Cheers,
Ben.


--
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/

Re: linux-next: build failure after merge of the powerpc tree

[Benjamin Herrenschmidt]

On Wed, 2012-11-28 at 14:03 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the powerpc tree, next-20121115's build (powerpc
> allmodconfig) failed like this:
> 
> ERROR: ".of_reconfig_notifier_register" [drivers/crypto/nx/nx-compress.ko] 
> undefined!
> ERROR: ".of_reconfig_notifier_unregister" [drivers/crypto/nx/nx-compress.ko] 
> undefined!
> 
> Caused by commit 1cf3d8b3d24c ("powerpc+of: Add of node/property
> notification chain for adds and removes").

That nx stuff should just have gone through the powerpc tree... that's
not the first time it trips on generic changes because we miss it
being in the crypto tree...

Ashley, Nathan, who owns that ? Can you come up with a fixup patch ?

Ben.


--
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/

Re: linux-next: build failure after merge of the powerpc tree

[Benjamin Herrenschmidt]

On Wed, 2012-11-28 at 14:03 +1100, Stephen Rothwell wrote:
 Hi all,
 
 After merging the powerpc tree, next-20121115's build (powerpc
 allmodconfig) failed like this:
 
 ERROR: .of_reconfig_notifier_register [drivers/crypto/nx/nx-compress.ko] 
 undefined!
 ERROR: .of_reconfig_notifier_unregister [drivers/crypto/nx/nx-compress.ko] 
 undefined!
 
 Caused by commit 1cf3d8b3d24c (powerpc+of: Add of node/property
 notification chain for adds and removes).

That nx stuff should just have gone through the powerpc tree... that's
not the first time it trips on generic changes because we miss it
being in the crypto tree...

Ashley, Nathan, who owns that ? Can you come up with a fixup patch ?

Ben.


--
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/