Linux-Next Archive on lore.kernel.org
 help / color / Atom feed
* linux-next: build failure after merge of the driver-core tree
@ 2020-07-27  6:55 Stephen Rothwell
  2020-07-27 10:17 ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2020-07-27  6:55 UTC (permalink / raw)
  To: Greg KH
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Kees Cook,
	Scott Branden


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

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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2020-07-27  6:55 linux-next: build failure after merge of the driver-core tree Stephen Rothwell
@ 2020-07-27 10:17 ` Greg KH
  2020-07-28 19:53   ` Kees Cook
  0 siblings, 1 reply; 127+ messages in thread
From: Greg KH @ 2020-07-27 10:17 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Kees Cook,
	Scott Branden

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2020-07-27 10:17 ` Greg KH
@ 2020-07-28 19:53   ` Kees Cook
  0 siblings, 0 replies; 127+ messages in thread
From: Kees Cook @ 2020-07-28 19:53 UTC (permalink / raw)
  To: Greg KH
  Cc: Stephen Rothwell, Linux Next Mailing List,
	Linux Kernel Mailing List, Scott Branden

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2019-09-18 19:03   ` Linus Torvalds
  2019-09-18 19:07     ` Greg KH
@ 2019-09-18 21:55     ` Mark Brown
  1 sibling, 0 replies; 127+ messages in thread
From: Mark Brown @ 2019-09-18 21:55 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Greg KH, Suzuki K Poulose, Wolfram Sang, Mika Westerberg,
	linux-i2c, Linux Next Mailing List, Linux Kernel Mailing List


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

On Wed, Sep 18, 2019 at 12:03:17PM -0700, Linus Torvalds wrote:
> On Wed, Sep 18, 2019 at 11:53 AM Greg KH <gregkh@linuxfoundation.org> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2019-09-18 19:07     ` Greg KH
@ 2019-09-18 20:56       ` Suzuki K Poulose
  0 siblings, 0 replies; 127+ messages in thread
From: Suzuki K Poulose @ 2019-09-18 20:56 UTC (permalink / raw)
  To: gregkh, torvalds
  Cc: broonie, wsa, mika.westerberg, linux-i2c, linux-next, linux-kernel

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 <gregkh@linuxfoundation.org> 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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2019-09-18 19:03   ` Linus Torvalds
@ 2019-09-18 19:07     ` Greg KH
  2019-09-18 20:56       ` Suzuki K Poulose
  2019-09-18 21:55     ` Mark Brown
  1 sibling, 1 reply; 127+ messages in thread
From: Greg KH @ 2019-09-18 19:07 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Mark Brown, Suzuki K Poulose, Wolfram Sang, Mika Westerberg,
	linux-i2c, Linux Next Mailing List, Linux Kernel Mailing List

On Wed, Sep 18, 2019 at 12:03:17PM -0700, Linus Torvalds wrote:
> On Wed, Sep 18, 2019 at 11:53 AM Greg KH <gregkh@linuxfoundation.org> 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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2019-09-18 18:52 ` Greg KH
@ 2019-09-18 19:03   ` Linus Torvalds
  2019-09-18 19:07     ` Greg KH
  2019-09-18 21:55     ` Mark Brown
  0 siblings, 2 replies; 127+ messages in thread
From: Linus Torvalds @ 2019-09-18 19:03 UTC (permalink / raw)
  To: Greg KH
  Cc: Mark Brown, Suzuki K Poulose, Wolfram Sang, Mika Westerberg,
	linux-i2c, Linux Next Mailing List, Linux Kernel Mailing List

On Wed, Sep 18, 2019 at 11:53 AM Greg KH <gregkh@linuxfoundation.org> 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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2019-09-18 17:09 Mark Brown
@ 2019-09-18 18:52 ` Greg KH
  2019-09-18 19:03   ` Linus Torvalds
  0 siblings, 1 reply; 127+ messages in thread
From: Greg KH @ 2019-09-18 18:52 UTC (permalink / raw)
  To: Linus Torvalds, Mark Brown
  Cc: Suzuki K Poulose, Wolfram Sang, Mika Westerberg, linux-i2c,
	Linux Next Mailing List, Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2019-09-18 17:09 Mark Brown
  2019-09-18 18:52 ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: Mark Brown @ 2019-09-18 17:09 UTC (permalink / raw)
  To: Greg KH, Suzuki K Poulose, Wolfram Sang, Mika Westerberg
  Cc: linux-i2c, Linux Next Mailing List, Linux Kernel Mailing List


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

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2019-08-29  7:35 Stephen Rothwell
@ 2019-08-29 10:10 ` Greg KH
  0 siblings, 0 replies; 127+ messages in thread
From: Greg KH @ 2019-08-29 10:10 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Thierry Reding, Stephen Boyd, Guenter Roeck,
	Bartlomiej Zolnierkiewicz

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 <sfr@canb.auug.org.au>
> 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 <sfr@canb.auug.org.au>
> ---
>  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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2019-08-29  7:35 Stephen Rothwell
  2019-08-29 10:10 ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2019-08-29  7:35 UTC (permalink / raw)
  To: Greg KH
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Thierry Reding, Stephen Boyd, Guenter Roeck,
	Bartlomiej Zolnierkiewicz


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

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 <sfr@canb.auug.org.au>
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 <sfr@canb.auug.org.au>
---
 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);
 
 /**
  * platform_irq_count - Count the number of IRQs a platform device uses
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2019-02-01  2:41 Stephen Rothwell
@ 2019-02-01 14:18 ` Greg KH
  0 siblings, 0 replies; 127+ messages in thread
From: Greg KH @ 2019-02-01 14:18 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Richard Gong

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 <sfr@canb.auug.org.au>
> 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 <sfr@canb.auug.org.au>
> ---
>  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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2019-02-01  2:41 Stephen Rothwell
  2019-02-01 14:18 ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2019-02-01  2:41 UTC (permalink / raw)
  To: Greg KH; +Cc: Linux Next Mailing List, Linux Kernel Mailing List, Richard Gong


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

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 <sfr@canb.auug.org.au>
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 <sfr@canb.auug.org.au>
---
 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2017-06-13  6:20 ` Greg KH
  2017-06-13  6:25   ` Stephen Rothwell
@ 2017-06-13  6:30   ` Sergey Senozhatsky
  1 sibling, 0 replies; 127+ messages in thread
From: Sergey Senozhatsky @ 2017-06-13  6:30 UTC (permalink / raw)
  To: Greg KH
  Cc: Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List, 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)
> >   &class_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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2017-06-13  6:20 ` Greg KH
@ 2017-06-13  6:25   ` Stephen Rothwell
  2017-06-13  6:30   ` Sergey Senozhatsky
  1 sibling, 0 replies; 127+ messages in thread
From: Stephen Rothwell @ 2017-06-13  6:25 UTC (permalink / raw)
  To: Greg KH
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Sergey Senozhatsky

Hi Greg,

On Tue, 13 Jun 2017 08:20:48 +0200 Greg KH <greg@kroah.com> 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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2017-06-13  6:04 Stephen Rothwell
@ 2017-06-13  6:20 ` Greg KH
  2017-06-13  6:25   ` Stephen Rothwell
  2017-06-13  6:30   ` Sergey Senozhatsky
  0 siblings, 2 replies; 127+ messages in thread
From: Greg KH @ 2017-06-13  6:20 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Sergey Senozhatsky

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)
>   &class_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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2017-06-13  6:04 Stephen Rothwell
  2017-06-13  6:20 ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2017-06-13  6:04 UTC (permalink / raw)
  To: Greg KH
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Sergey Senozhatsky

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)
  &class_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).

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2016-05-02 11:40 ` William Breathitt Gray
@ 2016-05-02 14:47   ` Greg KH
  0 siblings, 0 replies; 127+ messages in thread
From: Greg KH @ 2016-05-02 14:47 UTC (permalink / raw)
  To: William Breathitt Gray
  Cc: Stephen Rothwell, linux-next, linux-kernel, Ingo Molnar

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:
> <https://lkml.org/lkml/2016/5/1/100>. 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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2016-05-02  5:42 Stephen Rothwell
@ 2016-05-02 11:40 ` William Breathitt Gray
  2016-05-02 14:47   ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: William Breathitt Gray @ 2016-05-02 11:40 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel, Ingo Molnar

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:
<https://lkml.org/lkml/2016/5/1/100>. 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 <https://lkml.org/lkml/2016/4/11/421> for the history behind these
two patches.

William Breathitt Gray

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2016-05-02  5:42 Stephen Rothwell
  2016-05-02 11:40 ` William Breathitt Gray
  0 siblings, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2016-05-02  5:42 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, William Breathitt Gray, Ingo Molnar

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2015-05-21  7:52 Stephen Rothwell
  0 siblings, 0 replies; 127+ messages in thread
From: Stephen Rothwell @ 2015-05-21  7:52 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Luis R. Rodriguez, Dmitry Torokhov


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

Hi Greg,

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

drivers/base/dd.c: In function 'driver_allows_async_probing':
drivers/base/dd.c:430:31: error: dereferencing pointer to incomplete type
   if (drv->owner && drv->owner->async_probe_requested)
                               ^

Caused by commit f2411da74698 ("driver-core: add driver module
asynchronous probe support").

I have applied the following fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 21 May 2015 17:44:10 +1000
Subject: [PATCH] driver-core: add driver module asynchronous probe support fix

struct module is not defined if CONFIG_MODULES is not set.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/base/dd.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 39292535c74e..12e120ddbc34 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -427,8 +427,10 @@ bool driver_allows_async_probing(struct device_driver *drv)
 		return false;
 
 	default:
+#ifdef CONFIG_MODULES
 		if (drv->owner && drv->owner->async_probe_requested)
 			return true;
+#endif
 
 		return false;
 	}
-- 
2.1.4

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2014-12-01  7:49 Stephen Rothwell
  0 siblings, 0 replies; 127+ messages in thread
From: Stephen Rothwell @ 2014-12-01  7:49 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel


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

Hi Greg,

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

fs/debugfs/file.c:797:16: error: conflicting types for 'debugfs_create_devm_seqfile'
 struct dentry *debugfs_create_devm_seqfile(struct device *dev, const char *name,
                ^
In file included from fs/debugfs/file.c:21:0:
include/linux/debugfs.h:102:16: note: previous declaration of 'debugfs_create_devm_seqfile' was here
 struct dentry *debugfs_create_devm_seqfile(struct device *dev, const char *name,
                ^

Caused by commit 98210b7f73f1 ("debugfs: add helper function to create
device related seq_file") but I am not sure how ... it seems to be
related to the warning I reported earlier as the following patch fixes
it (and the warnings).

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 1 Dec 2014 18:42:52 +1100
Subject: [PATCH] debugfs: predeclare struct device

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/debugfs.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
index d145287c0e44..37b17d95d648 100644
--- a/include/linux/debugfs.h
+++ b/include/linux/debugfs.h
@@ -21,6 +21,7 @@
 #include <linux/types.h>
 
 struct file_operations;
+struct device;
 
 struct debugfs_blob_wrapper {
 	void *data;
-- 
2.1.3

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-05-28  8:03 Stephen Rothwell
@ 2014-05-28  9:30 ` Jean Delvare
  0 siblings, 0 replies; 127+ messages in thread
From: Jean Delvare @ 2014-05-28  9:30 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2014-05-28  8:03 Stephen Rothwell
  2014-05-28  9:30 ` Jean Delvare
  0 siblings, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2014-05-28  8:03 UTC (permalink / raw)
  To: Greg KH, Jean Delvare; +Cc: linux-next, linux-kernel


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

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 :-)

I have used the driver-core tree from next-20140527 for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-18  0:22               ` Benjamin Herrenschmidt
@ 2014-03-18 15:58                 ` Tejun Heo
  0 siblings, 0 replies; 127+ messages in thread
From: Tejun Heo @ 2014-03-18 15:58 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Greg KH, Stephen Rothwell, Mark Brown, Stewart Smith, linux-next,
	linux-kernel

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-17 22:21             ` Tejun Heo
  2014-03-18  0:07               ` Stewart Smith
@ 2014-03-18  0:22               ` Benjamin Herrenschmidt
  2014-03-18 15:58                 ` Tejun Heo
  1 sibling, 1 reply; 127+ messages in thread
From: Benjamin Herrenschmidt @ 2014-03-18  0:22 UTC (permalink / raw)
  To: Tejun Heo
  Cc: Greg KH, Stephen Rothwell, Mark Brown, Stewart Smith, linux-next,
	linux-kernel

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.

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-17 21:56         ` Greg KH
  2014-03-17 22:05           ` Tejun Heo
  2014-03-18  0:00           ` Stewart Smith
@ 2014-03-18  0:16           ` Benjamin Herrenschmidt
  2 siblings, 0 replies; 127+ messages in thread
From: Benjamin Herrenschmidt @ 2014-03-18  0:16 UTC (permalink / raw)
  To: Greg KH
  Cc: Stephen Rothwell, Mark Brown, Stewart Smith, Tejun Heo,
	linux-next, linux-kernel


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

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


[-- Attachment #2: sysfs-firmware-opal-elog --]
[-- Type: text/plain, Size: 2207 bytes --]

What:		/sys/firmware/opal/elog
Date:		Feb 2014
Contact:	Stewart Smith <stewart@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).

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-17 22:21             ` Tejun Heo
@ 2014-03-18  0:07               ` Stewart Smith
  2014-03-18  0:22               ` Benjamin Herrenschmidt
  1 sibling, 0 replies; 127+ messages in thread
From: Stewart Smith @ 2014-03-18  0:07 UTC (permalink / raw)
  To: Tejun Heo, Greg KH
  Cc: Benjamin Herrenschmidt, Stephen Rothwell, Mark Brown, linux-next,
	linux-kernel

Tejun Heo <tj@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 :)

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-17 21:56         ` Greg KH
  2014-03-17 22:05           ` Tejun Heo
@ 2014-03-18  0:00           ` Stewart Smith
  2014-03-18  0:16           ` Benjamin Herrenschmidt
  2 siblings, 0 replies; 127+ messages in thread
From: Stewart Smith @ 2014-03-18  0:00 UTC (permalink / raw)
  To: Greg KH, Benjamin Herrenschmidt
  Cc: Stephen Rothwell, Mark Brown, Tejun Heo, linux-next, linux-kernel

Greg KH <greg@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.

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-17 22:05           ` Tejun Heo
@ 2014-03-17 22:21             ` Tejun Heo
  2014-03-18  0:07               ` Stewart Smith
  2014-03-18  0:22               ` Benjamin Herrenschmidt
  0 siblings, 2 replies; 127+ messages in thread
From: Tejun Heo @ 2014-03-17 22:21 UTC (permalink / raw)
  To: Greg KH
  Cc: Benjamin Herrenschmidt, Stephen Rothwell, Mark Brown,
	Stewart Smith, linux-next, linux-kernel

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-17 21:56         ` Greg KH
@ 2014-03-17 22:05           ` Tejun Heo
  2014-03-17 22:21             ` Tejun Heo
  2014-03-18  0:00           ` Stewart Smith
  2014-03-18  0:16           ` Benjamin Herrenschmidt
  2 siblings, 1 reply; 127+ messages in thread
From: Tejun Heo @ 2014-03-17 22:05 UTC (permalink / raw)
  To: Greg KH
  Cc: Benjamin Herrenschmidt, Stephen Rothwell, Mark Brown,
	Stewart Smith, linux-next, linux-kernel

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-17 20:33       ` Benjamin Herrenschmidt
@ 2014-03-17 21:56         ` Greg KH
  2014-03-17 22:05           ` Tejun Heo
                             ` (2 more replies)
  0 siblings, 3 replies; 127+ messages in thread
From: Greg KH @ 2014-03-17 21:56 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Stephen Rothwell, Mark Brown, Stewart Smith, Tejun Heo,
	linux-next, linux-kernel

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-17 18:33     ` Greg KH
@ 2014-03-17 20:33       ` Benjamin Herrenschmidt
  2014-03-17 21:56         ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: Benjamin Herrenschmidt @ 2014-03-17 20:33 UTC (permalink / raw)
  To: Greg KH
  Cc: Stephen Rothwell, Mark Brown, Stewart Smith, Tejun Heo,
	linux-next, linux-kernel

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.

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-16 23:16                         ` Stephen Rothwell
@ 2014-03-17 18:36                           ` Greg KH
  0 siblings, 0 replies; 127+ messages in thread
From: Greg KH @ 2014-03-17 18:36 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Benjamin Herrenschmidt, Tejun Heo, Mark Brown, Stewart Smith,
	linux-next, linux-kernel, Linus

On Mon, Mar 17, 2014 at 10:16:21AM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> On Sat, 15 Mar 2014 05:29:42 +0000 Greg KH <greg@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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-16 23:16   ` Stephen Rothwell
@ 2014-03-17 18:33     ` Greg KH
  2014-03-17 20:33       ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 127+ messages in thread
From: Greg KH @ 2014-03-17 18:33 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Mark Brown, Stewart Smith, Benjamin Herrenschmidt, Tejun Heo,
	linux-next, linux-kernel

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 <greg@kroah.com> wrote:
> >
> > On Wed, Mar 12, 2014 at 12:51:52AM +0000, 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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-12  0:51 Mark Brown
  2014-03-12  1:50 ` Greg KH
@ 2014-03-17  8:28 ` Stephen Rothwell
  1 sibling, 0 replies; 127+ messages in thread
From: Stephen Rothwell @ 2014-03-17  8:28 UTC (permalink / raw)
  To: Greg KH
  Cc: Mark Brown, Stewart Smith, Benjamin Herrenschmidt, Tejun Heo,
	linux-next, linux-kernel


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

Hi all,

On Wed, 12 Mar 2014 00:51:52 +0000 Mark Brown <broonie@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 Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-15  5:29                       ` Greg KH
  2014-03-15  7:14                         ` Benjamin Herrenschmidt
@ 2014-03-16 23:16                         ` Stephen Rothwell
  2014-03-17 18:36                           ` Greg KH
  1 sibling, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2014-03-16 23:16 UTC (permalink / raw)
  To: Greg KH
  Cc: Benjamin Herrenschmidt, Tejun Heo, Mark Brown, Stewart Smith,
	linux-next, linux-kernel, Linus


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

Hi Greg,

On Sat, 15 Mar 2014 05:29:42 +0000 Greg KH <greg@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 Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-12  1:50 ` Greg KH
  2014-03-12  3:55   ` Benjamin Herrenschmidt
@ 2014-03-16 23:16   ` Stephen Rothwell
  2014-03-17 18:33     ` Greg KH
  1 sibling, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2014-03-16 23:16 UTC (permalink / raw)
  To: Greg KH
  Cc: Mark Brown, Stewart Smith, Benjamin Herrenschmidt, Tejun Heo,
	linux-next, linux-kernel


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

Hi Greg,

On Tue, 11 Mar 2014 18:50:21 -0700 Greg KH <greg@kroah.com> wrote:
>
> On Wed, Mar 12, 2014 at 12:51:52AM +0000, 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 Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-15  5:29                       ` Greg KH
@ 2014-03-15  7:14                         ` Benjamin Herrenschmidt
  2014-03-16 23:16                         ` Stephen Rothwell
  1 sibling, 0 replies; 127+ messages in thread
From: Benjamin Herrenschmidt @ 2014-03-15  7:14 UTC (permalink / raw)
  To: Greg KH; +Cc: Tejun Heo, Mark Brown, Stewart Smith, linux-next, linux-kernel

On Sat, 2014-03-15 at 05:29 +0000, 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.

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-15  2:57                     ` Benjamin Herrenschmidt
@ 2014-03-15  5:29                       ` Greg KH
  2014-03-15  7:14                         ` Benjamin Herrenschmidt
  2014-03-16 23:16                         ` Stephen Rothwell
  0 siblings, 2 replies; 127+ messages in thread
From: Greg KH @ 2014-03-15  5:29 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Tejun Heo, Mark Brown, Stewart Smith, linux-next, linux-kernel

On Sat, Mar 15, 2014 at 01:57:29PM +1100, Benjamin Herrenschmidt wrote:
> On Sat, 2014-03-15 at 00:03 +0000, 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-

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-15  0:03                   ` Greg KH
@ 2014-03-15  2:57                     ` Benjamin Herrenschmidt
  2014-03-15  5:29                       ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: Benjamin Herrenschmidt @ 2014-03-15  2:57 UTC (permalink / raw)
  To: Greg KH; +Cc: Tejun Heo, Mark Brown, Stewart Smith, linux-next, linux-kernel

On Sat, 2014-03-15 at 00:03 +0000, 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-13 22:14                 ` Benjamin Herrenschmidt
  2014-03-14 13:00                   ` Tejun Heo
@ 2014-03-15  0:03                   ` Greg KH
  2014-03-15  2:57                     ` Benjamin Herrenschmidt
  1 sibling, 1 reply; 127+ messages in thread
From: Greg KH @ 2014-03-15  0:03 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Tejun Heo, Mark Brown, Stewart Smith, linux-next, linux-kernel

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-13 22:14                 ` Benjamin Herrenschmidt
@ 2014-03-14 13:00                   ` Tejun Heo
  2014-03-15  0:03                   ` Greg KH
  1 sibling, 0 replies; 127+ messages in thread
From: Tejun Heo @ 2014-03-14 13:00 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Mark Brown, Greg KH, Stewart Smith, linux-next, linux-kernel

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-13  0:37               ` Benjamin Herrenschmidt
@ 2014-03-13 22:14                 ` Benjamin Herrenschmidt
  2014-03-14 13:00                   ` Tejun Heo
  2014-03-15  0:03                   ` Greg KH
  0 siblings, 2 replies; 127+ messages in thread
From: Benjamin Herrenschmidt @ 2014-03-13 22:14 UTC (permalink / raw)
  To: Tejun Heo; +Cc: Mark Brown, Greg KH, Stewart Smith, linux-next, linux-kernel

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.

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-12 20:21             ` Tejun Heo
@ 2014-03-13  0:37               ` Benjamin Herrenschmidt
  2014-03-13 22:14                 ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 127+ messages in thread
From: Benjamin Herrenschmidt @ 2014-03-13  0:37 UTC (permalink / raw)
  To: Tejun Heo; +Cc: Mark Brown, Greg KH, Stewart Smith, linux-next, linux-kernel

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.

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-12 20:14           ` Benjamin Herrenschmidt
@ 2014-03-12 20:21             ` Tejun Heo
  2014-03-13  0:37               ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 127+ messages in thread
From: Tejun Heo @ 2014-03-12 20:21 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Mark Brown, Greg KH, Stewart Smith, linux-next, linux-kernel

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-12 20:02         ` Tejun Heo
@ 2014-03-12 20:14           ` Benjamin Herrenschmidt
  2014-03-12 20:21             ` Tejun Heo
  0 siblings, 1 reply; 127+ messages in thread
From: Benjamin Herrenschmidt @ 2014-03-12 20:14 UTC (permalink / raw)
  To: Tejun Heo; +Cc: Mark Brown, Greg KH, Stewart Smith, linux-next, linux-kernel

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.

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-12 19:59       ` Benjamin Herrenschmidt
@ 2014-03-12 20:02         ` Tejun Heo
  2014-03-12 20:14           ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 127+ messages in thread
From: Tejun Heo @ 2014-03-12 20:02 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Mark Brown, Greg KH, Stewart Smith, linux-next, linux-kernel

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-12 11:37     ` Mark Brown
@ 2014-03-12 19:59       ` Benjamin Herrenschmidt
  2014-03-12 20:02         ` Tejun Heo
  0 siblings, 1 reply; 127+ messages in thread
From: Benjamin Herrenschmidt @ 2014-03-12 19:59 UTC (permalink / raw)
  To: Mark Brown; +Cc: Greg KH, Stewart Smith, Tejun Heo, linux-next, linux-kernel

On Wed, 2014-03-12 at 11:37 +0000, 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.

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-12  3:55   ` Benjamin Herrenschmidt
@ 2014-03-12 11:37     ` Mark Brown
  2014-03-12 19:59       ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 127+ messages in thread
From: Mark Brown @ 2014-03-12 11:37 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Greg KH, Stewart Smith, Tejun Heo, linux-next, linux-kernel


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

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.

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-12  1:50 ` Greg KH
@ 2014-03-12  3:55   ` Benjamin Herrenschmidt
  2014-03-12 11:37     ` Mark Brown
  2014-03-16 23:16   ` Stephen Rothwell
  1 sibling, 1 reply; 127+ messages in thread
From: Benjamin Herrenschmidt @ 2014-03-12  3:55 UTC (permalink / raw)
  To: Greg KH; +Cc: Mark Brown, Stewart Smith, Tejun Heo, linux-next, linux-kernel

On Tue, 2014-03-11 at 18:50 -0700, Greg KH wrote:
> On Wed, Mar 12, 2014 at 12:51:52AM +0000, 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.

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2014-03-12  0:51 Mark Brown
@ 2014-03-12  1:50 ` Greg KH
  2014-03-12  3:55   ` Benjamin Herrenschmidt
  2014-03-16 23:16   ` Stephen Rothwell
  2014-03-17  8:28 ` Stephen Rothwell
  1 sibling, 2 replies; 127+ messages in thread
From: Greg KH @ 2014-03-12  1:50 UTC (permalink / raw)
  To: Mark Brown
  Cc: Stewart Smith, Benjamin Herrenschmidt, Tejun Heo, linux-next,
	linux-kernel

On Wed, Mar 12, 2014 at 12:51:52AM +0000, 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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2014-03-12  0:51 Mark Brown
  2014-03-12  1:50 ` Greg KH
  2014-03-17  8:28 ` Stephen Rothwell
  0 siblings, 2 replies; 127+ messages in thread
From: Mark Brown @ 2014-03-12  0:51 UTC (permalink / raw)
  To: Greg KH, Stewart Smith, Benjamin Herrenschmidt, Tejun Heo
  Cc: linux-next, linux-kernel


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

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.

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2013-08-22  5:39 Stephen Rothwell
@ 2013-08-22 15:36 ` Greg KH
  0 siblings, 0 replies; 127+ messages in thread
From: Greg KH @ 2013-08-22 15:36 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2013-08-22  5:39 Stephen Rothwell
  2013-08-22 15:36 ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2013-08-22  5:39 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel


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

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").

I have used the driver-core tree from next-20130821 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* RE: linux-next: build failure after merge of the driver-core tree
  2013-01-18  4:13 ` Greg KH
@ 2013-01-18 14:14   ` Kondratiev, Vladimir
  0 siblings, 0 replies; 127+ messages in thread
From: Kondratiev, Vladimir @ 2013-01-18 14:14 UTC (permalink / raw)
  To: Greg KH, Stephen Rothwell
  Cc: linux-next, linux-kernel, qca_vkondrat, Jason Baron, John W. Linville


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 <sfr@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 <sfr@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.

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2013-01-18  2:29 Stephen Rothwell
@ 2013-01-18  4:13 ` Greg KH
  2013-01-18 14:14   ` Kondratiev, Vladimir
  0 siblings, 1 reply; 127+ messages in thread
From: Greg KH @ 2013-01-18  4:13 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Vladimir Kondratiev, Jason Baron,
	John W. Linville

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 <sfr@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 <sfr@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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2013-01-18  2:29 Stephen Rothwell
  2013-01-18  4:13 ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2013-01-18  2:29 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-next, linux-kernel, Vladimir Kondratiev, Jason Baron,
	John W. Linville


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

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 <sfr@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 <sfr@canb.auug.org.au>
---
 drivers/net/wireless/ath/wil6210/dbg_hexdump.h |   18 ++++--------------
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/dbg_hexdump.h b/drivers/net/wireless/ath/wil6210/dbg_hexdump.h
index 6a315ba..e5712f0 100644
--- a/drivers/net/wireless/ath/wil6210/dbg_hexdump.h
+++ b/drivers/net/wireless/ath/wil6210/dbg_hexdump.h
@@ -1,25 +1,15 @@
 #ifndef WIL_DBG_HEXDUMP_H_
 #define WIL_DBG_HEXDUMP_H_
 
-#if defined(CONFIG_DYNAMIC_DEBUG)
-#define wil_dynamic_hex_dump(prefix_str, prefix_type, rowsize,	\
-			     groupsize, buf, len, ascii)	\
-do {								\
-	DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,		\
-		__builtin_constant_p(prefix_str) ? prefix_str : "hexdump");\
-	if (unlikely(descriptor.flags & _DPRINTK_FLAGS_PRINT))	\
-		print_hex_dump(KERN_DEBUG, prefix_str,		\
-			       prefix_type, rowsize, groupsize,	\
-			       buf, len, ascii);		\
-} while (0)
+#include <linux/printk.h>
+#include <linux/dynamic_debug.h>
 
+#if defined(CONFIG_DYNAMIC_DEBUG)
 #define wil_print_hex_dump_debug(prefix_str, prefix_type, rowsize,	\
 				 groupsize, buf, len, ascii)		\
-	wil_dynamic_hex_dump(prefix_str, prefix_type, rowsize,		\
+	dynamic_hex_dump(prefix_str, prefix_type, rowsize,		\
 			     groupsize, buf, len, ascii)
 
-#define print_hex_dump_bytes(prefix_str, prefix_type, buf, len)	\
-	wil_dynamic_hex_dump(prefix_str, prefix_type, 16, 1, buf, len, true)
 #else /* defined(CONFIG_DYNAMIC_DEBUG) */
 #define wil_print_hex_dump_debug(prefix_str, prefix_type, rowsize,	\
 				 groupsize, buf, len, ascii)		\
