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

[Rob Herring]

On Wed, Feb 10, 2021 at 2:44 PM Saravana Kannan  wrote:
>
> On Wed, Feb 10, 2021 at 12:15 PM Rob Herring  wrote:
> >
> > On Wed, Feb 10, 2021 at 1:17 PM Saravana Kannan  
> > wrote:
> > >
> > > On Wed, Feb 10, 2021 at 11:06 AM Saravana Kannan  
> > > wrote:
> > > >
> > > > On Wed, Feb 10, 2021 at 10:18 AM Greg KH  wrote:
> > > > >
> > > > > On Wed, Feb 10, 2021 at 09:47:20PM +1100, Stephen Rothwell wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > After merging the driver-core tree, today's linux-next build 
> > > > > > (sparc64
> > > > > > defconfig) failed like this:
> > > > > >
> > > > > > drivers/of/property.o: In function `parse_interrupts':
> > > > > > property.c:(.text+0x14e0): undefined reference to `of_irq_parse_one'
> > > > > >
> > > > > > Caused by commit
> > > > > >
> > > > > >   f265f06af194 ("of: property: Fix fw_devlink handling of 
> > > > > > interrupts/interrupts-extended")
> > > > > >
> > > > > > CONFIG_OF_IRQ depends on !SPARC so of_irq_parse_one() needs a stub.
> >
> > It's always Sparc!
> >
> > > > > > I have added the following patch for today.
> > > > > >
> > > > > > From: Stephen Rothwell 
> > > > > > Date: Wed, 10 Feb 2021 21:27:56 +1100
> > > > > > Subject: [PATCH] of: irq: make a stub for of_irq_parse_one()
> > > > > >
> > > > > > Signed-off-by: Stephen Rothwell 
> > > > > > ---
> > > > > >  include/linux/of_irq.h | 9 +++--
> > > > > >  1 file changed, 7 insertions(+), 2 deletions(-)
> > > >
> > > > Thanks Stephen!
> > >
> > > Actually the stub needs to return an error. 0 indicates it found the 
> > > interrupt.
> >
> > I have a slight preference if you could add an 'if
> > (!IS_ENABLED(CONFIG_OF_IRQ))' at the caller instead.
> >
> > If you grep of_irq_parse_one, you'll see there's only a few users
> > which means it's on my hit list to make it private. Stub functions
> > give the impression 'use everywhere'.
>
> I already sent out a fix :(

Okay, it's fine. I misread Greg's mail.

> Will that check optimize out the code and not cause build errors? If
> so, I can send out a patch later.

Yes, it will not trigger link errors. You could still get compile
errors if say a struct member is ifdef'ed out.

Rob

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

[Saravana Kannan]

On Wed, Feb 10, 2021 at 12:15 PM Rob Herring  wrote:
>
> On Wed, Feb 10, 2021 at 1:17 PM Saravana Kannan  wrote:
> >
> > On Wed, Feb 10, 2021 at 11:06 AM Saravana Kannan  
> > wrote:
> > >
> > > On Wed, Feb 10, 2021 at 10:18 AM Greg KH  wrote:
> > > >
> > > > On Wed, Feb 10, 2021 at 09:47:20PM +1100, Stephen Rothwell wrote:
> > > > > Hi all,
> > > > >
> > > > > After merging the driver-core tree, today's linux-next build (sparc64
> > > > > defconfig) failed like this:
> > > > >
> > > > > drivers/of/property.o: In function `parse_interrupts':
> > > > > property.c:(.text+0x14e0): undefined reference to `of_irq_parse_one'
> > > > >
> > > > > Caused by commit
> > > > >
> > > > >   f265f06af194 ("of: property: Fix fw_devlink handling of 
> > > > > interrupts/interrupts-extended")
> > > > >
> > > > > CONFIG_OF_IRQ depends on !SPARC so of_irq_parse_one() needs a stub.
>
> It's always Sparc!
>
> > > > > I have added the following patch for today.
> > > > >
> > > > > From: Stephen Rothwell 
> > > > > Date: Wed, 10 Feb 2021 21:27:56 +1100
> > > > > Subject: [PATCH] of: irq: make a stub for of_irq_parse_one()
> > > > >
> > > > > Signed-off-by: Stephen Rothwell 
> > > > > ---
> > > > >  include/linux/of_irq.h | 9 +++--
> > > > >  1 file changed, 7 insertions(+), 2 deletions(-)
> > >
> > > Thanks Stephen!
> >
> > Actually the stub needs to return an error. 0 indicates it found the 
> > interrupt.
>
> I have a slight preference if you could add an 'if
> (!IS_ENABLED(CONFIG_OF_IRQ))' at the caller instead.
>
> If you grep of_irq_parse_one, you'll see there's only a few users
> which means it's on my hit list to make it private. Stub functions
> give the impression 'use everywhere'.

I already sent out a fix :(

Will that check optimize out the code and not cause build errors? If
so, I can send out a patch later.

-Saravana

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

[Rob Herring]

On Wed, Feb 10, 2021 at 1:17 PM Saravana Kannan  wrote:
>
> On Wed, Feb 10, 2021 at 11:06 AM Saravana Kannan  wrote:
> >
> > On Wed, Feb 10, 2021 at 10:18 AM Greg KH  wrote:
> > >
> > > On Wed, Feb 10, 2021 at 09:47:20PM +1100, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > > > After merging the driver-core tree, today's linux-next build (sparc64
> > > > defconfig) failed like this:
> > > >
> > > > drivers/of/property.o: In function `parse_interrupts':
> > > > property.c:(.text+0x14e0): undefined reference to `of_irq_parse_one'
> > > >
> > > > Caused by commit
> > > >
> > > >   f265f06af194 ("of: property: Fix fw_devlink handling of 
> > > > interrupts/interrupts-extended")
> > > >
> > > > CONFIG_OF_IRQ depends on !SPARC so of_irq_parse_one() needs a stub.

It's always Sparc!

> > > > I have added the following patch for today.
> > > >
> > > > From: Stephen Rothwell 
> > > > Date: Wed, 10 Feb 2021 21:27:56 +1100
> > > > Subject: [PATCH] of: irq: make a stub for of_irq_parse_one()
> > > >
> > > > Signed-off-by: Stephen Rothwell 
> > > > ---
> > > >  include/linux/of_irq.h | 9 +++--
> > > >  1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > Thanks Stephen!
>
> Actually the stub needs to return an error. 0 indicates it found the 
> interrupt.

I have a slight preference if you could add an 'if
(!IS_ENABLED(CONFIG_OF_IRQ))' at the caller instead.

If you grep of_irq_parse_one, you'll see there's only a few users
which means it's on my hit list to make it private. Stub functions
give the impression 'use everywhere'.

Rob

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

[Greg KH]

On Wed, Feb 10, 2021 at 11:17:16AM -0800, Saravana Kannan wrote:
> On Wed, Feb 10, 2021 at 11:06 AM Saravana Kannan  wrote:
> >
> > On Wed, Feb 10, 2021 at 10:18 AM Greg KH  wrote:
> > >
> > > On Wed, Feb 10, 2021 at 09:47:20PM +1100, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > > > After merging the driver-core tree, today's linux-next build (sparc64
> > > > defconfig) failed like this:
> > > >
> > > > drivers/of/property.o: In function `parse_interrupts':
> > > > property.c:(.text+0x14e0): undefined reference to `of_irq_parse_one'
> > > >
> > > > Caused by commit
> > > >
> > > >   f265f06af194 ("of: property: Fix fw_devlink handling of 
> > > > interrupts/interrupts-extended")
> > > >
> > > > CONFIG_OF_IRQ depends on !SPARC so of_irq_parse_one() needs a stub.
> > > > I have added the following patch for today.
> > > >
> > > > From: Stephen Rothwell 
> > > > Date: Wed, 10 Feb 2021 21:27:56 +1100
> > > > Subject: [PATCH] of: irq: make a stub for of_irq_parse_one()
> > > >
> > > > Signed-off-by: Stephen Rothwell 
> > > > ---
> > > >  include/linux/of_irq.h | 9 +++--
> > > >  1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > Thanks Stephen!
> 
> Actually the stub needs to return an error. 0 indicates it found the 
> interrupt.

Can you send a fix-up patch for this?  This is now in my tree :(

thanks,

greg k-h

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

[Saravana Kannan]

On Wed, Feb 10, 2021 at 11:06 AM Saravana Kannan  wrote:
>
> On Wed, Feb 10, 2021 at 10:18 AM Greg KH  wrote:
> >
> > On Wed, Feb 10, 2021 at 09:47:20PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the driver-core tree, today's linux-next build (sparc64
> > > defconfig) failed like this:
> > >
> > > drivers/of/property.o: In function `parse_interrupts':
> > > property.c:(.text+0x14e0): undefined reference to `of_irq_parse_one'
> > >
> > > Caused by commit
> > >
> > >   f265f06af194 ("of: property: Fix fw_devlink handling of 
> > > interrupts/interrupts-extended")
> > >
> > > CONFIG_OF_IRQ depends on !SPARC so of_irq_parse_one() needs a stub.
> > > I have added the following patch for today.
> > >
> > > From: Stephen Rothwell 
> > > Date: Wed, 10 Feb 2021 21:27:56 +1100
> > > Subject: [PATCH] of: irq: make a stub for of_irq_parse_one()
> > >
> > > Signed-off-by: Stephen Rothwell 
> > > ---
> > >  include/linux/of_irq.h | 9 +++--
> > >  1 file changed, 7 insertions(+), 2 deletions(-)
>
> Thanks Stephen!

Actually the stub needs to return an error. 0 indicates it found the interrupt.

-Saravana

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

[Saravana Kannan]

On Wed, Feb 10, 2021 at 10:18 AM Greg KH  wrote:
>
> On Wed, Feb 10, 2021 at 09:47:20PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the driver-core tree, today's linux-next build (sparc64
> > defconfig) failed like this:
> >
> > drivers/of/property.o: In function `parse_interrupts':
> > property.c:(.text+0x14e0): undefined reference to `of_irq_parse_one'
> >
> > Caused by commit
> >
> >   f265f06af194 ("of: property: Fix fw_devlink handling of 
> > interrupts/interrupts-extended")
> >
> > CONFIG_OF_IRQ depends on !SPARC so of_irq_parse_one() needs a stub.
> > I have added the following patch for today.
> >
> > From: Stephen Rothwell 
> > Date: Wed, 10 Feb 2021 21:27:56 +1100
> > Subject: [PATCH] of: irq: make a stub for of_irq_parse_one()
> >
> > Signed-off-by: Stephen Rothwell 
> > ---
> >  include/linux/of_irq.h | 9 +++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)

Thanks Stephen!

-Saravana

>
> Thanks for this, I'll go queue it up now.
>
> greg k-h

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

[Greg KH]

On Wed, Feb 10, 2021 at 09:47:20PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the driver-core tree, today's linux-next build (sparc64
> defconfig) failed like this:
> 
> drivers/of/property.o: In function `parse_interrupts':
> property.c:(.text+0x14e0): undefined reference to `of_irq_parse_one'
> 
> Caused by commit
> 
>   f265f06af194 ("of: property: Fix fw_devlink handling of 
> interrupts/interrupts-extended")
> 
> CONFIG_OF_IRQ depends on !SPARC so of_irq_parse_one() needs a stub.
> I have added the following patch for today.
> 
> From: Stephen Rothwell 
> Date: Wed, 10 Feb 2021 21:27:56 +1100
> Subject: [PATCH] of: irq: make a stub for of_irq_parse_one()
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  include/linux/of_irq.h | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)

Thanks for this, I'll go queue it up now.

greg k-h

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

[Kees Cook]

On Wed, Sep 09, 2020 at 09:21:05AM +0200, Greg KH wrote:
> On Wed, Sep 09, 2020 at 03:47:09PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the driver-core tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > lib/test_firmware.c: In function 'trigger_request_platform_store':
> > lib/test_firmware.c:517:35: error: 'efi_embedded_fw_list' undeclared (first 
> > use in this function); did you mean 'efi_embedded_fw_desc'?
> >   517 |  list_add(_embedded_fw.list, _embedded_fw_list);
> >   |   ^~~~
> >   |   efi_embedded_fw_desc
> > lib/test_firmware.c:517:35: note: each undeclared identifier is reported 
> > only once for each function it appears in
> > lib/test_firmware.c:518:34: error: 'efi_embedded_fw_checked' undeclared 
> > (first use in this function); did you mean 'saved_efi_embedded_fw_checked'?
> >   518 |  saved_efi_embedded_fw_checked = efi_embedded_fw_checked;
> >   |  ^~~
> >   |  saved_efi_embedded_fw_checked
> > 
> > Caused by commit
> > 
> >   18efb2f9e897 ("test_firmware: Test platform fw loading on non-EFI 
> > systems")
> 
> {sigh}
> 
> I'll go revert this, sorry about that.
> 
> Kees, can you fix up this whole series and resend it again?  I'm
> dropping it from my trees now...

Oh ew, I will check the configs. I wonder what went wrong with this...
sorry for the noise!

-- 
Kees Cook

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

[Greg KH]

On Wed, Sep 09, 2020 at 03:47:09PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> lib/test_firmware.c: In function 'trigger_request_platform_store':
> lib/test_firmware.c:517:35: error: 'efi_embedded_fw_list' undeclared (first 
> use in this function); did you mean 'efi_embedded_fw_desc'?
>   517 |  list_add(_embedded_fw.list, _embedded_fw_list);
>   |   ^~~~
>   |   efi_embedded_fw_desc
> lib/test_firmware.c:517:35: note: each undeclared identifier is reported only 
> once for each function it appears in
> lib/test_firmware.c:518:34: error: 'efi_embedded_fw_checked' undeclared 
> (first use in this function); did you mean 'saved_efi_embedded_fw_checked'?
>   518 |  saved_efi_embedded_fw_checked = efi_embedded_fw_checked;
>   |  ^~~
>   |  saved_efi_embedded_fw_checked
> 
> Caused by commit
> 
>   18efb2f9e897 ("test_firmware: Test platform fw loading on non-EFI systems")
> 
> I have reverted that commit for today.

Now reverted in my tree too, thanks.

greg k-h

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

[Greg KH]

On Wed, Sep 09, 2020 at 03:47:09PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> lib/test_firmware.c: In function 'trigger_request_platform_store':
> lib/test_firmware.c:517:35: error: 'efi_embedded_fw_list' undeclared (first 
> use in this function); did you mean 'efi_embedded_fw_desc'?
>   517 |  list_add(_embedded_fw.list, _embedded_fw_list);
>   |   ^~~~
>   |   efi_embedded_fw_desc
> lib/test_firmware.c:517:35: note: each undeclared identifier is reported only 
> once for each function it appears in
> lib/test_firmware.c:518:34: error: 'efi_embedded_fw_checked' undeclared 
> (first use in this function); did you mean 'saved_efi_embedded_fw_checked'?
>   518 |  saved_efi_embedded_fw_checked = efi_embedded_fw_checked;
>   |  ^~~
>   |  saved_efi_embedded_fw_checked
> 
> Caused by commit
> 
>   18efb2f9e897 ("test_firmware: Test platform fw loading on non-EFI systems")

{sigh}

I'll go revert this, sorry about that.

Kees, can you fix up this whole series and resend it again?  I'm
dropping it from my trees now...

thanks,

greg k-h

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

[Kees Cook]

On Mon, Jul 27, 2020 at 12:17:38PM +0200, Greg KH wrote:
> On Mon, Jul 27, 2020 at 04:55:39PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the driver-core tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > In file included from include/linux/dmi.h:5,
> >  from drivers/firmware/efi/embedded-firmware.c:8:
> > drivers/firmware/efi/embedded-firmware.c:25:38: error: static declaration 
> > of 'efi_embedded_fw_list' follows non-static declaration
> >25 | EFI_EMBEDDED_FW_VISIBILITY LIST_HEAD(efi_embedded_fw_list);
> >   |  ^~~~
> > include/linux/list.h:24:19: note: in definition of macro 'LIST_HEAD'
> >24 |  struct list_head name = LIST_HEAD_INIT(name)
> >   |   ^~~~
> > In file included from drivers/firmware/efi/embedded-firmware.c:17:
> > drivers/firmware/efi/embedded-firmware.h:16:25: note: previous declaration 
> > of 'efi_embedded_fw_list' was here
> >16 | extern struct list_head efi_embedded_fw_list;
> >   | ^~~~
> > drivers/firmware/efi/embedded-firmware.c:26:33: error: static declaration 
> > of 'efi_embedded_fw_checked' follows non-static declaration
> >26 | EFI_EMBEDDED_FW_VISIBILITY bool efi_embedded_fw_checked;
> >   | ^~~
> > In file included from drivers/firmware/efi/embedded-firmware.c:17:
> > drivers/firmware/efi/embedded-firmware.h:17:13: note: previous declaration 
> > of 'efi_embedded_fw_checked' was here
> >17 | extern bool efi_embedded_fw_checked;
> >   | ^~~
> > 
> > Caused by commit
> > 
> >   2d38dbf89a06 ("test_firmware: Test platform fw loading on non-EFI 
> > systems")
> > 
> > CONFIG_TEST_FIRMWARE=m for this build.
> > 
> > I have used the driver-core tree from next-20200724 for today.
> 
> Thanks, I've reverted this from my tree now.

Ugh, my mistake; sorry for the hassle! I will get this corrected and
re-sent.

-- 
Kees Cook

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

[Greg KH]

On Mon, Jul 27, 2020 at 04:55:39PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> In file included from include/linux/dmi.h:5,
>  from drivers/firmware/efi/embedded-firmware.c:8:
> drivers/firmware/efi/embedded-firmware.c:25:38: error: static declaration of 
> 'efi_embedded_fw_list' follows non-static declaration
>25 | EFI_EMBEDDED_FW_VISIBILITY LIST_HEAD(efi_embedded_fw_list);
>   |  ^~~~
> include/linux/list.h:24:19: note: in definition of macro 'LIST_HEAD'
>24 |  struct list_head name = LIST_HEAD_INIT(name)
>   |   ^~~~
> In file included from drivers/firmware/efi/embedded-firmware.c:17:
> drivers/firmware/efi/embedded-firmware.h:16:25: note: previous declaration of 
> 'efi_embedded_fw_list' was here
>16 | extern struct list_head efi_embedded_fw_list;
>   | ^~~~
> drivers/firmware/efi/embedded-firmware.c:26:33: error: static declaration of 
> 'efi_embedded_fw_checked' follows non-static declaration
>26 | EFI_EMBEDDED_FW_VISIBILITY bool efi_embedded_fw_checked;
>   | ^~~
> In file included from drivers/firmware/efi/embedded-firmware.c:17:
> drivers/firmware/efi/embedded-firmware.h:17:13: note: previous declaration of 
> 'efi_embedded_fw_checked' was here
>17 | extern bool efi_embedded_fw_checked;
>   | ^~~
> 
> Caused by commit
> 
>   2d38dbf89a06 ("test_firmware: Test platform fw loading on non-EFI systems")
> 
> CONFIG_TEST_FIRMWARE=m for this build.
> 
> I have used the driver-core tree from next-20200724 for today.

Thanks, I've reverted this from my tree now.

greg k-h

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

[Mark Brown]

On Wed, Sep 18, 2019 at 12:03:17PM -0700, Linus Torvalds wrote:
> On Wed, Sep 18, 2019 at 11:53 AM Greg KH  wrote:
> > On Wed, Sep 18, 2019 at 06:09:52PM +0100, Mark Brown wrote:

> > > After merging the driver-core tree, today's linux-next build
> > > for arm64 allmodconfig failed like this:

> > Wait, I thought Linus said this fixup was now resolved.  What went
> > wrong?

> I think this is purely a linux-next build failure.

> I do full allmodconfig builds between each merge I do, and what
> happened is that as part of the LED merge, I removed the
> no-longer-used 'i2c_acpi_find_match_adapter()' to resolve that build
> warning.

> Then linux-next presumably merged my tree with the driver-core tree,
> and that re-instated the use of i2c_acpi_find_match_adapter() - which
> was now gone.

> But when *I* merged the driver-core tree, I did the merge fixup
> correctly to actually re-instate not only the use, but also re-instate
> the removed function that now had a use again.

Yes, that's exactly what happened - it's purely an issue when Greg's
tree is merged automatically, I was reporting the same thing you fixed
up.  If the initial build of your tree had been broken I'd have been
complaining much more loudy and much earlier!

> > Linus, should I submit a fix for this?

> My tree should be fine, and I really think this is just a temporary
> linux-next effect from the above. I think linux-next only handled the
> actual syntactic conflicts, not the semantic conflict of "function had
> been removed to avoid build error from previous merge, and needed to
> be brought back"

Right, git just sees the code moving about and got confused.  Since
you've merged both trees now tomorrow's -next won't do anything for
driver-core and the automation will handle everything fine.


signature.asc
Description: PGP signature

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

[Suzuki K Poulose]

On 09/18/2019 08:07 PM, Greg KH wrote:

On Wed, Sep 18, 2019 at 12:03:17PM -0700, Linus Torvalds wrote:

On Wed, Sep 18, 2019 at 11:53 AM Greg KH  wrote:


On Wed, Sep 18, 2019 at 06:09:52PM +0100, Mark Brown wrote:


After merging the driver-core tree, today's linux-next build
for arm64 allmodconfig failed like this:


Wait, I thought Linus said this fixup was now resolved.  What went
wrong?


I think this is purely a linux-next build failure.

I do full allmodconfig builds between each merge I do, and what
happened is that as part of the LED merge, I removed the
no-longer-used 'i2c_acpi_find_match_adapter()' to resolve that build
warning.

Then linux-next presumably merged my tree with the driver-core tree,
and that re-instated the use of i2c_acpi_find_match_adapter() - which
was now gone.

But when *I* merged the driver-core tree, I did the merge fixup
correctly to actually re-instate not only the use, but also re-instate
the removed function that now had a use again.


Linus, should I submit a fix for this?


My tree should be fine, and I really think this is just a temporary
linux-next effect from the above. I think linux-next only handled the
actual syntactic conflicts, not the semantic conflict of "function had
been removed to avoid build error from previous merge, and needed to
be brought back"

Knock wood.


I looked at your merge of the driver core tree, and see that the
"missing" function is now back.

And I did a test build here and all works for me, so I think this is ok,
thanks for the fixup.

greg k-h



Thanks for the fixup ! Apologies for the inconvenience

Suzuki

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

[Greg KH]

On Wed, Sep 18, 2019 at 12:03:17PM -0700, Linus Torvalds wrote:
> On Wed, Sep 18, 2019 at 11:53 AM Greg KH  wrote:
> >
> > On Wed, Sep 18, 2019 at 06:09:52PM +0100, Mark Brown wrote:
> > >
> > > After merging the driver-core tree, today's linux-next build
> > > for arm64 allmodconfig failed like this:
> >
> > Wait, I thought Linus said this fixup was now resolved.  What went
> > wrong?
> 
> I think this is purely a linux-next build failure.
> 
> I do full allmodconfig builds between each merge I do, and what
> happened is that as part of the LED merge, I removed the
> no-longer-used 'i2c_acpi_find_match_adapter()' to resolve that build
> warning.
> 
> Then linux-next presumably merged my tree with the driver-core tree,
> and that re-instated the use of i2c_acpi_find_match_adapter() - which
> was now gone.
> 
> But when *I* merged the driver-core tree, I did the merge fixup
> correctly to actually re-instate not only the use, but also re-instate
> the removed function that now had a use again.
> 
> > Linus, should I submit a fix for this?
> 
> My tree should be fine, and I really think this is just a temporary
> linux-next effect from the above. I think linux-next only handled the
> actual syntactic conflicts, not the semantic conflict of "function had
> been removed to avoid build error from previous merge, and needed to
> be brought back"
> 
> Knock wood.

I looked at your merge of the driver core tree, and see that the
"missing" function is now back.

And I did a test build here and all works for me, so I think this is ok,
thanks for the fixup.

greg k-h

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

[Linus Torvalds]

On Wed, Sep 18, 2019 at 11:53 AM Greg KH  wrote:
>
> On Wed, Sep 18, 2019 at 06:09:52PM +0100, Mark Brown wrote:
> >
> > After merging the driver-core tree, today's linux-next build
> > for arm64 allmodconfig failed like this:
>
> Wait, I thought Linus said this fixup was now resolved.  What went
> wrong?

I think this is purely a linux-next build failure.

I do full allmodconfig builds between each merge I do, and what
happened is that as part of the LED merge, I removed the
no-longer-used 'i2c_acpi_find_match_adapter()' to resolve that build
warning.

Then linux-next presumably merged my tree with the driver-core tree,
and that re-instated the use of i2c_acpi_find_match_adapter() - which
was now gone.

But when *I* merged the driver-core tree, I did the merge fixup
correctly to actually re-instate not only the use, but also re-instate
the removed function that now had a use again.

> Linus, should I submit a fix for this?

My tree should be fine, and I really think this is just a temporary
linux-next effect from the above. I think linux-next only handled the
actual syntactic conflicts, not the semantic conflict of "function had
been removed to avoid build error from previous merge, and needed to
be brought back"

Knock wood.

  Linus

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

[Greg KH]

On Wed, Sep 18, 2019 at 06:09:52PM +0100, Mark Brown wrote:
> Hi all,
> 
> After merging the driver-core tree, today's linux-next build
> for arm64 allmodconfig failed like this:
> 
> /home/broonie/next/next/drivers/i2c/i2c-core-acpi.c: In function 
> 'i2c_acpi_find_adapter_by_handle':
> /home/broonie/next/next/drivers/i2c/i2c-core-acpi.c:352:10: error: 
> 'i2c_acpi_find_match_adapter' undeclared (first use in this function); did 
> you mean 'i2c_acpi_find_bus_speed'?
>   i2c_acpi_find_match_adapter);
>   ^~~
>   i2c_acpi_find_bus_speed
> /home/broonie/next/next/drivers/i2c/i2c-core-acpi.c:352:10: note: each 
> undeclared identifier is reported only once for each function it appears in
> 
> Caused by commit
> 
>   644bf600889554210 ("i2c: Revert incorrect conversion to use generic helper")
> 
> In yesterday's -next that function existed but it appears to have been
> removed in Linus' tree as part of the merge:
> 
>   4feaab05dc1eda3 ("Merge tag 'leds-for-5.4-rc1' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds")
> 
> by the commit
> 
>   00500147cbd3fc5 ("drivers: Introduce device lookup variants by 
> ACPI_COMPANION device")
> 
> (ie, the commit that the failing commit was trying to revert.)  I
> suspect this is confusion caused by things going into Linus' tree in
> different orders.  I've fixed this up by re-adding the function.

Wait, I thought Linus said this fixup was now resolved.  What went
wrong?

Linus, should I submit a fix for this?

thanks,

greg k-h

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

[Greg KH]

On Thu, Aug 29, 2019 at 05:35:15PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the driver-core tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> ERROR: "platform_get_irq_optional" [drivers/hwmon/pwm-fan.ko] undefined!
> 
> Caused by commit
> 
>   6e7e5c7fbc1c ("hwmon: pwm-fan: Use platform_get_irq_optional()")
> 
> [ or maybe commit
> 
>   8973ea47901c ("driver core: platform: Introduce 
> platform_get_irq_optional()")
> ]
> 
> I have added the following patch for today.
> 
> From: Stephen Rothwell 
> Date: Thu, 29 Aug 2019 17:26:34 +1000
> Subject: [PATCH] driver core: platform: export platform_get_irq_optional
> 
> Fixes: 6e7e5c7fbc1c ("hwmon: pwm-fan: Use platform_get_irq_optional()")
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/base/platform.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 0dda6ade50fd..11c6e56ccc22 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -213,6 +213,7 @@ int platform_get_irq_optional(struct platform_device 
> *dev, unsigned int num)
>  {
>   return __platform_get_irq(dev, num);
>  }
> +EXPORT_SYMBOL_GPL(platform_get_irq_optional);

I just got this same patch right before you sent this, so I've queued it
up, thanks.

greg k-h

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

[Greg KH]

On Fri, Feb 01, 2019 at 01:41:46PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> ERROR: "__arm_smccc_hvc" [drivers/firmware/stratix10-svc.ko] undefined!
> ERROR: "__arm_smccc_smc" [drivers/firmware/stratix10-svc.ko] undefined!
> 
> Exposed by commit
> 
>   095ff29d2b88 ("firmware: intel_stratix10_service: add hardware dependency")
> 
> I have added the following partial revert for today:
> 
> From: Stephen Rothwell 
> Date: Fri, 1 Feb 2019 13:37:59 +1100
> Subject: [PATCH] firmware: intel_stratix10_service: remove COMPILE_TEST
> 
> This does not build yet ...
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/firmware/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index 7e5491aed5c8..cac16c4b0df3 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -218,7 +218,7 @@ config FW_CFG_SYSFS_CMDLINE
>  
>  config INTEL_STRATIX10_SERVICE
>   tristate "Intel Stratix10 Service Layer"
> - depends on (ARCH_STRATIX10 && HAVE_ARM_SMCCC) || COMPILE_TEST
> + depends on ARCH_STRATIX10 && HAVE_ARM_SMCCC
>   default n
>   help
> Intel Stratix10 service layer runs at privileged exception level,
> -- 
> 2.20.1
> 
> -- 
> Cheers,
> Stephen Rothwell


Thanks, I've added this to my tree now.

greg k-h

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

[Sergey Senozhatsky]

On (06/13/17 08:20), Greg KH wrote:
> On Tue, Jun 13, 2017 at 04:04:18PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > After merging the driver-core tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > drivers/block/zram/zram_drv.c:1296:28: error: expected ')' before numeric 
> > constant
> >  static CLASS_ATTR(hot_add, 0400, hot_add_show, NULL);
> > ^
> > drivers/block/zram/zram_drv.c:1330:3: error: 'class_attr_hot_add' 
> > undeclared here (not in a function)
> >   _attr_hot_add.attr,
> >^
> > drivers/block/zram/zram_drv.c:1282:16: warning: 'hot_add_show' defined but 
> > not used [-Wunused-function]
> >  static ssize_t hot_add_show(struct class *class,
> > ^
> > 
> > Caused by commit
> > 
> >   27104a53d02e ("zram: use class_groups instead of class_attrs")
> > 
> > I have reverted that commit for today (and commit
> > 
> >   ecbaa83ee84c ("driver core: remove class_attrs from struct class")
> > 
> > temporarily so the the tree will build).
> 
> Crap I missed one.  I'll go fix that up now so this should work for
> tomorrows linux-next, thanks for letting me know.
> 
> Odd that 0-day isn't giving me any failed build reports :(

how did I miss that... I was pretty sure I compile-tested
the patch before I replied... odd... sorry!

thanks for the report, Stephen.

-ss

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

[Sergey Senozhatsky]

On (06/13/17 08:20), Greg KH wrote:
> On Tue, Jun 13, 2017 at 04:04:18PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > After merging the driver-core tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > drivers/block/zram/zram_drv.c:1296:28: error: expected ')' before numeric 
> > constant
> >  static CLASS_ATTR(hot_add, 0400, hot_add_show, NULL);
> > ^
> > drivers/block/zram/zram_drv.c:1330:3: error: 'class_attr_hot_add' 
> > undeclared here (not in a function)
> >   _attr_hot_add.attr,
> >^
> > drivers/block/zram/zram_drv.c:1282:16: warning: 'hot_add_show' defined but 
> > not used [-Wunused-function]
> >  static ssize_t hot_add_show(struct class *class,
> > ^
> > 
> > Caused by commit
> > 
> >   27104a53d02e ("zram: use class_groups instead of class_attrs")
> > 
> > I have reverted that commit for today (and commit
> > 
> >   ecbaa83ee84c ("driver core: remove class_attrs from struct class")
> > 
> > temporarily so the the tree will build).
> 
> Crap I missed one.  I'll go fix that up now so this should work for
> tomorrows linux-next, thanks for letting me know.
> 
> Odd that 0-day isn't giving me any failed build reports :(

how did I miss that... I was pretty sure I compile-tested
the patch before I replied... odd... sorry!

thanks for the report, Stephen.

-ss

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

[Stephen Rothwell]

Hi Greg,

On Tue, 13 Jun 2017 08:20:48 +0200 Greg KH  wrote:
>
> Odd that 0-day isn't giving me any failed build reports :(

Yeah, I wonder if 0-day is doing x86_64 allmodconfig builds regularly ...

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi Greg,

On Tue, 13 Jun 2017 08:20:48 +0200 Greg KH  wrote:
>
> Odd that 0-day isn't giving me any failed build reports :(

Yeah, I wonder if 0-day is doing x86_64 allmodconfig builds regularly ...

-- 
Cheers,
Stephen Rothwell

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

[Greg KH]

On Tue, Jun 13, 2017 at 04:04:18PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/block/zram/zram_drv.c:1296:28: error: expected ')' before numeric 
> constant
>  static CLASS_ATTR(hot_add, 0400, hot_add_show, NULL);
> ^
> drivers/block/zram/zram_drv.c:1330:3: error: 'class_attr_hot_add' undeclared 
> here (not in a function)
>   _attr_hot_add.attr,
>^
> drivers/block/zram/zram_drv.c:1282:16: warning: 'hot_add_show' defined but 
> not used [-Wunused-function]
>  static ssize_t hot_add_show(struct class *class,
> ^
> 
> Caused by commit
> 
>   27104a53d02e ("zram: use class_groups instead of class_attrs")
> 
> I have reverted that commit for today (and commit
> 
>   ecbaa83ee84c ("driver core: remove class_attrs from struct class")
> 
> temporarily so the the tree will build).

Crap I missed one.  I'll go fix that up now so this should work for
tomorrows linux-next, thanks for letting me know.

Odd that 0-day isn't giving me any failed build reports :(

thanks,

greg k-h

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

[Greg KH]

On Tue, Jun 13, 2017 at 04:04:18PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/block/zram/zram_drv.c:1296:28: error: expected ')' before numeric 
> constant
>  static CLASS_ATTR(hot_add, 0400, hot_add_show, NULL);
> ^
> drivers/block/zram/zram_drv.c:1330:3: error: 'class_attr_hot_add' undeclared 
> here (not in a function)
>   _attr_hot_add.attr,
>^
> drivers/block/zram/zram_drv.c:1282:16: warning: 'hot_add_show' defined but 
> not used [-Wunused-function]
>  static ssize_t hot_add_show(struct class *class,
> ^
> 
> Caused by commit
> 
>   27104a53d02e ("zram: use class_groups instead of class_attrs")
> 
> I have reverted that commit for today (and commit
> 
>   ecbaa83ee84c ("driver core: remove class_attrs from struct class")
> 
> temporarily so the the tree will build).

Crap I missed one.  I'll go fix that up now so this should work for
tomorrows linux-next, thanks for letting me know.

Odd that 0-day isn't giving me any failed build reports :(

thanks,

greg k-h

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

[Greg KH]

On Mon, May 02, 2016 at 07:40:47AM -0400, William Breathitt Gray wrote:
> On Mon, May 02, 2016 at 03:42:58PM +1000, Stephen Rothwell wrote:
> >Hi Greg,
> >
> >After merging the driver-core tree, today's linux-next build (x86_64
> >allmodconfig) failed like this:
> >
> >In file included from include/uapi/linux/stddef.h:1:0,
> > from include/linux/stddef.h:4,
> > from include/uapi/linux/posix_types.h:4,
> > from include/uapi/linux/types.h:13,
> > from include/linux/types.h:5,
> > from include/linux/list.h:4,
> > from include/linux/module.h:9,
> > from arch/x86/mm/extable.c:1:
> >arch/x86/mm/extable.c: In function 'fixup_exception':
> >arch/x86/mm/extable.c:102:15: error: implicit declaration of function 
> >'SEGMENT_IS_PNP_CODE' [-Werror=implicit-function-declaration]
> >  if (unlikely(SEGMENT_IS_PNP_CODE(regs->cs))) {
> >   ^
> >drivers/pnp/pnpbios/bioscalls.c:106:34: error: 'PNP_TS1' und
> >eclared (first use in this function)
> >   Q2_SET_SEL(smp_processor_id(), PNP_TS1, ts1_base, ts1_size);
> >  ^
> >drivers/pnp/pnpbios/bioscalls.c:108:34: error: 'PNP_TS2' undeclared (first 
> >use in this function)
> >   Q2_SET_SEL(smp_processor_id(), PNP_TS2, ts2_base, ts2_size);
> >  ^
> >drivers/pnp/pnpbios/bioscalls.c:133:13: error: 'PNP_CS32' undeclared (first 
> >use in this function)
> > "i"(PNP_CS32), "i"(0)
> > ^
> >
> >and on ...
> >
> >Somehow caused by commit
> >
> >  8ac0fba2da41 ("isa: Decouple X86_32 dependency from the ISA Kconfig 
> > option")
> >
> >I don't easily see why it causes the problem, but reverting it makes the
> >build work.  I also cannot rule out interaction with some other tree.
> >
> >I have reverted that commit for today.
> >
> >-- 
> >Cheers,
> >Stephen Rothwell
> 
> The PnP errors are due to an overly broad Kconfig dependency list, and
> are resolved with the following patch:
> . This patch should be applied first
> to prevent the PnP build for X86_64, when the X86_32 dependency is
> decoupled from the ISA Kconfig option in this current patch.

You didn't tell me that when I applied the above patch :(

I'll go apply the pnp patch now, but really, please be more careful with
dependancies next time.

greg k-h

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

[Greg KH]

On Mon, May 02, 2016 at 07:40:47AM -0400, William Breathitt Gray wrote:
> On Mon, May 02, 2016 at 03:42:58PM +1000, Stephen Rothwell wrote:
> >Hi Greg,
> >
> >After merging the driver-core tree, today's linux-next build (x86_64
> >allmodconfig) failed like this:
> >
> >In file included from include/uapi/linux/stddef.h:1:0,
> > from include/linux/stddef.h:4,
> > from include/uapi/linux/posix_types.h:4,
> > from include/uapi/linux/types.h:13,
> > from include/linux/types.h:5,
> > from include/linux/list.h:4,
> > from include/linux/module.h:9,
> > from arch/x86/mm/extable.c:1:
> >arch/x86/mm/extable.c: In function 'fixup_exception':
> >arch/x86/mm/extable.c:102:15: error: implicit declaration of function 
> >'SEGMENT_IS_PNP_CODE' [-Werror=implicit-function-declaration]
> >  if (unlikely(SEGMENT_IS_PNP_CODE(regs->cs))) {
> >   ^
> >drivers/pnp/pnpbios/bioscalls.c:106:34: error: 'PNP_TS1' und
> >eclared (first use in this function)
> >   Q2_SET_SEL(smp_processor_id(), PNP_TS1, ts1_base, ts1_size);
> >  ^
> >drivers/pnp/pnpbios/bioscalls.c:108:34: error: 'PNP_TS2' undeclared (first 
> >use in this function)
> >   Q2_SET_SEL(smp_processor_id(), PNP_TS2, ts2_base, ts2_size);
> >  ^
> >drivers/pnp/pnpbios/bioscalls.c:133:13: error: 'PNP_CS32' undeclared (first 
> >use in this function)
> > "i"(PNP_CS32), "i"(0)
> > ^
> >
> >and on ...
> >
> >Somehow caused by commit
> >
> >  8ac0fba2da41 ("isa: Decouple X86_32 dependency from the ISA Kconfig 
> > option")
> >
> >I don't easily see why it causes the problem, but reverting it makes the
> >build work.  I also cannot rule out interaction with some other tree.
> >
> >I have reverted that commit for today.
> >
> >-- 
> >Cheers,
> >Stephen Rothwell
> 
> The PnP errors are due to an overly broad Kconfig dependency list, and
> are resolved with the following patch:
> . This patch should be applied first
> to prevent the PnP build for X86_64, when the X86_32 dependency is
> decoupled from the ISA Kconfig option in this current patch.

You didn't tell me that when I applied the above patch :(

I'll go apply the pnp patch now, but really, please be more careful with
dependancies next time.

greg k-h

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

[William Breathitt Gray]

On Mon, May 02, 2016 at 03:42:58PM +1000, Stephen Rothwell wrote:
>Hi Greg,
>
>After merging the driver-core tree, today's linux-next build (x86_64
>allmodconfig) failed like this:
>
>In file included from include/uapi/linux/stddef.h:1:0,
> from include/linux/stddef.h:4,
> from include/uapi/linux/posix_types.h:4,
> from include/uapi/linux/types.h:13,
> from include/linux/types.h:5,
> from include/linux/list.h:4,
> from include/linux/module.h:9,
> from arch/x86/mm/extable.c:1:
>arch/x86/mm/extable.c: In function 'fixup_exception':
>arch/x86/mm/extable.c:102:15: error: implicit declaration of function 
>'SEGMENT_IS_PNP_CODE' [-Werror=implicit-function-declaration]
>  if (unlikely(SEGMENT_IS_PNP_CODE(regs->cs))) {
>   ^
>drivers/pnp/pnpbios/bioscalls.c:106:34: error: 'PNP_TS1' und
>eclared (first use in this function)
>   Q2_SET_SEL(smp_processor_id(), PNP_TS1, ts1_base, ts1_size);
>  ^
>drivers/pnp/pnpbios/bioscalls.c:108:34: error: 'PNP_TS2' undeclared (first use 
>in this function)
>   Q2_SET_SEL(smp_processor_id(), PNP_TS2, ts2_base, ts2_size);
>  ^
>drivers/pnp/pnpbios/bioscalls.c:133:13: error: 'PNP_CS32' undeclared (first 
>use in this function)
> "i"(PNP_CS32), "i"(0)
> ^
>
>and on ...
>
>Somehow caused by commit
>
>  8ac0fba2da41 ("isa: Decouple X86_32 dependency from the ISA Kconfig option")
>
>I don't easily see why it causes the problem, but reverting it makes the
>build work.  I also cannot rule out interaction with some other tree.
>
>I have reverted that commit for today.
>
>-- 
>Cheers,
>Stephen Rothwell

The PnP errors are due to an overly broad Kconfig dependency list, and
are resolved with the following patch:
. This patch should be applied first
to prevent the PnP build for X86_64, when the X86_32 dependency is
decoupled from the ISA Kconfig option in this current patch.

See  for the history behind these
two patches.

William Breathitt Gray

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

[William Breathitt Gray]

On Mon, May 02, 2016 at 03:42:58PM +1000, Stephen Rothwell wrote:
>Hi Greg,
>
>After merging the driver-core tree, today's linux-next build (x86_64
>allmodconfig) failed like this:
>
>In file included from include/uapi/linux/stddef.h:1:0,
> from include/linux/stddef.h:4,
> from include/uapi/linux/posix_types.h:4,
> from include/uapi/linux/types.h:13,
> from include/linux/types.h:5,
> from include/linux/list.h:4,
> from include/linux/module.h:9,
> from arch/x86/mm/extable.c:1:
>arch/x86/mm/extable.c: In function 'fixup_exception':
>arch/x86/mm/extable.c:102:15: error: implicit declaration of function 
>'SEGMENT_IS_PNP_CODE' [-Werror=implicit-function-declaration]
>  if (unlikely(SEGMENT_IS_PNP_CODE(regs->cs))) {
>   ^
>drivers/pnp/pnpbios/bioscalls.c:106:34: error: 'PNP_TS1' und
>eclared (first use in this function)
>   Q2_SET_SEL(smp_processor_id(), PNP_TS1, ts1_base, ts1_size);
>  ^
>drivers/pnp/pnpbios/bioscalls.c:108:34: error: 'PNP_TS2' undeclared (first use 
>in this function)
>   Q2_SET_SEL(smp_processor_id(), PNP_TS2, ts2_base, ts2_size);
>  ^
>drivers/pnp/pnpbios/bioscalls.c:133:13: error: 'PNP_CS32' undeclared (first 
>use in this function)
> "i"(PNP_CS32), "i"(0)
> ^
>
>and on ...
>
>Somehow caused by commit
>
>  8ac0fba2da41 ("isa: Decouple X86_32 dependency from the ISA Kconfig option")
>
>I don't easily see why it causes the problem, but reverting it makes the
>build work.  I also cannot rule out interaction with some other tree.
>
>I have reverted that commit for today.
>
>-- 
>Cheers,
>Stephen Rothwell

The PnP errors are due to an overly broad Kconfig dependency list, and
are resolved with the following patch:
. This patch should be applied first
to prevent the PnP build for X86_64, when the X86_32 dependency is
decoupled from the ISA Kconfig option in this current patch.

See  for the history behind these
two patches.

William Breathitt Gray

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

[Jean Delvare]

Hi Stephen, Greg,

Le Wednesday 28 May 2014 à 18:03 +1000, Stephen Rothwell a écrit :
> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/crypto/nx/nx-842.c: In function 'nx842_probe':
> drivers/crypto/nx/nx-842.c:1200:6: error: void value not ignored as it ought 
> to be
>   if (dev_set_drvdata(>dev, rcu_dereference(devdata))) {
>   ^
> 
> Caused by commit 2c1f1ff0f0d9 ("driver core: dev_set_drvdata returns
> void").  Grep is better than hope :-)

Oops, that would be my fault, sorry. I did grep for such cases but my
grep command must have been poor, I only caught 2 of the 3 cases in the
kernel tree. And make allmodconfig didn't help as the driver is
ppc64-specific.

I'll send a fix-up patch immediately, sorry for the trouble.

-- 
Jean Delvare
SUSE L3 Support

--
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 driver-core tree

[Jean Delvare]

Hi Stephen, Greg,

Le Wednesday 28 May 2014 à 18:03 +1000, Stephen Rothwell a écrit :
 Hi Greg,
 
 After merging the driver-core tree, today's linux-next build (powerpc
 ppc64_defconfig) failed like this:
 
 drivers/crypto/nx/nx-842.c: In function 'nx842_probe':
 drivers/crypto/nx/nx-842.c:1200:6: error: void value not ignored as it ought 
 to be
   if (dev_set_drvdata(viodev-dev, rcu_dereference(devdata))) {
   ^
 
 Caused by commit 2c1f1ff0f0d9 (driver core: dev_set_drvdata returns
 void).  Grep is better than hope :-)

Oops, that would be my fault, sorry. I did grep for such cases but my
grep command must have been poor, I only caught 2 of the 3 cases in the
kernel tree. And make allmodconfig didn't help as the driver is
ppc64-specific.

I'll send a fix-up patch immediately, sorry for the trouble.

-- 
Jean Delvare
SUSE L3 Support

--
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 driver-core tree

[Tejun Heo]

Hello, Ben.

On Tue, Mar 18, 2014 at 11:22:26AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2014-03-17 at 18:21 -0400, Tejun Heo wrote:
> > So, looked at the failed code.  The only necessary change seems to be
> > calling device_remove_file_self() in dump_ack_store() and then doing
> > kobject_put() directly afterwards, which would have been completely
> > fine as a merge fix patch.
> 
> Ok. Since there's no merge error, I'll have to tell Linus explicitly to
> apply it during the merge. I've never done that before but I suppose
> it's doable.

Yeah, that should be fine.  For the next tree, including the fix patch
in a temp branch and pulling that into your for-next branch should
work fine.

> Sorry I don't understand. Reverting the removal until after -rc1 (or
> later in the merge window) is the easiest path from my perspective and
> ensure no bisection breakage but whatever Linus prefers works here.

Merge fix doesn't cause any bisection issue either (because it *is* a
merge problem after all).  It could be just my personal preference but
I'd handle this one as merge fix.  If we rever the removal of the
interface, we'll probably need to mark it deprecated too as people
tend to fork off their devel branches before or at rc1.

> I don't think it's a drastic action or anything like that. It can
> trivially be re-applied once the merge window has settled. But I'm happy
> to also just send Linus a "apply this as a merge fixup" patch if he's
> happy with the method (as I said, I've never done that before on
> something that doesn't have an actual merge conflict to begin with)

Sure, either should work.

Thanks.

-- 
tejun
--
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 driver-core tree

[Tejun Heo]

Hello, Ben.

On Tue, Mar 18, 2014 at 11:22:26AM +1100, Benjamin Herrenschmidt wrote:
 On Mon, 2014-03-17 at 18:21 -0400, Tejun Heo wrote:
  So, looked at the failed code.  The only necessary change seems to be
  calling device_remove_file_self() in dump_ack_store() and then doing
  kobject_put() directly afterwards, which would have been completely
  fine as a merge fix patch.
 
 Ok. Since there's no merge error, I'll have to tell Linus explicitly to
 apply it during the merge. I've never done that before but I suppose
 it's doable.

Yeah, that should be fine.  For the next tree, including the fix patch
in a temp branch and pulling that into your for-next branch should
work fine.

 Sorry I don't understand. Reverting the removal until after -rc1 (or
 later in the merge window) is the easiest path from my perspective and
 ensure no bisection breakage but whatever Linus prefers works here.

Merge fix doesn't cause any bisection issue either (because it *is* a
merge problem after all).  It could be just my personal preference but
I'd handle this one as merge fix.  If we rever the removal of the
interface, we'll probably need to mark it deprecated too as people
tend to fork off their devel branches before or at rc1.

 I don't think it's a drastic action or anything like that. It can
 trivially be re-applied once the merge window has settled. But I'm happy
 to also just send Linus a apply this as a merge fixup patch if he's
 happy with the method (as I said, I've never done that before on
 something that doesn't have an actual merge conflict to begin with)

Sure, either should work.

Thanks.

-- 
tejun
--
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 driver-core tree

[Benjamin Herrenschmidt]

On Mon, 2014-03-17 at 18:21 -0400, Tejun Heo wrote:
> So, looked at the failed code.  The only necessary change seems to be
> calling device_remove_file_self() in dump_ack_store() and then doing
> kobject_put() directly afterwards, which would have been completely
> fine as a merge fix patch.

Ok. Since there's no merge error, I'll have to tell Linus explicitly to
apply it during the merge. I've never done that before but I suppose
it's doable.

> Just to be clear, I'm not necessarily against reverting the removal of
> the API.  The removal was based on the speculation that this isn't
> likely to cause trouble.  The speculation was perfectly reasonable but
> being a speculation it failed, so we take actions to remedy that and
> we *do* want to do things that way.  Reverting the removal can sure be
> one choice but the way that choice is being made here seems completely
> wrong to me.  There's no technical evaluation whatsoever.  I'd really
> hate to work in an environment where taking active trade off is
> discouraged replaced with blind policy enforcement.

Sorry I don't understand. Reverting the removal until after -rc1 (or
later in the merge window) is the easiest path from my perspective and
ensure no bisection breakage but whatever Linus prefers works here.

I don't think it's a drastic action or anything like that. It can
trivially be re-applied once the merge window has settled. But I'm happy
to also just send Linus a "apply this as a merge fixup" patch if he's
happy with the method (as I said, I've never done that before on
something that doesn't have an actual merge conflict to begin with)

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 driver-core tree

[Benjamin Herrenschmidt]

On Mon, 2014-03-17 at 14:56 -0700, Greg KH wrote:

> No you can't, sorry.
> 
> And this seems like a huge abuse of sysfs, you better be using binary
> sysfs files for your log data...
> 
> Do you have a pointer to where you document this sysfs api in
> Documentation/ABI/ ?

Yes, the patch adds the documentation along with the facility, I've
attached the doc file to this email.

This is a wrapper on top of firmware interfaces, in a way we are
following ACPI precedent of exposing a bunch of things via sysfs, which
also happen to be a simple and very convenient way of doing it.

The log itself is a binary attribute in PEL format (or SEL when we
support that), we have a userspace parser.

> > Now regarding the practicals of sorting out our trees, Stephen suggested
> > that rather than doing anything on my side (heh, I like that !), you
> > should revert the last patch of the series, the one removing the old
> > API, in your tree.
> > 
> > It can then be re-applied later around rc1.
> 
> I'll look to see if we can do that, let me dig it up out of my tree...

Thanks. That's how Stephen is fixing it up in -next at the moment.

Cheers,
Ben.

> thanks,
> 
> greg k-h
> --
> 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/

What:   /sys/firmware/opal/elog
Date:   Feb 2014
Contact:Stewart Smith 
Description:
This directory exposes error log entries retrieved
through the OPAL firmware interface.

Each error log is identified by a unique ID and will
exist until explicitly acknowledged to firmware.

Each log entry has a directory in /sys/firmware/opal/elog.

Log entries may be purged by the service processor
before retrieved by firmware or retrieved/acknowledged by
Linux if there is no room for more log entries.

In the event that Linux has retrieved the log entries
but not explicitly acknowledged them to firmware and
the service processor needs more room for log entries,
the only remaining copy of a log message may be in
Linux.

Typically, a user space daemon will monitor for new
entries, read them out and acknowledge them.

The service processor may be able to store more log
entries than firmware can, so after you acknowledge
an event from Linux you may instantly get another one
from the queue that was generated some time in the past.

The raw log format is a binary format. We currently
do not parse this at all in kernel, leaving it up to
user space to solve the problem. In future, we may
do more parsing in kernel and add more files to make
it easier for simple user space processes to extract
more information.

For each log entry (directory), there are the following
files:

id: An ASCII representation of the ID of the
error log, in hex - e.g. "0x01".

type:   An ASCII representation of the type id and
description of the type of error log.
Currently just "0x00 PEL" - platform error log.
In the future there may be additional types.

raw:A read-only binary file that can be read
to get the raw log entry. These are
<16kb, often just hundreds of bytes and
"average" 2kb.

acknowledge:Writing 'ack' to this file will acknowledge
the error log to firmware (and in turn
the service processor, if applicable).
Shortly after acknowledging it, the log
entry will be removed from sysfs.
Reading this file will list the supported
operations (curently just acknowledge).

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

[Stewart Smith]

Tejun Heo  writes:
> On Mon, Mar 17, 2014 at 06:05:54PM -0400, Tejun Heo wrote:
>> I think this is being blown out of proportion.  It was a rarely used
>> API and converting to the new one is mostly trivial which can be
>
> So, looked at the failed code.  The only necessary change seems to be
> calling device_remove_file_self() in dump_ack_store() and then doing
> kobject_put() directly afterwards, which would have been completely
> fine as a merge fix patch.

I had a quick look too and this seems correct (at least if my reading on
howto use sysfs APIs is correct).

I'm happy to post a patch somewhere - I guess it's easiest if the
removal waits for one linus merge things cycle and then I can get fix
and removal in? I'm not too fussed.

> Just to be clear, I'm not necessarily against reverting the removal of
> the API.  The removal was based on the speculation that this isn't
> likely to cause trouble.  The speculation was perfectly reasonable but
> being a speculation it failed, so we take actions to remedy that and
> we *do* want to do things that way.  Reverting the removal can sure be
> one choice but the way that choice is being made here seems completely
> wrong to me.  There's no technical evaluation whatsoever.  I'd really
> hate to work in an environment where taking active trade off is
> discouraged replaced with blind policy enforcement.

I use an API and it changes/disappears - it's a gift I have :)

--
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 driver-core tree

[Stewart Smith]

Greg KH  writes:
> On Tue, Mar 18, 2014 at 07:33:30AM +1100, Benjamin Herrenschmidt wrote:
>> On Mon, 2014-03-17 at 11:33 -0700, Greg KH wrote:
>> 
>> > There were only 3 (or 4), users of this api, and no new ones had been
>> > added in _years_, it's a very obscure thing, and odds are, it wouldn't
>> > ever be added again, especially as it was just removed entirely not
>> > being needed anymore.  And I'd argue, it's something that you shouldn't
>> > have even been doing in the first place, so why a new user of it was
>> > added now is quite strange to me.
>> 
>> Actually that's a good question. Is there a better way for us than to
>> use this API ? Essentially we use that because it's our understanding
>> that it is what is needed for a sysfs file that can remove its parent
>> directory from within a write() op.
>> 
>> We followed the driver "remove" implementation as an example.
>> 
>> The reason the opal elog and dump patches use it is that those two
>> patches add sysfs interface that represent the error logs (and platform
>> dumps but you can treat the latter as some kind of special case of error
>> logs) from the service processor in sysfs.
>> 
>> So for each log we create a dir (kobject) which we populate with a few
>> things like the log unique ID, raw data, etc and a file that can be
>> used to "ack" the log with the service processor.
>> 
>> The latter has the effect of removing it. This is done by the collection
>> daemon after it has confirmed that the error log has been stored to disk
>> and properly flushed.
>> 
>> Is there a better interface ? Can we implement for example unlink() on
>> the kobject itself ? IE. Do the ack by essentially having userspace rm
>> the directory ? :-)
>
> No you can't, sorry.
>
> And this seems like a huge abuse of sysfs, you better be using binary
> sysfs files for your log data...

We are. It's a binary format we get from the service processor that we
then parse in userspace.

Seeing as each of these log entries is a separate thing that can be
retrieved and acknowledged to the service processor, it seemed fitting
to have each of them exposed to userspace so that policy can be dictated
there (acking them removes them from FSP and we have use cases for
peeking at them)

If there's a better way, I'd be interested in hearing it - it appeared
to be relatively good fit for sysfs (no sysadmin overhead, busybox has
enough utility to semi-meaningfully poke at it).

> Do you have a pointer to where you document this sysfs api in
> Documentation/ABI/ ?

Yes:
- Documentation/ABI/stable/sysfs-firmware-opal-dump
- Documentation/ABI/stable/sysfs-firmware-opal-elog

>> Now regarding the practicals of sorting out our trees, Stephen suggested
>> that rather than doing anything on my side (heh, I like that !), you
>> should revert the last patch of the series, the one removing the old
>> API, in your tree.
>> 
>> It can then be re-applied later around rc1.
>
> I'll look to see if we can do that, let me dig it up out of my tree...

Thanks. The new API looks like it should work fine for us, I'll be sure
to covert my API usage and let you know.

--
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 driver-core tree

[Tejun Heo]

On Mon, Mar 17, 2014 at 06:05:54PM -0400, Tejun Heo wrote:
> I think this is being blown out of proportion.  It was a rarely used
> API and converting to the new one is mostly trivial which can be

So, looked at the failed code.  The only necessary change seems to be
calling device_remove_file_self() in dump_ack_store() and then doing
kobject_put() directly afterwards, which would have been completely
fine as a merge fix patch.

Just to be clear, I'm not necessarily against reverting the removal of
the API.  The removal was based on the speculation that this isn't
likely to cause trouble.  The speculation was perfectly reasonable but
being a speculation it failed, so we take actions to remedy that and
we *do* want to do things that way.  Reverting the removal can sure be
one choice but the way that choice is being made here seems completely
wrong to me.  There's no technical evaluation whatsoever.  I'd really
hate to work in an environment where taking active trade off is
discouraged replaced with blind policy enforcement.

Thanks.

-- 
tejun
--
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 driver-core tree

[Tejun Heo]

Hello,

On Mon, Mar 17, 2014 at 02:56:19PM -0700, Greg KH wrote:
> > Now regarding the practicals of sorting out our trees, Stephen suggested
> > that rather than doing anything on my side (heh, I like that !), you
> > should revert the last patch of the series, the one removing the old
> > API, in your tree.
> > 
> > It can then be re-applied later around rc1.
> 
> I'll look to see if we can do that, let me dig it up out of my tree...

I think this is being blown out of proportion.  It was a rarely used
API and converting to the new one is mostly trivial which can be
easily done as a merge fix, which is what it is.  Seriously, following
protocols is beneficial upto certain point but we don't want DMV level
beaurocracy in handling patches and there's something wrong when the
first questions for merge conflict in devel branches which comes up
are not "what's this change and what would it take to resolve it?" but
those of strict adherences to protocol.

Can we please take a step back and look at what we're doing?  This was
a change of API which was used very obscure and haven't seen new users
for years.  It is well within the scope of normal (and efficient)
patch routing to route it directly without separate staging release.
It sure developed a conflict but there's nothing wrong to that.  We
don't even want to try to eliminate all the conflicts.  That'd be a
lot of extra effort for no actual gain and simply a stupid trade-off.

This is a merge conflict well with in the scope of what we can expect
to happen with distributed development and this whole thing works as
well as it does only because we can make *sensible* trade offs not
only in code itself but also in how we resolve conflicts among
different branches.

Thanks.

-- 
tejun
--
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 driver-core tree

[Greg KH]

On Tue, Mar 18, 2014 at 07:33:30AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2014-03-17 at 11:33 -0700, Greg KH wrote:
> 
> > There were only 3 (or 4), users of this api, and no new ones had been
> > added in _years_, it's a very obscure thing, and odds are, it wouldn't
> > ever be added again, especially as it was just removed entirely not
> > being needed anymore.  And I'd argue, it's something that you shouldn't
> > have even been doing in the first place, so why a new user of it was
> > added now is quite strange to me.
> 
> Actually that's a good question. Is there a better way for us than to
> use this API ? Essentially we use that because it's our understanding
> that it is what is needed for a sysfs file that can remove its parent
> directory from within a write() op.
> 
> We followed the driver "remove" implementation as an example.
> 
> The reason the opal elog and dump patches use it is that those two
> patches add sysfs interface that represent the error logs (and platform
> dumps but you can treat the latter as some kind of special case of error
> logs) from the service processor in sysfs.
> 
> So for each log we create a dir (kobject) which we populate with a few
> things like the log unique ID, raw data, etc and a file that can be
> used to "ack" the log with the service processor.
> 
> The latter has the effect of removing it. This is done by the collection
> daemon after it has confirmed that the error log has been stored to disk
> and properly flushed.
> 
> Is there a better interface ? Can we implement for example unlink() on
> the kobject itself ? IE. Do the ack by essentially having userspace rm
> the directory ? :-)

No you can't, sorry.

And this seems like a huge abuse of sysfs, you better be using binary
sysfs files for your log data...

Do you have a pointer to where you document this sysfs api in
Documentation/ABI/ ?

> Now regarding the practicals of sorting out our trees, Stephen suggested
> that rather than doing anything on my side (heh, I like that !), you
> should revert the last patch of the series, the one removing the old
> API, in your tree.
> 
> It can then be re-applied later around rc1.

I'll look to see if we can do that, let me dig it up out of my tree...

thanks,

greg k-h
--
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 driver-core tree

[Benjamin Herrenschmidt]

On Mon, 2014-03-17 at 11:33 -0700, Greg KH wrote:

> There were only 3 (or 4), users of this api, and no new ones had been
> added in _years_, it's a very obscure thing, and odds are, it wouldn't
> ever be added again, especially as it was just removed entirely not
> being needed anymore.  And I'd argue, it's something that you shouldn't
> have even been doing in the first place, so why a new user of it was
> added now is quite strange to me.

Actually that's a good question. Is there a better way for us than to
use this API ? Essentially we use that because it's our understanding
that it is what is needed for a sysfs file that can remove its parent
directory from within a write() op.

We followed the driver "remove" implementation as an example.

The reason the opal elog and dump patches use it is that those two
patches add sysfs interface that represent the error logs (and platform
dumps but you can treat the latter as some kind of special case of error
logs) from the service processor in sysfs.

So for each log we create a dir (kobject) which we populate with a few
things like the log unique ID, raw data, etc and a file that can be
used to "ack" the log with the service processor.

The latter has the effect of removing it. This is done by the collection
daemon after it has confirmed that the error log has been stored to disk
and properly flushed.

Is there a better interface ? Can we implement for example unlink() on
the kobject itself ? IE. Do the ack by essentially having userspace rm
the directory ? :-)

Now regarding the practicals of sorting out our trees, Stephen suggested
that rather than doing anything on my side (heh, I like that !), you
should revert the last patch of the series, the one removing the old
API, in your tree.

It can then be re-applied later around rc1.

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 driver-core tree

[Greg KH]

On Mon, Mar 17, 2014 at 10:16:21AM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> On Sat, 15 Mar 2014 05:29:42 + Greg KH  wrote:
> >
> > On Sat, Mar 15, 2014 at 01:57:29PM +1100, Benjamin Herrenschmidt wrote:
> > > 
> > > It's messy. Stephen really doesn't like if we pull each other trees like
> > > that unless they are topic branches. He also doesn't like when we keep
> > > pulling Linus in.
> > 
> > I only pull Linus in after a -rc in which I have merged patches with him
> > for that "topic".  Otherwise I end up with merge issues, and for testing
> > reasons, I want those fixes from Linus and from me, in order to keep
> > people from hitting the same already-fixes issues.
> 
> Maybe you should consider instead just merging the branch you asked
> Linus' to merge instead of back merging his whole -rc ... especially when
> the merge commit message is usually just something like "We want those
> fixes here for testing and development" which doesn't actually tell us
> anything very useful.
> 
> Your trees always have lots of back merges of Linus' tree in them and I
> don't know why Linus has not complained about it before now (or at least
> explained to you why we normally don't do that).

No, I don't like merging at "unknown" points in the tree, I only merge
back at the -rc point as that is a "known good" version of Linus's tree.

And I only do the merge if I have patches that have been accepted in
Linus's tree for that tree (usb, staging, tty, etc.) as almost always,
if I don't, I get merge issues (as you find out all the time), and those
bugfixes that go into Linus's tree, I want them in the -next branch as
well so that the developers running those branches don't have the
problems that those fixes resolved.

> > Just take my tree, it's not a big deal,
> 
> Except, of course, you are completely discounting any testing that Ben
> has done on his tree that could be invalidated and/or complicated by
> pulling in so much more of Linus' tree at this point of the cycle.  And
> it complicates the git history even more than just your trees already do.

If Ben's testing is somehow "invalidated" by moving to a newer -rc
release, then when would that testing have ever happened?  -rc merges
should always be safe to do, otherwise you probably have problems in
your code that Linus will later run into when you ask him to pull for
-rc1.

thanks,

greg k-h
--
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 driver-core tree

[Greg KH]

On Mon, Mar 17, 2014 at 10:16:11AM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> On Tue, 11 Mar 2014 18:50:21 -0700 Greg KH  wrote:
> >
> > On Wed, Mar 12, 2014 at 12:51:52AM +, Mark Brown wrote:
> > > 
> > > After merging the driver-core tree, today's linux-next build ()
> > > failed like this on a PowerPC defconfig:
> > > 
> > > HEAD is now at ceb98e684dec Merge remote-tracking branch 
> > > 'driver-core/driver-core-next'
> > >   GEN /home/broonie/next/powerpc_ppc64_defconfig/Makefile
> > > #
> > > # configuration written to .config
> > > #
> > > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c: In 
> > > function 'elog_ack_store':
> > > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c:84:2: 
> > > error: implicit declaration of function 'sysfs_schedule_callback' 
> > > [-Werror=implicit-function-declaration]
> > >   sysfs_schedule_callback(_obj->kobj, delay_release_kobj,
> > >   ^
> > > cc1: all warnings being treated as errors
> > > make[3]: *** [arch/powerpc/platforms/powernv/opal-elog.o] Error 1
> > > make[3]: *** Waiting for unfinished jobs
> > > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c: In 
> > > function 'dump_ack_store':
> > > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c:100:2: 
> > > error: implicit declaration of function 'sysfs_schedule_callback' 
> > > [-Werror=implicit-function-declaration]
> > >   sysfs_schedule_callback(_obj->kobj, delay_release_kobj,
> > >   ^
> > > cc1: all warnings being treated as errors
> > > 
> > > due to an interaction between d1ba277e7988908 (sysfs, driver-core: remove 
> > > unused {sysfs|device}_schedule_callback_owner()) and 774fea1a38c6a5a8 
> > > (powerpc/powernv: Read OPAL error log and export it through sysfs) from 
> > > the PowerPC tree.
> > > 
> > > I reverted 774fea1a38c6a5a8 for today.
> > 
> > Sounds like the powerpc tree also needs to stop using this function :)
> 
> So, explain to us in detail why the old interface could not be maintained
> for a release, please.  I thought we had become a bit more sophisticated
> about changing core APIs i.e. introduce the new API - fix up all the
> users - keep the old one around if possible for a release (or beyond
> -rc1) to catch the new users.
> 
> It may be that there is a good reason not to so this in this case, but it
> is not explained as far as I can see.

There were only 3 (or 4), users of this api, and no new ones had been
added in _years_, it's a very obscure thing, and odds are, it wouldn't
ever be added again, especially as it was just removed entirely not
being needed anymore.  And I'd argue, it's something that you shouldn't
have even been doing in the first place, so why a new user of it was
added now is quite strange to me.

thanks,

greg k-h
--
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 driver-core tree

[Stephen Rothwell]

Hi all,

On Wed, 12 Mar 2014 00:51:52 + Mark Brown  wrote:
>
> After merging the driver-core tree, today's linux-next build ()
> failed like this on a PowerPC defconfig:
> 
> HEAD is now at ceb98e684dec Merge remote-tracking branch 
> 'driver-core/driver-core-next'
>   GEN /home/broonie/next/powerpc_ppc64_defconfig/Makefile
> #
> # configuration written to .config
> #
> /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c: In 
> function 'elog_ack_store':
> /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c:84:2: 
> error: implicit declaration of function 'sysfs_schedule_callback' 
> [-Werror=implicit-function-declaration]
>   sysfs_schedule_callback(_obj->kobj, delay_release_kobj,
>   ^
> cc1: all warnings being treated as errors
> make[3]: *** [arch/powerpc/platforms/powernv/opal-elog.o] Error 1
> make[3]: *** Waiting for unfinished jobs
> /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c: In 
> function 'dump_ack_store':
> /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c:100:2: 
> error: implicit declaration of function 'sysfs_schedule_callback' 
> [-Werror=implicit-function-declaration]
>   sysfs_schedule_callback(_obj->kobj, delay_release_kobj,
>   ^
> cc1: all warnings being treated as errors
> 
> due to an interaction between d1ba277e7988908 (sysfs, driver-core: remove 
> unused {sysfs|device}_schedule_callback_owner()) and 774fea1a38c6a5a8 
> (powerpc/powernv: Read OPAL error log and export it through sysfs) from the 
> PowerPC tree.
> 
> I reverted 774fea1a38c6a5a8 for today.

I instead reverted commit d1ba277e7988908 (sysfs, driver-core: remove
unused {sysfs|device}_schedule_callback_owner()).  I hope that will work
as well.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpGDY4g4IllU.pgp
Description: PGP signature

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

[Stephen Rothwell]

Hi all,

On Wed, 12 Mar 2014 00:51:52 + Mark Brown broo...@kernel.org wrote:

 After merging the driver-core tree, today's linux-next build ()
 failed like this on a PowerPC defconfig:
 
 HEAD is now at ceb98e684dec Merge remote-tracking branch 
 'driver-core/driver-core-next'
   GEN /home/broonie/next/powerpc_ppc64_defconfig/Makefile
 #
 # configuration written to .config
 #
 /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c: In 
 function 'elog_ack_store':
 /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c:84:2: 
 error: implicit declaration of function 'sysfs_schedule_callback' 
 [-Werror=implicit-function-declaration]
   sysfs_schedule_callback(elog_obj-kobj, delay_release_kobj,
   ^
 cc1: all warnings being treated as errors
 make[3]: *** [arch/powerpc/platforms/powernv/opal-elog.o] Error 1
 make[3]: *** Waiting for unfinished jobs
 /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c: In 
 function 'dump_ack_store':
 /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c:100:2: 
 error: implicit declaration of function 'sysfs_schedule_callback' 
 [-Werror=implicit-function-declaration]
   sysfs_schedule_callback(dump_obj-kobj, delay_release_kobj,
   ^
 cc1: all warnings being treated as errors
 
 due to an interaction between d1ba277e7988908 (sysfs, driver-core: remove 
 unused {sysfs|device}_schedule_callback_owner()) and 774fea1a38c6a5a8 
 (powerpc/powernv: Read OPAL error log and export it through sysfs) from the 
 PowerPC tree.
 
 I reverted 774fea1a38c6a5a8 for today.

I instead reverted commit d1ba277e7988908 (sysfs, driver-core: remove
unused {sysfs|device}_schedule_callback_owner()).  I hope that will work
as well.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpGDY4g4IllU.pgp
Description: PGP signature

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

[Greg KH]

On Mon, Mar 17, 2014 at 10:16:11AM +1100, Stephen Rothwell wrote:
 Hi Greg,
 
 On Tue, 11 Mar 2014 18:50:21 -0700 Greg KH g...@kroah.com wrote:
 
  On Wed, Mar 12, 2014 at 12:51:52AM +, Mark Brown wrote:
   
   After merging the driver-core tree, today's linux-next build ()
   failed like this on a PowerPC defconfig:
   
   HEAD is now at ceb98e684dec Merge remote-tracking branch 
   'driver-core/driver-core-next'
 GEN /home/broonie/next/powerpc_ppc64_defconfig/Makefile
   #
   # configuration written to .config
   #
   /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c: In 
   function 'elog_ack_store':
   /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c:84:2: 
   error: implicit declaration of function 'sysfs_schedule_callback' 
   [-Werror=implicit-function-declaration]
 sysfs_schedule_callback(elog_obj-kobj, delay_release_kobj,
 ^
   cc1: all warnings being treated as errors
   make[3]: *** [arch/powerpc/platforms/powernv/opal-elog.o] Error 1
   make[3]: *** Waiting for unfinished jobs
   /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c: In 
   function 'dump_ack_store':
   /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c:100:2: 
   error: implicit declaration of function 'sysfs_schedule_callback' 
   [-Werror=implicit-function-declaration]
 sysfs_schedule_callback(dump_obj-kobj, delay_release_kobj,
 ^
   cc1: all warnings being treated as errors
   
   due to an interaction between d1ba277e7988908 (sysfs, driver-core: remove 
   unused {sysfs|device}_schedule_callback_owner()) and 774fea1a38c6a5a8 
   (powerpc/powernv: Read OPAL error log and export it through sysfs) from 
   the PowerPC tree.
   
   I reverted 774fea1a38c6a5a8 for today.
  
  Sounds like the powerpc tree also needs to stop using this function :)
 
 So, explain to us in detail why the old interface could not be maintained
 for a release, please.  I thought we had become a bit more sophisticated
 about changing core APIs i.e. introduce the new API - fix up all the
 users - keep the old one around if possible for a release (or beyond
 -rc1) to catch the new users.
 
 It may be that there is a good reason not to so this in this case, but it
 is not explained as far as I can see.

There were only 3 (or 4), users of this api, and no new ones had been
added in _years_, it's a very obscure thing, and odds are, it wouldn't
ever be added again, especially as it was just removed entirely not
being needed anymore.  And I'd argue, it's something that you shouldn't
have even been doing in the first place, so why a new user of it was
added now is quite strange to me.

thanks,

greg k-h
--
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 driver-core tree

[Greg KH]

On Mon, Mar 17, 2014 at 10:16:21AM +1100, Stephen Rothwell wrote:
 Hi Greg,
 
 On Sat, 15 Mar 2014 05:29:42 + Greg KH g...@kroah.com wrote:
 
  On Sat, Mar 15, 2014 at 01:57:29PM +1100, Benjamin Herrenschmidt wrote:
   
   It's messy. Stephen really doesn't like if we pull each other trees like
   that unless they are topic branches. He also doesn't like when we keep
   pulling Linus in.
  
  I only pull Linus in after a -rc in which I have merged patches with him
  for that topic.  Otherwise I end up with merge issues, and for testing
  reasons, I want those fixes from Linus and from me, in order to keep
  people from hitting the same already-fixes issues.
 
 Maybe you should consider instead just merging the branch you asked
 Linus' to merge instead of back merging his whole -rc ... especially when
 the merge commit message is usually just something like We want those
 fixes here for testing and development which doesn't actually tell us
 anything very useful.
 
 Your trees always have lots of back merges of Linus' tree in them and I
 don't know why Linus has not complained about it before now (or at least
 explained to you why we normally don't do that).

No, I don't like merging at unknown points in the tree, I only merge
back at the -rc point as that is a known good version of Linus's tree.

And I only do the merge if I have patches that have been accepted in
Linus's tree for that tree (usb, staging, tty, etc.) as almost always,
if I don't, I get merge issues (as you find out all the time), and those
bugfixes that go into Linus's tree, I want them in the -next branch as
well so that the developers running those branches don't have the
problems that those fixes resolved.

  Just take my tree, it's not a big deal,
 
 Except, of course, you are completely discounting any testing that Ben
 has done on his tree that could be invalidated and/or complicated by
 pulling in so much more of Linus' tree at this point of the cycle.  And
 it complicates the git history even more than just your trees already do.

If Ben's testing is somehow invalidated by moving to a newer -rc
release, then when would that testing have ever happened?  -rc merges
should always be safe to do, otherwise you probably have problems in
your code that Linus will later run into when you ask him to pull for
-rc1.

thanks,

greg k-h
--
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 driver-core tree

[Benjamin Herrenschmidt]

On Mon, 2014-03-17 at 11:33 -0700, Greg KH wrote:

 There were only 3 (or 4), users of this api, and no new ones had been
 added in _years_, it's a very obscure thing, and odds are, it wouldn't
 ever be added again, especially as it was just removed entirely not
 being needed anymore.  And I'd argue, it's something that you shouldn't
 have even been doing in the first place, so why a new user of it was
 added now is quite strange to me.

Actually that's a good question. Is there a better way for us than to
use this API ? Essentially we use that because it's our understanding
that it is what is needed for a sysfs file that can remove its parent
directory from within a write() op.

We followed the driver remove implementation as an example.

The reason the opal elog and dump patches use it is that those two
patches add sysfs interface that represent the error logs (and platform
dumps but you can treat the latter as some kind of special case of error
logs) from the service processor in sysfs.

So for each log we create a dir (kobject) which we populate with a few
things like the log unique ID, raw data, etc and a file that can be
used to ack the log with the service processor.

The latter has the effect of removing it. This is done by the collection
daemon after it has confirmed that the error log has been stored to disk
and properly flushed.

Is there a better interface ? Can we implement for example unlink() on
the kobject itself ? IE. Do the ack by essentially having userspace rm
the directory ? :-)

Now regarding the practicals of sorting out our trees, Stephen suggested
that rather than doing anything on my side (heh, I like that !), you
should revert the last patch of the series, the one removing the old
API, in your tree.

It can then be re-applied later around rc1.

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 driver-core tree

[Greg KH]

On Tue, Mar 18, 2014 at 07:33:30AM +1100, Benjamin Herrenschmidt wrote:
 On Mon, 2014-03-17 at 11:33 -0700, Greg KH wrote:
 
  There were only 3 (or 4), users of this api, and no new ones had been
  added in _years_, it's a very obscure thing, and odds are, it wouldn't
  ever be added again, especially as it was just removed entirely not
  being needed anymore.  And I'd argue, it's something that you shouldn't
  have even been doing in the first place, so why a new user of it was
  added now is quite strange to me.
 
 Actually that's a good question. Is there a better way for us than to
 use this API ? Essentially we use that because it's our understanding
 that it is what is needed for a sysfs file that can remove its parent
 directory from within a write() op.
 
 We followed the driver remove implementation as an example.
 
 The reason the opal elog and dump patches use it is that those two
 patches add sysfs interface that represent the error logs (and platform
 dumps but you can treat the latter as some kind of special case of error
 logs) from the service processor in sysfs.
 
 So for each log we create a dir (kobject) which we populate with a few
 things like the log unique ID, raw data, etc and a file that can be
 used to ack the log with the service processor.
 
 The latter has the effect of removing it. This is done by the collection
 daemon after it has confirmed that the error log has been stored to disk
 and properly flushed.
 
 Is there a better interface ? Can we implement for example unlink() on
 the kobject itself ? IE. Do the ack by essentially having userspace rm
 the directory ? :-)

No you can't, sorry.

And this seems like a huge abuse of sysfs, you better be using binary
sysfs files for your log data...

Do you have a pointer to where you document this sysfs api in
Documentation/ABI/ ?

 Now regarding the practicals of sorting out our trees, Stephen suggested
 that rather than doing anything on my side (heh, I like that !), you
 should revert the last patch of the series, the one removing the old
 API, in your tree.
 
 It can then be re-applied later around rc1.

I'll look to see if we can do that, let me dig it up out of my tree...

thanks,

greg k-h
--
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 driver-core tree

[Tejun Heo]

Hello,

On Mon, Mar 17, 2014 at 02:56:19PM -0700, Greg KH wrote:
  Now regarding the practicals of sorting out our trees, Stephen suggested
  that rather than doing anything on my side (heh, I like that !), you
  should revert the last patch of the series, the one removing the old
  API, in your tree.
  
  It can then be re-applied later around rc1.
 
 I'll look to see if we can do that, let me dig it up out of my tree...

I think this is being blown out of proportion.  It was a rarely used
API and converting to the new one is mostly trivial which can be
easily done as a merge fix, which is what it is.  Seriously, following
protocols is beneficial upto certain point but we don't want DMV level
beaurocracy in handling patches and there's something wrong when the
first questions for merge conflict in devel branches which comes up
are not what's this change and what would it take to resolve it? but
those of strict adherences to protocol.

Can we please take a step back and look at what we're doing?  This was
a change of API which was used very obscure and haven't seen new users
for years.  It is well within the scope of normal (and efficient)
patch routing to route it directly without separate staging release.
It sure developed a conflict but there's nothing wrong to that.  We
don't even want to try to eliminate all the conflicts.  That'd be a
lot of extra effort for no actual gain and simply a stupid trade-off.

This is a merge conflict well with in the scope of what we can expect
to happen with distributed development and this whole thing works as
well as it does only because we can make *sensible* trade offs not
only in code itself but also in how we resolve conflicts among
different branches.

Thanks.

-- 
tejun
--
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 driver-core tree

[Tejun Heo]

On Mon, Mar 17, 2014 at 06:05:54PM -0400, Tejun Heo wrote:
 I think this is being blown out of proportion.  It was a rarely used
 API and converting to the new one is mostly trivial which can be

So, looked at the failed code.  The only necessary change seems to be
calling device_remove_file_self() in dump_ack_store() and then doing
kobject_put() directly afterwards, which would have been completely
fine as a merge fix patch.

Just to be clear, I'm not necessarily against reverting the removal of
the API.  The removal was based on the speculation that this isn't
likely to cause trouble.  The speculation was perfectly reasonable but
being a speculation it failed, so we take actions to remedy that and
we *do* want to do things that way.  Reverting the removal can sure be
one choice but the way that choice is being made here seems completely
wrong to me.  There's no technical evaluation whatsoever.  I'd really
hate to work in an environment where taking active trade off is
discouraged replaced with blind policy enforcement.

Thanks.

-- 
tejun
--
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 driver-core tree

[Stewart Smith]

Greg KH g...@kroah.com writes:
 On Tue, Mar 18, 2014 at 07:33:30AM +1100, Benjamin Herrenschmidt wrote:
 On Mon, 2014-03-17 at 11:33 -0700, Greg KH wrote:
 
  There were only 3 (or 4), users of this api, and no new ones had been
  added in _years_, it's a very obscure thing, and odds are, it wouldn't
  ever be added again, especially as it was just removed entirely not
  being needed anymore.  And I'd argue, it's something that you shouldn't
  have even been doing in the first place, so why a new user of it was
  added now is quite strange to me.
 
 Actually that's a good question. Is there a better way for us than to
 use this API ? Essentially we use that because it's our understanding
 that it is what is needed for a sysfs file that can remove its parent
 directory from within a write() op.
 
 We followed the driver remove implementation as an example.
 
 The reason the opal elog and dump patches use it is that those two
 patches add sysfs interface that represent the error logs (and platform
 dumps but you can treat the latter as some kind of special case of error
 logs) from the service processor in sysfs.
 
 So for each log we create a dir (kobject) which we populate with a few
 things like the log unique ID, raw data, etc and a file that can be
 used to ack the log with the service processor.
 
 The latter has the effect of removing it. This is done by the collection
 daemon after it has confirmed that the error log has been stored to disk
 and properly flushed.
 
 Is there a better interface ? Can we implement for example unlink() on
 the kobject itself ? IE. Do the ack by essentially having userspace rm
 the directory ? :-)

 No you can't, sorry.

 And this seems like a huge abuse of sysfs, you better be using binary
 sysfs files for your log data...

We are. It's a binary format we get from the service processor that we
then parse in userspace.

Seeing as each of these log entries is a separate thing that can be
retrieved and acknowledged to the service processor, it seemed fitting
to have each of them exposed to userspace so that policy can be dictated
there (acking them removes them from FSP and we have use cases for
peeking at them)

If there's a better way, I'd be interested in hearing it - it appeared
to be relatively good fit for sysfs (no sysadmin overhead, busybox has
enough utility to semi-meaningfully poke at it).

 Do you have a pointer to where you document this sysfs api in
 Documentation/ABI/ ?

Yes:
- Documentation/ABI/stable/sysfs-firmware-opal-dump
- Documentation/ABI/stable/sysfs-firmware-opal-elog

 Now regarding the practicals of sorting out our trees, Stephen suggested
 that rather than doing anything on my side (heh, I like that !), you
 should revert the last patch of the series, the one removing the old
 API, in your tree.
 
 It can then be re-applied later around rc1.

 I'll look to see if we can do that, let me dig it up out of my tree...

Thanks. The new API looks like it should work fine for us, I'll be sure
to covert my API usage and let you know.

--
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 driver-core tree

[Stewart Smith]

Tejun Heo t...@kernel.org writes:
 On Mon, Mar 17, 2014 at 06:05:54PM -0400, Tejun Heo wrote:
 I think this is being blown out of proportion.  It was a rarely used
 API and converting to the new one is mostly trivial which can be

 So, looked at the failed code.  The only necessary change seems to be
 calling device_remove_file_self() in dump_ack_store() and then doing
 kobject_put() directly afterwards, which would have been completely
 fine as a merge fix patch.

I had a quick look too and this seems correct (at least if my reading on
howto use sysfs APIs is correct).

I'm happy to post a patch somewhere - I guess it's easiest if the
removal waits for one linus merge things cycle and then I can get fix
and removal in? I'm not too fussed.

 Just to be clear, I'm not necessarily against reverting the removal of
 the API.  The removal was based on the speculation that this isn't
 likely to cause trouble.  The speculation was perfectly reasonable but
 being a speculation it failed, so we take actions to remedy that and
 we *do* want to do things that way.  Reverting the removal can sure be
 one choice but the way that choice is being made here seems completely
 wrong to me.  There's no technical evaluation whatsoever.  I'd really
 hate to work in an environment where taking active trade off is
 discouraged replaced with blind policy enforcement.

I use an API and it changes/disappears - it's a gift I have :)

--
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 driver-core tree

[Benjamin Herrenschmidt]

On Mon, 2014-03-17 at 14:56 -0700, Greg KH wrote:

 No you can't, sorry.
 
 And this seems like a huge abuse of sysfs, you better be using binary
 sysfs files for your log data...
 
 Do you have a pointer to where you document this sysfs api in
 Documentation/ABI/ ?

Yes, the patch adds the documentation along with the facility, I've
attached the doc file to this email.

This is a wrapper on top of firmware interfaces, in a way we are
following ACPI precedent of exposing a bunch of things via sysfs, which
also happen to be a simple and very convenient way of doing it.

The log itself is a binary attribute in PEL format (or SEL when we
support that), we have a userspace parser.

  Now regarding the practicals of sorting out our trees, Stephen suggested
  that rather than doing anything on my side (heh, I like that !), you
  should revert the last patch of the series, the one removing the old
  API, in your tree.
  
  It can then be re-applied later around rc1.
 
 I'll look to see if we can do that, let me dig it up out of my tree...

Thanks. That's how Stephen is fixing it up in -next at the moment.

Cheers,
Ben.

 thanks,
 
 greg k-h
 --
 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/

What:   /sys/firmware/opal/elog
Date:   Feb 2014
Contact:Stewart Smith stew...@linux.vnet.ibm.com
Description:
This directory exposes error log entries retrieved
through the OPAL firmware interface.

Each error log is identified by a unique ID and will
exist until explicitly acknowledged to firmware.

Each log entry has a directory in /sys/firmware/opal/elog.

Log entries may be purged by the service processor
before retrieved by firmware or retrieved/acknowledged by
Linux if there is no room for more log entries.

In the event that Linux has retrieved the log entries
but not explicitly acknowledged them to firmware and
the service processor needs more room for log entries,
the only remaining copy of a log message may be in
Linux.

Typically, a user space daemon will monitor for new
entries, read them out and acknowledge them.

The service processor may be able to store more log
entries than firmware can, so after you acknowledge
an event from Linux you may instantly get another one
from the queue that was generated some time in the past.

The raw log format is a binary format. We currently
do not parse this at all in kernel, leaving it up to
user space to solve the problem. In future, we may
do more parsing in kernel and add more files to make
it easier for simple user space processes to extract
more information.

For each log entry (directory), there are the following
files:

id: An ASCII representation of the ID of the
error log, in hex - e.g. 0x01.

type:   An ASCII representation of the type id and
description of the type of error log.
Currently just 0x00 PEL - platform error log.
In the future there may be additional types.

raw:A read-only binary file that can be read
to get the raw log entry. These are
16kb, often just hundreds of bytes and
average 2kb.

acknowledge:Writing 'ack' to this file will acknowledge
the error log to firmware (and in turn
the service processor, if applicable).
Shortly after acknowledging it, the log
entry will be removed from sysfs.
Reading this file will list the supported
operations (curently just acknowledge).

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

[Benjamin Herrenschmidt]

On Mon, 2014-03-17 at 18:21 -0400, Tejun Heo wrote:
 So, looked at the failed code.  The only necessary change seems to be
 calling device_remove_file_self() in dump_ack_store() and then doing
 kobject_put() directly afterwards, which would have been completely
 fine as a merge fix patch.

Ok. Since there's no merge error, I'll have to tell Linus explicitly to
apply it during the merge. I've never done that before but I suppose
it's doable.

 Just to be clear, I'm not necessarily against reverting the removal of
 the API.  The removal was based on the speculation that this isn't
 likely to cause trouble.  The speculation was perfectly reasonable but
 being a speculation it failed, so we take actions to remedy that and
 we *do* want to do things that way.  Reverting the removal can sure be
 one choice but the way that choice is being made here seems completely
 wrong to me.  There's no technical evaluation whatsoever.  I'd really
 hate to work in an environment where taking active trade off is
 discouraged replaced with blind policy enforcement.

Sorry I don't understand. Reverting the removal until after -rc1 (or
later in the merge window) is the easiest path from my perspective and
ensure no bisection breakage but whatever Linus prefers works here.

I don't think it's a drastic action or anything like that. It can
trivially be re-applied once the merge window has settled. But I'm happy
to also just send Linus a apply this as a merge fixup patch if he's
happy with the method (as I said, I've never done that before on
something that doesn't have an actual merge conflict to begin with)

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 driver-core tree

[Stephen Rothwell]

Hi Greg,

On Tue, 11 Mar 2014 18:50:21 -0700 Greg KH  wrote:
>
> On Wed, Mar 12, 2014 at 12:51:52AM +, Mark Brown wrote:
> > 
> > After merging the driver-core tree, today's linux-next build ()
> > failed like this on a PowerPC defconfig:
> > 
> > HEAD is now at ceb98e684dec Merge remote-tracking branch 
> > 'driver-core/driver-core-next'
> >   GEN /home/broonie/next/powerpc_ppc64_defconfig/Makefile
> > #
> > # configuration written to .config
> > #
> > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c: In 
> > function 'elog_ack_store':
> > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c:84:2: 
> > error: implicit declaration of function 'sysfs_schedule_callback' 
> > [-Werror=implicit-function-declaration]
> >   sysfs_schedule_callback(_obj->kobj, delay_release_kobj,
> >   ^
> > cc1: all warnings being treated as errors
> > make[3]: *** [arch/powerpc/platforms/powernv/opal-elog.o] Error 1
> > make[3]: *** Waiting for unfinished jobs
> > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c: In 
> > function 'dump_ack_store':
> > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c:100:2: 
> > error: implicit declaration of function 'sysfs_schedule_callback' 
> > [-Werror=implicit-function-declaration]
> >   sysfs_schedule_callback(_obj->kobj, delay_release_kobj,
> >   ^
> > cc1: all warnings being treated as errors
> > 
> > due to an interaction between d1ba277e7988908 (sysfs, driver-core: remove 
> > unused {sysfs|device}_schedule_callback_owner()) and 774fea1a38c6a5a8 
> > (powerpc/powernv: Read OPAL error log and export it through sysfs) from the 
> > PowerPC tree.
> > 
> > I reverted 774fea1a38c6a5a8 for today.
> 
> Sounds like the powerpc tree also needs to stop using this function :)

So, explain to us in detail why the old interface could not be maintained
for a release, please.  I thought we had become a bit more sophisticated
about changing core APIs i.e. introduce the new API - fix up all the
users - keep the old one around if possible for a release (or beyond
-rc1) to catch the new users.

It may be that there is a good reason not to so this in this case, but it
is not explained as far as I can see.

Alternatively, it looks as though there may be a fairly trivial transform
from using the old interface to using the new one which could be applied
as part of the merge of these two trees (in linux-next and then in Linus'
tree during the merge window).  Maybe you or Tejun should have explained
that and provided a prototype for the merge fix up.

Greg, you are doing core infrastructure changes in your trees - you need
to consider that new usages may be introduced while those changes are
ongoing.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpd1ZODvTLtN.pgp
Description: PGP signature

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

[Stephen Rothwell]

Hi Greg,

On Sat, 15 Mar 2014 05:29:42 + Greg KH  wrote:
>
> On Sat, Mar 15, 2014 at 01:57:29PM +1100, Benjamin Herrenschmidt wrote:
> > 
> > It's messy. Stephen really doesn't like if we pull each other trees like
> > that unless they are topic branches. He also doesn't like when we keep
> > pulling Linus in.
> 
> I only pull Linus in after a -rc in which I have merged patches with him
> for that "topic".  Otherwise I end up with merge issues, and for testing
> reasons, I want those fixes from Linus and from me, in order to keep
> people from hitting the same already-fixes issues.

Maybe you should consider instead just merging the branch you asked
Linus' to merge instead of back merging his whole -rc ... especially when
the merge commit message is usually just something like "We want those
fixes here for testing and development" which doesn't actually tell us
anything very useful.

Your trees always have lots of back merges of Linus' tree in them and I
don't know why Linus has not complained about it before now (or at least
explained to you why we normally don't do that).

> Just take my tree, it's not a big deal,

Except, of course, you are completely discounting any testing that Ben
has done on his tree that could be invalidated and/or complicated by
pulling in so much more of Linus' tree at this point of the cycle.  And
it complicates the git history even more than just your trees already do.

/me is a bit cross after such a nice holiday in HobbitLand and may need
to take deep breath :-(
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgptMq8OE8DeD.pgp
Description: PGP signature

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

[Stephen Rothwell]

Hi Greg,

On Tue, 11 Mar 2014 18:50:21 -0700 Greg KH g...@kroah.com wrote:

 On Wed, Mar 12, 2014 at 12:51:52AM +, Mark Brown wrote:
  
  After merging the driver-core tree, today's linux-next build ()
  failed like this on a PowerPC defconfig:
  
  HEAD is now at ceb98e684dec Merge remote-tracking branch 
  'driver-core/driver-core-next'
GEN /home/broonie/next/powerpc_ppc64_defconfig/Makefile
  #
  # configuration written to .config
  #
  /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c: In 
  function 'elog_ack_store':
  /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c:84:2: 
  error: implicit declaration of function 'sysfs_schedule_callback' 
  [-Werror=implicit-function-declaration]
sysfs_schedule_callback(elog_obj-kobj, delay_release_kobj,
^
  cc1: all warnings being treated as errors
  make[3]: *** [arch/powerpc/platforms/powernv/opal-elog.o] Error 1
  make[3]: *** Waiting for unfinished jobs
  /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c: In 
  function 'dump_ack_store':
  /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c:100:2: 
  error: implicit declaration of function 'sysfs_schedule_callback' 
  [-Werror=implicit-function-declaration]
sysfs_schedule_callback(dump_obj-kobj, delay_release_kobj,
^
  cc1: all warnings being treated as errors
  
  due to an interaction between d1ba277e7988908 (sysfs, driver-core: remove 
  unused {sysfs|device}_schedule_callback_owner()) and 774fea1a38c6a5a8 
  (powerpc/powernv: Read OPAL error log and export it through sysfs) from the 
  PowerPC tree.
  
  I reverted 774fea1a38c6a5a8 for today.
 
 Sounds like the powerpc tree also needs to stop using this function :)

So, explain to us in detail why the old interface could not be maintained
for a release, please.  I thought we had become a bit more sophisticated
about changing core APIs i.e. introduce the new API - fix up all the
users - keep the old one around if possible for a release (or beyond
-rc1) to catch the new users.

It may be that there is a good reason not to so this in this case, but it
is not explained as far as I can see.

Alternatively, it looks as though there may be a fairly trivial transform
from using the old interface to using the new one which could be applied
as part of the merge of these two trees (in linux-next and then in Linus'
tree during the merge window).  Maybe you or Tejun should have explained
that and provided a prototype for the merge fix up.

Greg, you are doing core infrastructure changes in your trees - you need
to consider that new usages may be introduced while those changes are
ongoing.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpd1ZODvTLtN.pgp
Description: PGP signature

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

[Stephen Rothwell]

Hi Greg,

On Sat, 15 Mar 2014 05:29:42 + Greg KH g...@kroah.com wrote:

 On Sat, Mar 15, 2014 at 01:57:29PM +1100, Benjamin Herrenschmidt wrote:
  
  It's messy. Stephen really doesn't like if we pull each other trees like
  that unless they are topic branches. He also doesn't like when we keep
  pulling Linus in.
 
 I only pull Linus in after a -rc in which I have merged patches with him
 for that topic.  Otherwise I end up with merge issues, and for testing
 reasons, I want those fixes from Linus and from me, in order to keep
 people from hitting the same already-fixes issues.

Maybe you should consider instead just merging the branch you asked
Linus' to merge instead of back merging his whole -rc ... especially when
the merge commit message is usually just something like We want those
fixes here for testing and development which doesn't actually tell us
anything very useful.

Your trees always have lots of back merges of Linus' tree in them and I
don't know why Linus has not complained about it before now (or at least
explained to you why we normally don't do that).

 Just take my tree, it's not a big deal,

Except, of course, you are completely discounting any testing that Ben
has done on his tree that could be invalidated and/or complicated by
pulling in so much more of Linus' tree at this point of the cycle.  And
it complicates the git history even more than just your trees already do.

/me is a bit cross after such a nice holiday in HobbitLand and may need
to take deep breath :-(
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgptMq8OE8DeD.pgp
Description: PGP signature

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

[Benjamin Herrenschmidt]

On Sat, 2014-03-15 at 05:29 +, Greg KH wrote:
> Just take my tree, it's not a big deal, I'll merge first with Linus if
> you want and then everything is simple.

Yup, I'll do that. Thanks.

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 driver-core tree

[Benjamin Herrenschmidt]

On Sat, 2014-03-15 at 05:29 +, Greg KH wrote:
 Just take my tree, it's not a big deal, I'll merge first with Linus if
 you want and then everything is simple.

Yup, I'll do that. Thanks.

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 driver-core tree

[Greg KH]

On Sat, Mar 15, 2014 at 01:57:29PM +1100, Benjamin Herrenschmidt wrote:
> On Sat, 2014-03-15 at 00:03 +, Greg KH wrote:
> > On Fri, Mar 14, 2014 at 09:14:55AM +1100, Benjamin Herrenschmidt wrote:
> > > On Thu, 2014-03-13 at 11:37 +1100, Benjamin Herrenschmidt wrote:
> > > > On Wed, 2014-03-12 at 16:21 -0400, Tejun Heo wrote:
> > > > > It's a series of rather complex patches.  I really don't think
> > > > > duplicating them is a good idea.  We can either resurrect the old API
> > > > > to kill it again or set up a merge branch which I don't think is too
> > > > > unusual in situations like this.
> > > > 
> > > > Right, a topic branch that gets merged in both driver-core-next and
> > > > powerpc-next.
> > > 
> > > Just want to make sure we agree ... ie, the offending commit is already
> > > in powerpc-next on my side and I can't really back it out (I could
> > > revert it though).
> > 
> > You can pull in driver-core-next into your tree if you want, it's not
> > going to be reverted, and will be sent to Linus for 3.15-rc1, so you can
> > base your work on it and fix up the api usage in your tree that way.
> 
> It's messy. Stephen really doesn't like if we pull each other trees like
> that unless they are topic branches. He also doesn't like when we keep
> pulling Linus in.

I only pull Linus in after a -rc in which I have merged patches with him
for that "topic".  Otherwise I end up with merge issues, and for testing
reasons, I want those fixes from Linus and from me, in order to keep
people from hitting the same already-fixes issues.

> For example I purposefully kept powerpc -next on top of rc2. You seem to
> regularly merge subsequent rc's into driver-core-next. So by pulling
> your tree I would bring a whole lot of stuff on top of mine, which is
> fine by git but makes histories more complicated and annoys Stephen.
> 
> I might still do it this time around, because the other solution for me
> is revert + re-apply with fixups on top of a separate branch itself
> derived from driver-core-next and send multiple pull requests to Linus,
> and that's messy too. The question is which one is more :-)

Just take my tree, it's not a big deal, I'll merge first with Linus if
you want and then everything is simple.

thanks,

greg k-h-
--
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 driver-core tree

[Benjamin Herrenschmidt]

On Sat, 2014-03-15 at 00:03 +, Greg KH wrote:
> On Fri, Mar 14, 2014 at 09:14:55AM +1100, Benjamin Herrenschmidt wrote:
> > On Thu, 2014-03-13 at 11:37 +1100, Benjamin Herrenschmidt wrote:
> > > On Wed, 2014-03-12 at 16:21 -0400, Tejun Heo wrote:
> > > > It's a series of rather complex patches.  I really don't think
> > > > duplicating them is a good idea.  We can either resurrect the old API
> > > > to kill it again or set up a merge branch which I don't think is too
> > > > unusual in situations like this.
> > > 
> > > Right, a topic branch that gets merged in both driver-core-next and
> > > powerpc-next.
> > 
> > Just want to make sure we agree ... ie, the offending commit is already
> > in powerpc-next on my side and I can't really back it out (I could
> > revert it though).
> 
> You can pull in driver-core-next into your tree if you want, it's not
> going to be reverted, and will be sent to Linus for 3.15-rc1, so you can
> base your work on it and fix up the api usage in your tree that way.

It's messy. Stephen really doesn't like if we pull each other trees like
that unless they are topic branches. He also doesn't like when we keep
pulling Linus in.

For example I purposefully kept powerpc -next on top of rc2. You seem to
regularly merge subsequent rc's into driver-core-next. So by pulling
your tree I would bring a whole lot of stuff on top of mine, which is
fine by git but makes histories more complicated and annoys Stephen.

I might still do it this time around, because the other solution for me
is revert + re-apply with fixups on top of a separate branch itself
derived from driver-core-next and send multiple pull requests to Linus,
and that's messy too. The question is which one is more :-)

Cheers,
Ben.

> thanks,
> 
> greg k-h
> --
> 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/


--
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 driver-core tree

[Greg KH]

On Fri, Mar 14, 2014 at 09:14:55AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2014-03-13 at 11:37 +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2014-03-12 at 16:21 -0400, Tejun Heo wrote:
> > > It's a series of rather complex patches.  I really don't think
> > > duplicating them is a good idea.  We can either resurrect the old API
> > > to kill it again or set up a merge branch which I don't think is too
> > > unusual in situations like this.
> > 
> > Right, a topic branch that gets merged in both driver-core-next and
> > powerpc-next.
> 
> Just want to make sure we agree ... ie, the offending commit is already
> in powerpc-next on my side and I can't really back it out (I could
> revert it though).

You can pull in driver-core-next into your tree if you want, it's not
going to be reverted, and will be sent to Linus for 3.15-rc1, so you can
base your work on it and fix up the api usage in your tree that way.

thanks,

greg k-h
--
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 driver-core tree

[Tejun Heo]

Hello,

On Fri, Mar 14, 2014 at 09:14:55AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2014-03-13 at 11:37 +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2014-03-12 at 16:21 -0400, Tejun Heo wrote:
> > > It's a series of rather complex patches.  I really don't think
> > > duplicating them is a good idea.  We can either resurrect the old API
> > > to kill it again or set up a merge branch which I don't think is too
> > > unusual in situations like this.
> > 
> > Right, a topic branch that gets merged in both driver-core-next and
> > powerpc-next.
> 
> Just want to make sure we agree ... ie, the offending commit is already
> in powerpc-next on my side and I can't really back it out (I could
> revert it though).

Hmmm... reverting may be an option too but I don't think fixing it
retroactively in a new branch should be okay too.

Thanks.

-- 
tejun
--
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 driver-core tree

[Tejun Heo]

Hello,

On Fri, Mar 14, 2014 at 09:14:55AM +1100, Benjamin Herrenschmidt wrote:
 On Thu, 2014-03-13 at 11:37 +1100, Benjamin Herrenschmidt wrote:
  On Wed, 2014-03-12 at 16:21 -0400, Tejun Heo wrote:
   It's a series of rather complex patches.  I really don't think
   duplicating them is a good idea.  We can either resurrect the old API
   to kill it again or set up a merge branch which I don't think is too
   unusual in situations like this.
  
  Right, a topic branch that gets merged in both driver-core-next and
  powerpc-next.
 
 Just want to make sure we agree ... ie, the offending commit is already
 in powerpc-next on my side and I can't really back it out (I could
 revert it though).

Hmmm... reverting may be an option too but I don't think fixing it
retroactively in a new branch should be okay too.

Thanks.

-- 
tejun
--
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 driver-core tree

[Greg KH]

On Fri, Mar 14, 2014 at 09:14:55AM +1100, Benjamin Herrenschmidt wrote:
 On Thu, 2014-03-13 at 11:37 +1100, Benjamin Herrenschmidt wrote:
  On Wed, 2014-03-12 at 16:21 -0400, Tejun Heo wrote:
   It's a series of rather complex patches.  I really don't think
   duplicating them is a good idea.  We can either resurrect the old API
   to kill it again or set up a merge branch which I don't think is too
   unusual in situations like this.
  
  Right, a topic branch that gets merged in both driver-core-next and
  powerpc-next.
 
 Just want to make sure we agree ... ie, the offending commit is already
 in powerpc-next on my side and I can't really back it out (I could
 revert it though).

You can pull in driver-core-next into your tree if you want, it's not
going to be reverted, and will be sent to Linus for 3.15-rc1, so you can
base your work on it and fix up the api usage in your tree that way.

thanks,

greg k-h
--
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 driver-core tree

[Benjamin Herrenschmidt]

On Sat, 2014-03-15 at 00:03 +, Greg KH wrote:
 On Fri, Mar 14, 2014 at 09:14:55AM +1100, Benjamin Herrenschmidt wrote:
  On Thu, 2014-03-13 at 11:37 +1100, Benjamin Herrenschmidt wrote:
   On Wed, 2014-03-12 at 16:21 -0400, Tejun Heo wrote:
It's a series of rather complex patches.  I really don't think
duplicating them is a good idea.  We can either resurrect the old API
to kill it again or set up a merge branch which I don't think is too
unusual in situations like this.
   
   Right, a topic branch that gets merged in both driver-core-next and
   powerpc-next.
  
  Just want to make sure we agree ... ie, the offending commit is already
  in powerpc-next on my side and I can't really back it out (I could
  revert it though).
 
 You can pull in driver-core-next into your tree if you want, it's not
 going to be reverted, and will be sent to Linus for 3.15-rc1, so you can
 base your work on it and fix up the api usage in your tree that way.

It's messy. Stephen really doesn't like if we pull each other trees like
that unless they are topic branches. He also doesn't like when we keep
pulling Linus in.

For example I purposefully kept powerpc -next on top of rc2. You seem to
regularly merge subsequent rc's into driver-core-next. So by pulling
your tree I would bring a whole lot of stuff on top of mine, which is
fine by git but makes histories more complicated and annoys Stephen.

I might still do it this time around, because the other solution for me
is revert + re-apply with fixups on top of a separate branch itself
derived from driver-core-next and send multiple pull requests to Linus,
and that's messy too. The question is which one is more :-)

Cheers,
Ben.

 thanks,
 
 greg k-h
 --
 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/


--
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 driver-core tree

[Greg KH]

On Sat, Mar 15, 2014 at 01:57:29PM +1100, Benjamin Herrenschmidt wrote:
 On Sat, 2014-03-15 at 00:03 +, Greg KH wrote:
  On Fri, Mar 14, 2014 at 09:14:55AM +1100, Benjamin Herrenschmidt wrote:
   On Thu, 2014-03-13 at 11:37 +1100, Benjamin Herrenschmidt wrote:
On Wed, 2014-03-12 at 16:21 -0400, Tejun Heo wrote:
 It's a series of rather complex patches.  I really don't think
 duplicating them is a good idea.  We can either resurrect the old API
 to kill it again or set up a merge branch which I don't think is too
 unusual in situations like this.

Right, a topic branch that gets merged in both driver-core-next and
powerpc-next.
   
   Just want to make sure we agree ... ie, the offending commit is already
   in powerpc-next on my side and I can't really back it out (I could
   revert it though).
  
  You can pull in driver-core-next into your tree if you want, it's not
  going to be reverted, and will be sent to Linus for 3.15-rc1, so you can
  base your work on it and fix up the api usage in your tree that way.
 
 It's messy. Stephen really doesn't like if we pull each other trees like
 that unless they are topic branches. He also doesn't like when we keep
 pulling Linus in.

I only pull Linus in after a -rc in which I have merged patches with him
for that topic.  Otherwise I end up with merge issues, and for testing
reasons, I want those fixes from Linus and from me, in order to keep
people from hitting the same already-fixes issues.

 For example I purposefully kept powerpc -next on top of rc2. You seem to
 regularly merge subsequent rc's into driver-core-next. So by pulling
 your tree I would bring a whole lot of stuff on top of mine, which is
 fine by git but makes histories more complicated and annoys Stephen.
 
 I might still do it this time around, because the other solution for me
 is revert + re-apply with fixups on top of a separate branch itself
 derived from driver-core-next and send multiple pull requests to Linus,
 and that's messy too. The question is which one is more :-)

Just take my tree, it's not a big deal, I'll merge first with Linus if
you want and then everything is simple.

thanks,

greg k-h-
--
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 driver-core tree

[Benjamin Herrenschmidt]

On Thu, 2014-03-13 at 11:37 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2014-03-12 at 16:21 -0400, Tejun Heo wrote:
> > It's a series of rather complex patches.  I really don't think
> > duplicating them is a good idea.  We can either resurrect the old API
> > to kill it again or set up a merge branch which I don't think is too
> > unusual in situations like this.
> 
> Right, a topic branch that gets merged in both driver-core-next and
> powerpc-next.

Just want to make sure we agree ... ie, the offending commit is already
in powerpc-next on my side and I can't really back it out (I could
revert it though).

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 driver-core tree

[Benjamin Herrenschmidt]

On Thu, 2014-03-13 at 11:37 +1100, Benjamin Herrenschmidt wrote:
 On Wed, 2014-03-12 at 16:21 -0400, Tejun Heo wrote:
  It's a series of rather complex patches.  I really don't think
  duplicating them is a good idea.  We can either resurrect the old API
  to kill it again or set up a merge branch which I don't think is too
  unusual in situations like this.
 
 Right, a topic branch that gets merged in both driver-core-next and
 powerpc-next.

Just want to make sure we agree ... ie, the offending commit is already
in powerpc-next on my side and I can't really back it out (I could
revert it though).

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 driver-core tree

[Benjamin Herrenschmidt]

On Wed, 2014-03-12 at 16:21 -0400, Tejun Heo wrote:
> It's a series of rather complex patches.  I really don't think
> duplicating them is a good idea.  We can either resurrect the old API
> to kill it again or set up a merge branch which I don't think is too
> unusual in situations like this.

Right, a topic branch that gets merged in both driver-core-next and
powerpc-next.

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 driver-core tree

[Tejun Heo]

Hello,

On Thu, Mar 13, 2014 at 07:14:52AM +1100, Benjamin Herrenschmidt wrote:
> It's generally consider bad taste to pull entire trees into each
> other :-) I know Stephen isn't fan of it...

I wouldn't say it's considered "generally" bad taste.  For one-off
changes, maybe.  This was a rather large restructuring of the whole
thing, so actually duplicating all the rather significant commits
would be a lot worse.

> I'd rather have just that series (or even better, just the patches
> introducing the new function) in a topic branch, itself pulled into
> both driver-core-next and my tree.
> 
> Can you produce that ? (I need a non-rebase guarantee though).

It's a series of rather complex patches.  I really don't think
duplicating them is a good idea.  We can either resurrect the old API
to kill it again or set up a merge branch which I don't think is too
unusual in situations like this.

Thanks.

-- 
tejun
--
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 driver-core tree

[Benjamin Herrenschmidt]

On Wed, 2014-03-12 at 16:02 -0400, Tejun Heo wrote:
> On Thu, Mar 13, 2014 at 06:59:56AM +1100, Benjamin Herrenschmidt wrote:
> > Either that or I can put a copy of the patch that introduces the new
> > function in my tree as long as it's a single patch. The resulting
> > conflict should resolve trivially and Linus should be fine if
> > appropriate explanations are provided (though I would have preferred
> > pulling in a topic branch).
> 
> An alternative that I personally prefer to resolve conflicts like this
> is to pull driver-core-next into the broken tree and resolve it there.
> It's highly likely that the pending changes are gonna be included in
> the next merge window.  If contaminating the merge history is a
> concern, it can live in a separate branch which is pulled into
> for-next.

It's generally consider bad taste to pull entire trees into each
other :-) I know Stephen isn't fan of it...

I'd rather have just that series (or even better, just the patches
introducing the new function) in a topic branch, itself pulled into
both driver-core-next and my tree.

