[build bug] drivers/built-in.o: In function `rt2x00leds_resume': : undefined reference to `led_classdev_resume'

[build bug] drivers/built-in.o: In function `rt2x00leds_resume': : undefined reference to `led_classdev_resume'

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> a third -git build failure triggered in last night's x86.git 
> build/boot testing:

and after i restarted last night's QA run, within a few iterations a 
fourth build failure popped up:

  drivers/built-in.o: In function `rt2x00leds_resume':
  : undefined reference to `led_classdev_resume'
  drivers/built-in.o: In function `rt2x00leds_resume':
  : undefined reference to `led_classdev_resume'
  [...]

config:

  http://redhat.com/~mingo/misc/config-Sun_Apr_20_09_43_01_CEST_2008.bad

suspected commit is: a2e1d52a32 "rt2x00: Remove MAC80211_LEDS 
dependency".

so far the -git track record: 4 networking build failures 1 SCSI build 
failure. (and i'm not picking these bugs nor am i trying to pick any 
fight here - randconfig does)

... and i think a little bit of grumpiness might be in order now: none 
of these commits were announced on lkml, so i have to hijack this thread 
again. As exciting as reporting bugs might seem from the outside, i'm 
supposed to find x86 and scheduler bugs, not networking bugs. Really, 
your practice of removing networking commits and pull requests from lkml 
does not result in a stellar quality track record.

	Ingo

Re: [build bug] drivers/built-in.o: In function `rt2x00leds_resume': : undefined reference to `led_classdev_resume'

[David Miller]

From: Ingo Molnar <mingo@elte.hu>
Date: Sun, 20 Apr 2008 10:13:02 +0200

> Really, your practice of removing networking commits and pull
> requests from lkml does not result in a stellar quality track
> record.

Ingo I started posting them the way you asked me to today.
Because everyone must do as Ingo says or else he'll berate
them on the list every day.

So please, just drop it already.  You got what you wanted.

FWIW, all of the patches in question were posted to netdev and
linux-wireless.  And I already explained my original logic for not
posting the huge networking merge pull request, it's too damn large
(128K or so) to be useful at all and will result in tons of bounces
(which I have to process btw)

But even with all that, I'm doing it now Ingo, just to make you quiet.

So just LEAVE ME ALONE already!

Re: [build bug] drivers/built-in.o: In function `rt2x00leds_resume': : undefined reference to `led_classdev_resume'

[David Miller]

From: Ingo Molnar <mingo@elte.hu>
Date: Sun, 20 Apr 2008 10:13:02 +0200

>   drivers/built-in.o: In function `rt2x00leds_resume':
>   : undefined reference to `led_classdev_resume'
>   drivers/built-in.o: In function `rt2x00leds_resume':
>   : undefined reference to `led_classdev_resume'
>   [...]
> 
> config:
> 
>   http://redhat.com/~mingo/misc/config-Sun_Apr_20_09_43_01_CEST_2008.bad

Thanks for your report.

This is a similar case to the iwlwifi build failure you reported
earlier today (where the leds infrastructure knob is modular but the
driver using the interfaces is built-in).  Therefore, it likely should
use select too.

This should fix it:

rt2x00: Select LEDS_CLASS instead of using 'depends'.

Based upon a build failure reported by Ingo Molnar.

Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/drivers/net/wireless/rt2x00/Kconfig b/drivers/net/wireless/rt2x00/Kconfig
index a1e3938..ab1029e 100644
--- a/drivers/net/wireless/rt2x00/Kconfig
+++ b/drivers/net/wireless/rt2x00/Kconfig
@@ -60,7 +60,8 @@ config RT2400PCI_RFKILL
 
 config RT2400PCI_LEDS
 	bool "RT2400 leds support"
-	depends on RT2400PCI && LEDS_CLASS
+	depends on RT2400PCI
+	select LEDS_CLASS
 	select RT2X00_LIB_LEDS
 	---help---
 	  This adds support for led triggers provided my mac80211.
@@ -86,7 +87,8 @@ config RT2500PCI_RFKILL
 
 config RT2500PCI_LEDS
 	bool "RT2500 leds support"
-	depends on RT2500PCI && LEDS_CLASS
+	depends on RT2500PCI
+	select LEDS_CLASS
 	select RT2X00_LIB_LEDS
 	---help---
 	  This adds support for led triggers provided my mac80211.
@@ -114,7 +116,8 @@ config RT61PCI_RFKILL
 
 config RT61PCI_LEDS
 	bool "RT61 leds support"