-- 
1.7.10.280.gaa39

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2012-08-17  4:01 Stephen Rothwell
@ 2012-08-17 13:25 ` Greg KH
  0 siblings, 0 replies; 127+ messages in thread
From: Greg KH @ 2012-08-17 13:25 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Ming Lei

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2012-08-17  4:01 Stephen Rothwell
  2012-08-17 13:25 ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2012-08-17  4:01 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Ming Lei


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

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").

I have used the driver-core tree from next-20120816 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2012-07-10 11:14   ` Stephen Rothwell
@ 2012-07-10 21:10     ` Linus Walleij
  0 siblings, 0 replies; 127+ messages in thread
From: Linus Walleij @ 2012-07-10 21:10 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Mark Brown, Greg KH, linux-next, linux-kernel, Axel Lin,
	Grant Likely, Andrew Morton, Stephen Warren

On Tue, Jul 10, 2012 at 1:14 PM, Stephen Rothwell <sfr@canb.auug.org.au> 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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2012-07-10  9:03 ` Mark Brown
@ 2012-07-10 11:14   ` Stephen Rothwell
  2012-07-10 21:10     ` Linus Walleij
  0 siblings, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2012-07-10 11:14 UTC (permalink / raw)
  To: Mark Brown
  Cc: Greg KH, linux-next, linux-kernel, Axel Lin, Grant Likely,
	Linus Walleij, Andrew Morton, Stephen Warren


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

Hi Mark,

On Tue, 10 Jul 2012 10:03:25 +0100 Mark Brown <broonie@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 Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2012-07-10  5:32 Stephen Rothwell
@ 2012-07-10  9:03 ` Mark Brown
  2012-07-10 11:14   ` Stephen Rothwell
  0 siblings, 1 reply; 127+ messages in thread
From: Mark Brown @ 2012-07-10  9:03 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Greg KH, linux-next, linux-kernel, Axel Lin, Grant Likely, Linus Walleij


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

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.

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2012-07-10  5:32 Stephen Rothwell
  2012-07-10  9:03 ` Mark Brown
  0 siblings, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2012-07-10  5:32 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-next, linux-kernel, Mark Brown, Axel Lin, Grant Likely,
	Linus Walleij


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

Hi Greg,

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

ERROR: "devm_gpio_request_one" [drivers/extcon/extcon-arizona.ko] undefined!

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

This has not been seen earlier because CONFIG_MFD_ARIZONA only got added
today :-(

I have added the following merge fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 10 Jul 2012 15:25:14 +1000
Subject: [PATCH] extcon: extcon-arizone can not be built as a module for now

fixes this build error:

ERROR: "devm_gpio_request_one" [drivers/extcon/extcon-arizona.ko] undefined!

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/extcon/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index dbd96af..a2071e4 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -30,7 +30,7 @@ config EXTCON_MAX8997
 	  detector and switch.
 
 config EXTCON_ARIZONA
-	tristate "Wolfson Arizona EXTCON support"
+	bool "Wolfson Arizona EXTCON support"
 	depends on MFD_ARIZONA
 	help
 	  Say Y here to enable support for external accessory detection
-- 
1.7.10.280.gaa39

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2012-05-01  4:59 Stephen Rothwell
  2012-05-01  7:05 ` Bart Van Assche