Can you produce that ? (I need a non-rebase guarantee though).

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 driver-core tree

[Tejun Heo]

On Thu, Mar 13, 2014 at 06:59:56AM +1100, Benjamin Herrenschmidt wrote:
> Either that or I can put a copy of the patch that introduces the new
> function in my tree as long as it's a single patch. The resulting
> conflict should resolve trivially and Linus should be fine if
> appropriate explanations are provided (though I would have preferred
> pulling in a topic branch).

An alternative that I personally prefer to resolve conflicts like this
is to pull driver-core-next into the broken tree and resolve it there.
It's highly likely that the pending changes are gonna be included in
the next merge window.  If contaminating the merge history is a
concern, it can live in a separate branch which is pulled into
for-next.

Thanks.

-- 
tejun
--
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 driver-core tree

[Benjamin Herrenschmidt]

On Wed, 2014-03-12 at 11:37 +, Mark Brown wrote:
> On Wed, Mar 12, 2014 at 02:55:41PM +1100, Benjamin Herrenschmidt wrote:
> 
> > How do you suggest we proceed ? I can't add a fix to powerpc-next to use
> > the new function since it doesn't exist upstream yet. I would have to
> > pull drivers-core-next in which I really don't want to do
> 
> > Can the removal of the function be delayed to -rc1 so we can properly
> > do the fixup ? Or do you have the introduction of the new function in
> > a topic branch I can pull in without the rest of drivers-core-next ?
> 
> The delay would have been my first suggestion - otherwise I'd not be
> surprised to see this coming up again.  Perhaps change to tagging the
> APIs as deprecated for now (so any futher new users get flagged up)
> would help.
 
