All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: David Miller <davem@davemloft.net>
Cc: linville@tuxdriver.com, tomas.winkler@intel.com,
	linux-kernel@vger.kernel.org, kaber@trash.net,
	torvalds@linux-foundation.org, akpm@linux-foundation.org,
	netdev@vger.kernel.org, netfilter-devel@vger.kernel.org,
	mabbas@linux.intel.com, ischram@telenet.be, rjw@sisk.pl,
	ivdoorn@gmail.com
Subject: Re: [build bug] drivers/built-in.o: In function `rt2x00leds_resume': : undefined reference to `led_classdev_resume'
Date: Fri, 25 Apr 2008 10:00:33 +0200	[thread overview]
Message-ID: <20080425080033.GA14121@elte.hu> (raw)
In-Reply-To: <20080425.003947.72853787.davem@davemloft.net>


* 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.

  reply	other threads:[~2008-04-25  8:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-20  8:13 [build bug] drivers/built-in.o: In function `rt2x00leds_resume': : undefined reference to `led_classdev_resume' Ingo Molnar
2008-04-20  8:54 ` David Miller
2008-04-20  9:05 ` David Miller
2008-04-20  9:31   ` Ivo van Doorn
2008-04-20  9:47     ` David Miller
2008-04-20 10:01       ` David Miller
2008-04-25  7:35   ` Ingo Molnar
2008-04-25  7:39     ` David Miller
2008-04-25  8:00       ` Ingo Molnar [this message]
2008-04-25  8:05         ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080425080033.GA14121@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=ischram@telenet.be \
    --cc=ivdoorn@gmail.com \
    --cc=kaber@trash.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=mabbas@linux.intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=tomas.winkler@intel.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.