-	depends on RT61PCI && LEDS_CLASS
+	depends on RT61PCI
+	select LEDS_CLASS
 	select RT2X00_LIB_LEDS
 	---help---
 	  This adds support for led triggers provided my mac80211.
@@ -130,7 +133,8 @@ config RT2500USB
 
 config RT2500USB_LEDS
 	bool "RT2500 leds support"
-	depends on RT2500USB && LEDS_CLASS
+	depends on RT2500USB
+	select LEDS_CLASS
 	select RT2X00_LIB_LEDS
 	---help---
 	  This adds support for led triggers provided my mac80211.
@@ -148,7 +152,8 @@ config RT73USB
 
 config RT73USB_LEDS
 	bool "RT73 leds support"
-	depends on RT73USB && LEDS_CLASS
+	depends on RT73USB
+	select LEDS_CLASS
 	select RT2X00_LIB_LEDS
 	---help---
 	  This adds support for led triggers provided my mac80211.

Re: [build bug] drivers/built-in.o: In function `rt2x00leds_resume': : undefined reference to `led_classdev_resume'

[Ivo van Doorn]

On Sunday 20 April 2008, David Miller wrote:
> From: Ingo Molnar <mingo@elte.hu>
> Date: Sun, 20 Apr 2008 10:13:02 +0200
> 
> >   drivers/built-in.o: In function `rt2x00leds_resume':
> >   : undefined reference to `led_classdev_resume'
> >   drivers/built-in.o: In function `rt2x00leds_resume':
> >   : undefined reference to `led_classdev_resume'
> >   [...]
> > 
> > config:
> > 
> >   http://redhat.com/~mingo/misc/config-Sun_Apr_20_09_43_01_CEST_2008.bad
> 
> Thanks for your report.
> 
> This is a similar case to the iwlwifi build failure you reported
> earlier today (where the leds infrastructure knob is modular but the
> driver using the interfaces is built-in).  Therefore, it likely should
> use select too.
> 
> This should fix it:
> 
> rt2x00: Select LEDS_CLASS instead of using 'depends'.
> 
> Based upon a build failure reported by Ingo Molnar.
> 
> Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> diff --git a/drivers/net/wireless/rt2x00/Kconfig b/drivers/net/wireless/rt2x00/Kconfig
> index a1e3938..ab1029e 100644
> --- a/drivers/net/wireless/rt2x00/Kconfig
> +++ b/drivers/net/wireless/rt2x00/Kconfig
> @@ -60,7 +60,8 @@ config RT2400PCI_RFKILL
>  
>  config RT2400PCI_LEDS
>  	bool "RT2400 leds support"
> -	depends on RT2400PCI && LEDS_CLASS
> +	depends on RT2400PCI
> +	select LEDS_CLASS

Not sure about it, but doesn't LEDS_CLASS depend on NEW_LEDS ?
Which would make selecting LEDS_CLASS broken when NEW_LEDS isn't enabled?

>  	select RT2X00_LIB_LEDS
>  	---help---
>  	  This adds support for led triggers provided my mac80211.
> @@ -86,7 +87,8 @@ config RT2500PCI_RFKILL
>  
>  config RT2500PCI_LEDS
>  	bool "RT2500 leds support"
> -	depends on RT2500PCI && LEDS_CLASS
> +	depends on RT2500PCI
> +	select LEDS_CLASS
>  	select RT2X00_LIB_LEDS
>  	---help---
>  	  This adds support for led triggers provided my mac80211.
> @@ -114,7 +116,8 @@ config RT61PCI_RFKILL
>  
>  config RT61PCI_LEDS
>  	bool "RT61 leds support"
> -	depends on RT61PCI && LEDS_CLASS
> +	depends on RT61PCI
> +	select LEDS_CLASS
>  	select RT2X00_LIB_LEDS
>  	---help---
>  	  This adds support for led triggers provided my mac80211.
> @@ -130,7 +133,8 @@ config RT2500USB
>  
>  config RT2500USB_LEDS
>  	bool "RT2500 leds support"
> -	depends on RT2500USB && LEDS_CLASS
> +	depends on RT2500USB
> +	select LEDS_CLASS
>  	select RT2X00_LIB_LEDS
>  	---help---
>  	  This adds support for led triggers provided my mac80211.
> @@ -148,7 +152,8 @@ config RT73USB
>  
>  config RT73USB_LEDS
>  	bool "RT73 leds support"
> -	depends on RT73USB && LEDS_CLASS
> +	depends on RT73USB
> +	select LEDS_CLASS
>  	select RT2X00_LIB_LEDS
>  	---help---
>  	  This adds support for led triggers provided my mac80211.
> 