Either that or I can put a copy of the patch that introduces the new
function in my tree as long as it's a single patch. The resulting
conflict should resolve trivially and Linus should be fine if
appropriate explanations are provided (though I would have preferred
pulling in a topic branch).

Greg, how do you want to proceed ?

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 driver-core tree

[Mark Brown]

On Wed, Mar 12, 2014 at 02:55:41PM +1100, Benjamin Herrenschmidt wrote:

> How do you suggest we proceed ? I can't add a fix to powerpc-next to use
> the new function since it doesn't exist upstream yet. I would have to
> pull drivers-core-next in which I really don't want to do

> Can the removal of the function be delayed to -rc1 so we can properly
> do the fixup ? Or do you have the introduction of the new function in
> a topic branch I can pull in without the rest of drivers-core-next ?

The delay would have been my first suggestion - otherwise I'd not be
surprised to see this coming up again.  Perhaps change to tagging the
APIs as deprecated for now (so any futher new users get flagged up)
would help.


signature.asc
Description: Digital signature

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

[Benjamin Herrenschmidt]

On Wed, 2014-03-12 at 11:37 +, Mark Brown wrote:
 On Wed, Mar 12, 2014 at 02:55:41PM +1100, Benjamin Herrenschmidt wrote:
 
  How do you suggest we proceed ? I can't add a fix to powerpc-next to use
  the new function since it doesn't exist upstream yet. I would have to
  pull drivers-core-next in which I really don't want to do
 
  Can the removal of the function be delayed to -rc1 so we can properly
  do the fixup ? Or do you have the introduction of the new function in
  a topic branch I can pull in without the rest of drivers-core-next ?
 
 The delay would have been my first suggestion - otherwise I'd not be
 surprised to see this coming up again.  Perhaps change to tagging the
 APIs as deprecated for now (so any futher new users get flagged up)
 would help.
 
