All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: mingo@elte.hu
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 01:05:34 -0700 (PDT)	[thread overview]
Message-ID: <20080425.010534.66319216.davem@davemloft.net> (raw)
In-Reply-To: <20080425080033.GA14121@elte.hu>

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.

      reply	other threads:[~2008-04-25  8:05 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
2008-04-25  8:05         ` David Miller [this message]

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=20080425.010534.66319216.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=akpm@linux-foundation.org \
    --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=mingo@elte.hu \
    --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.