From: Randy Dunlap <rdunlap@infradead.org>
To: simon@mungewell.org
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Jiri Kosina <jkosina@suse.cz>,
"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>
Subject: Re: [PATCH -next] hid: fix hid-steelseries kconfig/build
Date: Wed, 01 May 2013 12:39:57 -0700 [thread overview]
Message-ID: <51816F8D.80607@infradead.org> (raw)
In-Reply-To: <c23b45b45b6a27055cdf18fe4dbc6309.squirrel@www.mungewell.org>
On 05/01/13 12:27, simon@mungewell.org wrote:
> Hi Randy and all,
> Seems like you found a problem... but the relevant sections of
> 'hid-steelseries.c' already have
> --
> #if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE)
which should be replaced with:
#include <linux/kconfig.h>
#if IS_ENABLED(LEDS_CLASS)
> ...
> #endif
> --
>
> Shouldn't this prevent the module having calls to register/unregister if
> the LED_CLASS is not enabled?
Please read the patch description. CONFIG_LEDS_CLASS=m but CONFIG_HID_STEELSEREIS=y.
A builtin driver cannot make calls to a modular driver if the modular driver
is not loaded. Is there a way to require that the modular driver is loaded
for hid-steelseries? Maybe so, but I don't know.
> Does forcing a 'depends on LED_CLASS' in Kconfig prevent the
> hid-steelseries module being built on systems without LEDs, or is this
> simply a way to ensure that the LED_CLASS module gets loaded first?
It prevents the driver from being built. I think that a satisfactory solution
would be this small change:
depends on LEDS_CLASS || LEDS_CLASS=n
That makes HID_STEELSERIES depend on LEDS_CLASS when it is enabled but still
allows the driver to build when LEDS_CLASS=n. Makes sense?
Oh, and please don't top-post.
Thanks.
>
> Simon.
>
>> From: Randy Dunlap <rdunlap@infradead.org>
>>
>> Fix hid-steelseries build by making it depends on LEDS_CLASS.
>> Build errors happen when LEDS_CLASS=m and HID_STEELSERIES=y.
>>
>> drivers/built-in.o: In function `steelseries_srws1_remove':
>> hid-steelseries.c:(.text+0x3b97a1): undefined reference to
>> `led_classdev_unregister'
>> drivers/built-in.o: In function `steelseries_srws1_probe':
>> hid-steelseries.c:(.text+0x3b9c51): undefined reference to
>> `led_classdev_register'
>> hid-steelseries.c:(.text+0x3b9ce5): undefined reference to
>> `led_classdev_register'
>> hid-steelseries.c:(.text+0x3b9d4b): undefined reference to
>> `led_classdev_unregister'
>>
>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>> ---
>> drivers/hid/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> --- linux-next-20130501.orig/drivers/hid/Kconfig
>> +++ linux-next-20130501/drivers/hid/Kconfig
>> @@ -610,6 +610,7 @@ config HID_SPEEDLINK
>> config HID_STEELSERIES
>> tristate "Steelseries SRW-S1 steering wheel support"
>> depends on HID
>> + depends on LEDS_CLASS
>> ---help---
>> Support for Steelseries SRW-S1 steering wheel
>>
>> --
--
~Randy
next prev parent reply other threads:[~2013-05-01 19:40 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-01 8:37 linux-next: Tree for May 1 Stephen Rothwell
2013-05-01 11:22 ` Sedat Dilek
2013-05-01 17:59 ` linux-next: Tree for May 1 (media/usb/stk1160) Randy Dunlap
2013-05-01 19:28 ` Yann E. MORIN
2013-05-01 19:32 ` Randy Dunlap
2013-05-01 19:58 ` David Rientjes
2013-05-01 20:23 ` Randy Dunlap
2013-05-01 20:40 ` David Rientjes
2013-05-01 20:53 ` Yann E. MORIN
2013-05-01 20:58 ` Randy Dunlap
2013-05-02 14:52 ` Mauro Carvalho Chehab
2013-05-02 21:23 ` Randy Dunlap
2013-05-04 17:21 ` Splitting stk1160-ac97 as a module (Re: linux-next: Tree for May 1 (media/usb/stk1160)) Ezequiel Garcia
2013-05-04 19:59 ` Yann E. MORIN
2013-05-06 13:11 ` Ezequiel Garcia
2013-05-01 18:44 ` [PATCH -next] hid: fix hid-steelseries kconfig/build Randy Dunlap
2013-05-01 19:27 ` simon
2013-05-01 19:39 ` Randy Dunlap [this message]
2013-05-01 20:32 ` simon
2013-05-01 19:18 ` [PATCH -next] power: fix lp8788-charger kconfig & build Randy Dunlap
2013-05-01 23:04 ` Kim, Milo
2013-05-03 4:22 ` Anton Vorontsov
2013-05-01 19:27 ` [PATCH -next] staging: sep: fix driver build and kconfig Randy Dunlap
2013-05-02 7:37 ` linux-next: Tree for May 1 ZX
2013-05-02 7:46 ` Hannes Reinecke
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=51816F8D.80607@infradead.org \
--to=rdunlap@infradead.org \
--cc=jkosina@suse.cz \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=simon@mungewell.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).