Either that or I can put a copy of the patch that introduces the new
function in my tree as long as it's a single patch. The resulting
conflict should resolve trivially and Linus should be fine if
appropriate explanations are provided (though I would have preferred
pulling in a topic branch).

Greg, how do you want to proceed ?

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 driver-core tree

[Tejun Heo]

On Thu, Mar 13, 2014 at 06:59:56AM +1100, Benjamin Herrenschmidt wrote:
 Either that or I can put a copy of the patch that introduces the new
 function in my tree as long as it's a single patch. The resulting
 conflict should resolve trivially and Linus should be fine if
 appropriate explanations are provided (though I would have preferred
 pulling in a topic branch).

An alternative that I personally prefer to resolve conflicts like this
is to pull driver-core-next into the broken tree and resolve it there.
It's highly likely that the pending changes are gonna be included in
the next merge window.  If contaminating the merge history is a
concern, it can live in a separate branch which is pulled into
for-next.

Thanks.

-- 
tejun
--
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 driver-core tree

[Benjamin Herrenschmidt]

On Wed, 2014-03-12 at 16:02 -0400, Tejun Heo wrote:
 On Thu, Mar 13, 2014 at 06:59:56AM +1100, Benjamin Herrenschmidt wrote:
  Either that or I can put a copy of the patch that introduces the new
  function in my tree as long as it's a single patch. The resulting
  conflict should resolve trivially and Linus should be fine if
  appropriate explanations are provided (though I would have preferred
  pulling in a topic branch).
 
 An alternative that I personally prefer to resolve conflicts like this
 is to pull driver-core-next into the broken tree and resolve it there.
 It's highly likely that the pending changes are gonna be included in
 the next merge window.  If contaminating the merge history is a
 concern, it can live in a separate branch which is pulled into
 for-next.