Ivo

Re: [build bug] drivers/built-in.o: In function `rt2x00leds_resume': : undefined reference to `led_classdev_resume'

[David Miller]

From: Ivo van Doorn <ivdoorn@gmail.com>
Date: Sun, 20 Apr 2008 11:31:00 +0200

> Not sure about it, but doesn't LEDS_CLASS depend on NEW_LEDS ?
> Which would make selecting LEDS_CLASS broken when NEW_LEDS isn't enabled?

True, what an awful dependency chain.

NEW_LEDS requires HAS_IOMEM.  This is to handle platforms like
S390 and UM.

But I think this protection is overboard.  Specific drivers
might need IOMEM functionality, but the basic infrastructure
does not.

All of the core infrastrucure and generic LEDS facilities, including
NEW_LEDS, LEDS_CLASS, and LEDS_TRIGGERS, don't need the IOMEM
protection.

And neither do the LED device drivers, they already each have a
depenency for a specific platform.

You could even imagine a hypervisor based LED driver that a platform
like S390, which does not enable HAS_IOMEM, might want to support
under this infrastructure.

I think NEW_LEDS can be completely eliminated.

Re: [build bug] drivers/built-in.o: In function `rt2x00leds_resume': : undefined reference to `led_classdev_resume'

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Sun, 20 Apr 2008 02:47:04 -0700 (PDT)

> I think NEW_LEDS can be completely eliminated.

Actually, more accurately, I propose removing the HAS_IOMEM
restriction.

This allows LEDS infrastructure to be select'd by drivers safely.

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 859814f..91d36d0 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -1,6 +1,5 @@
 menuconfig NEW_LEDS
 	bool "LED Support"
-	depends on HAS_IOMEM
 	help
 	  Say Y to enable Linux LED support.  This allows control of supported
 	  LEDs from both userspace and optionally, by kernel events (triggers).

Re: [build bug] drivers/built-in.o: In function `rt2x00leds_resume': : undefined reference to `led_classdev_resume'

[Ingo Molnar]

* David Miller <davem@davemloft.net> wrote:

> Thanks for your report.
> 
> This is a similar case to the iwlwifi build failure you reported 
> earlier today (where the leds infrastructure knob is modular but the 
> driver using the interfaces is built-in).  Therefore, it likely should 
> use select too.
> 
> This should fix it:
> 
> rt2x00: Select LEDS_CLASS instead of using 'depends'.

hm, it seems there's still some small hole left in its Kconfig 
structure, overnight testing triggered this randconfig combination:

|  drivers/built-in.o: In function `rt2x00leds_resume':
|  : undefined reference to `led_classdev_resume'
|  drivers/built-in.o: In function `rt2x00leds_resume':
|  : undefined reference to `led_classdev_resume'
|
|  http://redhat.com/~mingo/misc/config-Fri_Apr_25_08_50_47_CEST_2008.bad

... no biggie though, the usual distro configs build fine. I've 
reinstated the quick hack below.

btw., for some reason LEDS was a source of various build problems in the 
past too - we fought with it in the x86 tree as well in .25. It seems to 
have problems much more so than other config options that get select-ed. 
Perhaps there's something particularly fragile about LEDS?

	Ingo

-------------->
Subject: rt2x00: turn off temporarily
From: Ingo Molnar <mingo@elte.hu>
Date: Sun Apr 20 10:18:45 CEST 2008

NOT-Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 drivers/net/wireless/rt2x00/Kconfig |    4 ++++
 1 file changed, 4 insertions(+)

Index: linux/drivers/net/wireless/rt2x00/Kconfig
===================================================================
--- linux.orig/drivers/net/wireless/rt2x00/Kconfig
+++ linux/drivers/net/wireless/rt2x00/Kconfig
@@ -62,6 +62,7 @@ config RT2400PCI_LEDS
 	bool "RT2400 leds support"
 	depends on RT2400PCI
 	select LEDS_CLASS
+	depends on 0
 	select RT2X00_LIB_LEDS
 	---help---
 	  This adds support for led triggers provided my mac80211.
@@ -89,6 +90,7 @@ config RT2500PCI_LEDS
 	bool "RT2500 leds support"
 	depends on RT2500PCI
 	select LEDS_CLASS
+	depends on 0
 	select RT2X00_LIB_LEDS
 	---help---
 	  This adds support for led triggers provided my mac80211.
