linux-next: driver-core tree build failure

linux-next: driver-core tree build failure

[Stephen Rothwell]

Hi Greg,

Today's linux-next build (x86_64 allmodconfig) failed like this:

drivers/mtd/mtdcore.c:220: error: expected '{' before 'const'
drivers/mtd/mtdcore.c:227: error: 'mtd_groups' undeclared here (not in a function)

Caused by the update to commit ba87b739a1f5dd545679d886b8d193cdede991cf
("driver model: constify attribute groups").

I have applied the patch below for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 14 Jul 2009 16:29:39 +1000
Subject: [PATCH] driver-core: fix for mtd typo

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

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 93e6731..05a16be 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -217,7 +217,7 @@ struct attribute_group mtd_group = {
 	.attrs		= mtd_attrs,
 };
 
-struct const attribute_group *mtd_groups[] = {
+const struct attribute_group *mtd_groups[] = {
 	&mtd_group,
 	NULL,
 };
-- 
1.6.3.3

Re: linux-next: driver-core tree build failure

[David Brownell]

On Monday 13 July 2009, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> drivers/mtd/mtdcore.c:220: error: expected '{' before 'const'
> drivers/mtd/mtdcore.c:227: error: 'mtd_groups' undeclared here (not in a function)
> 
> Caused by the update to commit ba87b739a1f5dd545679d886b8d193cdede991cf
> ("driver model: constify attribute groups").
> 
> I have applied the patch below for today.

That's a good patch, go with it.  Sorry; I guess this wasn't
the version I had test-built.  My eyes were reporting "static"
as the (expected) initial keyword there; they lied!


> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 14 Jul 2009 16:29:39 +1000
> Subject: [PATCH] driver-core: fix for mtd typo
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/mtd/mtdcore.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index 93e6731..05a16be 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -217,7 +217,7 @@ struct attribute_group mtd_group = {
>  	.attrs		= mtd_attrs,
>  };
>  
> -struct const attribute_group *mtd_groups[] = {
> +const struct attribute_group *mtd_groups[] = {
>  	&mtd_group,
>  	NULL,
>  };
> -- 
> 1.6.3.3
> 
> 

Re: linux-next: driver-core tree build failure

[Greg KH]

On Tue, Jul 14, 2009 at 12:31:27AM -0700, David Brownell wrote:
> On Monday 13 July 2009, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > 
> > drivers/mtd/mtdcore.c:220: error: expected '{' before 'const'
> > drivers/mtd/mtdcore.c:227: error: 'mtd_groups' undeclared here (not in a function)
> > 
> > Caused by the update to commit ba87b739a1f5dd545679d886b8d193cdede991cf
> > ("driver model: constify attribute groups").
> > 
> > I have applied the patch below for today.
> 
> That's a good patch, go with it.  Sorry; I guess this wasn't
> the version I had test-built.  My eyes were reporting "static"
> as the (expected) initial keyword there; they lied!

I've merged this with your original one, thanks.

greg k-h

Re: linux-next: driver-core tree build failure

[Greg KH]

On Tue, Jun 23, 2009 at 08:29:16AM -0700, Greg KH wrote:
> On Tue, Jun 23, 2009 at 04:01:00PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > Today's linux-next build (arm omap_osk_5912_defconfig) failed like this:
> > 
> > drivers/video/omap/omapfb_main.c: In function 'omapfb_show_caps_num':
> > drivers/video/omap/omapfb_main.c:1253: error: 'struct device' has no member named 'driver_data'
> > drivers/video/omap/omapfb_main.c: In function 'omapfb_show_caps_text':
> > drivers/video/omap/omapfb_main.c:1273: error: 'struct device' has no member named 'driver_data'
> > drivers/video/omap/omapfb_main.c: In function 'omapfb_show_panel_name':
> > drivers/video/omap/omapfb_main.c:1320: error: 'struct device' has no member named 'driver_data'
> > drivers/video/omap/omapfb_main.c: In function 'omapfb_show_bklight_level':
> > drivers/video/omap/omapfb_main.c:1329: error: 'struct device' has no member named 'driver_data'
> > drivers/video/omap/omapfb_main.c: In function 'omapfb_store_bklight_level':
> > drivers/video/omap/omapfb_main.c:1344: error: 'struct device' has no member named 'driver_data'
> > drivers/video/omap/omapfb_main.c: In function 'omapfb_show_bklight_max':
> > drivers/video/omap/omapfb_main.c:1363: error: 'struct device' has no member named 'driver_data'
> > drivers/video/omap/omapfb_main.c: In function 'omapfb_show_ctrl_name':
> > drivers/video/omap/omapfb_main.c:1396: error: 'struct device' has no member named 'driver_data'
> > 
> > Caused by commit 53d8ba57f16029a47ed5df9840ab6c3f9abd3727 ("Driver core:
> > move dev_get/set_drvdata to drivers/base/dd.c") from the driver-core tree.
> > 
> > I see more grepping in your future :-)
> 
> Heh, thanks, I got i386, x86-64, and ppc64 working properly this time
> around, but new things keep slipping in :)
> 
> I'll go resolve these as well.

Now fixed and pushed out.

thanks,

greg k-h

Re: linux-next: driver-core tree build failure

[Greg KH]

On Tue, Jun 23, 2009 at 04:01:00PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next build (arm omap_osk_5912_defconfig) failed like this:
> 
> drivers/video/omap/omapfb_main.c: In function 'omapfb_show_caps_num':
> drivers/video/omap/omapfb_main.c:1253: error: 'struct device' has no member named 'driver_data'
> drivers/video/omap/omapfb_main.c: In function 'omapfb_show_caps_text':
> drivers/video/omap/omapfb_main.c:1273: error: 'struct device' has no member named 'driver_data'
> drivers/video/omap/omapfb_main.c: In function 'omapfb_show_panel_name':
> drivers/video/omap/omapfb_main.c:1320: error: 'struct device' has no member named 'driver_data'
> drivers/video/omap/omapfb_main.c: In function 'omapfb_show_bklight_level':
> drivers/video/omap/omapfb_main.c:1329: error: 'struct device' has no member named 'driver_data'
> drivers/video/omap/omapfb_main.c: In function 'omapfb_store_bklight_level':
> drivers/video/omap/omapfb_main.c:1344: error: 'struct device' has no member named 'driver_data'
> drivers/video/omap/omapfb_main.c: In function 'omapfb_show_bklight_max':
> drivers/video/omap/omapfb_main.c:1363: error: 'struct device' has no member named 'driver_data'
> drivers/video/omap/omapfb_main.c: In function 'omapfb_show_ctrl_name':
> drivers/video/omap/omapfb_main.c:1396: error: 'struct device' has no member named 'driver_data'
> 
> Caused by commit 53d8ba57f16029a47ed5df9840ab6c3f9abd3727 ("Driver core:
> move dev_get/set_drvdata to drivers/base/dd.c") from the driver-core tree.
> 
> I see more grepping in your future :-)

Heh, thanks, I got i386, x86-64, and ppc64 working properly this time
around, but new things keep slipping in :)

I'll go resolve these as well.

thanks,

greg k-h

linux-next: driver-core tree build failure

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next build (arm omap_osk_5912_defconfig) failed like this:

drivers/video/omap/omapfb_main.c: In function 'omapfb_show_caps_num':
drivers/video/omap/omapfb_main.c:1253: error: 'struct device' has no member named 'driver_data'
drivers/video/omap/omapfb_main.c: In function 'omapfb_show_caps_text':
drivers/video/omap/omapfb_main.c:1273: error: 'struct device' has no member named 'driver_data'
drivers/video/omap/omapfb_main.c: In function 'omapfb_show_panel_name':
drivers/video/omap/omapfb_main.c:1320: error: 'struct device' has no member named 'driver_data'
drivers/video/omap/omapfb_main.c: In function 'omapfb_show_bklight_level':
drivers/video/omap/omapfb_main.c:1329: error: 'struct device' has no member named 'driver_data'
drivers/video/omap/omapfb_main.c: In function 'omapfb_store_bklight_level':
drivers/video/omap/omapfb_main.c:1344: error: 'struct device' has no member named 'driver_data'
drivers/video/omap/omapfb_main.c: In function 'omapfb_show_bklight_max':
drivers/video/omap/omapfb_main.c:1363: error: 'struct device' has no member named 'driver_data'
drivers/video/omap/omapfb_main.c: In function 'omapfb_show_ctrl_name':
drivers/video/omap/omapfb_main.c:1396: error: 'struct device' has no member named 'driver_data'

Caused by commit 53d8ba57f16029a47ed5df9840ab6c3f9abd3727 ("Driver core:
move dev_get/set_drvdata to drivers/base/dd.c") from the driver-core tree.

I see more grepping in your future :-)
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: driver-core tree build failure

[Stephen Rothwell]

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

Hi Greg,

On Tue, 12 May 2009 17:13:17 -0700 Greg KH <greg@kroah.com> wrote:
>
> I've now dropped the offending patch and will work to fix up the rest of
> these before adding it back.

Thanks for that.  I have refetched the driver-core and usb trees for
today's linux-next.

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

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

Re: linux-next: driver-core tree build failure

[Greg KH]

On Mon, May 11, 2009 at 09:05:18PM -0700, Greg KH wrote:
> On Tue, May 12, 2009 at 01:44:01PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > Today's linux-next build (powerpc_ppc64_defconfig) failed like this:
> > 
> > In file included from arch/powerpc/platforms/ps3/platform.h:28,
> >                  from arch/powerpc/platforms/ps3/mm.c:32:
> > arch/powerpc/include/asm/ps3.h: In function 'ps3_system_bus_set_driver_data':
> > arch/powerpc/include/asm/ps3.h:424: error: 'struct device' has no member named 'driver_data'
> > arch/powerpc/include/asm/ps3.h: In function 'ps3_system_bus_get_driver_data':
> > arch/powerpc/include/asm/ps3.h:429: error: 'struct device' has no member named 'driver_data'
> > 
> > Caused (obviously) by commit 9499952d8efc857406365bfc04079ff1e85660ff
> > ("Driver core: move dev_get/set_drvdata to drivers/base/dd.c") which I
> > have reverted.
> > 
> > Grep is your friend ...
> 
> Do you know how many false-positives there currently are for hitting
> driver_data?  It's insane...  I got 'make allmodconfig' working for
> i386, x86-64, and s390, and I thought ps3 as well, sorry about that.
> 
> > Actually there is a patch for this ...
> > http://patchwork.ozlabs.org/patch/27061/ ... also for another ...
> > http://patchwork.ozlabs.org/patch/27062/
> > 
> > Please leave the above commit out of the tree until you have at least
> > fixed all the in tree users.

I've now dropped the offending patch and will work to fix up the rest of
these before adding it back.

thanks,

greg k-h

Re: linux-next: driver-core tree build failure

[Greg KH]