It's generally consider bad taste to pull entire trees into each
other :-) I know Stephen isn't fan of it...

I'd rather have just that series (or even better, just the patches
introducing the new function) in a topic branch, itself pulled into
both driver-core-next and my tree.

Can you produce that ? (I need a non-rebase guarantee though).

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 driver-core tree

[Tejun Heo]

Hello,

On Thu, Mar 13, 2014 at 07:14:52AM +1100, Benjamin Herrenschmidt wrote:
 It's generally consider bad taste to pull entire trees into each
 other :-) I know Stephen isn't fan of it...

I wouldn't say it's considered generally bad taste.  For one-off
changes, maybe.  This was a rather large restructuring of the whole
thing, so actually duplicating all the rather significant commits
would be a lot worse.

 I'd rather have just that series (or even better, just the patches
 introducing the new function) in a topic branch, itself pulled into
 both driver-core-next and my tree.
 
 Can you produce that ? (I need a non-rebase guarantee though).

It's a series of rather complex patches.  I really don't think
duplicating them is a good idea.  We can either resurrect the old API
to kill it again or set up a merge branch which I don't think is too
unusual in situations like this.

Thanks.

-- 
tejun
--
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 driver-core tree

[Benjamin Herrenschmidt]

On Wed, 2014-03-12 at 16:21 -0400, Tejun Heo wrote:
 It's a series of rather complex patches.  I really don't think
 duplicating them is a good idea.  We can either resurrect the old API
 to kill it again or set up a merge branch which I don't think is too
 unusual in situations like this.