@@ -118,6 +120,7 @@ config RT61PCI_LEDS
 	bool "RT61 leds support"
 	depends on RT61PCI
 	select LEDS_CLASS
+	depends on 0
 	select RT2X00_LIB_LEDS
 	---help---
 	  This adds support for led triggers provided my mac80211.
@@ -154,6 +157,7 @@ config RT73USB_LEDS
 	bool "RT73 leds support"
 	depends on RT73USB
 	select LEDS_CLASS
+	depends on 0
 	select RT2X00_LIB_LEDS
 	---help---
 	  This adds support for led triggers provided my mac80211.

Re: [build bug] drivers/built-in.o: In function `rt2x00leds_resume': : undefined reference to `led_classdev_resume'

[David Miller]

From: Ingo Molnar <mingo@elte.hu>
Date: Fri, 25 Apr 2008 09:35:04 +0200

> hm, it seems there's still some small hole left in its Kconfig 
> structure, overnight testing triggered this randconfig combination:
> 
> |  drivers/built-in.o: In function `rt2x00leds_resume':
> |  : undefined reference to `led_classdev_resume'
> |  drivers/built-in.o: In function `rt2x00leds_resume':
> |  : undefined reference to `led_classdev_resume'
> |
> |  http://redhat.com/~mingo/misc/config-Fri_Apr_25_08_50_47_CEST_2008.bad

This was reported elsewhere as well.

I was sure that the patch below fixed it.

I don't understand how it can still fail, unless the problem is that
selecting "FOO" does not take care to enable any dependencies of
"FOO".

commit 201410ce85d80b7b893cdc72e944a1341dd393f1
Author: David S. Miller <davem@davemloft.net>
Date:   Wed Apr 23 03:34:50 2008 -0700

    rt2x00: Select LEDS_CLASS.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/drivers/net/wireless/rt2x00/Kconfig b/drivers/net/wireless/rt2x00/Kconfig
index a1e3938..ab1029e 100644
--- a/drivers/net/wireless/rt2x00/Kconfig
+++ b/drivers/net/wireless/rt2x00/Kconfig
@@ -60,7 +60,8 @@ config RT2400PCI_RFKILL
 
 config RT2400PCI_LEDS
 	bool "RT2400 leds support"
-	depends on RT2400PCI && LEDS_CLASS
+	depends on RT2400PCI
+	select LEDS_CLASS
 	select RT2X00_LIB_LEDS
 	---help---
 	  This adds support for led triggers provided my mac80211.
@@ -86,7 +87,8 @@ config RT2500PCI_RFKILL
 
 config RT2500PCI_LEDS
 	bool "RT2500 leds support"
-	depends on RT2500PCI && LEDS_CLASS
+	depends on RT2500PCI
+	select LEDS_CLASS
 	select RT2X00_LIB_LEDS
 	---help---
 	  This adds support for led triggers provided my mac80211.
@@ -114,7 +116,8 @@ config RT61PCI_RFKILL
 
 config RT61PCI_LEDS
 	bool "RT61 leds support"
-	depends on RT61PCI && LEDS_CLASS
+	depends on RT61PCI
+	select LEDS_CLASS
 	select RT2X00_LIB_LEDS
 	---help---
 	  This adds support for led triggers provided my mac80211.
@@ -130,7 +133,8 @@ config RT2500USB
 
 config RT2500USB_LEDS
 	bool "RT2500 leds support"
-	depends on RT2500USB && LEDS_CLASS
+	depends on RT2500USB
+	select LEDS_CLASS
 	select RT2X00_LIB_LEDS
 	---help---
 	  This adds support for led triggers provided my mac80211.
@@ -148,7 +152,8 @@ config RT73USB
 
 config RT73USB_LEDS
 	bool "RT73 leds support"
-	depends on RT73USB && LEDS_CLASS
+	depends on RT73USB
+	select LEDS_CLASS
 	select RT2X00_LIB_LEDS
 	---help---
 	  This adds support for led triggers provided my mac80211.

Re: [build bug] drivers/built-in.o: In function `rt2x00leds_resume': : undefined reference to `led_classdev_resume'

[Ingo Molnar]

* David Miller <davem@davemloft.net> wrote:

> This was reported elsewhere as well.
> 
> I was sure that the patch below fixed it.
> 
> I don't understand how it can still fail, unless the problem is that 
> selecting "FOO" does not take care to enable any dependencies of 
> "FOO".

