All of lore.kernel.org
 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:39 UTC|newest]

Thread overview: 32+ 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  8:37 ` 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 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.