@ 2012-05-01 13:45 ` Greg KH
  1 sibling, 0 replies; 127+ messages in thread
From: Greg KH @ 2012-05-01 13:45 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Bart Van Assche, Jim Cromie, Roland Dreier

On Tue, May 01, 2012 at 02:59:22PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> In file included from include/linux/kernel.h:23:0,
>                  from include/linux/cache.h:4,
>                  from include/linux/time.h:7,
>                  from include/linux/stat.h:60,
>                  from include/linux/module.h:10,
>                  from drivers/infiniband/ulp/srp/ib_srp.c:35:
> include/linux/dynamic_debug.h: In function 'ddebug_dyndbg_module_param_cb':
> include/linux/dynamic_debug.h:112:3: error: expected ')' before 'PFX'
> 
> Caused by commit b48420c1d301 ("dynamic_debug: make dynamic-debug work
> for module initialization") interacting with commit e0bda7d8c33e
> ("IB/srp: Use pr_fmt() and pr_err()/pr_warn()") from Linus' tree (added
> before v3.4-rc1).
> 
> I have used the driver-core tree from next-20120430 for today.

Thanks, but this is a driver-core tree problem, not an IB tree problem,
so should you should have dropped my tree :)

I've applied a patch to the driver-core tree that should solve this
issue now, thanks for letting us know.

greg k-h

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2012-05-01  4:59 Stephen Rothwell
@ 2012-05-01  7:05 ` Bart Van Assche
  2012-05-01 13:45 ` Greg KH
  1 sibling, 0 replies; 127+ messages in thread
From: Bart Van Assche @ 2012-05-01  7:05 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Greg KH, linux-next, linux-kernel, Jim Cromie, Roland Dreier

On 05/01/12 04:59, Stephen Rothwell wrote:

> After merging the driver-core tree, today's linux-next build
> (powerpc ppc64_defconfig) failed like this:
> 
> In file included from include/linux/kernel.h:23:0, from
> include/linux/cache.h:4, from include/linux/time.h:7, from
> include/linux/stat.h:60, from include/linux/module.h:10, from
> drivers/infiniband/ulp/srp/ib_srp.c:35: 
> include/linux/dynamic_debug.h: In function
> 'ddebug_dyndbg_module_param_cb': 
> include/linux/dynamic_debug.h:112:3: error: expected ')' before
> 'PFX'
> 
> Caused by commit b48420c1d301 ("dynamic_debug: make dynamic-debug
> work for module initialization") interacting with commit
> e0bda7d8c33e ("IB/srp: Use pr_fmt() and pr_err()/pr_warn()") from
> Linus' tree (added before v3.4-rc1).
> 
> I have used the driver-core tree from next-20120430 for today.


This reveals that the pr_warn() statement in that dynamic_debug patch
uses the pr_fmt() macro of the module from which it has been included
(e.g. ib_srp) instead that of the dynamic debug module itself. That
looks incorrect to me. How about moving the definition of
ddebug_dyndbg_module_param_cb() from include/linux/dynamic_debug.h
into lib/dynamic_debug.c ?

Bart.

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2012-05-01  4:59 Stephen Rothwell
  2012-05-01  7:05 ` Bart Van Assche
  2012-05-01 13:45 ` Greg KH
  0 siblings, 2 replies; 127+ messages in thread
From: Stephen Rothwell @ 2012-05-01  4:59 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-next, linux-kernel, Bart Van Assche, Jim Cromie, Roland Dreier


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

Hi Greg,

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

In file included from include/linux/kernel.h:23:0,
                 from include/linux/cache.h:4,
                 from include/linux/time.h:7,
                 from include/linux/stat.h:60,
                 from include/linux/module.h:10,
                 from drivers/infiniband/ulp/srp/ib_srp.c:35:
include/linux/dynamic_debug.h: In function 'ddebug_dyndbg_module_param_cb':
include/linux/dynamic_debug.h:112:3: error: expected ')' before 'PFX'

Caused by commit b48420c1d301 ("dynamic_debug: make dynamic-debug work
for module initialization") interacting with commit e0bda7d8c33e
("IB/srp: Use pr_fmt() and pr_err()/pr_warn()") from Linus' tree (added
before v3.4-rc1).

I have used the driver-core tree from next-20120430 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2012-04-19  4:48 Stephen Rothwell
  2012-04-19 20:07 ` Greg KH
@ 2012-04-20  2:19 ` Greg KH
  1 sibling, 0 replies; 127+ messages in thread
From: Greg KH @ 2012-04-20  2:19 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Hannes Reinecke

On Thu, Apr 19, 2012 at 02:48:15PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> lib/klist.c: In function 'klist_iter_init_node':
> lib/klist.c:287:4: error: too few arguments to function 'kref_put'
> include/linux/kref.h:92:19: note: declared here
> 
> Caused by commit a15d49fd3094 ("driver core: check start node in
> klist_iter_init_node").  That really hasn't been build tested, has it?
> 
> I have used the driver-core tree from next-20120418 for today.

Ok, that was just totally obviously broken, I have no idea how that
passed my testing, as it just failed right now.  So I've reverted it.

Hannes, care to fix this up and resend when it works?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2012-04-19  4:48 Stephen Rothwell
@ 2012-04-19 20:07 ` Greg KH
  2012-04-20  2:19 ` Greg KH
  1 sibling, 0 replies; 127+ messages in thread
From: Greg KH @ 2012-04-19 20:07 UTC (permalink / raw)
  To: Stephen Rothwell, Hannes Reinecke; +Cc: linux-next, linux-kernel

On Thu, Apr 19, 2012 at 02:48:15PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> lib/klist.c: In function 'klist_iter_init_node':
> lib/klist.c:287:4: error: too few arguments to function 'kref_put'
> include/linux/kref.h:92:19: note: declared here
> 
> Caused by commit a15d49fd3094 ("driver core: check start node in
> klist_iter_init_node").  That really hasn't been build tested, has it?
> 
> I have used the driver-core tree from next-20120418 for today.

Ick.  Hannes, care to send me a fix for this?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2012-04-19  4:48 Stephen Rothwell
  2012-04-19 20:07 ` Greg KH
  2012-04-20  2:19 ` Greg KH
  0 siblings, 2 replies; 127+ messages in thread
From: Stephen Rothwell @ 2012-04-19  4:48 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Hannes Reinecke


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

Hi Greg,

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

lib/klist.c: In function 'klist_iter_init_node':
lib/klist.c:287:4: error: too few arguments to function 'kref_put'
include/linux/kref.h:92:19: note: declared here

Caused by commit a15d49fd3094 ("driver core: check start node in
klist_iter_init_node").  That really hasn't been build tested, has it?

I have used the driver-core tree from next-20120418 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2012-01-27  2:59 Stephen Rothwell
  2012-01-27 15:24 ` Alan Stern
@ 2012-01-27 22:36 ` Greg KH
  1 sibling, 0 replies; 127+ messages in thread
From: Greg KH @ 2012-01-27 22:36 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Alan Stern, David S. Miller,
	Konrad Rzeszutek Wilk, Michael Buesch, Joerg Roedel

On Fri, Jan 27, 2012 at 01:59:12PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/pci/xen-pcifront.c: In function 'pcifront_common_process':
> drivers/pci/xen-pcifront.c:596:6: error: used struct type value where scalar is required
> 
> Caused by commit f3ff9247088a ("Remove useless get_driver()/put_driver()
> calls").
> 
> Please build test this stuff ...

Sorry, I do build test this, but I didn't have Xen enabled in that
.config as I never run Xen :)

I'll queue up Alan's patch so all should be good now.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2012-01-27  2:59 Stephen Rothwell
@ 2012-01-27 15:24 ` Alan Stern
  2012-01-27 22:36 ` Greg KH
  1 sibling, 0 replies; 127+ messages in thread
From: Alan Stern @ 2012-01-27 15:24 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Greg KH, linux-next, Kernel development list, David S. Miller,
	Konrad Rzeszutek Wilk, Michael Buesch, Joerg Roedel

On Fri, 27 Jan 2012, Stephen Rothwell wrote:

> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/pci/xen-pcifront.c: In function 'pcifront_common_process':
> drivers/pci/xen-pcifront.c:596:6: error: used struct type value where scalar is required
> 
> Caused by commit f3ff9247088a ("Remove useless get_driver()/put_driver()
> calls").
> 
> Please build test this stuff ...
> 
> I have used the driver-core tree from next-20120125 for today.

Sorry about the mistake.  I don't always build-test everything because 
it's not easy to do it on my system.  Anyway, the patch below will 
fix the problem.

Alan Stern

-----------------------------------------------------------------
Subject: [PATCH] PCI/XEN: Fix bug introduced by a recent change

This patch (as1516) fixes a bug introduced during the removal of
put_driver() and get_driver() from drivers/pci/xen-pcifront.c.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>

---

 drivers/pci/xen-pcifront.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: usb-3.3/drivers/pci/xen-pcifront.c
===================================================================
--- usb-3.3.orig/drivers/pci/xen-pcifront.c
+++ usb-3.3/drivers/pci/xen-pcifront.c
@@ -593,7 +593,7 @@ static pci_ers_result_t pcifront_common_
 	}
 	pdrv = pcidev->driver;
 
-	if (pdrv->driver) {
+	if (pdrv) {
 		if (pdrv->err_handler && pdrv->err_handler->error_detected) {
 			dev_dbg(&pcidev->dev,
 				"trying to call AER service\n");

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2012-01-27  2:59 Stephen Rothwell
  2012-01-27 15:24 ` Alan Stern
  2012-01-27 22:36 ` Greg KH
  0 siblings, 2 replies; 127+ messages in thread
From: Stephen Rothwell @ 2012-01-27  2:59 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-next, linux-kernel, Alan Stern, David S. Miller,
	Konrad Rzeszutek Wilk, Michael Buesch, Joerg Roedel


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

Hi Greg,

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

drivers/pci/xen-pcifront.c: In function 'pcifront_common_process':
drivers/pci/xen-pcifront.c:596:6: error: used struct type value where scalar is required

Caused by commit f3ff9247088a ("Remove useless get_driver()/put_driver()
calls").

Please build test this stuff ...

I have used the driver-core tree from next-20120125 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2012-01-05  6:28 Stephen Rothwell
@ 2012-01-05 23:20 ` Greg KH
  0 siblings, 0 replies; 127+ messages in thread
From: Greg KH @ 2012-01-05 23:20 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Srivatsa S. Bhat, Borislav Petkov,
	Jan Beulich, Kay Sievers

