linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  reply	other threads:[~2013-05-01 19:40 UTC|newest]

Thread overview: 31+ 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-02  6:27   ` [PATCH] HID: hid-steelseries fix led class build issue Simon Wood
2013-05-02 21:50     ` Randy Dunlap
2013-05-02 21:58       ` David Rientjes
2013-05-03  1:43         ` [PATCH-V2] " Simon Wood
2013-05-03  8:27           ` Jiri Kosina
2013-05-02  6:30   ` [PATCH] " Simon Wood
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).