On Tue, May 12, 2009 at 01:44:01PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next build (powerpc_ppc64_defconfig) failed like this:
> 
> In file included from arch/powerpc/platforms/ps3/platform.h:28,
>                  from arch/powerpc/platforms/ps3/mm.c:32:
> arch/powerpc/include/asm/ps3.h: In function 'ps3_system_bus_set_driver_data':
> arch/powerpc/include/asm/ps3.h:424: error: 'struct device' has no member named 'driver_data'
> arch/powerpc/include/asm/ps3.h: In function 'ps3_system_bus_get_driver_data':
> arch/powerpc/include/asm/ps3.h:429: error: 'struct device' has no member named 'driver_data'
> 
> Caused (obviously) by commit 9499952d8efc857406365bfc04079ff1e85660ff
> ("Driver core: move dev_get/set_drvdata to drivers/base/dd.c") which I
> have reverted.
> 
> Grep is your friend ...

Do you know how many false-positives there currently are for hitting
driver_data?  It's insane...  I got 'make allmodconfig' working for
i386, x86-64, and s390, and I thought ps3 as well, sorry about that.

> Actually there is a patch for this ...
> http://patchwork.ozlabs.org/patch/27061/ ... also for another ...
> http://patchwork.ozlabs.org/patch/27062/
> 
> Please leave the above commit out of the tree until you have at least
> fixed all the in tree users.

I thought I had.  This was my way of shaking out the residue as I don't
have a working ppc cross-compiler anymore :(

I'll add the above two patches (don't know if the second one needs it)
for tomorrow.

Roel, do you have any other patches doing this that I haven't picked up
yet?

thanks,

greg k-h

linux-next: driver-core tree build failure

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next build (powerpc_ppc64_defconfig) failed like this:

In file included from arch/powerpc/platforms/ps3/platform.h:28,
                 from arch/powerpc/platforms/ps3/mm.c:32:
arch/powerpc/include/asm/ps3.h: In function 'ps3_system_bus_set_driver_data':
arch/powerpc/include/asm/ps3.h:424: error: 'struct device' has no member named 'driver_data'
arch/powerpc/include/asm/ps3.h: In function 'ps3_system_bus_get_driver_data':
arch/powerpc/include/asm/ps3.h:429: error: 'struct device' has no member named 'driver_data'

Caused (obviously) by commit 9499952d8efc857406365bfc04079ff1e85660ff
("Driver core: move dev_get/set_drvdata to drivers/base/dd.c") which I
have reverted.

Grep is your friend ...  Actually there is a patch for this ...
http://patchwork.ozlabs.org/patch/27061/ ... also for another ...
http://patchwork.ozlabs.org/patch/27062/

Please leave the above commit out of the tree until you have at least
fixed all the in tree users.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: driver-core tree build failure

[Greg KH]