Right, a topic branch that gets merged in both driver-core-next and
powerpc-next.

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 driver-core tree

[Mark Brown]

On Wed, Mar 12, 2014 at 02:55:41PM +1100, Benjamin Herrenschmidt wrote:

 How do you suggest we proceed ? I can't add a fix to powerpc-next to use
 the new function since it doesn't exist upstream yet. I would have to
 pull drivers-core-next in which I really don't want to do

 Can the removal of the function be delayed to -rc1 so we can properly
 do the fixup ? Or do you have the introduction of the new function in
 a topic branch I can pull in without the rest of drivers-core-next ?

The delay would have been my first suggestion - otherwise I'd not be
surprised to see this coming up again.  Perhaps change to tagging the
APIs as deprecated for now (so any futher new users get flagged up)
would help.


signature.asc
Description: Digital signature

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

[Benjamin Herrenschmidt]

On Tue, 2014-03-11 at 18:50 -0700, Greg KH wrote:
> On Wed, Mar 12, 2014 at 12:51:52AM +, Mark Brown wrote:
> > Hi Greg,
> > 
> > After merging the driver-core tree, today's linux-next build ()
> > failed like this on a PowerPC defconfig:
> > 
> > HEAD is now at ceb98e684dec Merge remote-tracking branch 
> > 'driver-core/driver-core-next'
> >   GEN /home/broonie/next/powerpc_ppc64_defconfig/Makefile
> > #
> > # configuration written to .config
> > #
> > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c: In 
> > function 'elog_ack_store':
> > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c:84:2: 
> > error: implicit declaration of function 'sysfs_schedule_callback' 
> > [-Werror=implicit-function-declaration]
> >   sysfs_schedule_callback(_obj->kobj, delay_release_kobj,
> >   ^
> > cc1: all warnings being treated as errors
> > make[3]: *** [arch/powerpc/platforms/powernv/opal-elog.o] Error 1
> > make[3]: *** Waiting for unfinished jobs
> > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c: In 
> > function 'dump_ack_store':
> > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c:100:2: 
> > error: implicit declaration of function 'sysfs_schedule_callback' 
> > [-Werror=implicit-function-declaration]
> >   sysfs_schedule_callback(_obj->kobj, delay_release_kobj,
> >   ^
> > cc1: all warnings being treated as errors
> > 
> > due to an interaction between d1ba277e7988908 (sysfs, driver-core: remove 
> > unused {sysfs|device}_schedule_callback_owner()) and 774fea1a38c6a5a8 
> > (powerpc/powernv: Read OPAL error log and export it through sysfs) from the 
> > PowerPC tree.
> > 
> > I reverted 774fea1a38c6a5a8 for today.
> 
> Sounds like the powerpc tree also needs to stop using this function :)

powerpc -next is a never-rebase branch, so we are somewhat stuffed here.

How do you suggest we proceed ? I can't add a fix to powerpc-next to use
the new function since it doesn't exist upstream yet. I would have to
pull drivers-core-next in which I really don't want to do

Can the removal of the function be delayed to -rc1 so we can properly
do the fixup ? Or do you have the introduction of the new function in
a topic branch I can pull in without the rest of drivers-core-next ?

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 driver-core tree

[Greg KH]

On Wed, Mar 12, 2014 at 12:51:52AM +, Mark Brown wrote:
> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build ()
> failed like this on a PowerPC defconfig:
> 
> HEAD is now at ceb98e684dec Merge remote-tracking branch 
> 'driver-core/driver-core-next'
>   GEN /home/broonie/next/powerpc_ppc64_defconfig/Makefile
> #
> # configuration written to .config
> #
> /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c: In 
> function 'elog_ack_store':
> /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c:84:2: 
> error: implicit declaration of function 'sysfs_schedule_callback' 
> [-Werror=implicit-function-declaration]
>   sysfs_schedule_callback(_obj->kobj, delay_release_kobj,
>   ^
> cc1: all warnings being treated as errors
> make[3]: *** [arch/powerpc/platforms/powernv/opal-elog.o] Error 1
> make[3]: *** Waiting for unfinished jobs
> /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c: In 
> function 'dump_ack_store':
> /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c:100:2: 
> error: implicit declaration of function 'sysfs_schedule_callback' 
> [-Werror=implicit-function-declaration]
>   sysfs_schedule_callback(_obj->kobj, delay_release_kobj,
>   ^
> cc1: all warnings being treated as errors
> 
> due to an interaction between d1ba277e7988908 (sysfs, driver-core: remove 
> unused {sysfs|device}_schedule_callback_owner()) and 774fea1a38c6a5a8 
> (powerpc/powernv: Read OPAL error log and export it through sysfs) from the 
> PowerPC tree.
> 
> I reverted 774fea1a38c6a5a8 for today.

Sounds like the powerpc tree also needs to stop using this function :)

thanks,

greg k-h
--
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 driver-core tree

[Greg KH]

On Wed, Mar 12, 2014 at 12:51:52AM +, Mark Brown wrote:
 Hi Greg,
 
 After merging the driver-core tree, today's linux-next build ()
 failed like this on a PowerPC defconfig:
 
 HEAD is now at ceb98e684dec Merge remote-tracking branch 
 'driver-core/driver-core-next'
   GEN /home/broonie/next/powerpc_ppc64_defconfig/Makefile
 #
 # configuration written to .config
 #
 /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c: In 
 function 'elog_ack_store':
 /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c:84:2: 
 error: implicit declaration of function 'sysfs_schedule_callback' 
 [-Werror=implicit-function-declaration]
   sysfs_schedule_callback(elog_obj-kobj, delay_release_kobj,
   ^
 cc1: all warnings being treated as errors
 make[3]: *** [arch/powerpc/platforms/powernv/opal-elog.o] Error 1
 make[3]: *** Waiting for unfinished jobs
 /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c: In 
 function 'dump_ack_store':
 /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c:100:2: 
 error: implicit declaration of function 'sysfs_schedule_callback' 
 [-Werror=implicit-function-declaration]
   sysfs_schedule_callback(dump_obj-kobj, delay_release_kobj,
   ^
 cc1: all warnings being treated as errors
 
 due to an interaction between d1ba277e7988908 (sysfs, driver-core: remove 
 unused {sysfs|device}_schedule_callback_owner()) and 774fea1a38c6a5a8 
 (powerpc/powernv: Read OPAL error log and export it through sysfs) from the 
 PowerPC tree.
 
 I reverted 774fea1a38c6a5a8 for today.

Sounds like the powerpc tree also needs to stop using this function :)

thanks,

greg k-h
--
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 driver-core tree

[Benjamin Herrenschmidt]

On Tue, 2014-03-11 at 18:50 -0700, Greg KH wrote:
 On Wed, Mar 12, 2014 at 12:51:52AM +, Mark Brown wrote:
  Hi Greg,
  
  After merging the driver-core tree, today's linux-next build ()
  failed like this on a PowerPC defconfig:
  
  HEAD is now at ceb98e684dec Merge remote-tracking branch 
  'driver-core/driver-core-next'
GEN /home/broonie/next/powerpc_ppc64_defconfig/Makefile
  #
  # configuration written to .config
  #
  /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c: In 
  function 'elog_ack_store':
  /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c:84:2: 
  error: implicit declaration of function 'sysfs_schedule_callback' 
  [-Werror=implicit-function-declaration]
sysfs_schedule_callback(elog_obj-kobj, delay_release_kobj,
^
  cc1: all warnings being treated as errors
  make[3]: *** [arch/powerpc/platforms/powernv/opal-elog.o] Error 1
  make[3]: *** Waiting for unfinished jobs
  /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c: In 
  function 'dump_ack_store':
  /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c:100:2: 
  error: implicit declaration of function 'sysfs_schedule_callback' 
  [-Werror=implicit-function-declaration]
sysfs_schedule_callback(dump_obj-kobj, delay_release_kobj,
^
  cc1: all warnings being treated as errors
  
  due to an interaction between d1ba277e7988908 (sysfs, driver-core: remove 
  unused {sysfs|device}_schedule_callback_owner()) and 774fea1a38c6a5a8 
  (powerpc/powernv: Read OPAL error log and export it through sysfs) from the 
  PowerPC tree.
  
  I reverted 774fea1a38c6a5a8 for today.
 
 Sounds like the powerpc tree also needs to stop using this function :)

powerpc -next is a never-rebase branch, so we are somewhat stuffed here.

How do you suggest we proceed ? I can't add a fix to powerpc-next to use
the new function since it doesn't exist upstream yet. I would have to
pull drivers-core-next in which I really don't want to do

Can the removal of the function be delayed to -rc1 so we can properly
do the fixup ? Or do you have the introduction of the new function in
a topic branch I can pull in without the rest of drivers-core-next ?

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 driver-core tree

[Greg KH]

On Thu, Aug 22, 2013 at 03:39:42PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> In file included from include/linux/kobject.h:21:0,
>  from include/linux/module.h:16,
>  from drivers/acpi/bgrt.c:11:
> drivers/acpi/bgrt.c: In function 'bgrt_init':
> drivers/acpi/bgrt.c:89:23: error: 'image_attr' undeclared (first use in this 
> function)
>   sysfs_bin_attr_init(_attr);
>^
> include/linux/sysfs.h:53:3: note: in definition of macro 'sysfs_attr_init'
>   (attr)->key = &__key;\
>^
> drivers/acpi/bgrt.c:89:2: note: in expansion of macro 'sysfs_bin_attr_init'
>   sysfs_bin_attr_init(_attr);
>   ^
> drivers/acpi/bgrt.c:89:23: note: each undeclared identifier is reported only 
> once for each function it appears in
>   sysfs_bin_attr_init(_attr);
>^
> include/linux/sysfs.h:53:3: note: in definition of macro 'sysfs_attr_init'
>   (attr)->key = &__key;\
>^
> drivers/acpi/bgrt.c:89:2: note: in expansion of macro 'sysfs_bin_attr_init'
>   sysfs_bin_attr_init(_attr);
>   ^
> 
> Presumably caused by commit 65f44679580d ("ACPI: bgrt: take advantage of
> binary sysfs groups").

It's as if I never even built the patch I submitted, I have no idea what
happened here, sorry about that.

I've now fixed it up, it should be fine for the next linux-next release.

thanks,

greg k-h
--
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 driver-core tree

[Greg KH]

On Thu, Aug 22, 2013 at 03:39:42PM +1000, Stephen Rothwell wrote:
 Hi Greg,
 
 After merging the driver-core tree, today's linux-next build (x86_64
 allmodconfig) failed like this:
 
 In file included from include/linux/kobject.h:21:0,
  from include/linux/module.h:16,
  from drivers/acpi/bgrt.c:11:
 drivers/acpi/bgrt.c: In function 'bgrt_init':
 drivers/acpi/bgrt.c:89:23: error: 'image_attr' undeclared (first use in this 
 function)
   sysfs_bin_attr_init(image_attr);
^
 include/linux/sysfs.h:53:3: note: in definition of macro 'sysfs_attr_init'
   (attr)-key = __key;\
^
 drivers/acpi/bgrt.c:89:2: note: in expansion of macro 'sysfs_bin_attr_init'
   sysfs_bin_attr_init(image_attr);
   ^
 drivers/acpi/bgrt.c:89:23: note: each undeclared identifier is reported only 
 once for each function it appears in
   sysfs_bin_attr_init(image_attr);
^
 include/linux/sysfs.h:53:3: note: in definition of macro 'sysfs_attr_init'
   (attr)-key = __key;\
^
 drivers/acpi/bgrt.c:89:2: note: in expansion of macro 'sysfs_bin_attr_init'
   sysfs_bin_attr_init(image_attr);
   ^
 
 Presumably caused by commit 65f44679580d (ACPI: bgrt: take advantage of
 binary sysfs groups).

It's as if I never even built the patch I submitted, I have no idea what
happened here, sorry about that.

I've now fixed it up, it should be fine for the next linux-next release.

thanks,

greg k-h
--
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 driver-core tree

[Kondratiev, Vladimir]

On Fri, Jan 18, 2013 at 01:29:04PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from drivers/net/wireless/ath/wil6210/wil6210.h:24:0,
>  from drivers/net/wireless/ath/wil6210/main.c:26:
> drivers/net/wireless/ath/wil6210/dbg_hexdump.h:21:0: error: 
> "print_hex_dump_bytes" redefined [-Werror]
> include/linux/printk.h:322:0: note: this is the location of the previous 
> definition
>
> Caused by commit 7a555613eb77 ("dynamic_debug: dynamic hex dump")
> interacting with commit 2be7d22f0625 ("wireless: add new wil6210 802.11ad
> 60GHz driver") that was added to Linus' tree in the last few days.
>
> I have applied the following merge fix patch for today:
>
> From: Stephen Rothwell 
> Date: Fri, 18 Jan 2013 13:24:32 +1100
> Subject: [PATCH] wireless: remove conflicting version of print_hex_dump_bytes
>
> Signed-off-by: Stephen Rothwell 

Thanks, I've merged 3.9-rc4 into my tree and applied this patch to fix
the build breakage.

greg k-h

Sorry for the mess; this conflicting file should disappear after the other 
commit, 
"dynamic_debug: dynamic hex dump", merged. It was intended as temporal 
replacement.

Patch by Stephen Rothwell is just fine in the mean time.

Unfortunately, this catches me on my way to the airport, going for 1 week ski 
vacation.

I'll submit patch to remove 
drivers/net/wireless/ath/wil6210/dbg_hexdump.h
and s/wil_print_hex_dump_debug/print_hex_dump_debug/ for the rest of the 
wil6210 driver.

Thanks, Vladimir.

--
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 driver-core tree

[Kondratiev, Vladimir]

On Fri, Jan 18, 2013 at 01:29:04PM +1100, Stephen Rothwell wrote:
 Hi Greg,

 After merging the driver-core tree, today's linux-next build (x86_64
 allmodconfig) failed like this:

 In file included from drivers/net/wireless/ath/wil6210/wil6210.h:24:0,
  from drivers/net/wireless/ath/wil6210/main.c:26:
 drivers/net/wireless/ath/wil6210/dbg_hexdump.h:21:0: error: 
 print_hex_dump_bytes redefined [-Werror]
 include/linux/printk.h:322:0: note: this is the location of the previous 
 definition

 Caused by commit 7a555613eb77 (dynamic_debug: dynamic hex dump)
 interacting with commit 2be7d22f0625 (wireless: add new wil6210 802.11ad
 60GHz driver) that was added to Linus' tree in the last few days.

 I have applied the following merge fix patch for today:

 From: Stephen Rothwell s...@canb.auug.org.au
 Date: Fri, 18 Jan 2013 13:24:32 +1100
 Subject: [PATCH] wireless: remove conflicting version of print_hex_dump_bytes

 Signed-off-by: Stephen Rothwell s...@canb.auug.org.au

Thanks, I've merged 3.9-rc4 into my tree and applied this patch to fix
the build breakage.

greg k-h

Sorry for the mess; this conflicting file should disappear after the other 
commit, 
dynamic_debug: dynamic hex dump, merged. It was intended as temporal 
replacement.

Patch by Stephen Rothwell is just fine in the mean time.

Unfortunately, this catches me on my way to the airport, going for 1 week ski 
vacation.

I'll submit patch to remove 
drivers/net/wireless/ath/wil6210/dbg_hexdump.h
and s/wil_print_hex_dump_debug/print_hex_dump_debug/ for the rest of the 
wil6210 driver.

Thanks, Vladimir.

--
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 driver-core tree

[Greg KH]

On Fri, Jan 18, 2013 at 01:29:04PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> In file included from drivers/net/wireless/ath/wil6210/wil6210.h:24:0,
>  from drivers/net/wireless/ath/wil6210/main.c:26:
> drivers/net/wireless/ath/wil6210/dbg_hexdump.h:21:0: error: 
> "print_hex_dump_bytes" redefined [-Werror]
> include/linux/printk.h:322:0: note: this is the location of the previous 
> definition
> 
> Caused by commit 7a555613eb77 ("dynamic_debug: dynamic hex dump")
> interacting with commit 2be7d22f0625 ("wireless: add new wil6210 802.11ad
> 60GHz driver") that was added to Linus' tree in the last few days.
> 
> I have applied the following merge fix patch for today:
> 
> From: Stephen Rothwell 
> Date: Fri, 18 Jan 2013 13:24:32 +1100
> Subject: [PATCH] wireless: remove conflicting version of print_hex_dump_bytes
> 
> Signed-off-by: Stephen Rothwell 

Thanks, I've merged 3.9-rc4 into my tree and applied this patch to fix
the build breakage.

greg k-h
--
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 driver-core tree

[Greg KH]

On Fri, Jan 18, 2013 at 01:29:04PM +1100, Stephen Rothwell wrote:
 Hi Greg,
 
 After merging the driver-core tree, today's linux-next build (x86_64
 allmodconfig) failed like this:
 
 In file included from drivers/net/wireless/ath/wil6210/wil6210.h:24:0,
  from drivers/net/wireless/ath/wil6210/main.c:26:
 drivers/net/wireless/ath/wil6210/dbg_hexdump.h:21:0: error: 
 print_hex_dump_bytes redefined [-Werror]
 include/linux/printk.h:322:0: note: this is the location of the previous 
 definition
 
 Caused by commit 7a555613eb77 (dynamic_debug: dynamic hex dump)
 interacting with commit 2be7d22f0625 (wireless: add new wil6210 802.11ad
 60GHz driver) that was added to Linus' tree in the last few days.
 
 I have applied the following merge fix patch for today:
 
 From: Stephen Rothwell s...@canb.auug.org.au
 Date: Fri, 18 Jan 2013 13:24:32 +1100
 Subject: [PATCH] wireless: remove conflicting version of print_hex_dump_bytes
 
 Signed-off-by: Stephen Rothwell s...@canb.auug.org.au

Thanks, I've merged 3.9-rc4 into my tree and applied this patch to fix
the build breakage.

greg k-h
--
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 driver-core tree

[Greg KH]

On Fri, Aug 17, 2012 at 02:01:23PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> ERROR: "device_pm_lock" [drivers/base/firmware_class.ko] undefined!
> ERROR: "dpm_list" [drivers/base/firmware_class.ko] undefined!
> ERROR: "device_pm_unlock" [drivers/base/firmware_class.ko] undefined!
> 
> Caused by commit 37276a51f803 ("firmware: introduce
> device_cache/uncache_fw_images").

Thanks, known bug, Ming is working on resolving the issue.

greg k-h
--
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 driver-core tree

[Greg KH]

On Fri, Aug 17, 2012 at 02:01:23PM +1000, Stephen Rothwell wrote:
 Hi Greg,
 
 After merging the driver-core tree, today's linux-next build (x86_64
 allmodconfig) failed like this:
 
 ERROR: device_pm_lock [drivers/base/firmware_class.ko] undefined!
 ERROR: dpm_list [drivers/base/firmware_class.ko] undefined!
 ERROR: device_pm_unlock [drivers/base/firmware_class.ko] undefined!
 
 Caused by commit 37276a51f803 (firmware: introduce
 device_cache/uncache_fw_images).

Thanks, known bug, Ming is working on resolving the issue.

greg k-h
--
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 driver-core tree

[Linus Walleij]

On Tue, Jul 10, 2012 at 1:14 PM, Stephen Rothwell  wrote:

> Linus (Walleij), Stephen, Grant, can someone please send this patch to
> Linus (Torvalds)?

I sent it by pill request a few minutes ago.

Ironically my pull request was postponed two days for the sole reason of
getting some rotation of the patches in linux-next...

Yours,
Linus Walleij
--
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 driver-core tree

[Stephen Rothwell]

Hi Mark,

On Tue, 10 Jul 2012 10:03:25 +0100 Mark Brown 
 wrote:
>
> On Tue, Jul 10, 2012 at 03:32:10PM +1000, Stephen Rothwell wrote:
> 
> > Caused by commit 01eaf2458773 ("extcon: Convert extcon_gpio to
> > devm_gpio_request_one").  devm_gpio_request_one is not currently exported
> > to modules.
> 
> A patch for this has been in -next for most of this release cycle and
> really should've been sent to Linus by now - this issue is cropping up
> an awful lot and there's further patches not getting applied due to the
> dependency on this.
> 
> I *think* the patch is sitting in Andrew's tree at the minute.

Its actually in the gpio-lw tree (more cc's added).  It was in Andrew's
tree before that.

Linus (Walleij), Stephen, Grant, can someone please send this patch to
Linus (Torvalds)?

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpHvLTk9Abug.pgp
Description: PGP signature

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

[Mark Brown]

On Tue, Jul 10, 2012 at 03:32:10PM +1000, Stephen Rothwell wrote:

> Caused by commit 01eaf2458773 ("extcon: Convert extcon_gpio to
> devm_gpio_request_one").  devm_gpio_request_one is not currently exported
> to modules.

A patch for this has been in -next for most of this release cycle and
really should've been sent to Linus by now - this issue is cropping up
an awful lot and there's further patches not getting applied due to the
dependency on this.

I *think* the patch is sitting in Andrew's tree at the minute.


signature.asc
Description: Digital signature

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

[Mark Brown]

On Tue, Jul 10, 2012 at 03:32:10PM +1000, Stephen Rothwell wrote:

 Caused by commit 01eaf2458773 (extcon: Convert extcon_gpio to
 devm_gpio_request_one).  devm_gpio_request_one is not currently exported
 to modules.

A patch for this has been in -next for most of this release cycle and
really should've been sent to Linus by now - this issue is cropping up
an awful lot and there's further patches not getting applied due to the
dependency on this.

I *think* the patch is sitting in Andrew's tree at the minute.


signature.asc
Description: Digital signature

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

[Stephen Rothwell]

Hi Mark,

On Tue, 10 Jul 2012 10:03:25 +0100 Mark Brown 
broo...@opensource.wolfsonmicro.com wrote:

 On Tue, Jul 10, 2012 at 03:32:10PM +1000, Stephen Rothwell wrote:
 
  Caused by commit 01eaf2458773 (extcon: Convert extcon_gpio to
  devm_gpio_request_one).  devm_gpio_request_one is not currently exported
  to modules.
 
 A patch for this has been in -next for most of this release cycle and
 really should've been sent to Linus by now - this issue is cropping up
 an awful lot and there's further patches not getting applied due to the
 dependency on this.
 
 I *think* the patch is sitting in Andrew's tree at the minute.

Its actually in the gpio-lw tree (more cc's added).  It was in Andrew's
tree before that.

Linus (Walleij), Stephen, Grant, can someone please send this patch to
Linus (Torvalds)?

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpHvLTk9Abug.pgp
Description: PGP signature