On Thu, Jan 05, 2012 at 05:28:56PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> arch/x86/kernel/microcode_core.c: In function 'microcode_init':
> arch/x86/kernel/microcode_core.c:557:2: error: implicit declaration of function 'sysdev_driver_unregister' [-Werror=implicit-function-declaration]
> arch/x86/kernel/microcode_core.c:557:28: error: 'cpu_sysdev_class' undeclared (first use in this function)
> arch/x86/kernel/microcode_core.c:557:47: error: 'mc_sysdev_driver' undeclared (first use in this function)
> 
> Caused by commit 8a25a2fd126c ("cpu: convert 'cpu' and 'machinecheck'
> sysdev_class to a regular subsystem") interacting with commit
> bd399063976c ("x86, microcode: Fix the failure path of microcode update
> driver init code") which was added to Linux' tree in v3.2-rc5,
> 
> I have applied the following merge fix patch:

Thanks, this looks good, and I'll queue it up when push these to Linus.

greg k-h

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2012-01-05  6:28 Stephen Rothwell
  2012-01-05 23:20 ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2012-01-05  6:28 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-next, linux-kernel, Srivatsa S. Bhat, Borislav Petkov,
	Jan Beulich, Kay Sievers


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

Hi Greg,

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

arch/x86/kernel/microcode_core.c: In function 'microcode_init':
arch/x86/kernel/microcode_core.c:557:2: error: implicit declaration of function 'sysdev_driver_unregister' [-Werror=implicit-function-declaration]
arch/x86/kernel/microcode_core.c:557:28: error: 'cpu_sysdev_class' undeclared (first use in this function)
arch/x86/kernel/microcode_core.c:557:47: error: 'mc_sysdev_driver' undeclared (first use in this function)

Caused by commit 8a25a2fd126c ("cpu: convert 'cpu' and 'machinecheck'
sysdev_class to a regular subsystem") interacting with commit
bd399063976c ("x86, microcode: Fix the failure path of microcode update
driver init code") which was added to Linux' tree in v3.2-rc5,

I have applied the following merge fix patch:

From e4aefaed98c4462d5d5d71099756606b547e7364 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 5 Jan 2012 17:26:14 +1100
Subject: [PATCH] cpu: fix up for sysdev removal

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/kernel/microcode_core.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/microcode_core.c b/arch/x86/kernel/microcode_core.c
index ef127e54..fb34a56 100644
--- a/arch/x86/kernel/microcode_core.c
+++ b/arch/x86/kernel/microcode_core.c
@@ -540,7 +540,7 @@ static int __init microcode_init(void)
 
 	error = microcode_dev_init();
 	if (error)
-		goto out_sysdev_driver;
+		goto out_driver;
 
 	register_syscore_ops(&mc_syscore_ops);
 	register_hotcpu_notifier(&mc_cpu_notifier);
@@ -550,11 +550,11 @@ static int __init microcode_init(void)
 
 	return 0;
 
-out_sysdev_driver:
+out_driver:
 	get_online_cpus();
 	mutex_lock(&microcode_mutex);
 
-	sysdev_driver_unregister(&cpu_sysdev_class, &mc_sysdev_driver);
+	subsys_interface_unregister(&mc_cpu_interface);
 
 	mutex_unlock(&microcode_mutex);
 	put_online_cpus();
-- 
1.7.8.197.g73c6b

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

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2012-01-05  0:01     ` Kay Sievers
  2012-01-05  0:17       ` Stephen Rothwell
@ 2012-01-05  0:57       ` Josh Triplett
  1 sibling, 0 replies; 127+ messages in thread
From: Josh Triplett @ 2012-01-05  0:57 UTC (permalink / raw)
  To: Kay Sievers; +Cc: Stephen Rothwell, Greg KH, linux-next, linux-kernel

On Thu, Jan 05, 2012 at 01:01:51AM +0100, Kay Sievers wrote:
> On Thu, Jan 5, 2012 at 00:48, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Kay, Greg, any hints would be nice.  The tip tree commit is adding this:
> >
> > bool cpu_is_hotpluggable(unsigned cpu)
> > {
> >        struct sys_device *dev = get_cpu_sysdev(cpu);
> >        return dev && container_of(dev, struct cpu, sysdev)->hotpluggable;
> > }
> >
> > and, of course, all the sys_device stuff has now gone ...
> >
> > So is this correct?
> >
> > bool cpu_is_hotpluggable(unsigned cpu)
> > {
> >        struct device *dev = get_cpu_device(cpu);
> >        return dev && container_of(dev, struct cpu, dev)->hotpluggable;
> > }
> 
> Yes, that look like the right pattern.
> 
> Stephen, thanks a lot for your help here, it's very much appreciated.

Definitely, thanks for fixing up cpu_is_hotpluggable for this change.

- Josh Triplett

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2012-01-05  0:01     ` Kay Sievers
@ 2012-01-05  0:17       ` Stephen Rothwell
  2012-01-05  0:57       ` Josh Triplett
  1 sibling, 0 replies; 127+ messages in thread
From: Stephen Rothwell @ 2012-01-05  0:17 UTC (permalink / raw)
  To: Kay Sievers; +Cc: Greg KH, linux-next, linux-kernel, Josh Triplett


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

Hi Kay,

On Thu, 5 Jan 2012 01:01:51 +0100 Kay Sievers <kay.sievers@vrfy.org> wrote:
>
> Yes, that look like the right pattern.

Good, thanks.

> Stephen, thanks a lot for your help here, it's very much appreciated.
> I know we cause a lot of trouble every other year. :)

Its how I justify myself :-)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2012-01-04 23:48   ` Stephen Rothwell
@ 2012-01-05  0:01     ` Kay Sievers
  2012-01-05  0:17       ` Stephen Rothwell
  2012-01-05  0:57       ` Josh Triplett
  0 siblings, 2 replies; 127+ messages in thread
From: Kay Sievers @ 2012-01-05  0:01 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel, Josh Triplett

On Thu, Jan 5, 2012 at 00:48, Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Kay, Greg, any hints would be nice.  The tip tree commit is adding this:
>
> bool cpu_is_hotpluggable(unsigned cpu)
> {
>        struct sys_device *dev = get_cpu_sysdev(cpu);
>        return dev && container_of(dev, struct cpu, sysdev)->hotpluggable;
> }
>
> and, of course, all the sys_device stuff has now gone ...
>
> So is this correct?
>
> bool cpu_is_hotpluggable(unsigned cpu)
> {
>        struct device *dev = get_cpu_device(cpu);
>        return dev && container_of(dev, struct cpu, dev)->hotpluggable;
> }

Yes, that look like the right pattern.

Stephen, thanks a lot for your help here, it's very much appreciated.
I know we cause a lot of trouble every other year. :)

Thanks,
Kay

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2012-01-04 23:07 ` Greg KH
@ 2012-01-04 23:48   ` Stephen Rothwell
  2012-01-05  0:01     ` Kay Sievers
  0 siblings, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2012-01-04 23:48 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Josh Triplett, Kay Sievers


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

Hi Greg,

On Wed, 4 Jan 2012 15:07:20 -0800 Greg KH <greg@kroah.com> wrote:
>
> Ok, I'll take off the warn_unused_result flag for device_create_file for
> now, which should solve this, and your other build problems with the
> driver-core tree.

Yes, I think that is it.

> > drivers/base/cpu.c: In function 'cpu_is_hotpluggable':
> > drivers/base/cpu.c:272:9: error: implicit declaration of function 'get_cpu_sysdev' [-Werror=implicit-function-declaration]
> > drivers/base/cpu.c:272:27: warning: initialization makes pointer from integer without a cast [enabled by default]
> > drivers/base/cpu.c:273:16: error: 'struct cpu' has no member named 'sysdev'
> > drivers/base/cpu.c:273:16: warning: initialization from incompatible pointer type [enabled by default]
> > drivers/base/cpu.c:273:16: error: 'struct cpu' has no member named 'sysdev'
> > drivers/base/cpu.c:274:1: warning: control reaches end of non-void function [-Wreturn-type]
> > 
> > Caused by the above commit interacting with commit 2987557f52b9
> > ("driver-core/cpu: Expose hotpluggability to the rest of the kernel")
> > from the tip tree.  This is will fix up in the merge commit next time.
> 
> Yeah, nothing I can do here about this, sorry.

Kay, Greg, any hints would be nice.  The tip tree commit is adding this:

bool cpu_is_hotpluggable(unsigned cpu)
{
        struct sys_device *dev = get_cpu_sysdev(cpu);
        return dev && container_of(dev, struct cpu, sysdev)->hotpluggable;
}

and, of course, all the sys_device stuff has now gone ...

So is this correct?

bool cpu_is_hotpluggable(unsigned cpu)
{
        struct device *dev = get_cpu_device(cpu);
        return dev && container_of(dev, struct cpu, dev)->hotpluggable;
}
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2012-01-04 22:03       ` Kay Sievers
@ 2012-01-04 23:13         ` Greg KH
  0 siblings, 0 replies; 127+ messages in thread
From: Greg KH @ 2012-01-04 23:13 UTC (permalink / raw)
  To: Kay Sievers; +Cc: Stephen Rothwell, linux-next, linux-kernel, Josh Triplett

On Wed, Jan 04, 2012 at 11:03:54PM +0100, Kay Sievers wrote:
> On Wed, Jan 4, 2012 at 01:31, Greg KH <greg@kroah.com> wrote:
> > On Wed, Jan 04, 2012 at 01:07:52AM +0100, Kay Sievers wrote:
> >> On Tue, Jan 3, 2012 at 17:21, Greg KH <greg@kroah.com> wrote:
> >> > On Wed, Dec 28, 2011 at 05:45:18PM +1100, Stephen Rothwell wrote:
> >> >> Because of the powerpc problems above, I have used the driver-core tree
> >> >> from next-20111222 for today.
> >> >
> >> > Sorry about all of the problems, we tried to fix everything we could,
> >> > but your merges and cross-builds found stuff we missed :(
> >> >
> >> > Kay, care to send me patches to fix this, and all of the other
> >> > linux-next-reported problems to me so we can get this resolved this
> >> > week?
> >>
> >> I rather don't want to add error checking to stuff that doesn't do it
> >> today. The sysdev stuff never had that forced checks, but the normal
> >> device stuff has.
> >
> > That's fine.
> >
> >> I think the force return value check is really a pretty misguided idea
> >> in general, and it's up to the caller to do these checks and handle
> >> rollbacks, not the driver core, I think.
> >>
> >> Can't we just remove that forced check?
> >
> > Probably, if it fixes these warning-is-an-error problems.  There were
> > other issues with linux-next that were build issues, not just this one
> > from what I recall, that kept Stephen from including the tree in
> > linux-next.  I can bounce them to you if you missed them.
> 
> Oh, I thought that was all: "I fixed it up (see below) and can carry
> the fix as necessary" material.
> 
> I might have missed some stuff, I don't see any others. Care to check
> yours and let me know?

Ok, I think you are right, I've pushed the "remove __must_check" patch
to driver-core-next and hopefully it should all be good now.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2011-12-28  6:45 Stephen Rothwell
  2012-01-03 16:21 ` Greg KH
@ 2012-01-04 23:07 ` Greg KH
  2012-01-04 23:48   ` Stephen Rothwell
  1 sibling, 1 reply; 127+ messages in thread
From: Greg KH @ 2012-01-04 23:07 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Josh Triplett, Kay Sievers

On Wed, Dec 28, 2011 at 05:45:18PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> arch/powerpc/platforms/cell/spu_base.c: In function 'spu_add_dev_attr':
> arch/powerpc/platforms/cell/spu_base.c:533:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> cc1: all warnings being treated as errors
> arch/powerpc/kernel/sysfs.c: In function 'topology_init':
> arch/powerpc/kernel/sysfs.c:658:22: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> arch/powerpc/kernel/sysfs.c: In function 'register_cpu_online':
> arch/powerpc/kernel/sysfs.c:346:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> arch/powerpc/kernel/sysfs.c:380:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> arch/powerpc/kernel/sysfs.c:384:22: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> arch/powerpc/kernel/sysfs.c:388:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> arch/powerpc/kernel/sysfs.c:391:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> arch/powerpc/kernel/sysfs.c:394:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> arch/powerpc/kernel/sysfs.c:397:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> arch/powerpc/kernel/sysfs.c:400:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> arch/powerpc/kernel/sysfs.c: In function 'cpu_add_dev_attr':
> arch/powerpc/kernel/sysfs.c:532:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> cc1: all warnings being treated as errors
> 
> Caused by commit 8a25a2fd126c ("cpu: convert 'cpu' and 'machinecheck'
> sysdev_class to a regular subsystem").   Powerpc builds parts of
> arch/powerpc with -Werror.

Ok, I'll take off the warn_unused_result flag for device_create_file for
now, which should solve this, and your other build problems with the
driver-core tree.

> drivers/base/cpu.c: In function 'cpu_is_hotpluggable':
> drivers/base/cpu.c:272:9: error: implicit declaration of function 'get_cpu_sysdev' [-Werror=implicit-function-declaration]
> drivers/base/cpu.c:272:27: warning: initialization makes pointer from integer without a cast [enabled by default]
> drivers/base/cpu.c:273:16: error: 'struct cpu' has no member named 'sysdev'
> drivers/base/cpu.c:273:16: warning: initialization from incompatible pointer type [enabled by default]
> drivers/base/cpu.c:273:16: error: 'struct cpu' has no member named 'sysdev'
> drivers/base/cpu.c:274:1: warning: control reaches end of non-void function [-Wreturn-type]
> 
> Caused by the above commit interacting with commit 2987557f52b9
> ("driver-core/cpu: Expose hotpluggability to the rest of the kernel")
> from the tip tree.  This is will fix up in the merge commit next time.

Yeah, nothing I can do here about this, sorry.

So this should fix the build problems in the driver-core-next branch for
linux-next.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2012-01-04  0:31     ` Greg KH
@ 2012-01-04 22:03       ` Kay Sievers
  2012-01-04 23:13         ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: Kay Sievers @ 2012-01-04 22:03 UTC (permalink / raw)
  To: Greg KH; +Cc: Stephen Rothwell, linux-next, linux-kernel, Josh Triplett

On Wed, Jan 4, 2012 at 01:31, Greg KH <greg@kroah.com> wrote:
> On Wed, Jan 04, 2012 at 01:07:52AM +0100, Kay Sievers wrote:
>> On Tue, Jan 3, 2012 at 17:21, Greg KH <greg@kroah.com> wrote:
>> > On Wed, Dec 28, 2011 at 05:45:18PM +1100, Stephen Rothwell wrote:
>> >> Because of the powerpc problems above, I have used the driver-core tree
>> >> from next-20111222 for today.
>> >
>> > Sorry about all of the problems, we tried to fix everything we could,
>> > but your merges and cross-builds found stuff we missed :(
>> >
>> > Kay, care to send me patches to fix this, and all of the other
>> > linux-next-reported problems to me so we can get this resolved this
>> > week?
>>
>> I rather don't want to add error checking to stuff that doesn't do it
>> today. The sysdev stuff never had that forced checks, but the normal
>> device stuff has.
>
> That's fine.
>
>> I think the force return value check is really a pretty misguided idea
>> in general, and it's up to the caller to do these checks and handle
>> rollbacks, not the driver core, I think.
>>
>> Can't we just remove that forced check?
>
> Probably, if it fixes these warning-is-an-error problems.  There were
> other issues with linux-next that were build issues, not just this one
> from what I recall, that kept Stephen from including the tree in
> linux-next.  I can bounce them to you if you missed them.

Oh, I thought that was all: "I fixed it up (see below) and can carry
the fix as necessary" material.

I might have missed some stuff, I don't see any others. Care to check
yours and let me know?

Thanks and sorry,
Kay

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2012-01-04  0:07   ` Kay Sievers
@ 2012-01-04  0:31     ` Greg KH
  2012-01-04 22:03       ` Kay Sievers
  0 siblings, 1 reply; 127+ messages in thread
From: Greg KH @ 2012-01-04  0:31 UTC (permalink / raw)
  To: Kay Sievers; +Cc: Stephen Rothwell, linux-next, linux-kernel, Josh Triplett

On Wed, Jan 04, 2012 at 01:07:52AM +0100, Kay Sievers wrote:
> On Tue, Jan 3, 2012 at 17:21, Greg KH <greg@kroah.com> wrote:
> > On Wed, Dec 28, 2011 at 05:45:18PM +1100, Stephen Rothwell wrote:
> >> Because of the powerpc problems above, I have used the driver-core tree
> >> from next-20111222 for today.
> >
> > Sorry about all of the problems, we tried to fix everything we could,
> > but your merges and cross-builds found stuff we missed :(
> >
> > Kay, care to send me patches to fix this, and all of the other
> > linux-next-reported problems to me so we can get this resolved this
> > week?
> 
> I rather don't want to add error checking to stuff that doesn't do it
> today. The sysdev stuff never had that forced checks, but the normal
> device stuff has.

That's fine.

> I think the force return value check is really a pretty misguided idea
> in general, and it's up to the caller to do these checks and handle
> rollbacks, not the driver core, I think.
> 
> Can't we just remove that forced check?

Probably, if it fixes these warning-is-an-error problems.  There were
other issues with linux-next that were build issues, not just this one
from what I recall, that kept Stephen from including the tree in
linux-next.  I can bounce them to you if you missed them.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2012-01-03 16:21 ` Greg KH
@ 2012-01-04  0:07   ` Kay Sievers
  2012-01-04  0:31     ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: Kay Sievers @ 2012-01-04  0:07 UTC (permalink / raw)
  To: Greg KH; +Cc: Stephen Rothwell, linux-next, linux-kernel, Josh Triplett

On Tue, Jan 3, 2012 at 17:21, Greg KH <greg@kroah.com> wrote:
> On Wed, Dec 28, 2011 at 05:45:18PM +1100, Stephen Rothwell wrote:
>> Because of the powerpc problems above, I have used the driver-core tree
>> from next-20111222 for today.
>
> Sorry about all of the problems, we tried to fix everything we could,
> but your merges and cross-builds found stuff we missed :(
>
> Kay, care to send me patches to fix this, and all of the other
> linux-next-reported problems to me so we can get this resolved this
> week?

I rather don't want to add error checking to stuff that doesn't do it
today. The sysdev stuff never had that forced checks, but the normal
device stuff has.

I think the force return value check is really a pretty misguided idea
in general, and it's up to the caller to do these checks and handle
rollbacks, not the driver core, I think.

Can't we just remove that forced check?

Kay

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2011-12-28  6:45 Stephen Rothwell
@ 2012-01-03 16:21 ` Greg KH
  2012-01-04  0:07   ` Kay Sievers
  2012-01-04 23:07 ` Greg KH
  1 sibling, 1 reply; 127+ messages in thread
From: Greg KH @ 2012-01-03 16:21 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Josh Triplett, Kay Sievers

On Wed, Dec 28, 2011 at 05:45:18PM +1100, Stephen Rothwell wrote:
> Because of the powerpc problems above, I have used the driver-core tree
> from next-20111222 for today.

Sorry about all of the problems, we tried to fix everything we could,
but your merges and cross-builds found stuff we missed :(

Kay, care to send me patches to fix this, and all of the other
linux-next-reported problems to me so we can get this resolved this
week?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2011-12-28  6:45 Stephen Rothwell
  2012-01-03 16:21 ` Greg KH
  2012-01-04 23:07 ` Greg KH
  0 siblings, 2 replies; 127+ messages in thread
From: Stephen Rothwell @ 2011-12-28  6:45 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Josh Triplett, Kay Sievers


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

Hi Greg,

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

arch/powerpc/platforms/cell/spu_base.c: In function 'spu_add_dev_attr':
arch/powerpc/platforms/cell/spu_base.c:533:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
cc1: all warnings being treated as errors
arch/powerpc/kernel/sysfs.c: In function 'topology_init':
arch/powerpc/kernel/sysfs.c:658:22: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
arch/powerpc/kernel/sysfs.c: In function 'register_cpu_online':
arch/powerpc/kernel/sysfs.c:346:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
arch/powerpc/kernel/sysfs.c:380:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
arch/powerpc/kernel/sysfs.c:384:22: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
arch/powerpc/kernel/sysfs.c:388:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
arch/powerpc/kernel/sysfs.c:391:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
arch/powerpc/kernel/sysfs.c:394:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
arch/powerpc/kernel/sysfs.c:397:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
arch/powerpc/kernel/sysfs.c:400:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
arch/powerpc/kernel/sysfs.c: In function 'cpu_add_dev_attr':
arch/powerpc/kernel/sysfs.c:532:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
cc1: all warnings being treated as errors

Caused by commit 8a25a2fd126c ("cpu: convert 'cpu' and 'machinecheck'
sysdev_class to a regular subsystem").   Powerpc builds parts of
arch/powerpc with -Werror.

drivers/base/cpu.c: In function 'cpu_is_hotpluggable':
drivers/base/cpu.c:272:9: error: implicit declaration of function 'get_cpu_sysdev' [-Werror=implicit-function-declaration]
drivers/base/cpu.c:272:27: warning: initialization makes pointer from integer without a cast [enabled by default]
drivers/base/cpu.c:273:16: error: 'struct cpu' has no member named 'sysdev'
drivers/base/cpu.c:273:16: warning: initialization from incompatible pointer type [enabled by default]
drivers/base/cpu.c:273:16: error: 'struct cpu' has no member named 'sysdev'
drivers/base/cpu.c:274:1: warning: control reaches end of non-void function [-Wreturn-type]

Caused by the above commit interacting with commit 2987557f52b9
("driver-core/cpu: Expose hotpluggability to the rest of the kernel")
from the tip tree.  This is will fix up in the merge commit next time.

drivers/base/cpu.c: In function 'register_cpu_control':
drivers/base/cpu.c:66:20: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Wunused-result]
cc1: some warnings being treated as errors

Caused by the above commit.

Because of the powerpc problems above, I have used the driver-core tree
from next-20111222 for today.

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

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2011-12-15 10:10   ` Kay Sievers
@ 2011-12-15 19:09     ` Greg KH
  0 siblings, 0 replies; 127+ messages in thread
From: Greg KH @ 2011-12-15 19:09 UTC (permalink / raw)
  To: Kay Sievers; +Cc: Stephen Rothwell, linux-next, linux-kernel

On Thu, Dec 15, 2011 at 11:10:26AM +0100, Kay Sievers wrote:
> On Thu, Dec 15, 2011 at 08:21, Greg KH <greg@kroah.com> wrote:
> > On Thu, Dec 15, 2011 at 05:37:54PM +1100, Stephen Rothwell wrote:
> >> After merging the driver-core tree, today's linux-next build (x86_64
> >> allmodconfig) failed like this:
> >>
> >> drivers/xen/xen-selfballoon.c:305:36: error: expected ')' before '(' token
> >> drivers/xen/xen-selfballoon.c:327:42: error: expected ')' before '(' token
> >> drivers/xen/xen-selfballoon.c:349:48: error: expected ')' before '(' token
> >>
> >> etc ...
> >>
> >> [Along with many warnings like:
> >>
> >> drivers/xen/xen-selfballoon.c:284:8: warning: 'struct device_attribute' declared inside parameter list [enabled by default]
> >> ]
> >>
> >> Presumably caused by commit drivers/xen/xen-selfballoon.c ("xen-balloon:
> >> convert sysdev_class to a regular subsystem").
> >
> > Ick, Kay, can you make a fix-up patch?
> >
> > And here I thought I built xen in my test kernel, crap, sorry about
> > that.
> 
> It seems it's a compiler version issue, or similar. I'm unable to
> reproduce it here, allmodconfig and the Xen part gets through without
> any problems.
> 
> I guess we both have very recent systems again. :)
> 
> I expect adding a device.h include will fix it. I'll send you a patch.

Yeah, that fixed it (I was able to duplicate this on my laptop, odd that
my build machine didn't show it.)

Now pushed out to my tree.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2011-12-15  7:21 ` Greg KH
@ 2011-12-15 10:10   ` Kay Sievers
  2011-12-15 19:09     ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: Kay Sievers @ 2011-12-15 10:10 UTC (permalink / raw)
  To: Greg KH; +Cc: Stephen Rothwell, linux-next, linux-kernel

On Thu, Dec 15, 2011 at 08:21, Greg KH <greg@kroah.com> wrote:
> On Thu, Dec 15, 2011 at 05:37:54PM +1100, Stephen Rothwell wrote:
>> After merging the driver-core tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/xen/xen-selfballoon.c:305:36: error: expected ')' before '(' token
>> drivers/xen/xen-selfballoon.c:327:42: error: expected ')' before '(' token
>> drivers/xen/xen-selfballoon.c:349:48: error: expected ')' before '(' token
>>
>> etc ...
>>
>> [Along with many warnings like:
>>
>> drivers/xen/xen-selfballoon.c:284:8: warning: 'struct device_attribute' declared inside parameter list [enabled by default]
>> ]
>>
>> Presumably caused by commit drivers/xen/xen-selfballoon.c ("xen-balloon:
>> convert sysdev_class to a regular subsystem").
>
> Ick, Kay, can you make a fix-up patch?
>
> And here I thought I built xen in my test kernel, crap, sorry about
> that.

It seems it's a compiler version issue, or similar. I'm unable to
reproduce it here, allmodconfig and the Xen part gets through without
any problems.

I guess we both have very recent systems again. :)

I expect adding a device.h include will fix it. I'll send you a patch.

Thanks,
Kay

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2011-12-15  6:37 Stephen Rothwell
@ 2011-12-15  7:21 ` Greg KH
  2011-12-15 10:10   ` Kay Sievers
  0 siblings, 1 reply; 127+ messages in thread
From: Greg KH @ 2011-12-15  7:21 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Kay Sievers

On Thu, Dec 15, 2011 at 05:37:54PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/xen/xen-selfballoon.c:305:36: error: expected ')' before '(' token
> drivers/xen/xen-selfballoon.c:327:42: error: expected ')' before '(' token
> drivers/xen/xen-selfballoon.c:349:48: error: expected ')' before '(' token
> 
> etc ...
> 
> [Along with many warnings like:
> 
> drivers/xen/xen-selfballoon.c:284:8: warning: 'struct device_attribute' declared inside parameter list [enabled by default]
> ]
> 
> Presumably caused by commit drivers/xen/xen-selfballoon.c ("xen-balloon:
> convert sysdev_class to a regular subsystem").

Ick, Kay, can you make a fix-up patch?

And here I thought I built xen in my test kernel, crap, sorry about
that.

greg k-h

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2011-12-15  6:37 Stephen Rothwell
  2011-12-15  7:21 ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2011-12-15  6:37 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Kay Sievers


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

Hi Greg,

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

drivers/xen/xen-selfballoon.c:305:36: error: expected ')' before '(' token
drivers/xen/xen-selfballoon.c:327:42: error: expected ')' before '(' token
drivers/xen/xen-selfballoon.c:349:48: error: expected ')' before '(' token

etc ...

[Along with many warnings like:

drivers/xen/xen-selfballoon.c:284:8: warning: 'struct device_attribute' declared inside parameter list [enabled by default]
]

Presumably caused by commit drivers/xen/xen-selfballoon.c ("xen-balloon:
convert sysdev_class to a regular subsystem").

I have used the driver-core tree from next-20111213 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2011-12-14 17:01       ` Greg KH
@ 2011-12-14 19:24         ` Greg KH
  0 siblings, 0 replies; 127+ messages in thread
From: Greg KH @ 2011-12-14 19:24 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, linux-next, linux-kernel, Alexey Dobriyan,
	Andrew Morton

On Wed, Dec 14, 2011 at 09:01:44AM -0800, Greg KH wrote:
> On Wed, Dec 14, 2011 at 04:13:05PM +0100, Peter Zijlstra wrote:
> > On Wed, 2011-12-14 at 07:03 -0800, Greg KH wrote:
> > 
> > > I'll remove the use of kfree in the WARN_ON(), which should solve this
> > > problem.
> > 
> > The alternative is that we introduce something like CONFIG_KREF_DEBUG
> > and out-of-line the functions in that case while also adding more debug
> > checks. Alexey recently proposed a refcnt.h thing that almost does what
> > kref does but has different debug checks.
> 
> That might be nice to have, but the kfree check was there to catch
> people who were trying to be "tricky", and they will not be running with
> that debug option enabled.
> 
> I'll just remove it, and rely on the documentation and public
> humiliation instead of kernel warnings to try to enforce this rule.
> It's worked pretty good so far with the kobject rules :)

Here's the patch I just applied to the driver-core-next tree, which
should resolve this build problem.

>From 6261ddee70174372d6a75601f40719b7a5392f3f Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh@suse.de>
Date: Wed, 14 Dec 2011 11:19:07 -0800
Subject: kref: fix up the kfree build problems

It turns out that some memory allocators use kobjects, which use krefs,
and kref.h was wanting to figure out the address of kfree(), which ended
up in a loop.

kfree was only being needed for a warning to tell the caller that they
were doing something stupid.  Now we just move that warning into the
comments for the functions, which results in a bit more fun as everyone
enjoys digging for people to mock at times of boredom.

So, remove the dependancy of slab.h on kref.h, and fix up the other
include file as well (we really only need bug.h and atomic.h, not
types.h).

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 include/linux/kref.h |   15 ++++++++++-----
 1 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/include/linux/kref.h b/include/linux/kref.h
index d66c88a..abc0120 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -15,8 +15,8 @@
 #ifndef _KREF_H_
 #define _KREF_H_
 
-#include <linux/types.h>
-#include <linux/slab.h>
+#include <linux/bug.h>
+#include <linux/atomic.h>
 
 struct kref {
 	atomic_t refcount;
@@ -48,7 +48,10 @@ static inline void kref_get(struct kref *kref)
  * @release: pointer to the function that will clean up the object when the
  *	     last reference to the object is released.
  *	     This pointer is required, and it is not acceptable to pass kfree
- *	     in as this function.
+ *	     in as this function.  If the caller does pass kfree to this
+ *	     function, you will be publicly mocked mercilessly by the kref
+ *	     maintainer, and anyone else who happens to notice it.  You have
+ *	     been warned.
  *
  * Subtract @count from the refcount, and if 0, call release().
  * Return 1 if the object was removed, otherwise return 0.  Beware, if this
@@ -60,7 +63,6 @@ static inline int kref_sub(struct kref *kref, unsigned int count,
 	     void (*release)(struct kref *kref))
 {
 	WARN_ON(release == NULL);
-	WARN_ON(release == (void (*)(struct kref *))kfree);
 
 	if (atomic_sub_and_test((int) count, &kref->refcount)) {
 		release(kref);
@@ -75,7 +77,10 @@ static inline int kref_sub(struct kref *kref, unsigned int count,
  * @release: pointer to the function that will clean up the object when the
  *	     last reference to the object is released.
  *	     This pointer is required, and it is not acceptable to pass kfree
- *	     in as this function.
+ *	     in as this function.  If the caller does pass kfree to this
+ *	     function, you will be publicly mocked mercilessly by the kref
+ *	     maintainer, and anyone else who happens to notice it.  You have
+ *	     been warned.
  *
  * Decrement the refcount, and if 0, call release().
  * Return 1 if the object was removed, otherwise return 0.  Beware, if this
-- 
1.7.7.3

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2011-12-14 15:13     ` Peter Zijlstra
@ 2011-12-14 17:01       ` Greg KH
  2011-12-14 19:24         ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: Greg KH @ 2011-12-14 17:01 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Stephen Rothwell, linux-next, linux-kernel, Alexey Dobriyan,
	Andrew Morton

On Wed, Dec 14, 2011 at 04:13:05PM +0100, Peter Zijlstra wrote:
> On Wed, 2011-12-14 at 07:03 -0800, Greg KH wrote:
> 
> > I'll remove the use of kfree in the WARN_ON(), which should solve this
> > problem.
> 
> The alternative is that we introduce something like CONFIG_KREF_DEBUG
> and out-of-line the functions in that case while also adding more debug
> checks. Alexey recently proposed a refcnt.h thing that almost does what
> kref does but has different debug checks.

That might be nice to have, but the kfree check was there to catch
people who were trying to be "tricky", and they will not be running with
that debug option enabled.

I'll just remove it, and rely on the documentation and public
humiliation instead of kernel warnings to try to enforce this rule.
It's worked pretty good so far with the kobject rules :)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2011-12-14 15:03   ` Greg KH
@ 2011-12-14 15:13     ` Peter Zijlstra
  2011-12-14 17:01       ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: Peter Zijlstra @ 2011-12-14 15:13 UTC (permalink / raw)
  To: Greg KH
  Cc: Stephen Rothwell, linux-next, linux-kernel, Alexey Dobriyan,
	Andrew Morton

On Wed, 2011-12-14 at 07:03 -0800, Greg KH wrote:

> I'll remove the use of kfree in the WARN_ON(), which should solve this
> problem.

The alternative is that we introduce something like CONFIG_KREF_DEBUG
and out-of-line the functions in that case while also adding more debug
checks. Alexey recently proposed a refcnt.h thing that almost does what
kref does but has different debug checks.

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2011-12-14  9:24 ` Peter Zijlstra
@ 2011-12-14 15:03   ` Greg KH
  2011-12-14 15:13     ` Peter Zijlstra
  0 siblings, 1 reply; 127+ messages in thread
From: Greg KH @ 2011-12-14 15:03 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: Stephen Rothwell, linux-next, linux-kernel

On Wed, Dec 14, 2011 at 10:24:57AM +0100, Peter Zijlstra wrote:
> On Wed, 2011-12-14 at 15:48 +1100, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > After merging the driver-core tree, today's linux-next build
> > (powerpc_ppc64_defconfig) failed like this:
> > 
> > In file included from include/linux/slab.h:185:0,
> >                  from include/linux/kref.h:19,
> >                  from include/linux/kobject.h:24,
> >                  from include/linux/sysdev.h:24,
> >                  from include/linux/node.h:17,
> >                  from include/linux/swap.h:10,
> >                  from include/linux/suspend.h:4,
> >                  from arch/powerpc/kernel/asm-offsets.c:24:
> > include/linux/slub_def.h:100:17: error: field 'kobj' has incomplete type
> > 
> > Caused by commit 4af679cd7cbb ("kref: Inline all functions") ... we now
> > have kref.h -> slab.h -> slub_def.h -> kobject.h -> kref.h when
> > CONFIG_SLUB is set.
> 
> Egads, that's nasty.. 
> 
> The nicest thing I can come up with is something like the below, but its
> not all that nice at all :/

I'll remove the use of kfree in the WARN_ON(), which should solve this
problem.

greg k-h

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2011-12-14  4:48 Stephen Rothwell
@ 2011-12-14  9:24 ` Peter Zijlstra
  2011-12-14 15:03   ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: Peter Zijlstra @ 2011-12-14  9:24 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel

On Wed, 2011-12-14 at 15:48 +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build
> (powerpc_ppc64_defconfig) failed like this:
> 
> In file included from include/linux/slab.h:185:0,
>                  from include/linux/kref.h:19,
>                  from include/linux/kobject.h:24,
>                  from include/linux/sysdev.h:24,
>                  from include/linux/node.h:17,
>                  from include/linux/swap.h:10,
>                  from include/linux/suspend.h:4,
>                  from arch/powerpc/kernel/asm-offsets.c:24:
> include/linux/slub_def.h:100:17: error: field 'kobj' has incomplete type
> 
> Caused by commit 4af679cd7cbb ("kref: Inline all functions") ... we now
> have kref.h -> slab.h -> slub_def.h -> kobject.h -> kref.h when
> CONFIG_SLUB is set.

Egads, that's nasty.. 

The nicest thing I can come up with is something like the below, but its
not all that nice at all :/



---
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -16,7 +16,8 @@
 #define _KREF_H_
 
 #include <linux/types.h>
-#include <linux/slab.h>
+
+extern void kfree(const void *);
 
 struct kref {
 	atomic_t refcount;

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2011-12-14  4:48 Stephen Rothwell
  2011-12-14  9:24 ` Peter Zijlstra
  0 siblings, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2011-12-14  4:48 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Peter Zijlstra


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

Hi Greg,

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

In file included from include/linux/slab.h:185:0,
                 from include/linux/kref.h:19,
                 from include/linux/kobject.h:24,
                 from include/linux/sysdev.h:24,
                 from include/linux/node.h:17,
                 from include/linux/swap.h:10,
                 from include/linux/suspend.h:4,
                 from arch/powerpc/kernel/asm-offsets.c:24:
include/linux/slub_def.h:100:17: error: field 'kobj' has incomplete type

Caused by commit 4af679cd7cbb ("kref: Inline all functions") ... we now
have kref.h -> slab.h -> slub_def.h -> kobject.h -> kref.h when
CONFIG_SLUB is set.

I have used the driver-core tree from next-20111213 for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2011-11-21  1:57 Stephen Rothwell
  0 siblings, 0 replies; 127+ messages in thread
From: Stephen Rothwell @ 2011-11-21  1:57 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Alessandro Rubini


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

Hi Greg,

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

fs/debugfs/file.c: In function 'debugfs_print_regs32':
fs/debugfs/file.c:560:7: error: implicit declaration of function 'readl' [-Werror=implicit-function-declaration]

Caused by commit 1a087c6ad975 ("debugfs: add tools to printk 32-bit
registers"). To use readl(), linux/io.h should be included.

I have used the driver-core tree from next-20111118 for today.

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

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-08-04  4:25 Stephen Rothwell
  2010-08-04  4:44 ` Guenter Roeck
  2010-08-04 15:52 ` Greg KH
@ 2010-08-04 21:24 ` Jesse Barnes
  2 siblings, 0 replies; 127+ messages in thread
From: Jesse Barnes @ 2010-08-04 21:24 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Greg KH, linux-next, linux-kernel, Narendra K, Jordan Hargrave,
	Guenter Roeck

On Wed, 4 Aug 2010 14:25:31 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/pci/pci-label.c:100: error: unknown field 'owner' specified in initializer
> drivers/pci/pci-label.c:100: warning: initialization from incompatible pointer type
> drivers/pci/pci-label.c:105: error: unknown field 'owner' specified in initializer
> drivers/pci/pci-label.c:105: warning: initialization from incompatible pointer type
> 
> Caused by commit 60cc62ad579afa0eb5bded82e08dd0617d461d52 ("sysfs: Remove
> owner field from sysfs struct attribute") interacting with commit
> 911e1c9b05a8e3559a7aa89083930700a0b9e7ee ("PCI: export SMBIOS provided
> firmware instance and label to sysfs") from the pci tree.
> 
> I applied the following merge fix patch (Jesse, this patch can already be
> applied to the pci tree without problems):
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 4 Aug 2010 14:21:42 +1000
> Subject: [PATCH] pci: update for owner removal from struct device_attribute
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Applied, thanks.

-- 
Jesse Barnes, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-08-04  4:25 Stephen Rothwell
  2010-08-04  4:44 ` Guenter Roeck
@ 2010-08-04 15:52 ` Greg KH
  2010-08-04 21:24 ` Jesse Barnes
  2 siblings, 0 replies; 127+ messages in thread
From: Greg KH @ 2010-08-04 15:52 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Narendra K, Jordan Hargrave,
	Jesse Barnes, Guenter Roeck

On Wed, Aug 04, 2010 at 02:25:31PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/pci/pci-label.c:100: error: unknown field 'owner' specified in initializer
> drivers/pci/pci-label.c:100: warning: initialization from incompatible pointer type
> drivers/pci/pci-label.c:105: error: unknown field 'owner' specified in initializer
> drivers/pci/pci-label.c:105: warning: initialization from incompatible pointer type
> 
> Caused by commit 60cc62ad579afa0eb5bded82e08dd0617d461d52 ("sysfs: Remove
> owner field from sysfs struct attribute") interacting with commit
> 911e1c9b05a8e3559a7aa89083930700a0b9e7ee ("PCI: export SMBIOS provided
> firmware instance and label to sysfs") from the pci tree.
> 
> I applied the following merge fix patch (Jesse, this patch can already be
> applied to the pci tree without problems):

Thanks, your fix looks correct, that field is now gone.

greg k-h

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-08-04  4:25 Stephen Rothwell
@ 2010-08-04  4:44 ` Guenter Roeck
  2010-08-04 15:52 ` Greg KH
  2010-08-04 21:24 ` Jesse Barnes
  2 siblings, 0 replies; 127+ messages in thread
From: Guenter Roeck @ 2010-08-04  4:44 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Greg KH, linux-next, linux-kernel, Narendra K, Jordan Hargrave,
	Jesse Barnes

On Wed, Aug 04, 2010 at 12:25:31AM -0400, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/pci/pci-label.c:100: error: unknown field 'owner' specified in initializer
> drivers/pci/pci-label.c:100: warning: initialization from incompatible pointer type
> drivers/pci/pci-label.c:105: error: unknown field 'owner' specified in initializer
> drivers/pci/pci-label.c:105: warning: initialization from incompatible pointer type
> 
> Caused by commit 60cc62ad579afa0eb5bded82e08dd0617d461d52 ("sysfs: Remove
> owner field from sysfs struct attribute") interacting with commit
> 911e1c9b05a8e3559a7aa89083930700a0b9e7ee ("PCI: export SMBIOS provided
> firmware instance and label to sysfs") from the pci tree.
> 
> I applied the following merge fix patch (Jesse, this patch can already be
> applied to the pci tree without problems):
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 4 Aug 2010 14:21:42 +1000
> Subject: [PATCH] pci: update for owner removal from struct device_attribute
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>

Sorry for the trouble. Looks like I missed that by a day.

Guenter

> ---
>  drivers/pci/pci-label.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
> index 111500e..90c0a72 100644
> --- a/drivers/pci/pci-label.c
> +++ b/drivers/pci/pci-label.c
> @@ -97,12 +97,12 @@ smbiosinstance_show(struct device *dev,
>  }
>  
>  static struct device_attribute smbios_attr_label = {
> -	.attr = {.name = "label", .mode = 0444, .owner = THIS_MODULE},
> +	.attr = {.name = "label", .mode = 0444},
>  	.show = smbioslabel_show,
>  };
>  
>  static struct device_attribute smbios_attr_instance = {
> -	.attr = {.name = "index", .mode = 0444, .owner = THIS_MODULE},
> +	.attr = {.name = "index", .mode = 0444},
>  	.show = smbiosinstance_show,
>  };
>  
> -- 
> 1.7.1
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2010-08-04  4:25 Stephen Rothwell
  2010-08-04  4:44 ` Guenter Roeck
                   ` (2 more replies)
  0 siblings, 3 replies; 127+ messages in thread
From: Stephen Rothwell @ 2010-08-04  4:25 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-next, linux-kernel, Narendra K, Jordan Hargrave,
	Jesse Barnes, Guenter Roeck

Hi Greg,

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

drivers/pci/pci-label.c:100: error: unknown field 'owner' specified in initializer
drivers/pci/pci-label.c:100: warning: initialization from incompatible pointer type
drivers/pci/pci-label.c:105: error: unknown field 'owner' specified in initializer
drivers/pci/pci-label.c:105: warning: initialization from incompatible pointer type

Caused by commit 60cc62ad579afa0eb5bded82e08dd0617d461d52 ("sysfs: Remove
owner field from sysfs struct attribute") interacting with commit
911e1c9b05a8e3559a7aa89083930700a0b9e7ee ("PCI: export SMBIOS provided
firmware instance and label to sysfs") from the pci tree.

I applied the following merge fix patch (Jesse, this patch can already be
applied to the pci tree without problems):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 4 Aug 2010 14:21:42 +1000
Subject: [PATCH] pci: update for owner removal from struct device_attribute

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/pci/pci-label.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
index 111500e..90c0a72 100644
--- a/drivers/pci/pci-label.c
+++ b/drivers/pci/pci-label.c
@@ -97,12 +97,12 @@ smbiosinstance_show(struct device *dev,
 }
 
 static struct device_attribute smbios_attr_label = {
-	.attr = {.name = "label", .mode = 0444, .owner = THIS_MODULE},
+	.attr = {.name = "label", .mode = 0444},
 	.show = smbioslabel_show,
 };
 
 static struct device_attribute smbios_attr_instance = {
-	.attr = {.name = "index", .mode = 0444, .owner = THIS_MODULE},
+	.attr = {.name = "index", .mode = 0444},
 	.show = smbiosinstance_show,
 };
 
-- 
1.7.1

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-05-18 21:25   ` Greg KH
@ 2010-05-18 21:59     ` Eric W. Biederman
  0 siblings, 0 replies; 127+ messages in thread
From: Eric W. Biederman @ 2010-05-18 21:59 UTC (permalink / raw)
  To: Greg KH; +Cc: Stephen Rothwell, linux-next, linux-kernel, Al Viro

Greg KH <greg@kroah.com> writes:

> On Tue, May 18, 2010 at 12:58:33PM -0700, Eric W. Biederman wrote:
>> 
>> Greg this fixes the conflict with the vfs tree we see in linux-next.
>
> Thanks, I can apply this to my tree right now, right?

Yes it is safe to apply to your tree right now.  Apologies if that
wasn't clear.

Eric

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-05-18 19:58 ` Eric W. Biederman
@ 2010-05-18 21:25   ` Greg KH
  2010-05-18 21:59     ` Eric W. Biederman
  0 siblings, 1 reply; 127+ messages in thread
From: Greg KH @ 2010-05-18 21:25 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: Stephen Rothwell, linux-next, linux-kernel, Al Viro

On Tue, May 18, 2010 at 12:58:33PM -0700, Eric W. Biederman wrote:
> 
> Greg this fixes the conflict with the vfs tree we see in linux-next.

Thanks, I can apply this to my tree right now, right?

greg k-h

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-05-18 21:06   ` Chris Wright
@ 2010-05-18 21:24     ` Greg KH
  0 siblings, 0 replies; 127+ messages in thread
From: Greg KH @ 2010-05-18 21:24 UTC (permalink / raw)
  To: Chris Wright; +Cc: Stephen Rothwell, linux-next, linux-kernel

On Tue, May 18, 2010 at 02:06:07PM -0700, Chris Wright wrote:
> * Greg KH (greg@kroah.com) wrote:
> > On Tue, May 18, 2010 at 04:44:09PM +1000, Stephen Rothwell wrote:
> > > Hi Greg,
> > > 
> > > After merging the driver-core tree, today's linux-next build (powerpc
> > > ppc64_defconfig) failed like this:
> > > 
> > > cc1: warnings being treated as errors
> > > In file included from include/linux/kobject.h:21,
> > >                  from include/linux/device.h:17,
> > >                  from arch/powerpc/lib/devres.c:10:
> > > include/linux/sysfs.h:97: error: 'struct file' declared inside parameter list
> > > include/linux/sysfs.h:97: error: its scope is only this definition or declaration, which is probably not what you want
> > > include/linux/sysfs.h:99: error: 'struct file' declared inside parameter list
> > > include/linux/sysfs.h:101: error: 'struct file' declared inside parameter list
> > > 
> > > and many more (arch/powerpc is built with -Werror (as do some other
> > > architectures)) and lots of similar warnings ...
> > > 
> > > Caused by commit f8e898186196a22756b50b908ecd92123265f8a2 ("sysfs: add
> > > struct file* to bin_attr callbacks").   See Rule 1 in
> > > Documentation/SubmitChecklist.  The header file probably just needs
> > > "struct file;" added in the right place.
> > > 
> > > I have reverted that commit for today (and commit
> > > 44e425ab9f887ec6d3a7a4481f3b0c99f120de19 ("pci: check caps from sysfs
> > > file open to read device dependent config space") that depends on it).
> > 
> > Ick.
> > 
> > Chris, care to send a patch to resolve this?
> 
> Would you prefer incremental to fold in, or respin?  It's just this
> one-liner fwd declaration as Stephen mentioned.

Incremental to fold in is easier.  That way there's no build error in
the tree.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-05-18 14:02 ` Greg KH
  2010-05-18 14:04   ` Chris Wright
@ 2010-05-18 21:06   ` Chris Wright
  2010-05-18 21:24     ` Greg KH
  1 sibling, 1 reply; 127+ messages in thread
From: Chris Wright @ 2010-05-18 21:06 UTC (permalink / raw)
  To: Greg KH; +Cc: Stephen Rothwell, Chris Wright, linux-next, linux-kernel

* Greg KH (greg@kroah.com) wrote:
> On Tue, May 18, 2010 at 04:44:09PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > After merging the driver-core tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > cc1: warnings being treated as errors
> > In file included from include/linux/kobject.h:21,
> >                  from include/linux/device.h:17,
> >                  from arch/powerpc/lib/devres.c:10:
> > include/linux/sysfs.h:97: error: 'struct file' declared inside parameter list
> > include/linux/sysfs.h:97: error: its scope is only this definition or declaration, which is probably not what you want
> > include/linux/sysfs.h:99: error: 'struct file' declared inside parameter list
> > include/linux/sysfs.h:101: error: 'struct file' declared inside parameter list
> > 
> > and many more (arch/powerpc is built with -Werror (as do some other
> > architectures)) and lots of similar warnings ...
> > 
> > Caused by commit f8e898186196a22756b50b908ecd92123265f8a2 ("sysfs: add
> > struct file* to bin_attr callbacks").   See Rule 1 in
> > Documentation/SubmitChecklist.  The header file probably just needs
> > "struct file;" added in the right place.
> > 
> > I have reverted that commit for today (and commit
> > 44e425ab9f887ec6d3a7a4481f3b0c99f120de19 ("pci: check caps from sysfs
> > file open to read device dependent config space") that depends on it).
> 
> Ick.
> 
> Chris, care to send a patch to resolve this?

Would you prefer incremental to fold in, or respin?  It's just this
one-liner fwd declaration as Stephen mentioned.

thanks,
-chris

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-05-18  6:45 Stephen Rothwell
  2010-05-18  7:00 ` Eric W. Biederman
@ 2010-05-18 19:58 ` Eric W. Biederman
  2010-05-18 21:25   ` Greg KH
  1 sibling, 1 reply; 127+ messages in thread
From: Eric W. Biederman @ 2010-05-18 19:58 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel, Al Viro


Greg this fixes the conflict with the vfs tree we see in linux-next.

Al I will be happy to work with you to rework this hunk of code in the
next cycle so you can kill sb_lock.  It is just too late in the cycle
to be making more than the minimal change necessary.

Eric

From: Eric W. Biederman <ebiederm@aristanetworks.com>
Date: Tue, 18 May 2010 12:24:26 -0700
Subject: [PATCH] sysfs:  Remove usage of S_BIAS to avoid merge conflict with the vfs tree

In Al's latest vfs tree the code is reworked and S_BIAS has been removed.

It turns out that checking to see if a super block is in the
middle of an unmount in sysfs_exit_ns is unnecessary because we
remove the super_block from the s_supers/s_instances list before
struct sysfs_super_info pointed to by sb->s_fs_info is freed.

For now just delete the unnecessary check to see if a superblock is in the
middle of an unmount, it isn't necessary with or without Al's changes
and it just causes a needless conflict.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
---
 fs/sysfs/mount.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/fs/sysfs/mount.c b/fs/sysfs/mount.c
index bbba090..74f0529 100644
--- a/fs/sysfs/mount.c
+++ b/fs/sysfs/mount.c
@@ -144,6 +144,9 @@ static void sysfs_kill_sb(struct super_block *sb)
 {
 	struct sysfs_super_info *info = sysfs_info(sb);
 
+	/* Remove the superblock from fs_supers/s_instances
+	 * so we can't find it, before freeing sysfs_super_info.
+	 */
 	kill_anon_super(sb);
 	kfree(info);
 }
@@ -162,9 +165,11 @@ void sysfs_exit_ns(enum kobj_ns_type type, const void *ns)
 	spin_lock(&sb_lock);
 	list_for_each_entry(sb, &sysfs_fs_type.fs_supers, s_instances) {
 		struct sysfs_super_info *info = sysfs_info(sb);
-		/* Ignore superblocks that are in the process of unmounting */
-		if (sb->s_count <= S_BIAS)
-			continue;
+		/*
+		 * If we see a superblock on the fs_supers/s_instances
+		 * list the unmount has not completed and sb->s_fs_info
+		 * points to a valid struct sysfs_super_info.
+		 */
 		/* Ignore superblocks with the wrong ns */
 		if (info->ns[type] != ns)
 			continue;
-- 
1.6.6.1

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-05-18 10:35     ` Eric W. Biederman
@ 2010-05-18 15:02       ` Al Viro
  0 siblings, 0 replies; 127+ messages in thread
From: Al Viro @ 2010-05-18 15:02 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: Stephen Rothwell, Greg KH, linux-next, linux-kernel

On Tue, May 18, 2010 at 03:35:10AM -0700, Eric W. Biederman wrote:
> Thanks.
> 
> I will cook up a proper incremental patch after I get some sleep.  Stephen
> it appears those two lines you have commented out are actually unnecessary.
> 
> We have
> deactivate_super
>   kill_sb aka sysfs_kill_sb
>     kill_anon_super
>       generic_shutdown_super
>          sb_lock
>          list_del(sb->s_instances)
>          sb_unlock
>   kfree(info)
> 
> Nothing generic stomps on s_fs_info.
> 
> Which means that if I find a superblock on sb->s_instances sb->s_fs_info
> still points to a valid sysfs_super_info.

Except that sb_lock is going away next cycle.  There are very few users left
outside of fs/super.c and I'd much prefer it to become static.

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-05-18 14:02 ` Greg KH
@ 2010-05-18 14:04   ` Chris Wright
  2010-05-18 21:06   ` Chris Wright
  1 sibling, 0 replies; 127+ messages in thread
From: Chris Wright @ 2010-05-18 14:04 UTC (permalink / raw)
  To: Greg KH; +Cc: Stephen Rothwell, Chris Wright, linux-next, linux-kernel

* Greg KH (greg@kroah.com) wrote:
> On Tue, May 18, 2010 at 04:44:09PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > After merging the driver-core tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > cc1: warnings being treated as errors
> > In file included from include/linux/kobject.h:21,
> >                  from include/linux/device.h:17,
> >                  from arch/powerpc/lib/devres.c:10:
> > include/linux/sysfs.h:97: error: 'struct file' declared inside parameter list
> > include/linux/sysfs.h:97: error: its scope is only this definition or declaration, which is probably not what you want
> > include/linux/sysfs.h:99: error: 'struct file' declared inside parameter list
> > include/linux/sysfs.h:101: error: 'struct file' declared inside parameter list
> > 
> > and many more (arch/powerpc is built with -Werror (as do some other
> > architectures)) and lots of similar warnings ...
> > 
> > Caused by commit f8e898186196a22756b50b908ecd92123265f8a2 ("sysfs: add
> > struct file* to bin_attr callbacks").   See Rule 1 in
> > Documentation/SubmitChecklist.  The header file probably just needs
> > "struct file;" added in the right place.
> > 
> > I have reverted that commit for today (and commit
> > 44e425ab9f887ec6d3a7a4481f3b0c99f120de19 ("pci: check caps from sysfs
> > file open to read device dependent config space") that depends on it).
> 
> Ick.
> 
> Chris, care to send a patch to resolve this?

Yeah, I'll see where the header is missing.

thanks,
-chris

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-05-18  6:44 Stephen Rothwell
@ 2010-05-18 14:02 ` Greg KH
  2010-05-18 14:04   ` Chris Wright
  2010-05-18 21:06   ` Chris Wright
  0 siblings, 2 replies; 127+ messages in thread
From: Greg KH @ 2010-05-18 14:02 UTC (permalink / raw)
  To: Stephen Rothwell, Chris Wright; +Cc: linux-next, linux-kernel

On Tue, May 18, 2010 at 04:44:09PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> cc1: warnings being treated as errors
> In file included from include/linux/kobject.h:21,
>                  from include/linux/device.h:17,
>                  from arch/powerpc/lib/devres.c:10:
> include/linux/sysfs.h:97: error: 'struct file' declared inside parameter list
> include/linux/sysfs.h:97: error: its scope is only this definition or declaration, which is probably not what you want
> include/linux/sysfs.h:99: error: 'struct file' declared inside parameter list
> include/linux/sysfs.h:101: error: 'struct file' declared inside parameter list
> 
> and many more (arch/powerpc is built with -Werror (as do some other
> architectures)) and lots of similar warnings ...
> 
> Caused by commit f8e898186196a22756b50b908ecd92123265f8a2 ("sysfs: add
> struct file* to bin_attr callbacks").   See Rule 1 in
> Documentation/SubmitChecklist.  The header file probably just needs
> "struct file;" added in the right place.
> 
> I have reverted that commit for today (and commit
> 44e425ab9f887ec6d3a7a4481f3b0c99f120de19 ("pci: check caps from sysfs
> file open to read device dependent config space") that depends on it).

Ick.

Chris, care to send a patch to resolve this?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-05-18  7:54   ` Stephen Rothwell
@ 2010-05-18 10:35     ` Eric W. Biederman
  2010-05-18 15:02       ` Al Viro
  0 siblings, 1 reply; 127+ messages in thread
From: Eric W. Biederman @ 2010-05-18 10:35 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel, Al Viro

Stephen Rothwell <sfr@canb.auug.org.au> writes:

> Hi Eric,
>
> On Tue, 18 May 2010 00:00:01 -0700 ebiederm@xmission.com (Eric W. Biederman) wrote:
>>
>> Stephen what is the easiest way to get a copy of Al's tree so I can take
>> a look to see what needs to happen?
>
> It is here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git#for-next
>
> [The latest list of trees included in linux-next can always be found here:
> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=Next/Trees]

Thanks.

I will cook up a proper incremental patch after I get some sleep.  Stephen
it appears those two lines you have commented out are actually unnecessary.

We have
deactivate_super
  kill_sb aka sysfs_kill_sb
    kill_anon_super
      generic_shutdown_super
         sb_lock
         list_del(sb->s_instances)
         sb_unlock
  kfree(info)

Nothing generic stomps on s_fs_info.

Which means that if I find a superblock on sb->s_instances sb->s_fs_info
still points to a valid sysfs_super_info.





As as for the race Al mentions between sysfs_exit_ns and
sysfs_readdir, I looked and a small race has crept in.  The primary
prevention of problems is that all matching sysfs_dirents for that
namespace are required to be removed before sysfs_exit_ns is called.

What remains is the tiniest of races where a namespace structure is
freed and a new namespace structure of the same type is allocated at
the same address and sysfs_dirents for it are created, all during the
a single kernel readdir operation.  Possible with slabs, and
copy_to_user triggering a page fault.  Still the worst case is that we
tell userspace some name that it wasn't supposed to see on that mount
point.  From a userspace point of view this seems to fall under a
readdir implementations license to return some odd things if the
directory is changing during the readdir call.  Overall we do preserve
the property of returning everything that is in the directory between
opendir and the time readdir his the end of file.

Eric

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-05-18  7:00 ` Eric W. Biederman
  2010-05-18  7:48   ` Al Viro
@ 2010-05-18  7:54   ` Stephen Rothwell
  2010-05-18 10:35     ` Eric W. Biederman
  1 sibling, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2010-05-18  7:54 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: Greg KH, linux-next, linux-kernel, Al Viro


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

Hi Eric,

On Tue, 18 May 2010 00:00:01 -0700 ebiederm@xmission.com (Eric W. Biederman) wrote:
>
> Stephen what is the easiest way to get a copy of Al's tree so I can take
> a look to see what needs to happen?

It is here:

git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git#for-next

[The latest list of trees included in linux-next can always be found here:
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=Next/Trees]

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

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-05-18  7:00 ` Eric W. Biederman
@ 2010-05-18  7:48   ` Al Viro
  2010-05-18  7:54   ` Stephen Rothwell
  1 sibling, 0 replies; 127+ messages in thread
From: Al Viro @ 2010-05-18  7:48 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: Stephen Rothwell, Greg KH, linux-next, linux-kernel

On Tue, May 18, 2010 at 12:00:01AM -0700, Eric W. Biederman wrote:
> Stephen Rothwell <sfr@canb.auug.org.au> writes:
> 
> > Hi Greg,
> >
> > After merging the driver-core tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > fs/sysfs/mount.c: In function 'sysfs_exit_ns':
> > fs/sysfs/mount.c:160: error: 'S_BIAS' undeclared (first use in this function)
> >
> > Caused by commit c80e63f000aa7cf73a430b2cb57dbbb91554a847 ("sysfs:
> > Implement sysfs tagged directory support") from the driver-core tree
> > interacting with commit f3ffc7acb6a6ebec0a9e660d9211ed048d7e90f5 ("get
> > rid of S_BIAS") from the vfs tree.
> >
> > I don't know how to fix this, so I just commented the code out for now
> > (see below). Please someone supply a correct fix.
> >
> > [Al, I notice that the "get rid of S_BIAS" patch has an author date of
> > March 22 - it would have been nice if it had been in linux-next during
> > the last two months so that we could have had a fix for this some time
> > ago.]
> 
> Stephen what is the easiest way to get a copy of Al's tree so I can take
> a look to see what needs to happen?

What needs to happen is the end of s_instances abuse in there.  If you
do something to all your sysfs_super_info instances, put those into a
list of its own.  What seems to be done there is blind "slap NULL at
that member in all those structures, no matter what might be going on".
Since the only thing you apparently care about is that sb->s_fs_info won't
disappear under you...

I really wonder what you intend to happen with readdir/sysfs_exit_ns races,
but that's a separate question.  Note that there you drop all locks many
times (and don't get me started on the amount of contention in sysfs), you
have no protection against old info->ns[...] contents getting stale, AFAICS.

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-05-18  6:45 Stephen Rothwell
@ 2010-05-18  7:00 ` Eric W. Biederman
  2010-05-18  7:48   ` Al Viro
  2010-05-18  7:54   ` Stephen Rothwell
  2010-05-18 19:58 ` Eric W. Biederman
  1 sibling, 2 replies; 127+ messages in thread
From: Eric W. Biederman @ 2010-05-18  7:00 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel, Al Viro

Stephen Rothwell <sfr@canb.auug.org.au> writes:

> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/sysfs/mount.c: In function 'sysfs_exit_ns':
> fs/sysfs/mount.c:160: error: 'S_BIAS' undeclared (first use in this function)
>
> Caused by commit c80e63f000aa7cf73a430b2cb57dbbb91554a847 ("sysfs:
> Implement sysfs tagged directory support") from the driver-core tree
> interacting with commit f3ffc7acb6a6ebec0a9e660d9211ed048d7e90f5 ("get
> rid of S_BIAS") from the vfs tree.
>
> I don't know how to fix this, so I just commented the code out for now
> (see below). Please someone supply a correct fix.
>
> [Al, I notice that the "get rid of S_BIAS" patch has an author date of
> March 22 - it would have been nice if it had been in linux-next during
> the last two months so that we could have had a fix for this some time
> ago.]

Stephen what is the easiest way to get a copy of Al's tree so I can take
a look to see what needs to happen?

Eric

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2010-05-18  6:45 Stephen Rothwell
  2010-05-18  7:00 ` Eric W. Biederman
  2010-05-18 19:58 ` Eric W. Biederman
  0 siblings, 2 replies; 127+ messages in thread
From: Stephen Rothwell @ 2010-05-18  6:45 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Eric W. Biederman, Al Viro

Hi Greg,

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

fs/sysfs/mount.c: In function 'sysfs_exit_ns':
fs/sysfs/mount.c:160: error: 'S_BIAS' undeclared (first use in this function)

Caused by commit c80e63f000aa7cf73a430b2cb57dbbb91554a847 ("sysfs:
Implement sysfs tagged directory support") from the driver-core tree
interacting with commit f3ffc7acb6a6ebec0a9e660d9211ed048d7e90f5 ("get
rid of S_BIAS") from the vfs tree.

I don't know how to fix this, so I just commented the code out for now
(see below). Please someone supply a correct fix.

[Al, I notice that the "get rid of S_BIAS" patch has an author date of
March 22 - it would have been nice if it had been in linux-next during
the last two months so that we could have had a fix for this some time
ago.]
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 18 May 2010 16:36:22 +1000
Subject: [PATCH] sysfs: fix for S_BIAS going away

Not a real fix, but it lets the code build.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/sysfs/mount.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/sysfs/mount.c b/fs/sysfs/mount.c
index 1afa32b..49258e1 100644
--- a/fs/sysfs/mount.c
+++ b/fs/sysfs/mount.c
@@ -150,22 +150,22 @@ static struct file_system_type sysfs_fs_type = {
 
 void sysfs_exit_ns(enum kobj_ns_type type, const void *ns)
 {
 	struct super_block *sb;
 
 	mutex_lock(&sysfs_mutex);
 	spin_lock(&sb_lock);
 	list_for_each_entry(sb, &sysfs_fs_type.fs_supers, s_instances) {
 		struct sysfs_super_info *info = sysfs_info(sb);
 		/* Ignore superblocks that are in the process of unmounting */
-		if (sb->s_count <= S_BIAS)
-			continue;
+//		if (sb->s_count <= S_BIAS)
+//			continue;
 		/* Ignore superblocks with the wrong ns */
 		if (info->ns[type] != ns)
 			continue;
 		info->ns[type] = NULL;
 	}
 	spin_unlock(&sb_lock);
 	mutex_unlock(&sysfs_mutex);
 }
 
 int __init sysfs_init(void)
-- 
1.7.1

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2010-05-18  6:44 Stephen Rothwell
  2010-05-18 14:02 ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2010-05-18  6:44 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Chris Wright


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

Hi Greg,

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

cc1: warnings being treated as errors
In file included from include/linux/kobject.h:21,
                 from include/linux/device.h:17,
                 from arch/powerpc/lib/devres.c:10:
include/linux/sysfs.h:97: error: 'struct file' declared inside parameter list
include/linux/sysfs.h:97: error: its scope is only this definition or declaration, which is probably not what you want
include/linux/sysfs.h:99: error: 'struct file' declared inside parameter list
include/linux/sysfs.h:101: error: 'struct file' declared inside parameter list

and many more (arch/powerpc is built with -Werror (as do some other
architectures)) and lots of similar warnings ...

Caused by commit f8e898186196a22756b50b908ecd92123265f8a2 ("sysfs: add
struct file* to bin_attr callbacks").   See Rule 1 in
Documentation/SubmitChecklist.  The header file probably just needs
"struct file;" added in the right place.

I have reverted that commit for today (and commit
44e425ab9f887ec6d3a7a4481f3b0c99f120de19 ("pci: check caps from sysfs
file open to read device dependent config space") that depends on it).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-03-24  1:37     ` Neil Brown
@ 2010-03-24 14:54       ` Sage Weil
  0 siblings, 0 replies; 127+ messages in thread
From: Sage Weil @ 2010-03-24 14:54 UTC (permalink / raw)
  To: Neil Brown; +Cc: Stephen Rothwell, Greg KH, linux-next, linux-kernel

On Wed, 24 Mar 2010, Neil Brown wrote:
> Sage Weil <sage@newdream.net> wrote:
> > > It is a pity that this code cannot use mempool_t....
> > > What if mempool_t were changed to only re-alloc the vector of pointers when
> > > it grew, or when it shrank to less than 1/2 it's current size.  Would that
> > > reduce the frequency of allocations enough for you to be comfortable with it? 
> > > i.e. always make the vector a power-of-2 size (which is what is probably
> > > allocated anyway) while the pool size might be less.
> > > ??
> > 
> > That would improve the situation, but still mean potentially large 
> > allocations (the pools can grow pretty big) that aren't strictly 
> > necessary.  I can imagine a more modular mempool_t with an ops vector for 
> > adding/removing from the pool to cope with situations like this, but I'm 
> > not sure it's worth the effort?
> 
> How big?
> mempools (and equivalents) should just be large enough to get you through a
> tight spot.  The working assumption is that they will not normally be used.
> So 2 or 3 should normally be plenty.
> 
> (looks at code)
> 
> The only time you resize a ceph_mempool is in ceph_monc_do_statfs
> where you increment it, perform a synchronous statfs call on the 
> network, then decrement the size of the mempool.
> How many concurrent statfs calls does it even make sense to make.
> I'm probably missing something obvious, but wouldn't it make sense to
> put that all under a mutex so there was only ever one outstanding statfs (per
> filesystem) - or maybe under a counting semaphore to allow some small number,
> and make sure to prime the mempool to cover that number.
> Then you would never resize a mempool at all.

You're right.  In fact, after reviewing the code again, it looks like 
_none_ of the msgpools (current or planned) needs to get large anymore.  
A protocol change a month or two back made it possible to allocate space 
for the reply along with the request, which means the only remaining use 
for the pools is for low memory writeout and the handful of messages we 
might receive from servers without asking for them.  (There used to be 
more of the msgpool resizing going on for other types of requests, but 
it's been mostly fixed up.)

I'll work on cleaning up the request/reply instances to avoid pools 
altogether.  The remaining pools should be small enough to use the 
standard mempool_t.

Thanks for looking into this!
sage

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-03-17 15:51   ` Sage Weil
  2010-03-17 22:30     ` Stephen Rothwell
@ 2010-03-24  1:37     ` Neil Brown
  2010-03-24 14:54       ` Sage Weil
  1 sibling, 1 reply; 127+ messages in thread
From: Neil Brown @ 2010-03-24  1:37 UTC (permalink / raw)
  To: Sage Weil; +Cc: Stephen Rothwell, Greg KH, linux-next, linux-kernel

On Wed, 17 Mar 2010 08:51:49 -0700 (PDT)
Sage Weil <sage@newdream.net> wrote:


> > It is a pity that this code cannot use mempool_t....
> > What if mempool_t were changed to only re-alloc the vector of pointers when
> > it grew, or when it shrank to less than 1/2 it's current size.  Would that
> > reduce the frequency of allocations enough for you to be comfortable with it? 
> > i.e. always make the vector a power-of-2 size (which is what is probably
> > allocated anyway) while the pool size might be less.
> > ??
> 
> That would improve the situation, but still mean potentially large 
> allocations (the pools can grow pretty big) that aren't strictly 
> necessary.  I can imagine a more modular mempool_t with an ops vector for 
> adding/removing from the pool to cope with situations like this, but I'm 
> not sure it's worth the effort?

How big?
mempools (and equivalents) should just be large enough to get you through a
tight spot.  The working assumption is that they will not normally be used.
So 2 or 3 should normally be plenty.

(looks at code)

The only time you resize a ceph_mempool is in ceph_monc_do_statfs
where you increment it, perform a synchronous statfs call on the 
network, then decrement the size of the mempool.
How many concurrent statfs calls does it even make sense to make.
I'm probably missing something obvious, but wouldn't it make sense to
put that all under a mutex so there was only ever one outstanding statfs (per
filesystem) - or maybe under a counting semaphore to allow some small number,
and make sure to prime the mempool to cover that number.
Then you would never resize a mempool at all.

I notice that all other mempools that ceph uses are sensibly quite small and
stay that way.

NeilBrown

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-03-17 15:51   ` Sage Weil
@ 2010-03-17 22:30     ` Stephen Rothwell
  2010-03-24  1:37     ` Neil Brown
  1 sibling, 0 replies; 127+ messages in thread
From: Stephen Rothwell @ 2010-03-17 22:30 UTC (permalink / raw)
  To: Sage Weil; +Cc: Neil Brown, Greg KH, linux-next, linux-kernel


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

Hi guys,

On Wed, 17 Mar 2010 08:51:49 -0700 (PDT) Sage Weil <sage@newdream.net> wrote:
>
> On Wed, 17 Mar 2010, Neil Brown wrote:
> 
> > I would say this is correct.
> 
> Yeah, the fix is good, thanks Stephen!  I'll add it to my tree shortly.

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

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-03-17  7:21 ` Neil Brown
@ 2010-03-17 15:51   ` Sage Weil
  2010-03-17 22:30     ` Stephen Rothwell
  2010-03-24  1:37     ` Neil Brown
  0 siblings, 2 replies; 127+ messages in thread
From: Sage Weil @ 2010-03-17 15:51 UTC (permalink / raw)
  To: Neil Brown; +Cc: Stephen Rothwell, Greg KH, linux-next, linux-kernel

On Wed, 17 Mar 2010, Neil Brown wrote:

> On Wed, 17 Mar 2010 15:41:45 +1100
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi Greg,
> > 
> > After merging the driver-core tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > fs/ceph/msgpool.c: In function 'ceph_msgpool_put':
> > fs/ceph/msgpool.c:173: error: implicit declaration of function 'kref_set'
> > 
> > Caused by commit 10c5d9fdc9ba89606b34f01cbe6ea287abba7395 ("kref: remove
> > kref_set") from the driver-core tree interacting with commit
> > c2e552e76e2c6907ca50cd9a4b747a2e2e8c615e ("ceph: use kref for ceph_msg")
> > from the ceph tree.
> > 
> > I applied the following patch for today (which may not be correct):
> 
> I would say this is correct.

Yeah, the fix is good, thanks Stephen!  I'll add it to my tree shortly.

> It is a pity that this code cannot use mempool_t....
> What if mempool_t were changed to only re-alloc the vector of pointers when
> it grew, or when it shrank to less than 1/2 it's current size.  Would that
> reduce the frequency of allocations enough for you to be comfortable with it? 
> i.e. always make the vector a power-of-2 size (which is what is probably
> allocated anyway) while the pool size might be less.
> ??

That would improve the situation, but still mean potentially large 
allocations (the pools can grow pretty big) that aren't strictly 
necessary.  I can imagine a more modular mempool_t with an ops vector for 
adding/removing from the pool to cope with situations like this, but I'm 
not sure it's worth the effort?

sage

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-03-17  4:41 Stephen Rothwell
@ 2010-03-17  7:21 ` Neil Brown
  2010-03-17 15:51   ` Sage Weil
  0 siblings, 1 reply; 127+ messages in thread
From: Neil Brown @ 2010-03-17  7:21 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel, Sage Weil

On Wed, 17 Mar 2010 15:41:45 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Greg,
> 
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> fs/ceph/msgpool.c: In function 'ceph_msgpool_put':
> fs/ceph/msgpool.c:173: error: implicit declaration of function 'kref_set'
> 
> Caused by commit 10c5d9fdc9ba89606b34f01cbe6ea287abba7395 ("kref: remove
> kref_set") from the driver-core tree interacting with commit
> c2e552e76e2c6907ca50cd9a4b747a2e2e8c615e ("ceph: use kref for ceph_msg")
> from the ceph tree.
> 
> I applied the following patch for today (which may not be correct):

I would say this is correct.

The msg has seen it's last_put and is being placed in the pool of
free messages, so it needs to be in the same state that ceph_msg_new
(called in __fill_msgpool) leaves it in.
ceph_msg_new used kref_init, so ceph_msgpool_put should use kref_init too to
match.

It is a pity that this code cannot use mempool_t....
What if mempool_t were changed to only re-alloc the vector of pointers when
it grew, or when it shrank to less than 1/2 it's current size.  Would that
reduce the frequency of allocations enough for you to be comfortable with it? 
i.e. always make the vector a power-of-2 size (which is what is probably
allocated anyway) while the pool size might be less.
??

NeilBrown

> 
> [Sage, if this patch is correct, it should be applied to the ceph tree.]
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 17 Mar 2010 15:35:22 +1100
> Subject: [PATCH] ceph: update for removal of kref_set
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/ceph/msgpool.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/fs/ceph/msgpool.c b/fs/ceph/msgpool.c
> index ca3b44a..030297f 100644
> --- a/fs/ceph/msgpool.c
> +++ b/fs/ceph/msgpool.c
> @@ -170,7 +170,7 @@ void ceph_msgpool_put(struct ceph_msgpool *pool, struct ceph_msg *msg)
>  		msg->front.iov_len = pool->front_len;
>  		msg->hdr.front_len = cpu_to_le32(pool->front_len);
>  
> -		kref_set(&msg->kref, 1);  /* retake a single ref */
> +		kref_init(&msg->kref);  /* retake a single ref */
>  		list_add(&msg->list_head, &pool->msgs);
>  		pool->num++;
>  		dout("msgpool_put %p reclaim %p, now %d/%d\n", pool, msg,

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2010-03-17  4:41 Stephen Rothwell
  2010-03-17  7:21 ` Neil Brown
  0 siblings, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2010-03-17  4:41 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Sage Weil, NeilBrown

Hi Greg,

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

fs/ceph/msgpool.c: In function 'ceph_msgpool_put':
fs/ceph/msgpool.c:173: error: implicit declaration of function 'kref_set'

Caused by commit 10c5d9fdc9ba89606b34f01cbe6ea287abba7395 ("kref: remove
kref_set") from the driver-core tree interacting with commit
c2e552e76e2c6907ca50cd9a4b747a2e2e8c615e ("ceph: use kref for ceph_msg")
from the ceph tree.

I applied the following patch for today (which may not be correct):

[Sage, if this patch is correct, it should be applied to the ceph tree.]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 17 Mar 2010 15:35:22 +1100
Subject: [PATCH] ceph: update for removal of kref_set

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/ceph/msgpool.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/ceph/msgpool.c b/fs/ceph/msgpool.c
index ca3b44a..030297f 100644
--- a/fs/ceph/msgpool.c
+++ b/fs/ceph/msgpool.c
@@ -170,7 +170,7 @@ void ceph_msgpool_put(struct ceph_msgpool *pool, struct ceph_msg *msg)
 		msg->front.iov_len = pool->front_len;
 		msg->hdr.front_len = cpu_to_le32(pool->front_len);
 
-		kref_set(&msg->kref, 1);  /* retake a single ref */
+		kref_init(&msg->kref);  /* retake a single ref */
 		list_add(&msg->list_head, &pool->msgs);
 		pool->num++;
 		dout("msgpool_put %p reclaim %p, now %d/%d\n", pool, msg,
-- 
1.7.0

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-03-03  6:14 Stephen Rothwell
@ 2010-03-03  6:31 ` Stephen Rothwell
  0 siblings, 0 replies; 127+ messages in thread
From: Stephen Rothwell @ 2010-03-03  6:31 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-next, linux-kernel, Johannes Berg, John W. Linville,
	Thomas Gleixner


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

Hi all,

On Wed, 3 Mar 2010 17:14:32 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> John, Johannes, device_lock/unlock() already exist in Linus' tree, so you
> should be able to apply this to the wireless tree already.

This is not correct, sorry.  I was thinking of something else.

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

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2010-03-03  6:14 Stephen Rothwell
  2010-03-03  6:31 ` Stephen Rothwell
  0 siblings, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2010-03-03  6:14 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-next, linux-kernel, Johannes Berg, John W. Linville,
	Thomas Gleixner

Hi Greg,

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

drivers/net/wireless/ath/ar9170/usb.c: In function 'ar9170_usb_firmware_failed':
drivers/net/wireless/ath/ar9170/usb.c:729: error: 'struct device' has no member named 'sem'
drivers/net/wireless/ath/ar9170/usb.c:732: error: 'struct device' has no member named 'sem'

Caused by commit 535765179fd4e8af26b69d2240d7ec33702a370a ("ar9170: load
firmware asynchronously") from the wireless tree interacting with
commitf989226577d096eb9ebbf95da1d0e8303ecc660c ("drivers/base: Convert
dev->sem to mutex") from the driver-core tree.

I applied the following patch for today.

John, Johannes, device_lock/unlock() already exist in Linus' tree, so you
should be able to apply this to the wireless tree already.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 3 Mar 2010 17:08:11 +1100
Subject: [PATCH] ar9170: fix for driver-core ABI change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/net/wireless/ath/ar9170/usb.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ar9170/usb.c b/drivers/net/wireless/ath/ar9170/usb.c
index 4e30197..7fc1034 100644
--- a/drivers/net/wireless/ath/ar9170/usb.c
+++ b/drivers/net/wireless/ath/ar9170/usb.c
@@ -41,6 +41,7 @@
 #include <linux/usb.h>
 #include <linux/firmware.h>
 #include <linux/etherdevice.h>
+#include <linux/mutex.h>
 #include <net/mac80211.h>
 #include "ar9170.h"
 #include "cmd.h"
@@ -726,10 +727,10 @@ static void ar9170_usb_firmware_failed(struct ar9170_usb *aru)
 
 	/* unbind anything failed */
 	if (parent)
-		down(&parent->sem);
+		device_lock(parent);
 	device_release_driver(&aru->udev->dev);
 	if (parent)
-		up(&parent->sem);
+		device_unlock(parent);
 }
 
 static void ar9170_usb_firmware_finish(const struct firmware *fw, void *context)
-- 
1.7.0

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

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-02-17  4:56   ` Greg KH
@ 2010-02-18  4:27     ` Greg KH
  0 siblings, 0 replies; 127+ messages in thread
From: Greg KH @ 2010-02-18  4:27 UTC (permalink / raw)
  To: Jean Delvare; +Cc: Stephen Rothwell, linux-next, linux-kernel, Thomas Gleixner

On Tue, Feb 16, 2010 at 08:56:16PM -0800, Greg KH wrote:
> On Tue, Feb 16, 2010 at 10:01:00AM +0100, Jean Delvare wrote:
> > Hi Stephen,
> > 
> > On Tue, 16 Feb 2010 17:39:26 +1100, Stephen Rothwell wrote:
> > > After merging the driver-core tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > > 
> > > drivers/i2c/i2c-smbus.c:58: error: 'struct device' has no member named 'sem'
> > > drivers/i2c/i2c-smbus.c:66: error: 'struct device' has no member named 'sem'
> > > 
> > > Caused by commit 0819a881db29059d113fc5f019f7c489dea5937d from the
> > > driver-core tree interacting with commit
> > > 38f1e8aedf0a238d56fbcd3660fc140b50dbc89a ("i2c: Add SMBus alert support")
> > > from the i2c tree.
> > > 
> > > I have applied the following patch for today and will use it as a merge
> > > fixup for the driver-core tree while necessary.
> > 
> > Thanks for the heads up and the fix. Greg, is there an API I am
> > supposed to use instead of accessing the device's semaphore/mutex
> > directly?
> 
> I will create a device_lock() and device_unlock() api to solve this
> problem.  That will fix the issue for when we try to change this from a
> semaphore to a mutex (like the patch in linux-next does), but we need to
> revert it due to lockdep issues that are being reported incorrectly.
> 
> For now, your code is fine, I'll change over your code in the .34 tree
> when the new api goes in.  I'll also drop this mutex patch in a day as
> well, because of the problems it has caused.

The functions are now in my tree, I'll fix up your code in the .34 merge
period.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-02-16  9:01 ` Jean Delvare
@ 2010-02-17  4:56   ` Greg KH
  2010-02-18  4:27     ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: Greg KH @ 2010-02-17  4:56 UTC (permalink / raw)
  To: Jean Delvare; +Cc: Stephen Rothwell, linux-next, linux-kernel, Thomas Gleixner

On Tue, Feb 16, 2010 at 10:01:00AM +0100, Jean Delvare wrote:
> Hi Stephen,
> 
> On Tue, 16 Feb 2010 17:39:26 +1100, Stephen Rothwell wrote:
> > After merging the driver-core tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > drivers/i2c/i2c-smbus.c:58: error: 'struct device' has no member named 'sem'
> > drivers/i2c/i2c-smbus.c:66: error: 'struct device' has no member named 'sem'
> > 
> > Caused by commit 0819a881db29059d113fc5f019f7c489dea5937d from the
> > driver-core tree interacting with commit
> > 38f1e8aedf0a238d56fbcd3660fc140b50dbc89a ("i2c: Add SMBus alert support")
> > from the i2c tree.
> > 
> > I have applied the following patch for today and will use it as a merge
> > fixup for the driver-core tree while necessary.
> 
> Thanks for the heads up and the fix. Greg, is there an API I am
> supposed to use instead of accessing the device's semaphore/mutex
> directly?

I will create a device_lock() and device_unlock() api to solve this
problem.  That will fix the issue for when we try to change this from a
semaphore to a mutex (like the patch in linux-next does), but we need to
revert it due to lockdep issues that are being reported incorrectly.

For now, your code is fine, I'll change over your code in the .34 tree
when the new api goes in.  I'll also drop this mutex patch in a day as
well, because of the problems it has caused.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 127+ messages in thread

* Re: linux-next: build failure after merge of the driver-core tree
  2010-02-16  6:39 Stephen Rothwell
@ 2010-02-16  9:01 ` Jean Delvare
  2010-02-17  4:56   ` Greg KH
  0 siblings, 1 reply; 127+ messages in thread
From: Jean Delvare @ 2010-02-16  9:01 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel, Thomas Gleixner

Hi Stephen,

On Tue, 16 Feb 2010 17:39:26 +1100, Stephen Rothwell wrote:
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/i2c/i2c-smbus.c:58: error: 'struct device' has no member named 'sem'
> drivers/i2c/i2c-smbus.c:66: error: 'struct device' has no member named 'sem'
> 
> Caused by commit 0819a881db29059d113fc5f019f7c489dea5937d from the
> driver-core tree interacting with commit
> 38f1e8aedf0a238d56fbcd3660fc140b50dbc89a ("i2c: Add SMBus alert support")
> from the i2c tree.
> 
> I have applied the following patch for today and will use it as a merge
> fixup for the driver-core tree while necessary.

Thanks for the heads up and the fix. Greg, is there an API I am
supposed to use instead of accessing the device's semaphore/mutex
directly?

-- 
Jean Delvare

^ permalink raw reply	[flat|nested] 127+ messages in thread

* linux-next: build failure after merge of the driver-core tree
@ 2010-02-16  6:39 Stephen Rothwell
  2010-02-16  9:01 ` Jean Delvare
  0 siblings, 1 reply; 127+ messages in thread
From: Stephen Rothwell @ 2010-02-16  6:39 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Thomas Gleixner, Jean Delvare

Hi Greg,

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

drivers/i2c/i2c-smbus.c:58: error: 'struct device' has no member named 'sem'
drivers/i2c/i2c-smbus.c:66: error: 'struct device' has no member named 'sem'

Caused by commit 0819a881db29059d113fc5f019f7c489dea5937d from the
driver-core tree interacting with commit
38f1e8aedf0a238d56fbcd3660fc140b50dbc89a ("i2c: Add SMBus alert support")
from the i2c tree.

I have applied the following patch for today and will use it as a merge
fixup for the driver-core tree while necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 16 Feb 2010 17:28:56 +1100
Subject: [PATCH] i2c: update for semaphore to mutex conversion of devices

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/i2c/i2c-smbus.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/i2c-smbus.c b/drivers/i2c/i2c-smbus.c
index 333527c..52aa775 100644
--- a/drivers/i2c/i2c-smbus.c
+++ b/drivers/i2c/i2c-smbus.c
@@ -27,6 +27,7 @@
 #include <linux/workqueue.h>
 #include <linux/i2c.h>
 #include <linux/i2c-smbus.h>
+#include <linux/mutex.h>
 
 struct i2c_smbus_alert {
 	unsigned int		alert_edge_triggered:1;
@@ -55,7 +56,7 @@ static int smbus_do_alert(struct device *dev, void *addrp)
 	 * Drivers should either disable alerts, or provide at least
 	 * a minimal handler.  Lock so client->driver won't change.
 	 */
-	down(&dev->sem);
+	mutex_lock(&dev->mutex);
 	if (client->driver) {
 		if (client->driver->alert)
 			client->driver->alert(client, data->flag);
@@ -63,7 +64,7 @@ static int smbus_do_alert(struct device *dev, void *addrp)
 			dev_warn(&client->dev, "no driver alert()!\n");
 	} else
 		dev_dbg(&client->dev, "alert with no driver\n");
-	up(&dev->sem);
+	mutex_unlock(&dev->mutex);
 
 	/* Stop iterating after we find the device */
 	return -EBUSY;
-- 
1.6.6.2

^ permalink raw reply	[flat|nested] 127+ messages in thread

end of thread, back to index

Thread overview: 127+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-27  6:55 linux-next: build failure after merge of the driver-core tree Stephen Rothwell
2020-07-27 10:17 ` Greg KH
2020-07-28 19:53   ` Kees Cook
  -- strict thread matches above, loose matches on Subject: below --
2019-09-18 17:09 Mark Brown
2019-09-18 18:52 ` Greg KH
2019-09-18 19:03   ` Linus Torvalds
2019-09-18 19:07     ` Greg KH
2019-09-18 20:56       ` Suzuki K Poulose
2019-09-18 21:55     ` Mark Brown
2019-08-29  7:35 Stephen Rothwell
2019-08-29 10:10 ` Greg KH
2019-02-01  2:41 Stephen Rothwell
2019-02-01 14:18 ` Greg KH
2017-06-13  6:04 Stephen Rothwell
2017-06-13  6:20 ` Greg KH
2017-06-13  6:25   ` Stephen Rothwell
2017-06-13  6:30   ` Sergey Senozhatsky
2016-05-02  5:42 Stephen Rothwell
2016-05-02 11:40 ` William Breathitt Gray
2016-05-02 14:47   ` Greg KH
2015-05-21  7:52 Stephen Rothwell
2014-12-01  7:49 Stephen Rothwell
2014-05-28  8:03 Stephen Rothwell
2014-05-28  9:30 ` Jean Delvare
2014-03-12  0:51 Mark Brown
2014-03-12  1:50 ` Greg KH
2014-03-12  3:55   ` Benjamin Herrenschmidt
2014-03-12 11:37     ` Mark Brown
2014-03-12 19:59       ` Benjamin Herrenschmidt
2014-03-12 20:02         ` Tejun Heo
2014-03-12 20:14           ` Benjamin Herrenschmidt
2014-03-12 20:21             ` Tejun Heo
2014-03-13  0:37               ` Benjamin Herrenschmidt
2014-03-13 22:14                 ` Benjamin Herrenschmidt
2014-03-14 13:00                   ` Tejun Heo
2014-03-15  0:03                   ` Greg KH
2014-03-15  2:57                     ` Benjamin Herrenschmidt
2014-03-15  5:29                       ` Greg KH
2014-03-15  7:14                         ` Benjamin Herrenschmidt
2014-03-16 23:16                         ` Stephen Rothwell
2014-03-17 18:36                           ` Greg KH
2014-03-16 23:16   ` Stephen Rothwell
2014-03-17 18:33     ` Greg KH
2014-03-17 20:33       ` Benjamin Herrenschmidt
2014-03-17 21:56         ` Greg KH
2014-03-17 22:05           ` Tejun Heo
2014-03-17 22:21             ` Tejun Heo
2014-03-18  0:07               ` Stewart Smith
2014-03-18  0:22               ` Benjamin Herrenschmidt
2014-03-18 15:58                 ` Tejun Heo
2014-03-18  0:00           ` Stewart Smith
2014-03-18  0:16           ` Benjamin Herrenschmidt
2014-03-17  8:28 ` Stephen Rothwell
2013-08-22  5:39 Stephen Rothwell
2013-08-22 15:36 ` Greg KH
2013-01-18  2:29 Stephen Rothwell
2013-01-18  4:13 ` Greg KH
2013-01-18 14:14   ` Kondratiev, Vladimir
2012-08-17  4:01 Stephen Rothwell
2012-08-17 13:25 ` Greg KH
2012-07-10  5:32 Stephen Rothwell
2012-07-10  9:03 ` Mark Brown
2012-07-10 11:14   ` Stephen Rothwell
2012-07-10 21:10     ` Linus Walleij
2012-05-01  4:59 Stephen Rothwell
2012-05-01  7:05 ` Bart Van Assche
2012-05-01 13:45 ` Greg KH
2012-04-19  4:48 Stephen Rothwell
2012-04-19 20:07 ` Greg KH
2012-04-20  2:19 ` Greg KH
2012-01-27  2:59 Stephen Rothwell
2012-01-27 15:24 ` Alan Stern
2012-01-27 22:36 ` Greg KH
2012-01-05  6:28 Stephen Rothwell
2012-01-05 23:20 ` Greg KH
2011-12-28  6:45 Stephen Rothwell
2012-01-03 16:21 ` Greg KH
2012-01-04  0:07   ` Kay Sievers
2012-01-04  0:31     ` Greg KH
2012-01-04 22:03       ` Kay Sievers
2012-01-04 23:13         ` Greg KH
2012-01-04 23:07 ` Greg KH
2012-01-04 23:48   ` Stephen Rothwell
2012-01-05  0:01     ` Kay Sievers
2012-01-05  0:17       ` Stephen Rothwell
2012-01-05  0:57       ` Josh Triplett
2011-12-15  6:37 Stephen Rothwell
2011-12-15  7:21 ` Greg KH
2011-12-15 10:10   ` Kay Sievers
2011-12-15 19:09     ` Greg KH
2011-12-14  4:48 Stephen Rothwell
2011-12-14  9:24 ` Peter Zijlstra
2011-12-14 15:03   ` Greg KH
2011-12-14 15:13     ` Peter Zijlstra
2011-12-14 17:01       ` Greg KH
2011-12-14 19:24         ` Greg KH
2011-11-21  1:57 Stephen Rothwell
2010-08-04  4:25 Stephen Rothwell
2010-08-04  4:44 ` Guenter Roeck
2010-08-04 15:52 ` Greg KH
2010-08-04 21:24 ` Jesse Barnes
2010-05-18  6:45 Stephen Rothwell
2010-05-18  7:00 ` Eric W. Biederman
2010-05-18  7:48   ` Al Viro
2010-05-18  7:54   ` Stephen Rothwell
2010-05-18 10:35     ` Eric W. Biederman
2010-05-18 15:02       ` Al Viro
2010-05-18 19:58 ` Eric W. Biederman
2010-05-18 21:25   ` Greg KH
2010-05-18 21:59     ` Eric W. Biederman
2010-05-18  6:44 Stephen Rothwell
2010-05-18 14:02 ` Greg KH
2010-05-18 14:04   ` Chris Wright
2010-05-18 21:06   ` Chris Wright
2010-05-18 21:24     ` Greg KH
2010-03-17  4:41 Stephen Rothwell
2010-03-17  7:21 ` Neil Brown
2010-03-17 15:51   ` Sage Weil
2010-03-17 22:30     ` Stephen Rothwell
2010-03-24  1:37     ` Neil Brown
2010-03-24 14:54       ` Sage Weil
2010-03-03  6:14 Stephen Rothwell
2010-03-03  6:31 ` Stephen Rothwell
2010-02-16  6:39 Stephen Rothwell
2010-02-16  9:01 ` Jean Delvare
2010-02-17  4:56   ` Greg KH
2010-02-18  4:27     ` Greg KH

Linux-Next Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \
		linux-next@vger.kernel.org
	public-inbox-index linux-next

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git