On Sat, May 09, 2009 at 09:16:11PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> On Mon, 4 May 2009 16:25:42 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > 
> > drivers/hid/usbhid/hiddev.c:965: error: unknown field 'nodename' specified in initializer
> > drivers/hid/usbhid/hiddev.c:965: warning: initialization from incompatible pointer type
> > 
> > Caused by commit 5b1e3a40a98ad5a822cb527439cd57dc60a41db9 ("Driver Core:
> > devtmpfs - driver core maintained /dev tmpfs").  As far as I can see the
> > version of this patch in your quilt series currently has never been
> > posted anywhere public ... The diff summaries for the previous and
> > current version of this patch are:
> > 
> > - 18 files changed, 484 insertions(+), 5 deletions(-)
> > + 38 files changed, 599 insertions(+), 11 deletions(-)
> > 
> > Which is a pretty big change for something in linux-next.  So, can we
> > please remove this patch until it has proper review, been tested and has
> > settled down a bit.
> 
> OK, so now I have another new version of this patch (split up as many
> patches) in the driver-core tree (destined for linux-next) which has also
> not been posted to LKML (which is where I assumed it would be posted).  I
> think people would like the opportunity to review this stuff.

Yes, it will be sent there, I thought it more important to get my tree
working again and out there, thinking you were not going to be doing a
linux-next release over the weekend.

Was I incorrect in that assumption?

I'll be sending it in a few hours.

thanks,

greg k-h

Re: linux-next: driver-core tree build failure

[Stephen Rothwell]

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

Hi Greg,

On Mon, 4 May 2009 16:25:42 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> drivers/hid/usbhid/hiddev.c:965: error: unknown field 'nodename' specified in initializer
> drivers/hid/usbhid/hiddev.c:965: warning: initialization from incompatible pointer type
> 
> Caused by commit 5b1e3a40a98ad5a822cb527439cd57dc60a41db9 ("Driver Core:
> devtmpfs - driver core maintained /dev tmpfs").  As far as I can see the
> version of this patch in your quilt series currently has never been
> posted anywhere public ... The diff summaries for the previous and
> current version of this patch are:
> 
> - 18 files changed, 484 insertions(+), 5 deletions(-)
> + 38 files changed, 599 insertions(+), 11 deletions(-)
> 
> Which is a pretty big change for something in linux-next.  So, can we
> please remove this patch until it has proper review, been tested and has
> settled down a bit.

OK, so now I have another new version of this patch (split up as many
patches) in the driver-core tree (destined for linux-next) which has also
not been posted to LKML (which is where I assumed it would be posted).  I
think people would like the opportunity to review this stuff.

What do I do?  I keep telling everyone that stuff should only be in
linux-next *after* it has been reviewed and stabilised ...

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

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

Re: linux-next: driver-core tree build failure

[Greg KH]

On Tue, May 05, 2009 at 02:18:19PM +1000, Stephen Rothwell wrote:
> Hi Kay, Greg,
> 
> On Mon, 4 May 2009 15:00:51 +0200 Kay Sievers <kay.sievers@vrfy.org> wrote:
> >
> > On Mon, May 4, 2009 at 08:25, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > >
> > > drivers/hid/usbhid/hiddev.c:965: error: unknown field 'nodename' specified in initializer
> > > drivers/hid/usbhid/hiddev.c:965: warning: initialization from incompatible pointer type
> > 
> > Sorry, that was my fault. I merged a fix wrongly with the original
> > patch. I sent an updated patch to Greg.
> 
> Since that update didn't make it into Greg's tree today, I just dropped
> the patch from the series for today.

That's fine, sorry about that, I didn't have the chance to get to it
today.

I should have it resolved tomorrow.

thanks,

greg k-h

Re: linux-next: driver-core tree build failure

[Stephen Rothwell]

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

Hi Kay, Greg,

On Mon, 4 May 2009 15:00:51 +0200 Kay Sievers <kay.sievers@vrfy.org> wrote:
>
> On Mon, May 4, 2009 at 08:25, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> >
> > drivers/hid/usbhid/hiddev.c:965: error: unknown field 'nodename' specified in initializer
> > drivers/hid/usbhid/hiddev.c:965: warning: initialization from incompatible pointer type
> 
> Sorry, that was my fault. I merged a fix wrongly with the original
> patch. I sent an updated patch to Greg.

Since that update didn't make it into Greg's tree today, I just dropped
the patch from the series for today.

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

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

Re: linux-next: driver-core tree build failure

[Kay Sievers]

On Mon, May 4, 2009 at 08:25, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> drivers/hid/usbhid/hiddev.c:965: error: unknown field 'nodename' specified in initializer
> drivers/hid/usbhid/hiddev.c:965: warning: initialization from incompatible pointer type

Sorry, that was my fault. I merged a fix wrongly with the original
patch. I sent an updated patch to Greg.

Thanks a lot and sorry for the mess,
Kay

linux-next: driver-core tree build failure

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

drivers/hid/usbhid/hiddev.c:965: error: unknown field 'nodename' specified in initializer
drivers/hid/usbhid/hiddev.c:965: warning: initialization from incompatible pointer type

Caused by commit 5b1e3a40a98ad5a822cb527439cd57dc60a41db9 ("Driver Core:
devtmpfs - driver core maintained /dev tmpfs").  As far as I can see the
version of this patch in your quilt series currently has never been
posted anywhere public ... The diff summaries for the previous and
current version of this patch are:

- 18 files changed, 484 insertions(+), 5 deletions(-)
+ 38 files changed, 599 insertions(+), 11 deletions(-)

Which is a pretty big change for something in linux-next.  So, can we
please remove this patch until it has proper review, been tested and has
settled down a bit.

I have reverted that patch for today (anything else was harder).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: driver-core tree build failure

[Jesse Barnes]

On Thu, 26 Mar 2009 18:34:33 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Greg, Jesse,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> drivers/pci/hotplug/fakephp.c: In function 'legacy_add_slot':
> drivers/pci/hotplug/fakephp.c:91: error: 'struct device' has no
> member named 'bus_id'
> 
> Caused by commit 83dbf66f04b96e65c6c18436c16d40f9cf8630aa ("PCI
> Hotplug: restore fakephp interface with complete reimplementation")
> from the pci tree which added another use of bus_id. (Commit
> c32e967b935450c5178ebeaabb9ed889b14ed197 ("driver core: get rid of
> struct device's bus_id string array") removes bus_id.)
> 
> I applied the batch below.  Jesse, this is suitable for the pci tree
> as the dev_name() interface already exists in Linus' tree.

Applied, thanks.

-- 
Jesse Barnes, Intel Open Source Technology Center

linux-next: driver-core tree build failure

[Stephen Rothwell]

Hi Greg, Jesse,

Today's linux-next build (x86_64 allmodconfig) failed like this:

drivers/pci/hotplug/fakephp.c: In function 'legacy_add_slot':
drivers/pci/hotplug/fakephp.c:91: error: 'struct device' has no member named 'bus_id'

Caused by commit 83dbf66f04b96e65c6c18436c16d40f9cf8630aa ("PCI Hotplug:
restore fakephp interface with complete reimplementation") from the pci
tree which added another use of bus_id. (Commit
c32e967b935450c5178ebeaabb9ed889b14ed197 ("driver core: get rid of struct
device's bus_id string array") removes bus_id.)

I applied the batch below.  Jesse, this is suitable for the pci tree as
the dev_name() interface already exists in Linus' tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 26 Mar 2009 18:25:06 +1100
Subject: [PATCH] pci: update fakephp for bus_id removal

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

diff --git a/drivers/pci/hotplug/fakephp.c b/drivers/pci/hotplug/fakephp.c
index 2dc7828..21c2f5d 100644
--- a/drivers/pci/hotplug/fakephp.c
+++ b/drivers/pci/hotplug/fakephp.c
@@ -18,6 +18,7 @@
 #include <linux/sysfs.h>
 #include <linux/init.h>
 #include <linux/pci.h>
+#include <linux/device.h>
 #include "../pci.h"
 
 struct legacy_slot {
@@ -88,7 +89,7 @@ static int legacy_add_slot(struct pci_dev *pdev)
 
 	if (kobject_init_and_add(&slot->kobj, &legacy_ktype,
 				 &pci_slots_kset->kobj, "%s",
-				 pdev->dev.bus_id)) {
+				 dev_name(&pdev->dev))) {
 		dev_warn(&pdev->dev, "Failed to created legacy fake slot\n");
 		return -EINVAL;
 	}
-- 
1.6.2.1

Re: linux-next: driver-core tree build failure

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Sun, 22 Mar 2009 23:22:37 +1100

> net: update dnet.c for bus_id removal
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Applied, thanks Stephen.

Re: linux-next: driver-core tree build failure

[Stephen Rothwell]

Hi Greg, Dave,

On Mon, 16 Mar 2009 20:47:03 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Dave, this could apply to net-current (or net after you merge
> net-current) or Greg could put it in driver-core after net-current gets
> merged into Linus' tree.

The dnet driver is now upstream, so can one of you add this to your tree,
please?  Apologies if I missed it.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 16 Mar 2009 20:37:10 +1100
Subject: [PATCH] net: update dnet.c for bus_id removal

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

diff --git a/drivers/net/dnet.c b/drivers/net/dnet.c
index 5c347f7..1b40632 100644
--- a/drivers/net/dnet.c
+++ b/drivers/net/dnet.c
@@ -280,11 +280,11 @@ static int dnet_mii_probe(struct net_device *dev)
 
 	/* attach the mac to the phy */
 	if (bp->capabilities & DNET_HAS_RMII) {
-		phydev = phy_connect(dev, phydev->dev.bus_id,
+		phydev = phy_connect(dev, dev_name(&phydev->dev),
 				     &dnet_handle_link_change, 0,
 				     PHY_INTERFACE_MODE_RMII);
 	} else {
-		phydev = phy_connect(dev, phydev->dev.bus_id,
+		phydev = phy_connect(dev, dev_name(&phydev->dev),
 				     &dnet_handle_link_change, 0,
 				     PHY_INTERFACE_MODE_MII);
 	}
@@ -927,7 +927,7 @@ static int __devinit dnet_probe(struct platform_device *pdev)
 	phydev = bp->phy_dev;
 	dev_info(&pdev->dev, "attached PHY driver [%s] "
 	       "(mii_bus:phy_addr=%s, irq=%d)\n",
-	       phydev->drv->name, phydev->dev.bus_id, phydev->irq);
+	       phydev->drv->name, dev_name(&phydev->dev), phydev->irq);
 
 	return 0;
 
-- 
1.6.2



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

linux-next: driver-core tree build failure

[Stephen Rothwell]

Hi Greg,

Today's linux-next build (x86_64 allmodconfig) failed like this:

drivers/net/dnet.c: In function 'dnet_mii_probe':
drivers/net/dnet.c:283: error: 'struct device' has no member named 'bus_id'
drivers/net/dnet.c:287: error: 'struct device' has no member named 'bus_id'
drivers/net/dnet.c: In function 'dnet_probe':
drivers/net/dnet.c:928: error: 'struct device' has no member named 'bus_id'

Another new driver (in net-current) that needs conversion for then bus_id
removal.  I applied the patch below for today.

Dave, this could apply to net-current (or net after you merge
net-current) or Greg could put it in driver-core after net-current gets
merged into Linus' tree.

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

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 16 Mar 2009 20:37:10 +1100
Subject: [PATCH] net: update dnet.c for bus_id removal

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

diff --git a/drivers/net/dnet.c b/drivers/net/dnet.c
index 5c347f7..1b40632 100644
--- a/drivers/net/dnet.c
+++ b/drivers/net/dnet.c
@@ -280,11 +280,11 @@ static int dnet_mii_probe(struct net_device *dev)
 
 	/* attach the mac to the phy */
 	if (bp->capabilities & DNET_HAS_RMII) {
-		phydev = phy_connect(dev, phydev->dev.bus_id,
+		phydev = phy_connect(dev, dev_name(&phydev->dev),
 				     &dnet_handle_link_change, 0,
 				     PHY_INTERFACE_MODE_RMII);
 	} else {
-		phydev = phy_connect(dev, phydev->dev.bus_id,
+		phydev = phy_connect(dev, dev_name(&phydev->dev),
 				     &dnet_handle_link_change, 0,
 				     PHY_INTERFACE_MODE_MII);
 	}
@@ -927,7 +927,7 @@ static int __devinit dnet_probe(struct platform_device *pdev)
 	phydev = bp->phy_dev;
 	dev_info(&pdev->dev, "attached PHY driver [%s] "
 	       "(mii_bus:phy_addr=%s, irq=%d)\n",
-	       phydev->drv->name, phydev->dev.bus_id, phydev->irq);
+	       phydev->drv->name, dev_name(&phydev->dev), phydev->irq);
 
 	return 0;
 
-- 
1.6.2

Re: linux-next: driver-core tree build failure

[Jason Baron]

On Wed, Mar 11, 2009 at 09:07:28PM +1100, Greg Banks wrote:
> 
> I think this patch does the same thing more cleanly.
> 
> When CONFIG_DYNAMIC_DEBUG is enabled, allow callers of pr_debug()
> to provide their own definition of pr_fmt() even if that definition
> uses tricks like
> 
> #define pr_fmt(fmt) "%s:" fmt, __func__
> 

patch looks good. I agree its simpler than what I proposed. However, I
don't think we want to add pr_fmt() in the dynamic_dev_dbg() path, since
dev_dbg() isn't doing that to start with. Other than that, I ack it.

thanks,

-Jason

Re: linux-next: driver-core tree build failure

[Geert Uytterhoeven]

On Wed, 11 Mar 2009, Greg Banks wrote:
> Jason Baron wrote:
> > On Tue, Mar 10, 2009 at 05:08:41PM +0100, Martin Schwidefsky wrote:
> >   
> >> On Tue, 10 Mar 2009 16:29:50 +0100 (CET)
> >> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> >>
> >>     
> >>>> The same could be done with the problematic pr_fmt definition:
> >>>>
> >>>> #define pr_fmt(fmt)     __func__ ": " fmt
> >>>>         
> >>> No, that also doesn't work:
> >>>
> >>> | crypto/zlib.c:150: error: expected '}' before string constant
> >>> | crypto/zlib.c:150: error: expected ')' before '__func__'
> >>> | crypto/zlib.c:162: error: expected '}' before string constant
> >>> | crypto/zlib.c:162: error: expected ')' before '__func__'
> >>> | crypto/zlib.c:166: error: expected '}' before string constant
> >>> | crypto/zlib.c:166: error: expected ')' before '__func__'
> >>> | crypto/zlib.c:170: error: expected '}' before string constant
> >>> | crypto/zlib.c:170: error: expected ')' before '__func__'
> >>>
> >>>       
> >>>>> BTW, Martin: Is `#define pr_fmt(fmt)     "%s: " fmt, __func__' a valid and
> >>>>> intended usage of your pr_fmt() infrastructure?
> >>>>>           
> >>>> The indended use is a simple prefix to the format string. To paste an
> >>>> additional parameter is an interesting use of the pr_fmt macro ..
> >>>>         
> >>> Bummer, I was so happy I could do things like
> >>>
> >>> | #define pr_fmt(fmt)	"%s:%u: " fmt, __func__, __LINE__
> >>>       
> >> Actually that seem like a nice thing to have. With the upstream version of
> >> dynamic_pr_debug this works, there the format string is used only on a printk.
> >> git commit 25b67b75587d43ff3f09ad88c03c70a38372d95d introduces the code
> >> that pastes the format string to the _ddebug structure.
> >>
> >>     
> >
> > hmmm...yeah, some macro magic in include/linux/dynamic_debug.h converts
> > the 'fmt' arg into a series of strings. It doesn't look as pretty in the
> > dynamic debug control file:
> >
> > crypto/zlib.c:333 [zlib]zlib_decompress_final - "\042%s: \042
> > \042avail_in %u, avail_out %u (consumed %u, produced %u)\n\042,
> > __func__"
> >
> > with all those '\042' there, which are the '"' characters, but we
> > probably could live with it.
> >
> > patch below.
> >
> >   
> 
> I think this patch does the same thing more cleanly.
> 
> When CONFIG_DYNAMIC_DEBUG is enabled, allow callers of pr_debug()
> to provide their own definition of pr_fmt() even if that definition
> uses tricks like
> 
> #define pr_fmt(fmt) "%s:" fmt, __func__
> 
> Signed-off-by: Greg Banks <gnb@sgi.com>

Thanks, much cleaner!

Acked-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>

> ---
> 
>  include/linux/dynamic_debug.h |    4 ++--
>  include/linux/kernel.h        |    3 ++-
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> Index: linux-git/include/linux/dynamic_debug.h
> ===================================================================
> --- linux-git.orig/include/linux/dynamic_debug.h
> +++ linux-git/include/linux/dynamic_debug.h
> @@ -57,7 +57,7 @@ extern int ddebug_remove_module(char *mo
>  	{ KBUILD_MODNAME, __func__, __FILE__, fmt, DEBUG_HASH,	\
>  		DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT };	\
>  	if (__dynamic_dbg_enabled(descriptor))				\
> -		printk(KERN_DEBUG KBUILD_MODNAME ":" fmt,		\
> +		printk(KERN_DEBUG KBUILD_MODNAME ":" pr_fmt(fmt),	\
>  				##__VA_ARGS__);				\
>  	} while (0)
>  
> @@ -70,7 +70,7 @@ extern int ddebug_remove_module(char *mo
>  		DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT };	\
>  	if (__dynamic_dbg_enabled(descriptor))				\
>  			dev_printk(KERN_DEBUG, dev,			\
> -					KBUILD_MODNAME ": " fmt,	\
> +					KBUILD_MODNAME ": " pr_fmt(fmt),\
>  					##__VA_ARGS__);			\
>  	} while (0)
>  
> Index: linux-git/include/linux/kernel.h
> ===================================================================
> --- linux-git.orig/include/linux/kernel.h
> +++ linux-git/include/linux/kernel.h
> @@ -359,8 +359,9 @@ static inline char *pack_hex_byte(char *
>  #define pr_debug(fmt, ...) \
>  	printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
>  #elif defined(CONFIG_DYNAMIC_DEBUG)
> +/* dynamic_pr_debug() uses pr_fmt() internally so we don't need it here */
>  #define pr_debug(fmt, ...) do { \
> -	dynamic_pr_debug(pr_fmt(fmt), ##__VA_ARGS__); \
> +	dynamic_pr_debug(fmt, ##__VA_ARGS__); \
>  	} while (0)
>  #else
>  #define pr_debug(fmt, ...) \

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010

Re: linux-next: driver-core tree build failure

[Greg Banks]

Jason Baron wrote:
> On Tue, Mar 10, 2009 at 05:08:41PM +0100, Martin Schwidefsky wrote:
>   
>> On Tue, 10 Mar 2009 16:29:50 +0100 (CET)
>> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
>>
>>     
>>>> The same could be done with the problematic pr_fmt definition:
>>>>
>>>> #define pr_fmt(fmt)     __func__ ": " fmt
>>>>         
>>> No, that also doesn't work:
>>>
>>> | crypto/zlib.c:150: error: expected '}' before string constant
>>> | crypto/zlib.c:150: error: expected ')' before '__func__'
>>> | crypto/zlib.c:162: error: expected '}' before string constant
>>> | crypto/zlib.c:162: error: expected ')' before '__func__'
>>> | crypto/zlib.c:166: error: expected '}' before string constant
>>> | crypto/zlib.c:166: error: expected ')' before '__func__'
>>> | crypto/zlib.c:170: error: expected '}' before string constant
>>> | crypto/zlib.c:170: error: expected ')' before '__func__'
>>>
>>>       
>>>>> BTW, Martin: Is `#define pr_fmt(fmt)     "%s: " fmt, __func__' a valid and
>>>>> intended usage of your pr_fmt() infrastructure?
>>>>>           
>>>> The indended use is a simple prefix to the format string. To paste an
>>>> additional parameter is an interesting use of the pr_fmt macro ..
>>>>         
>>> Bummer, I was so happy I could do things like
>>>
>>> | #define pr_fmt(fmt)	"%s:%u: " fmt, __func__, __LINE__
>>>       
>> Actually that seem like a nice thing to have. With the upstream version of
>> dynamic_pr_debug this works, there the format string is used only on a printk.
>> git commit 25b67b75587d43ff3f09ad88c03c70a38372d95d introduces the code
>> that pastes the format string to the _ddebug structure.
>>
>>     
>
> hmmm...yeah, some macro magic in include/linux/dynamic_debug.h converts
> the 'fmt' arg into a series of strings. It doesn't look as pretty in the
> dynamic debug control file:
>
> crypto/zlib.c:333 [zlib]zlib_decompress_final - "\042%s: \042
> \042avail_in %u, avail_out %u (consumed %u, produced %u)\n\042,
> __func__"
>
> with all those '\042' there, which are the '"' characters, but we
> probably could live with it.
>
> patch below.
>
>   

I think this patch does the same thing more cleanly.

When CONFIG_DYNAMIC_DEBUG is enabled, allow callers of pr_debug()
to provide their own definition of pr_fmt() even if that definition
uses tricks like

#define pr_fmt(fmt) "%s:" fmt, __func__

Signed-off-by: Greg Banks <gnb@sgi.com>
---

 include/linux/dynamic_debug.h |    4 ++--
 include/linux/kernel.h        |    3 ++-
 2 files changed, 4 insertions(+), 3 deletions(-)

Index: linux-git/include/linux/dynamic_debug.h
===================================================================
--- linux-git.orig/include/linux/dynamic_debug.h
+++ linux-git/include/linux/dynamic_debug.h
@@ -57,7 +57,7 @@ extern int ddebug_remove_module(char *mo
 	{ KBUILD_MODNAME, __func__, __FILE__, fmt, DEBUG_HASH,	\
 		DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT };	\
 	if (__dynamic_dbg_enabled(descriptor))				\
-		printk(KERN_DEBUG KBUILD_MODNAME ":" fmt,		\
+		printk(KERN_DEBUG KBUILD_MODNAME ":" pr_fmt(fmt),	\
 				##__VA_ARGS__);				\
 	} while (0)
 
@@ -70,7 +70,7 @@ extern int ddebug_remove_module(char *mo
 		DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT };	\
 	if (__dynamic_dbg_enabled(descriptor))				\
 			dev_printk(KERN_DEBUG, dev,			\
-					KBUILD_MODNAME ": " fmt,	\
+					KBUILD_MODNAME ": " pr_fmt(fmt),\
 					##__VA_ARGS__);			\
 	} while (0)
 
Index: linux-git/include/linux/kernel.h
===================================================================
--- linux-git.orig/include/linux/kernel.h
+++ linux-git/include/linux/kernel.h
@@ -359,8 +359,9 @@ static inline char *pack_hex_byte(char *
 #define pr_debug(fmt, ...) \
 	printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
 #elif defined(CONFIG_DYNAMIC_DEBUG)
+/* dynamic_pr_debug() uses pr_fmt() internally so we don't need it here */
 #define pr_debug(fmt, ...) do { \
-	dynamic_pr_debug(pr_fmt(fmt), ##__VA_ARGS__); \
+	dynamic_pr_debug(fmt, ##__VA_ARGS__); \
 	} while (0)
 #else
 #define pr_debug(fmt, ...) \



-- 
Greg Banks, P.Engineer, SGI Australian Software Group.
the brightly coloured sporks of revolution.
I don't speak for SGI.

Re: linux-next: driver-core tree build failure

[Geert Uytterhoeven]

On Tue, 10 Mar 2009, Jason Baron wrote:
> On Tue, Mar 10, 2009 at 05:08:41PM +0100, Martin Schwidefsky wrote:
> > On Tue, 10 Mar 2009 16:29:50 +0100 (CET)
> > Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > 
> > > > The same could be done with the problematic pr_fmt definition:
> > > > 
> > > > #define pr_fmt(fmt)     __func__ ": " fmt
> > > 
> > > No, that also doesn't work:
> > > 
> > > | crypto/zlib.c:150: error: expected '}' before string constant
> > > | crypto/zlib.c:150: error: expected ')' before '__func__'
> > > | crypto/zlib.c:162: error: expected '}' before string constant
> > > | crypto/zlib.c:162: error: expected ')' before '__func__'
> > > | crypto/zlib.c:166: error: expected '}' before string constant
> > > | crypto/zlib.c:166: error: expected ')' before '__func__'
> > > | crypto/zlib.c:170: error: expected '}' before string constant
> > > | crypto/zlib.c:170: error: expected ')' before '__func__'
> > > 
> > > > > BTW, Martin: Is `#define pr_fmt(fmt)     "%s: " fmt, __func__' a valid and
> > > > > intended usage of your pr_fmt() infrastructure?
> > > > 
> > > > The indended use is a simple prefix to the format string. To paste an
> > > > additional parameter is an interesting use of the pr_fmt macro ..
> > > 
> > > Bummer, I was so happy I could do things like
> > > 
> > > | #define pr_fmt(fmt)	"%s:%u: " fmt, __func__, __LINE__
> > 
> > Actually that seem like a nice thing to have. With the upstream version of
> > dynamic_pr_debug this works, there the format string is used only on a printk.
> > git commit 25b67b75587d43ff3f09ad88c03c70a38372d95d introduces the code
> > that pastes the format string to the _ddebug structure.
> > 
> 
> hmmm...yeah, some macro magic in include/linux/dynamic_debug.h converts
> the 'fmt' arg into a series of strings. It doesn't look as pretty in the
> dynamic debug control file:
> 
> crypto/zlib.c:333 [zlib]zlib_decompress_final - "\042%s: \042
> \042avail_in %u, avail_out %u (consumed %u, produced %u)\n\042,
> __func__"
> 
> with all those '\042' there, which are the '"' characters, but we
> probably could live with it.

Ugh, not only that, it also contains the __func__.

BTW, why do you store this string? The only thing you can do with it later is
to print it verbatim (without % format parameter expansion), as it has
swallowed the first parameter (__func__), but still contains the %s.

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010

Re: linux-next: driver-core tree build failure

[Greg KH]

On Tue, Mar 10, 2009 at 04:02:00PM -0400, Jason Baron wrote:
> On Tue, Mar 10, 2009 at 05:08:41PM +0100, Martin Schwidefsky wrote:
> > On Tue, 10 Mar 2009 16:29:50 +0100 (CET)
> > Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > 
> > > > The same could be done with the problematic pr_fmt definition:
> > > > 
> > > > #define pr_fmt(fmt)     __func__ ": " fmt
> > > 
> > > No, that also doesn't work:
> > > 
> > > | crypto/zlib.c:150: error: expected '}' before string constant
> > > | crypto/zlib.c:150: error: expected ')' before '__func__'
> > > | crypto/zlib.c:162: error: expected '}' before string constant
> > > | crypto/zlib.c:162: error: expected ')' before '__func__'
> > > | crypto/zlib.c:166: error: expected '}' before string constant
> > > | crypto/zlib.c:166: error: expected ')' before '__func__'
> > > | crypto/zlib.c:170: error: expected '}' before string constant
> > > | crypto/zlib.c:170: error: expected ')' before '__func__'
> > > 
> > > > > BTW, Martin: Is `#define pr_fmt(fmt)     "%s: " fmt, __func__' a valid and
> > > > > intended usage of your pr_fmt() infrastructure?
> > > > 
> > > > The indended use is a simple prefix to the format string. To paste an
> > > > additional parameter is an interesting use of the pr_fmt macro ..
> > > 
> > > Bummer, I was so happy I could do things like
> > > 
> > > | #define pr_fmt(fmt)	"%s:%u: " fmt, __func__, __LINE__
> > 
> > Actually that seem like a nice thing to have. With the upstream version of
> > dynamic_pr_debug this works, there the format string is used only on a printk.
> > git commit 25b67b75587d43ff3f09ad88c03c70a38372d95d introduces the code
> > that pastes the format string to the _ddebug structure.
> > 
> 
> hmmm...yeah, some macro magic in include/linux/dynamic_debug.h converts
> the 'fmt' arg into a series of strings. It doesn't look as pretty in the
> dynamic debug control file:
> 
> crypto/zlib.c:333 [zlib]zlib_decompress_final - "\042%s: \042
> \042avail_in %u, avail_out %u (consumed %u, produced %u)\n\042,
> __func__"
> 
> with all those '\042' there, which are the '"' characters, but we
> probably could live with it.
> 
> patch below.

Can you resend this with a description of what the patch does so I can
apply it?

thanks,

greg k-h

Re: linux-next: driver-core tree build failure

[Jason Baron]

On Tue, Mar 10, 2009 at 05:08:41PM +0100, Martin Schwidefsky wrote:
> On Tue, 10 Mar 2009 16:29:50 +0100 (CET)
> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> 
> > > The same could be done with the problematic pr_fmt definition:
> > > 
> > > #define pr_fmt(fmt)     __func__ ": " fmt
> > 
> > No, that also doesn't work:
> > 
> > | crypto/zlib.c:150: error: expected '}' before string constant
> > | crypto/zlib.c:150: error: expected ')' before '__func__'
> > | crypto/zlib.c:162: error: expected '}' before string constant
> > | crypto/zlib.c:162: error: expected ')' before '__func__'
> > | crypto/zlib.c:166: error: expected '}' before string constant
> > | crypto/zlib.c:166: error: expected ')' before '__func__'
> > | crypto/zlib.c:170: error: expected '}' before string constant
> > | crypto/zlib.c:170: error: expected ')' before '__func__'
> > 
> > > > BTW, Martin: Is `#define pr_fmt(fmt)     "%s: " fmt, __func__' a valid and
> > > > intended usage of your pr_fmt() infrastructure?
> > > 
> > > The indended use is a simple prefix to the format string. To paste an
> > > additional parameter is an interesting use of the pr_fmt macro ..
> > 
> > Bummer, I was so happy I could do things like
> > 
> > | #define pr_fmt(fmt)	"%s:%u: " fmt, __func__, __LINE__
> 
> Actually that seem like a nice thing to have. With the upstream version of
> dynamic_pr_debug this works, there the format string is used only on a printk.
> git commit 25b67b75587d43ff3f09ad88c03c70a38372d95d introduces the code
> that pastes the format string to the _ddebug structure.
> 

hmmm...yeah, some macro magic in include/linux/dynamic_debug.h converts
the 'fmt' arg into a series of strings. It doesn't look as pretty in the
dynamic debug control file:

crypto/zlib.c:333 [zlib]zlib_decompress_final - "\042%s: \042
\042avail_in %u, avail_out %u (consumed %u, produced %u)\n\042,
__func__"

with all those '\042' there, which are the '"' characters, but we
probably could live with it.

patch below.

thanks,

-Jason



Signed-off-by: Jason Baron <jbaron@redhat.com>


diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 07781aa..16cf212 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -50,28 +50,30 @@ extern int ddebug_remove_module(char *mod_name);
 					__ret = 1;			     \
 	__ret; })
 
-#define dynamic_pr_debug(fmt, ...) do {					\
-	static struct _ddebug descriptor				\
-	__used								\
-	__attribute__((section("__verbose"), aligned(8))) =		\
-	{ KBUILD_MODNAME, __func__, __FILE__, fmt, DEBUG_HASH,	\
-		DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT };	\
-	if (__dynamic_dbg_enabled(descriptor))				\
-		printk(KERN_DEBUG KBUILD_MODNAME ":" fmt,		\
-				##__VA_ARGS__);				\
+#define STRINGIFY(args...) #args
+
+#define dynamic_pr_debug(fmt, ...) do {					  \
+	static struct _ddebug descriptor				  \
+	__used								  \
+	__attribute__((section("__verbose"), aligned(8))) =		  \
+	{ KBUILD_MODNAME, __func__, __FILE__, STRINGIFY(fmt), DEBUG_HASH, \
+		DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT };	  \
+	if (__dynamic_dbg_enabled(descriptor))				  \
+		printk(KERN_DEBUG KBUILD_MODNAME ":" fmt,		  \
+				##__VA_ARGS__);				  \
 	} while (0)
 
 
-#define dynamic_dev_dbg(dev, fmt, ...) do {				\
-	static struct _ddebug descriptor				\
-	__used								\
-	__attribute__((section("__verbose"), aligned(8))) =		\
-	{ KBUILD_MODNAME, __func__, __FILE__, fmt, DEBUG_HASH,	\
-		DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT };	\
-	if (__dynamic_dbg_enabled(descriptor))				\
-			dev_printk(KERN_DEBUG, dev,			\
-					KBUILD_MODNAME ": " fmt,	\
-					##__VA_ARGS__);			\
+#define dynamic_dev_dbg(dev, fmt, ...) do {				  \
+	static struct _ddebug descriptor				  \
+	__used								  \
+	__attribute__((section("__verbose"), aligned(8))) =		  \
+	{ KBUILD_MODNAME, __func__, __FILE__, STRINGIFY(fmt), DEBUG_HASH, \
+		DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT };	  \
+	if (__dynamic_dbg_enabled(descriptor))				  \
+			dev_printk(KERN_DEBUG, dev,			  \
+					KBUILD_MODNAME ": " fmt,	  \
+					##__VA_ARGS__);			  \
 	} while (0)
 
 #else

Re: linux-next: driver-core tree build failure

[Martin Schwidefsky]

On Tue, 10 Mar 2009 16:29:50 +0100 (CET)
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:

> > The same could be done with the problematic pr_fmt definition:
> > 
> > #define pr_fmt(fmt)     __func__ ": " fmt
> 
> No, that also doesn't work:
> 
> | crypto/zlib.c:150: error: expected '}' before string constant
> | crypto/zlib.c:150: error: expected ')' before '__func__'
> | crypto/zlib.c:162: error: expected '}' before string constant
> | crypto/zlib.c:162: error: expected ')' before '__func__'
> | crypto/zlib.c:166: error: expected '}' before string constant
> | crypto/zlib.c:166: error: expected ')' before '__func__'
> | crypto/zlib.c:170: error: expected '}' before string constant
> | crypto/zlib.c:170: error: expected ')' before '__func__'
> 
> > > BTW, Martin: Is `#define pr_fmt(fmt)     "%s: " fmt, __func__' a valid and
> > > intended usage of your pr_fmt() infrastructure?
> > 
> > The indended use is a simple prefix to the format string. To paste an
> > additional parameter is an interesting use of the pr_fmt macro ..
> 
> Bummer, I was so happy I could do things like
> 
> | #define pr_fmt(fmt)	"%s:%u: " fmt, __func__, __LINE__

Actually that seem like a nice thing to have. With the upstream version of
dynamic_pr_debug this works, there the format string is used only on a printk.
git commit 25b67b75587d43ff3f09ad88c03c70a38372d95d introduces the code
that pastes the format string to the _ddebug structure.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: linux-next: driver-core tree build failure

[Geert Uytterhoeven]

On Tue, 10 Mar 2009, Martin Schwidefsky wrote:
> On Tue, 10 Mar 2009 14:31:17 +0100 (CET)
> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> 
> > crypto/zlib.c has:
> > 
> >     #define pr_fmt(fmt)     "%s: " fmt, __func__
> > 
> > If CONFIG_DYNAMIC_DEBUG is set, include/linux/kernel.h has:
> > 
> > #define pr_debug(fmt, ...) do { \
> > 	dynamic_pr_debug(pr_fmt(fmt), ##__VA_ARGS__); \
> > 	} while (0)
> > 
> > include/linux/dynamic_debug.h has:
> > 
> > #define dynamic_pr_debug(fmt, ...) do {					\
> > 	static struct _ddebug descriptor				\
> > 	__used								\
> > 	__attribute__((section("__verbose"), aligned(8))) =		\
> > 	{ KBUILD_MODNAME, __func__, __FILE__, fmt, DEBUG_HASH,	\
> > 		DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT };	\
> > 	if (__dynamic_dbg_enabled(descriptor))				\
> > 		printk(KERN_DEBUG KBUILD_MODNAME ":" fmt,		\
> > 				##__VA_ARGS__);				\
> > 	} while (0)
> 
> The dynamic_pr_debug macro currently works only with pr_fmt definitions
> that do not add additional parameters. The way how we use the pr_fmt
> macro is:
> 
> #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
> 
> The same could be done with the problematic pr_fmt definition:
> 
> #define pr_fmt(fmt)     __func__ ": " fmt

No, that also doesn't work:

| crypto/zlib.c:150: error: expected '}' before string constant
| crypto/zlib.c:150: error: expected ')' before '__func__'
| crypto/zlib.c:162: error: expected '}' before string constant
| crypto/zlib.c:162: error: expected ')' before '__func__'
| crypto/zlib.c:166: error: expected '}' before string constant
| crypto/zlib.c:166: error: expected ')' before '__func__'
| crypto/zlib.c:170: error: expected '}' before string constant
| crypto/zlib.c:170: error: expected ')' before '__func__'

> > BTW, Martin: Is `#define pr_fmt(fmt)     "%s: " fmt, __func__' a valid and
> > intended usage of your pr_fmt() infrastructure?
> 
> The indended use is a simple prefix to the format string. To paste an
> additional parameter is an interesting use of the pr_fmt macro ..

Bummer, I was so happy I could do things like

| #define pr_fmt(fmt)	"%s:%u: " fmt, __func__, __LINE__

...

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010

Re: linux-next: driver-core tree build failure

[Martin Schwidefsky]

On Tue, 10 Mar 2009 14:31:17 +0100 (CET)
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:

> crypto/zlib.c has:
> 
>     #define pr_fmt(fmt)     "%s: " fmt, __func__
> 
> If CONFIG_DYNAMIC_DEBUG is set, include/linux/kernel.h has:
> 
> #define pr_debug(fmt, ...) do { \
> 	dynamic_pr_debug(pr_fmt(fmt), ##__VA_ARGS__); \
> 	} while (0)
> 
> include/linux/dynamic_debug.h has:
> 
> #define dynamic_pr_debug(fmt, ...) do {					\
> 	static struct _ddebug descriptor				\
> 	__used								\
> 	__attribute__((section("__verbose"), aligned(8))) =		\
> 	{ KBUILD_MODNAME, __func__, __FILE__, fmt, DEBUG_HASH,	\
> 		DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT };	\
> 	if (__dynamic_dbg_enabled(descriptor))				\
> 		printk(KERN_DEBUG KBUILD_MODNAME ":" fmt,		\
> 				##__VA_ARGS__);				\
> 	} while (0)

The dynamic_pr_debug macro currently works only with pr_fmt definitions
that do not add additional parameters. The way how we use the pr_fmt
macro is:

#define pr_fmt(fmt) KMSG_COMPONENT ": " fmt

The same could be done with the problematic pr_fmt definition:

#define pr_fmt(fmt)     __func__ ": " fmt

> BTW, Martin: Is `#define pr_fmt(fmt)     "%s: " fmt, __func__' a valid and
> intended usage of your pr_fmt() infrastructure?

The indended use is a simple prefix to the format string. To paste an
additional parameter is an interesting use of the pr_fmt macro ..

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: linux-next: driver-core tree build failure

[Herbert Xu]

On Tue, Mar 10, 2009 at 02:31:17PM +0100, Geert Uytterhoeven wrote:
>
> Why doesn't it work for dynamic_pr_debug()?

Because fmt is expanded twice?

> BTW, Martin: Is `#define pr_fmt(fmt)     "%s: " fmt, __func__' a valid and
> intended usage of your pr_fmt() infrastructure?

I never liked this in the first place :) If anyone wants to debug
this they can add whatever printks they want.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: linux-next: driver-core tree build failure

[Geert Uytterhoeven]

On Tue, 10 Mar 2009, Stephen Rothwell wrote:
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> crypto/zlib.c: In function 'zlib_compress_update':
> crypto/zlib.c:148: warning: initialization makes integer from pointer without a cast
> crypto/zlib.c:148: error: initializer element is not computable at load time
> crypto/zlib.c:148: error: (near initialization for 'descriptor.primary_hash')
> crypto/zlib.c:148: warning: excess elements in struct initializer
> crypto/zlib.c:148: warning: (near initialization for 'descriptor')
> 
> And many more similar.  This line is a pr_debug() statement, so the
> finger points at commit 25b67b75587d43ff3f09ad88c03c70a38372d95d
> ("dynamic debug: combine dprintk and dynamic printk") from the
> driver-core tree.
> 
> The preprocessed code looks like this:
> 
> static int zlib_compress_update(struct crypto_pcomp *tfm,
>     struct comp_request *req)
> {
>  int ret;
>  struct zlib_ctx *dctx = crypto_tfm_ctx(crypto_pcomp_tfm(tfm));
>  struct z_stream_s *stream = &dctx->comp_stream;
> 
>  do { do { static struct _ddebug descriptor __attribute__((__used__)) __attribute__((section("__verbose"), aligned(8))) = { "zlib", __func__, "/scratch/sfr/next/crypto/zlib.c", "%s: " "avail_in %u, avail_out %u\n", __func__, 55, 33, 148, 0 }; if (({ int __ret = 0; if (__builtin_expect(!!((dynamic_debug_enabled & (1LL << 55)) && (dynamic_debug_enabled2 & (1LL << 33))), 0)) if (__builtin_expect(!!(descriptor.flags), 0)) __ret = 1; __ret; })) printk("<7>" "zlib" ":" "%s: " "avail_in %u, avail_out %u\n", __func__, req->avail_in, req->avail_out); } while (0); } while (0);
> 
> The problem is the line:
> 
> #define pr_fmt(fmt)     "%s: " fmt, __func__
> 
> in crypto/zlib.c which was introduced by commit
> bf68e65ec9ea61e32ab71bef59aa5d24d255241f ("crypto: zlib - New zlib crypto
> module, using pcomp") from the crypto tree.
> 
> For today, I have removed the above line from crypto/zlib.c, but
> something better needs to be done for tomorrow!

I had a closer look. It happens on all archs, if CONFIG_DYNAMIC_DEBUG=y.

crypto/zlib.c has:

    #define pr_fmt(fmt)     "%s: " fmt, __func__

If CONFIG_DYNAMIC_DEBUG is set, include/linux/kernel.h has:

#define pr_debug(fmt, ...) do { \
	dynamic_pr_debug(pr_fmt(fmt), ##__VA_ARGS__); \
	} while (0)

include/linux/dynamic_debug.h has:

#define dynamic_pr_debug(fmt, ...) do {					\
	static struct _ddebug descriptor				\
	__used								\
	__attribute__((section("__verbose"), aligned(8))) =		\
	{ KBUILD_MODNAME, __func__, __FILE__, fmt, DEBUG_HASH,	\
		DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT };	\
	if (__dynamic_dbg_enabled(descriptor))				\
		printk(KERN_DEBUG KBUILD_MODNAME ":" fmt,		\
				##__VA_ARGS__);				\
	} while (0)


So in crypto/zlib.c,

| pr_debug("avail_in %u, avail_out %u\n", req->avail_in, req->avail_out);

is expanded to

| do {
|   do {
|     static struct _ddebug descriptor
|       __attribute__((__used__))
|       __attribute__((section("__verbose"), aligned(8))) = {
|       "zlib",
|       __func__,
|       "crypto/zlib.c",
|       "%s: " "avail_in %u, avail_out %u\n",
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	This is the actual format string

|       __func__,
        ^^^^^^^^^
	But this is the first parameter, which should not be here!!!

|       55,
|       33,
|       150,
|       0
|     };
|     if (({
|       int __ret = 0;
|       if (__builtin_expect(!!((dynamic_debug_enabled & (1LL << 55)) &&
| 			      (dynamic_debug_enabled2 & (1LL << 33))), 0))
| 	if (__builtin_expect(!!(descriptor.flags), 0))
| 	    __ret = 1;
|       __ret;
|     }))
|     printk("<7>" "zlib" ":" "%s: " "avail_in %u, avail_out %u\n", __func__,
| 	   req->avail_in, req->avail_out);
|   } while (0);
| } while (0);

Due the the superfluous `__func__', all field members are shifted by one
position, and compilation breaks.

Apparently inside dynamic_pr_debug(), `fmt' is:

    "avail_in %u, avail_out %u\n", __func__
    
instead of only the part before the comma:

    "avail_in %u, avail_out %u\n"


For the non-CONFIG_DYNAMIC_DEBUG case, pr_debug() is expanded correctly:

DEBUG is defined:

#define pr_debug(fmt, ...) \
	printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)

and the line is expanded to:

| printk("<7>" "%s: " "avail_in %u, avail_out %u\n", __func__, req->avail_in, req->avail_out);

DEBUG is not defined:

#define pr_debug(fmt, ...) \
	({ if (0) printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__); 0; })

and the line is expanded to:

| ({ if (0) printk("<7>" "%s: " "avail_in %u, avail_out %u\n", __func__, req->avail_in, req->avail_out); 0; });

Why doesn't it work for dynamic_pr_debug()?

BTW, Martin: Is `#define pr_fmt(fmt)     "%s: " fmt, __func__' a valid and
intended usage of your pr_fmt() infrastructure?

Thanks!

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010

linux-next: driver-core tree build failure

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next build (x86_64 allmodconfig) failed like this:

crypto/zlib.c: In function 'zlib_compress_update':
crypto/zlib.c:148: warning: initialization makes integer from pointer without a cast
crypto/zlib.c:148: error: initializer element is not computable at load time
crypto/zlib.c:148: error: (near initialization for 'descriptor.primary_hash')
crypto/zlib.c:148: warning: excess elements in struct initializer
crypto/zlib.c:148: warning: (near initialization for 'descriptor')

And many more similar.  This line is a pr_debug() statement, so the
finger points at commit 25b67b75587d43ff3f09ad88c03c70a38372d95d
("dynamic debug: combine dprintk and dynamic printk") from the
driver-core tree.

The preprocessed code looks like this:

static int zlib_compress_update(struct crypto_pcomp *tfm,
    struct comp_request *req)
{
 int ret;
 struct zlib_ctx *dctx = crypto_tfm_ctx(crypto_pcomp_tfm(tfm));
 struct z_stream_s *stream = &dctx->comp_stream;

 do { do { static struct _ddebug descriptor __attribute__((__used__)) __attribute__((section("__verbose"), aligned(8))) = { "zlib", __func__, "/scratch/sfr/next/crypto/zlib.c", "%s: " "avail_in %u, avail_out %u\n", __func__, 55, 33, 148, 0 }; if (({ int __ret = 0; if (__builtin_expect(!!((dynamic_debug_enabled & (1LL << 55)) && (dynamic_debug_enabled2 & (1LL << 33))), 0)) if (__builtin_expect(!!(descriptor.flags), 0)) __ret = 1; __ret; })) printk("<7>" "zlib" ":" "%s: " "avail_in %u, avail_out %u\n", __func__, req->avail_in, req->avail_out); } while (0); } while (0);

The problem is the line:

#define pr_fmt(fmt)     "%s: " fmt, __func__

in crypto/zlib.c which was introduced by commit
bf68e65ec9ea61e32ab71bef59aa5d24d255241f ("crypto: zlib - New zlib crypto
module, using pcomp") from the crypto tree.

For today, I have removed the above line from crypto/zlib.c, but
something better needs to be done for tomorrow!

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

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

Re: linux-next: driver-core tree build failure

[Greg KH]

On Mon, Jan 26, 2009 at 01:19:42PM +0100, Kay Sievers wrote:
> On Mon, Jan 26, 2009 at 02:10, Greg KH <greg@kroah.com> wrote:
> > On Mon, Jan 26, 2009 at 11:50:44AM +1100, Stephen Rothwell wrote:
> 
> >> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> >>
> >> arch/powerpc/platforms/ps3/system-bus.c: In function 'ps3_system_bus_probe':
> >> arch/powerpc/platforms/ps3/system-bus.c:379: error: 'struct device' has no member named 'bus_id'
> >> arch/powerpc/platforms/ps3/system-bus.c: In function 'ps3_system_bus_remove':
> >> arch/powerpc/platforms/ps3/system-bus.c:401: error: 'struct device' has no member named 'bus_id'
> >>
> >> Caused by commit aab0d375e01d8c16e7e5b9bd915dfaa0a815418f ("powerpc:
> >> struct device - replace bus_id with dev_name(), dev_set_name()") not
> >> being thorough enough before commit
> >> 73babb2d89a71d2110b65aab658e6309748827c2 ("driver core: get rid of struct
> >> device's bus_id string array") was applied.
> >>
> >> I have reverted the latter commit.
> >
> > Gotta love the ps3 platform code, there is about 3 different fields
> > called "bus_id" in that file :(
> 
> Yeah, that's "fun", especially if you don't have the environment to
> compile it. :)
> 
> > Anyway, here's a patch that should fix this, Kay, look sane?
> 
> Looks fine, yes.

Thanks, I've queued it up and sent it to the ps3 maintainer for review.

greg k-h

Re: linux-next: driver-core tree build failure

[Kay Sievers]

On Mon, Jan 26, 2009 at 02:10, Greg KH <greg@kroah.com> wrote:
> On Mon, Jan 26, 2009 at 11:50:44AM +1100, Stephen Rothwell wrote:

>> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>>
>> arch/powerpc/platforms/ps3/system-bus.c: In function 'ps3_system_bus_probe':
>> arch/powerpc/platforms/ps3/system-bus.c:379: error: 'struct device' has no member named 'bus_id'
>> arch/powerpc/platforms/ps3/system-bus.c: In function 'ps3_system_bus_remove':
>> arch/powerpc/platforms/ps3/system-bus.c:401: error: 'struct device' has no member named 'bus_id'
>>
>> Caused by commit aab0d375e01d8c16e7e5b9bd915dfaa0a815418f ("powerpc:
>> struct device - replace bus_id with dev_name(), dev_set_name()") not
>> being thorough enough before commit
>> 73babb2d89a71d2110b65aab658e6309748827c2 ("driver core: get rid of struct
>> device's bus_id string array") was applied.
>>
>> I have reverted the latter commit.
>
> Gotta love the ps3 platform code, there is about 3 different fields
> called "bus_id" in that file :(

Yeah, that's "fun", especially if you don't have the environment to
compile it. :)

> Anyway, here's a patch that should fix this, Kay, look sane?

Looks fine, yes.

Thanks,
Kay

Re: linux-next: driver-core tree build failure

[Greg KH]

On Mon, Jan 26, 2009 at 11:50:44AM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> arch/powerpc/platforms/ps3/system-bus.c: In function 'ps3_system_bus_probe':
> arch/powerpc/platforms/ps3/system-bus.c:379: error: 'struct device' has no member named 'bus_id'
> arch/powerpc/platforms/ps3/system-bus.c: In function 'ps3_system_bus_remove':
> arch/powerpc/platforms/ps3/system-bus.c:401: error: 'struct device' has no member named 'bus_id'
> 
> Caused by commit aab0d375e01d8c16e7e5b9bd915dfaa0a815418f ("powerpc:
> struct device - replace bus_id with dev_name(), dev_set_name()") not
> being thorough enough before commit
> 73babb2d89a71d2110b65aab658e6309748827c2 ("driver core: get rid of struct
> device's bus_id string array") was applied.
> 
> I have reverted the latter commit.

Gotta love the ps3 platform code, there is about 3 different fields
called "bus_id" in that file :(

Anyway, here's a patch that should fix this, Kay, look sane?

thanks,

greg k-h

---
 arch/powerpc/platforms/ps3/system-bus.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/powerpc/platforms/ps3/system-bus.c
+++ b/arch/powerpc/platforms/ps3/system-bus.c
@@ -376,7 +376,7 @@ static int ps3_system_bus_probe(struct d
 	struct ps3_system_bus_driver *drv;
 
 	BUG_ON(!dev);
-	pr_debug(" -> %s:%d: %s\n", __func__, __LINE__, _dev->bus_id);
+	dev_dbg(_dev, "%s:%d\n", __func__, __LINE__);
 
 	drv = ps3_system_bus_dev_to_system_bus_drv(dev);
 	BUG_ON(!drv);
@@ -398,7 +398,7 @@ static int ps3_system_bus_remove(struct 
 	struct ps3_system_bus_driver *drv;
 
 	BUG_ON(!dev);
-	pr_debug(" -> %s:%d: %s\n", __func__, __LINE__, _dev->bus_id);
+	dev_dbg(_dev, "%s:%d\n", __func__, __LINE__);
 
 	drv = ps3_system_bus_dev_to_system_bus_drv(dev);
 	BUG_ON(!drv);

linux-next: driver-core tree build failure

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

arch/powerpc/platforms/ps3/system-bus.c: In function 'ps3_system_bus_probe':
arch/powerpc/platforms/ps3/system-bus.c:379: error: 'struct device' has no member named 'bus_id'
arch/powerpc/platforms/ps3/system-bus.c: In function 'ps3_system_bus_remove':
arch/powerpc/platforms/ps3/system-bus.c:401: error: 'struct device' has no member named 'bus_id'

Caused by commit aab0d375e01d8c16e7e5b9bd915dfaa0a815418f ("powerpc:
struct device - replace bus_id with dev_name(), dev_set_name()") not
being thorough enough before commit
73babb2d89a71d2110b65aab658e6309748827c2 ("driver core: get rid of struct
device's bus_id string array") was applied.

I have reverted the latter commit.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: driver-core tree build failure

[Stephen Rothwell]

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

Hi Greg,

On Thu, 1 Jan 2009 23:26:46 -0800 Greg KH <greg@kroah.com> wrote:
>
> Ugh, very sorry about this, I forgot to push the changes up to the
> kernel.org servers after I made them.

That's OK.

> Should be there now, thanks for your patience,

Good for Monday, then.

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

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

Re: linux-next: driver-core tree build failure

[Greg KH]

On Wed, Dec 31, 2008 at 02:28:03AM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> On Mon, 29 Dec 2008 17:34:44 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Mon, 22 Dec 2008 20:29:32 -0800 Greg KH <greg@kroah.com> wrote:
> > >
> > > On Mon, Dec 22, 2008 at 02:50:46PM +0000, Mark McLoughlin wrote:
> > > > On Mon, 2008-12-22 at 23:59 +1100, Stephen Rothwell wrote:
> > > > > Hi Greg,
> > > > > 
> > > > > Today's linux-next build (powerpc allnoconfig) failed like this:
> > > > > 
> > > > > drivers/base/core.c: In function '__root_device_register':
> > > > > drivers/base/core.c:1277: error: dereferencing pointer to incomplete type
> > > > > 
> > > > > Caused by bf86dbd2451d1012c2c968a960470e485b869f5b ("driver core: add
> > > > > root_device_register()").  This needs to cope with !CONFIG_MODULES (where
> > > > > struct module is not defined).
> > > > 
> > > > Ouch, my bad.
> > > > 
> > > > > I applied the following patch but only for today because it is too hard
> > > > > to revert the above patch ...
> > > > > 
> > > 
> > > Ick, I hate ifdefs...  I'll go fix this up.
> > 
> > Its still there today.  Lucky for you I didn't notice early enough to
> > drop the driver-core tree :-).  I will reapply my patch.
> 
> Today I dropped the driver-core tree (and the usb and staging trees that
> depend on it).

Ugh, very sorry about this, I forgot to push the changes up to the
kernel.org servers after I made them.

Should be there now, thanks for your patience,

greg k-h

Re: linux-next: driver-core tree build failure

[Stephen Rothwell]

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

Hi Greg,

On Mon, 29 Dec 2008 17:34:44 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 22 Dec 2008 20:29:32 -0800 Greg KH <greg@kroah.com> wrote:
> >
> > On Mon, Dec 22, 2008 at 02:50:46PM +0000, Mark McLoughlin wrote:
> > > On Mon, 2008-12-22 at 23:59 +1100, Stephen Rothwell wrote:
> > > > Hi Greg,
> > > > 
> > > > Today's linux-next build (powerpc allnoconfig) failed like this:
> > > > 
> > > > drivers/base/core.c: In function '__root_device_register':
> > > > drivers/base/core.c:1277: error: dereferencing pointer to incomplete type
> > > > 
> > > > Caused by bf86dbd2451d1012c2c968a960470e485b869f5b ("driver core: add
> > > > root_device_register()").  This needs to cope with !CONFIG_MODULES (where
> > > > struct module is not defined).
> > > 
> > > Ouch, my bad.
> > > 
> > > > I applied the following patch but only for today because it is too hard
> > > > to revert the above patch ...
> > > > 
> > 
> > Ick, I hate ifdefs...  I'll go fix this up.
> 
> Its still there today.  Lucky for you I didn't notice early enough to
> drop the driver-core tree :-).  I will reapply my patch.

Today I dropped the driver-core tree (and the usb and staging trees that
depend on it).

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

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

Re: linux-next: driver-core tree build failure

[Stephen Rothwell]

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

Hi Greg,

On Mon, 22 Dec 2008 20:29:32 -0800 Greg KH <greg@kroah.com> wrote:
>
> On Mon, Dec 22, 2008 at 02:50:46PM +0000, Mark McLoughlin wrote:
> > On Mon, 2008-12-22 at 23:59 +1100, Stephen Rothwell wrote:
> > > Hi Greg,
> > > 
> > > Today's linux-next build (powerpc allnoconfig) failed like this:
> > > 
> > > drivers/base/core.c: In function '__root_device_register':
> > > drivers/base/core.c:1277: error: dereferencing pointer to incomplete type
> > > 
> > > Caused by bf86dbd2451d1012c2c968a960470e485b869f5b ("driver core: add
> > > root_device_register()").  This needs to cope with !CONFIG_MODULES (where
> > > struct module is not defined).
> > 
> > Ouch, my bad.
> > 
> > > I applied the following patch but only for today because it is too hard
> > > to revert the above patch ...
> > > 
> > > -- 
> > > Cheers,
> > > Stephen Rothwell                    sfr@canb.auug.org.au
> > > http://www.canb.auug.org.au/~sfr/
> > > 
> > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Date: Mon, 22 Dec 2008 23:50:56 +1100
> > > Subject: [PATCH] driver core: fix root_device_register for not CONFIG_MODULES
> > > 
> > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > ---
> > >  drivers/base/core.c |    2 ++
> > >  1 files changed, 2 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/drivers/base/core.c b/drivers/base/core.c
> > > index 6fbdd8b..aa93980 100644
> > > --- a/drivers/base/core.c
> > > +++ b/drivers/base/core.c
> > > @@ -1273,6 +1273,7 @@ struct device *__root_device_register(const char *name, struct module *owner)
> > >  		return ERR_PTR(err);
> > >  	}
> > >  
> > > +#ifdef CONFIG_MODULE
> > >  	if (owner) {
> > >  		struct module_kobject *mk = &owner->mkobj;
> > >  
> > > @@ -1283,6 +1284,7 @@ struct device *__root_device_register(const char *name, struct module *owner)
> > >  		}
> > >  		root->owner = owner;
> > >  	}
> > > +#endif
> > 
> > Yep, looks correct to me ...
> 
> Ick, I hate ifdefs...  I'll go fix this up.

Its still there today.  Lucky for you I didn't notice early enough to
drop the driver-core tree :-).  I will reapply my patch.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: driver-core tree build failure

[Greg KH]

On Mon, Dec 22, 2008 at 02:50:46PM +0000, Mark McLoughlin wrote:
> On Mon, 2008-12-22 at 23:59 +1100, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > Today's linux-next build (powerpc allnoconfig) failed like this:
> > 
> > drivers/base/core.c: In function '__root_device_register':
> > drivers/base/core.c:1277: error: dereferencing pointer to incomplete type
> > 
> > Caused by bf86dbd2451d1012c2c968a960470e485b869f5b ("driver core: add
> > root_device_register()").  This needs to cope with !CONFIG_MODULES (where
> > struct module is not defined).
> 
> Ouch, my bad.
> 
> > I applied the following patch but only for today because it is too hard
> > to revert the above patch ...
> > 
> > -- 
> > Cheers,
> > Stephen Rothwell                    sfr@canb.auug.org.au
> > http://www.canb.auug.org.au/~sfr/
> > 
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Mon, 22 Dec 2008 23:50:56 +1100
> > Subject: [PATCH] driver core: fix root_device_register for not CONFIG_MODULES
> > 
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> >  drivers/base/core.c |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/base/core.c b/drivers/base/core.c
> > index 6fbdd8b..aa93980 100644
> > --- a/drivers/base/core.c
> > +++ b/drivers/base/core.c
> > @@ -1273,6 +1273,7 @@ struct device *__root_device_register(const char *name, struct module *owner)
> >  		return ERR_PTR(err);
> >  	}
> >  
> > +#ifdef CONFIG_MODULE
> >  	if (owner) {
> >  		struct module_kobject *mk = &owner->mkobj;
> >  
> > @@ -1283,6 +1284,7 @@ struct device *__root_device_register(const char *name, struct module *owner)
> >  		}
> >  		root->owner = owner;
> >  	}
> > +#endif
> 
> Yep, looks correct to me ...

Ick, I hate ifdefs...  I'll go fix this up.

thanks,

greg k-h

Re: linux-next: driver-core tree build failure

[Mark McLoughlin]

On Mon, 2008-12-22 at 23:59 +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next build (powerpc allnoconfig) failed like this:
> 
> drivers/base/core.c: In function '__root_device_register':
> drivers/base/core.c:1277: error: dereferencing pointer to incomplete type
> 
> Caused by bf86dbd2451d1012c2c968a960470e485b869f5b ("driver core: add
> root_device_register()").  This needs to cope with !CONFIG_MODULES (where
> struct module is not defined).

Ouch, my bad.

> I applied the following patch but only for today because it is too hard
> to revert the above patch ...
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 22 Dec 2008 23:50:56 +1100
> Subject: [PATCH] driver core: fix root_device_register for not CONFIG_MODULES
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/base/core.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 6fbdd8b..aa93980 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -1273,6 +1273,7 @@ struct device *__root_device_register(const char *name, struct module *owner)
>  		return ERR_PTR(err);
>  	}
>  
> +#ifdef CONFIG_MODULE
>  	if (owner) {
>  		struct module_kobject *mk = &owner->mkobj;
>  
> @@ -1283,6 +1284,7 @@ struct device *__root_device_register(const char *name, struct module *owner)
>  		}
>  		root->owner = owner;
>  	}
> +#endif

Yep, looks correct to me ...

Thanks,
Mark.

linux-next: driver-core tree build failure

[Stephen Rothwell]

Hi Greg,

Today's linux-next build (powerpc allnoconfig) failed like this:

drivers/base/core.c: In function '__root_device_register':
drivers/base/core.c:1277: error: dereferencing pointer to incomplete type

Caused by bf86dbd2451d1012c2c968a960470e485b869f5b ("driver core: add
root_device_register()").  This needs to cope with !CONFIG_MODULES (where
struct module is not defined).

I applied the following patch but only for today because it is too hard
to revert the above patch ...

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

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 22 Dec 2008 23:50:56 +1100
Subject: [PATCH] driver core: fix root_device_register for not CONFIG_MODULES

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

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 6fbdd8b..aa93980 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1273,6 +1273,7 @@ struct device *__root_device_register(const char *name, struct module *owner)
 		return ERR_PTR(err);
 	}
 
+#ifdef CONFIG_MODULE
 	if (owner) {
 		struct module_kobject *mk = &owner->mkobj;
 
@@ -1283,6 +1284,7 @@ struct device *__root_device_register(const char *name, struct module *owner)
 		}
 		root->owner = owner;
 	}
+#endif
 
 	return &root->dev;
 }
-- 
1.6.0.5

Re: linux-next: driver-core tree build failure

[Greg KH]

On Thu, Dec 11, 2008 at 11:21:27AM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> drivers/mtd/maps/physmap.c: In function 'physmap_flash_probe':
> drivers/mtd/maps/physmap.c:108: error: expected ')' before '{' token
> drivers/mtd/maps/physmap.c:144: error: expected expression before '}' token
> 
> Caused by commit 7267696c2421503e280d9da5bbdbd5c11e1e5b25 ("mtd: struct
> device - replace bus_id with dev_name(), dev_set_name()").
> 
> I have reverted that patch for today.
> 
> Please be more careful ... allmodconfig is your friend when doing wide
> ranging changes ...

Very sorry about that, I did kick off such a build, but forgot to look
at the result of it, my fault.

I've now fixed this up so it should be fine for tomorrow.

thanks for keeping us honest :)

greg k-h

linux-next: driver-core tree build failure

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next build (x86_64 allmodconfig) failed like this:

drivers/mtd/maps/physmap.c: In function 'physmap_flash_probe':
drivers/mtd/maps/physmap.c:108: error: expected ')' before '{' token
drivers/mtd/maps/physmap.c:144: error: expected expression before '}' token

Caused by commit 7267696c2421503e280d9da5bbdbd5c11e1e5b25 ("mtd: struct
device - replace bus_id with dev_name(), dev_set_name()").

I have reverted that patch for today.

Please be more careful ... allmodconfig is your friend when doing wide
ranging changes ...
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: driver-core tree build failure

[Greg KH]

On Wed, Nov 19, 2008 at 05:51:12PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> On Tue, 18 Nov 2008 22:26:44 -0800 Greg KH <greg@kroah.com> wrote:
> >
> > Right now there is no such dependancy (USB should build and apply just
> > fine without driver core, and staging depends on neither of these from
> > what I can see.)
> 
> The real problem is that because you tell me that usb is based on
> driver-core, then if I merge the usb tree it will pull in all of
> driver-core again after I have dropped it.  So if the trees are really
> independent, you could change (or remove) the NEXT-BASE comment in the
> series files.  But that means that you do have to test them independently
> as well, so it is probably not worth the effort.

Yeah, for now, it's fine, no big deal, I can live with being dropped for
a day :)

thanks,

greg k-h

Re: linux-next: driver-core tree build failure

[Stephen Rothwell]

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

Hi Greg,

On Tue, 18 Nov 2008 22:26:44 -0800 Greg KH <greg@kroah.com> wrote:
>
> Right now there is no such dependancy (USB should build and apply just
> fine without driver core, and staging depends on neither of these from
> what I can see.)

The real problem is that because you tell me that usb is based on
driver-core, then if I merge the usb tree it will pull in all of
driver-core again after I have dropped it.  So if the trees are really
independent, you could change (or remove) the NEXT-BASE comment in the
series files.  But that means that you do have to test them independently
as well, so it is probably not worth the effort.

> But that's ok, I'll fix up the driver-core tree right now.

Thanks.

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

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

Re: linux-next: driver-core tree build failure

[Greg KH]

On Wed, Nov 19, 2008 at 01:22:14PM +1100, Stephen Rothwell wrote:
> Hi Kay,
> 
> [Firstly, let me say that I appreciate all the work you are doing ...]
> 
> On Wed, 19 Nov 2008 01:40:42 +0100 "Kay Sievers" <kay.sievers@vrfy.org> wrote:
> >
> > Is this the only one, or only the first failure you've seen with the
> > driver-core tree? Some of the patches we've been unable to test, and
> > unfortunately the maintainers didn't respond for weeks now.
> 
> It is the first since that series of patches was added to the
> driver-core tree yesterday, but I have only built for powerpc and x86_64
> so far.
> 
> The patch had a CC for Paul Mackerras but not for the list associated
> with the PowerPC archiecture (in MAINTAINERS - linuxppc-dev@ozlabs.org).
> Some maintainers are very busy and cannot (or don't) test every single
> patch sent to them but the patches would probably would receive more
> attention if CC'd to the associated list.  [I am on the particular list
> and didn't see that patch posted.]
> 
> [And the Acked-by: Geoff Levand would really only cover the ps3 part of
> the patch.]
> 
> In any case, I assume it will be fixed tomorrow in Greg's tree.

Now fixed.

thanks,

greg k-h

Re: linux-next: driver-core tree build failure

[Greg KH]

On Wed, Nov 19, 2008 at 04:43:17PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> On Wed, 19 Nov 2008 11:30:31 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > I have dropped the driver-core tree (and the usb tree that depends on it)
> > from linux-next for today.
> 
> I had to drop the staging tree as well (since it depends on the usb
> tree), of course.

Right now there is no such dependancy (USB should build and apply just
fine without driver core, and staging depends on neither of these from
what I can see.)

But that's ok, I'll fix up the driver-core tree right now.

thanks,

greg k-h

Re: linux-next: driver-core tree build failure

[Stephen Rothwell]

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

Hi Greg,

On Wed, 19 Nov 2008 11:30:31 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I have dropped the driver-core tree (and the usb tree that depends on it)
> from linux-next for today.

I had to drop the staging tree as well (since it depends on the usb
tree), of course.

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

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

Re: linux-next: driver-core tree build failure

[Stephen Rothwell]

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

On Wed, 19 Nov 2008 13:22:14 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Wed, 19 Nov 2008 01:40:42 +0100 "Kay Sievers" <kay.sievers@vrfy.org> wrote:
> >
> > Is this the only one, or only the first failure you've seen with the
> > driver-core tree? Some of the patches we've been unable to test, and
> > unfortunately the maintainers didn't respond for weeks now.
> 
> In any case, I assume it will be fixed tomorrow in Greg's tree.

And maybe only the tested patches should have been put into Greg's
linux-next tree, hmmm?

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

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

Re: linux-next: driver-core tree build failure

[Stephen Rothwell]

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

Hi Kay,

[Firstly, let me say that I appreciate all the work you are doing ...]

On Wed, 19 Nov 2008 01:40:42 +0100 "Kay Sievers" <kay.sievers@vrfy.org> wrote:
>
> Is this the only one, or only the first failure you've seen with the
> driver-core tree? Some of the patches we've been unable to test, and
> unfortunately the maintainers didn't respond for weeks now.

It is the first since that series of patches was added to the
driver-core tree yesterday, but I have only built for powerpc and x86_64
so far.

The patch had a CC for Paul Mackerras but not for the list associated
with the PowerPC archiecture (in MAINTAINERS - linuxppc-dev@ozlabs.org).
Some maintainers are very busy and cannot (or don't) test every single
patch sent to them but the patches would probably would receive more
attention if CC'd to the associated list.  [I am on the particular list
and didn't see that patch posted.]

[And the Acked-by: Geoff Levand would really only cover the ps3 part of
the patch.]

In any case, I assume it will be fixed tomorrow in Greg's tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: driver-core tree build failure

[Kay Sievers]

On Wed, Nov 19, 2008 at 01:30, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> arch/powerpc/kernel/vio.c: In function 'vio_register_device_node':
> arch/powerpc/kernel/vio.c:1246: error: incompatible type for argument 1 of 'dev_name'
>
> Caused by commit 92136135687b1f8f5d3f03baa3cec40dbc6e73e9 ("powerpc:
> struct device - replace bus_id with dev_name(), dev_set_name()").
>
> I have dropped the driver-core tree (and the usb tree that depends on it)
> from linux-next for today.

Yep, a '&' is missing. It should be
  -                               __func__, viodev->dev.bus_id);
 +                               __func__, dev_name(&viodev->dev));

Is this the only one, or only the first failure you've seen with the
driver-core tree? Some of the patches we've been unable to test, and
unfortunately the maintainers didn't respond for weeks now.

Thanks,
Kay

linux-next: driver-core tree build failure

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

arch/powerpc/kernel/vio.c: In function 'vio_register_device_node':
arch/powerpc/kernel/vio.c:1246: error: incompatible type for argument 1 of 'dev_name'

Caused by commit 92136135687b1f8f5d3f03baa3cec40dbc6e73e9 ("powerpc:
struct device - replace bus_id with dev_name(), dev_set_name()").

I have dropped the driver-core tree (and the usb tree that depends on it)
from linux-next for today. 
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: driver-core tree build failure

[Greg KH]

On Fri, Sep 12, 2008 at 01:53:11PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> drivers/net/wireless/atmel_cs.c: In function 'atmel_config':
> drivers/net/wireless/atmel_cs.c:237: error: incompatible type for argument 1 of 'dev_get_drvdata'
> 
> Introduced by commit 107aeb9753159da848f066b26557f0aaab900a90 ("Driver
> core: Use dev_get_drvdata() accessors").  handle_to_dev returns a struct
> device not a struct device *.
> 
> I applied the following patch.
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 12 Sep 2008 13:50:07 +1000
> Subject: [PATCH] driver-core: atmel_cs.c fixup
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Merged in, thanks.

greg k-h

linux-next: driver-core tree build failure

[Stephen Rothwell]

Hi Greg,

Today's linux-next build (x86_64 allmodconfig) failed like this:

drivers/net/wireless/atmel_cs.c: In function 'atmel_config':
drivers/net/wireless/atmel_cs.c:237: error: incompatible type for argument 1 of 'dev_get_drvdata'

Introduced by commit 107aeb9753159da848f066b26557f0aaab900a90 ("Driver
core: Use dev_get_drvdata() accessors").  handle_to_dev returns a struct
device not a struct device *.

I applied the following patch.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 12 Sep 2008 13:50:07 +1000
Subject: [PATCH] driver-core: atmel_cs.c fixup

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

diff --git a/drivers/net/wireless/atmel_cs.c b/drivers/net/wireless/atmel_cs.c
index 9b002cc..8ef37d0 100644
--- a/drivers/net/wireless/atmel_cs.c
+++ b/drivers/net/wireless/atmel_cs.c
@@ -234,7 +234,7 @@ static int atmel_config(struct pcmcia_device *link)
 	struct pcmcia_device_id *did;
 
 	dev = link->priv;
-	did = dev_get_drvdata(handle_to_dev(link));
+	did = dev_get_drvdata(&handle_to_dev(link));
 
 	DEBUG(0, "atmel_config(0x%p)\n", link);
 
-- 
1.5.6.3

Re: linux-next: driver-core tree build failure

[Greg KH]

On Fri, Aug 15, 2008 at 06:25:36PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next build (powerpc allyesconfig) failed like this:
> 
> drivers/usb/gadget/f_ecm.c:737: error: __ksymtab_ecm_bind causes a section type conflict
> 
> You really shouldn't EXPORT static functions.  I applied the patch below.

Ick, sorry about that.  I'm still working with David Brownell how to
handle this kind of change, he has a different proposal now.

thanks,

greg k-h

linux-next: driver-core tree build failure

[Stephen Rothwell]

Hi Greg,

Today's linux-next build (powerpc allyesconfig) failed like this:

drivers/usb/gadget/f_ecm.c:737: error: __ksymtab_ecm_bind causes a section type conflict

You really shouldn't EXPORT static functions.  I applied the patch below.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --git a/drivers/usb/gadget/f_ecm.c b/drivers/usb/gadget/f_ecm.c
index ff85c9d..6d0a88c 100644
--- a/drivers/usb/gadget/f_ecm.c
+++ b/drivers/usb/gadget/f_ecm.c
@@ -599,7 +599,7 @@ static void ecm_close(struct gether *geth)
 
 /* ethernet function driver setup/binding */
 
-static int __init
+int __init
 ecm_bind(struct usb_configuration *c, struct usb_function *f)
 {
 	struct usb_composite_dev *cdev = c->cdev;