From: David Miller <davem@davemloft.net>
To: ivdoorn@gmail.com
Cc: mingo@elte.hu, 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
Subject: Re: [build bug] drivers/built-in.o: In function `rt2x00leds_resume': : undefined reference to `led_classdev_resume'
Date: Sun, 20 Apr 2008 02:47:04 -0700 (PDT) [thread overview]
Message-ID: <20080420.024704.02026708.davem@davemloft.net> (raw)
In-Reply-To: <200804201131.01504.IvDoorn@gmail.com>
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.
next prev parent reply other threads:[~2008-04-20 9:47 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 [this message]
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
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=20080420.024704.02026708.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.