yeah, i think that's a fundamental property of select: it does _not_ 
select the sub-dependencies. randconfig found that combination rather 
well it seems:

 # CONFIG_IWLWIFI_LEDS is not set
 # CONFIG_IWL4965_LEDS is not set
 # CONFIG_IWL3945_LEDS is not set
 CONFIG_RT2X00_LIB_LEDS=y
 # CONFIG_RT61PCI_LEDS is not set
 CONFIG_RT73USB_LEDS=y
 # CONFIG_NEW_LEDS is not set
 CONFIG_LEDS_CLASS=y

this weakness of select is the major reason why "select is evil" has 
been propagated.

personally i always considered this a Kconfig bug - although it's 
probably not an easy issue to solve. (what if there are conflicts? What 
if a driver's select choice disables another driver, without the user 
being openly aware of this side-effect?)

the patch below fixes it here but it's still kind of a band-aid - what 
if the Kconfig structure of LEDS get modified - does that have to be 
propagated to all LEDS using drivers? I dont think this necessity of 
open-coded dependency resolution is maintainable in the long run.

	Ingo

----------------->
Subject: rt2x00: leds fix
From: Ingo Molnar <mingo@elte.hu>
Date: Fri Apr 25 09:41:26 CEST 2008

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 drivers/net/wireless/rt2x00/Kconfig |    5 +++++
 1 file changed, 5 insertions(+)

Index: linux/drivers/net/wireless/rt2x00/Kconfig
===================================================================
--- linux.orig/drivers/net/wireless/rt2x00/Kconfig
+++ linux/drivers/net/wireless/rt2x00/Kconfig
@@ -62,6 +62,7 @@ config RT2400PCI_LEDS
 	bool "RT2400 leds support"
 	depends on RT2400PCI
 	select LEDS_CLASS
+	select NEW_LEDS
 	select RT2X00_LIB_LEDS
 	---help---
 	  This adds support for led triggers provided my mac80211.
@@ -89,6 +90,7 @@ config RT2500PCI_LEDS
 	bool "RT2500 leds support"
 	depends on RT2500PCI
 	select LEDS_CLASS
+	select NEW_LEDS
 	select RT2X00_LIB_LEDS
 	---help---
 	  This adds support for led triggers provided my mac80211.
@@ -118,6 +120,7 @@ config RT61PCI_LEDS
 	bool "RT61 leds support"
 	depends on RT61PCI
 	select LEDS_CLASS
+	select NEW_LEDS
 	select RT2X00_LIB_LEDS
 	---help---
 	  This adds support for led triggers provided my mac80211.
@@ -135,6 +138,7 @@ config RT2500USB_LEDS
 	bool "RT2500 leds support"
 	depends on RT2500USB
 	select LEDS_CLASS
+	select NEW_LEDS
 	select RT2X00_LIB_LEDS
 	---help---
 	  This adds support for led triggers provided my mac80211.
@@ -154,6 +158,7 @@ config RT73USB_LEDS
 	bool "RT73 leds support"
 	depends on RT73USB
 	select LEDS_CLASS
+	select NEW_LEDS
 	select RT2X00_LIB_LEDS
 	---help---
 	  This adds support for led triggers provided my mac80211.

Re: [build bug] drivers/built-in.o: In function `rt2x00leds_resume': : undefined reference to `led_classdev_resume'

[David Miller]

From: Ingo Molnar <mingo@elte.hu>
Date: Fri, 25 Apr 2008 10:00:33 +0200

> personally i always considered this a Kconfig bug - although it's 
> probably not an easy issue to solve. (what if there are conflicts? What 
> if a driver's select choice disables another driver, without the user 
> being openly aware of this side-effect?)

It definitely is seen as a bug in the context of the alternative,
using 'depend' and then forcing people to spend a lot of time trying
to figure out what magic option they have to enable just to turn
on the driver for their wireless card.

> the patch below fixes it here but it's still kind of a band-aid - what 
> if the Kconfig structure of LEDS get modified - does that have to be 
> propagated to all LEDS using drivers? I dont think this necessity of 
> open-coded dependency resolution is maintainable in the long run.

Yes, that would be the way to work around this.

iwlwifi used LEDS and would need a similar workaround.

Maybe part of the problem is the "if NEW_LEDS" construct used
by drivers/leds/Kconfig?  Perhaps we could make this work if
NEW_LEDS appeared as an explicit dependency of the various
LEDS_* options.

Or, maybe it works to make LEDS_CLASS select NEW_LEDS.

I don't know, this is just a gigantic maze, and I'm just throwing out
random ideas.