[PATCH -mm] rt2x00: fix Kconfig dependencies

[PATCH -mm] rt2x00: fix Kconfig dependencies

[Randy Dunlap]

From: Randy Dunlap <randy.dunlap@oracle.com>

If RT2X00=y but RFKILL=m, these build errors happen:

(.text+0x7c7d6): undefined reference to `rfkill_free'
rt2x00rfkill.c:(.text+0x7c830): undefined reference to `rfkill_force_state'
(.text+0x7c88d): undefined reference to `rfkill_unregister'
(.text+0x7c8cd): undefined reference to `rfkill_register'
(.text+0x7ca1a): undefined reference to `rfkill_allocate'

so restrict RT2X00's RFKILL config level to that of the main RFKILL option.
This is done by making the former a tristate instead of a bool
config option.


If RT2X00=y but LEDS_CLASS=m, these build errors happen:

(.text+0x11859f): undefined reference to `led_classdev_resume'
(.text+0x1185b3): undefined reference to `led_classdev_resume'
(.text+0x1185c7): undefined reference to `led_classdev_resume'
(.text+0x1185e4): undefined reference to `led_classdev_suspend'
(.text+0x1185f8): undefined reference to `led_classdev_suspend'
(.text+0x11860c): undefined reference to `led_classdev_suspend'
rt2x00leds.c:(.text+0x118620): undefined reference to `led_classdev_unregister'
rt2x00leds.c:(.text+0x118695): undefined reference to `led_classdev_register'

so restrict RT2X00's LEDS config level to that of the main LEDS_CLASS option.
This is done by making the former a tristate instead of a bool
config option.

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
 drivers/net/wireless/rt2x00/Kconfig |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- mmotm-2008-0922-0136.orig/drivers/net/wireless/rt2x00/Kconfig
+++ mmotm-2008-0922-0136/drivers/net/wireless/rt2x00/Kconfig
@@ -38,13 +38,13 @@ config RT2X00_LIB_CRYPTO
 	depends on RT2X00_LIB
 
 config RT2X00_LIB_RFKILL
-	boolean
+	tristate
 	depends on RT2X00_LIB
 	depends on RFKILL
 	default y
 
 config RT2X00_LIB_LEDS
-	boolean
+	tristate
 	depends on RT2X00_LIB
 	depends on NEW_LEDS
 	depends on LEDS_CLASS

Re: [PATCH -mm] rt2x00: fix Kconfig dependencies

[Ivo van Doorn]

On Tuesday 23 September 2008, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> If RT2X00=y but RFKILL=m, these build errors happen:
> 
> (.text+0x7c7d6): undefined reference to `rfkill_free'
> rt2x00rfkill.c:(.text+0x7c830): undefined reference to `rfkill_force_state'
> (.text+0x7c88d): undefined reference to `rfkill_unregister'
> (.text+0x7c8cd): undefined reference to `rfkill_register'
> (.text+0x7ca1a): undefined reference to `rfkill_allocate'
> 
> so restrict RT2X00's RFKILL config level to that of the main RFKILL option.
> This is done by making the former a tristate instead of a bool
> config option.
> 
> 
> If RT2X00=y but LEDS_CLASS=m, these build errors happen:
> 
> (.text+0x11859f): undefined reference to `led_classdev_resume'
> (.text+0x1185b3): undefined reference to `led_classdev_resume'
> (.text+0x1185c7): undefined reference to `led_classdev_resume'
> (.text+0x1185e4): undefined reference to `led_classdev_suspend'
> (.text+0x1185f8): undefined reference to `led_classdev_suspend'
> (.text+0x11860c): undefined reference to `led_classdev_suspend'
> rt2x00leds.c:(.text+0x118620): undefined reference to `led_classdev_unregister'
> rt2x00leds.c:(.text+0x118695): undefined reference to `led_classdev_register'
> 
> so restrict RT2X00's LEDS config level to that of the main LEDS_CLASS option.
> This is done by making the former a tristate instead of a bool
> config option.

Is that really going to work correctly?
rfkill and leds support should be compiled into rt2x00lib.ko, which means that
should become a module instead of the rfkill/leds support part only.

Ivo

> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> ---
>  drivers/net/wireless/rt2x00/Kconfig |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> --- mmotm-2008-0922-0136.orig/drivers/net/wireless/rt2x00/Kconfig
> +++ mmotm-2008-0922-0136/drivers/net/wireless/rt2x00/Kconfig
> @@ -38,13 +38,13 @@ config RT2X00_LIB_CRYPTO
>  	depends on RT2X00_LIB
>  
>  config RT2X00_LIB_RFKILL
> -	boolean
> +	tristate
>  	depends on RT2X00_LIB
>  	depends on RFKILL
>  	default y
>  
>  config RT2X00_LIB_LEDS
> -	boolean
> +	tristate
>  	depends on RT2X00_LIB
>  	depends on NEW_LEDS
>  	depends on LEDS_CLASS
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH -mm] rt2x00: fix Kconfig dependencies

[Randy Dunlap]

Ivo van Doorn wrote:
> On Tuesday 23 September 2008, Randy Dunlap wrote:
>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>
>> If RT2X00=y but RFKILL=m, these build errors happen:
>>
>> (.text+0x7c7d6): undefined reference to `rfkill_free'
>> rt2x00rfkill.c:(.text+0x7c830): undefined reference to `rfkill_force_state'
>> (.text+0x7c88d): undefined reference to `rfkill_unregister'
>> (.text+0x7c8cd): undefined reference to `rfkill_register'
>> (.text+0x7ca1a): undefined reference to `rfkill_allocate'
>>
>> so restrict RT2X00's RFKILL config level to that of the main RFKILL option.
>> This is done by making the former a tristate instead of a bool
>> config option.
>>
>>
>> If RT2X00=y but LEDS_CLASS=m, these build errors happen:
>>
>> (.text+0x11859f): undefined reference to `led_classdev_resume'
>> (.text+0x1185b3): undefined reference to `led_classdev_resume'
>> (.text+0x1185c7): undefined reference to `led_classdev_resume'
>> (.text+0x1185e4): undefined reference to `led_classdev_suspend'
>> (.text+0x1185f8): undefined reference to `led_classdev_suspend'
>> (.text+0x11860c): undefined reference to `led_classdev_suspend'
>> rt2x00leds.c:(.text+0x118620): undefined reference to `led_classdev_unregister'
>> rt2x00leds.c:(.text+0x118695): undefined reference to `led_classdev_register'
>>
>> so restrict RT2X00's LEDS config level to that of the main LEDS_CLASS option.
>> This is done by making the former a tristate instead of a bool
>> config option.
> 
> Is that really going to work correctly?
> rfkill and leds support should be compiled into rt2x00lib.ko, which means that
> should become a module instead of the rfkill/leds support part only.

I wondered about that lib.ko.  Any working build fix is OK with me.
What do you suggest?

Currently kconfig is converting an =m to =y because of tristate -> boolean.
This is not good.  It breaks things, as demonstrated here.
The Kconfig cannot stay like this AFAIK.

> Ivo
> 
>> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
>> ---
>>  drivers/net/wireless/rt2x00/Kconfig |    4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> --- mmotm-2008-0922-0136.orig/drivers/net/wireless/rt2x00/Kconfig
>> +++ mmotm-2008-0922-0136/drivers/net/wireless/rt2x00/Kconfig
>> @@ -38,13 +38,13 @@ config RT2X00_LIB_CRYPTO
>>  	depends on RT2X00_LIB
>>  
>>  config RT2X00_LIB_RFKILL
>> -	boolean
>> +	tristate
>>  	depends on RT2X00_LIB
>>  	depends on RFKILL
>>  	default y
>>  
>>  config RT2X00_LIB_LEDS
>> -	boolean
>> +	tristate
>>  	depends on RT2X00_LIB
>>  	depends on NEW_LEDS
>>  	depends on LEDS_CLASS
>>
>> --

Re: [PATCH -mm] rt2x00: fix Kconfig dependencies

[Ivo van Doorn]

On Tuesday 23 September 2008, Randy Dunlap wrote:
> Ivo van Doorn wrote:
> > On Tuesday 23 September 2008, Randy Dunlap wrote:
> >> From: Randy Dunlap <randy.dunlap@oracle.com>
> >>
> >> If RT2X00=y but RFKILL=m, these build errors happen:
> >>
> >> (.text+0x7c7d6): undefined reference to `rfkill_free'
> >> rt2x00rfkill.c:(.text+0x7c830): undefined reference to `rfkill_force_state'
> >> (.text+0x7c88d): undefined reference to `rfkill_unregister'
> >> (.text+0x7c8cd): undefined reference to `rfkill_register'
> >> (.text+0x7ca1a): undefined reference to `rfkill_allocate'
> >>
> >> so restrict RT2X00's RFKILL config level to that of the main RFKILL option.
> >> This is done by making the former a tristate instead of a bool
> >> config option.
> >>
> >>
> >> If RT2X00=y but LEDS_CLASS=m, these build errors happen:
> >>
> >> (.text+0x11859f): undefined reference to `led_classdev_resume'
> >> (.text+0x1185b3): undefined reference to `led_classdev_resume'
> >> (.text+0x1185c7): undefined reference to `led_classdev_resume'
> >> (.text+0x1185e4): undefined reference to `led_classdev_suspend'
> >> (.text+0x1185f8): undefined reference to `led_classdev_suspend'
> >> (.text+0x11860c): undefined reference to `led_classdev_suspend'
> >> rt2x00leds.c:(.text+0x118620): undefined reference to `led_classdev_unregister'
> >> rt2x00leds.c:(.text+0x118695): undefined reference to `led_classdev_register'
> >>
> >> so restrict RT2X00's LEDS config level to that of the main LEDS_CLASS option.
> >> This is done by making the former a tristate instead of a bool
> >> config option.
> > 
> > Is that really going to work correctly?
> > rfkill and leds support should be compiled into rt2x00lib.ko, which means that
> > should become a module instead of the rfkill/leds support part only.
> 
> I wondered about that lib.ko.  Any working build fix is OK with me.
> What do you suggest?

Actually I was hoping that you answer to my question was going to be "yes it will be working correctly" ;)

Would this work?

config RT2X00_LIB_RFKILL
	tristate
  	depends on RFKILL
  	default y
  
config RT2X00_LIB_LEDS
	tristate
  	depends on NEW_LEDS
  	depends on LEDS_CLASS
	default y

config RT2X00_LIB
	tristate
	depends on RT2X00_LIB_RFKILL if (RT2X00_LIB_RFKILL != n)
	depends on RT2X00_LIB_LEDS if (RT2X00_LIB_LEDS != n)

It's ugly, and I can't test this right now, but perhaps you have an idea if this could do the trick?

> Currently kconfig is converting an =m to =y because of tristate -> boolean.
> This is not good.  It breaks things, as demonstrated here.
> The Kconfig cannot stay like this AFAIK.

Agreed.

> > Ivo
> > 
> >> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> >> ---
> >>  drivers/net/wireless/rt2x00/Kconfig |    4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> --- mmotm-2008-0922-0136.orig/drivers/net/wireless/rt2x00/Kconfig
> >> +++ mmotm-2008-0922-0136/drivers/net/wireless/rt2x00/Kconfig
> >> @@ -38,13 +38,13 @@ config RT2X00_LIB_CRYPTO
> >>  	depends on RT2X00_LIB
> >>  
> >>  config RT2X00_LIB_RFKILL
> >> -	boolean
> >> +	tristate
> >>  	depends on RT2X00_LIB
> >>  	depends on RFKILL
> >>  	default y
> >>  
> >>  config RT2X00_LIB_LEDS
> >> -	boolean
> >> +	tristate
> >>  	depends on RT2X00_LIB
> >>  	depends on NEW_LEDS
> >>  	depends on LEDS_CLASS
> >>
> >> --
> 

Re: [PATCH -mm] rt2x00: fix Kconfig dependencies

[Randy Dunlap]

On Tue, 23 Sep 2008 19:51:00 +0200 Ivo van Doorn wrote:

> On Tuesday 23 September 2008, Randy Dunlap wrote:
> > Ivo van Doorn wrote:
> > > On Tuesday 23 September 2008, Randy Dunlap wrote:
> > >> From: Randy Dunlap <randy.dunlap@oracle.com>
> > >>
> > >> If RT2X00=y but RFKILL=m, these build errors happen:
> > >>
> > >> (.text+0x7c7d6): undefined reference to `rfkill_free'
> > >> rt2x00rfkill.c:(.text+0x7c830): undefined reference to `rfkill_force_state'
> > >> (.text+0x7c88d): undefined reference to `rfkill_unregister'
> > >> (.text+0x7c8cd): undefined reference to `rfkill_register'
> > >> (.text+0x7ca1a): undefined reference to `rfkill_allocate'
> > >>
> > >> so restrict RT2X00's RFKILL config level to that of the main RFKILL option.
> > >> This is done by making the former a tristate instead of a bool
> > >> config option.
> > >>
> > >>
> > >> If RT2X00=y but LEDS_CLASS=m, these build errors happen:
> > >>
> > >> (.text+0x11859f): undefined reference to `led_classdev_resume'
> > >> (.text+0x1185b3): undefined reference to `led_classdev_resume'
> > >> (.text+0x1185c7): undefined reference to `led_classdev_resume'
> > >> (.text+0x1185e4): undefined reference to `led_classdev_suspend'
> > >> (.text+0x1185f8): undefined reference to `led_classdev_suspend'
> > >> (.text+0x11860c): undefined reference to `led_classdev_suspend'
> > >> rt2x00leds.c:(.text+0x118620): undefined reference to `led_classdev_unregister'
> > >> rt2x00leds.c:(.text+0x118695): undefined reference to `led_classdev_register'
> > >>
> > >> so restrict RT2X00's LEDS config level to that of the main LEDS_CLASS option.
> > >> This is done by making the former a tristate instead of a bool
> > >> config option.
> > > 
> > > Is that really going to work correctly?
> > > rfkill and leds support should be compiled into rt2x00lib.ko, which means that
> > > should become a module instead of the rfkill/leds support part only.
> > 
> > I wondered about that lib.ko.  Any working build fix is OK with me.
> > What do you suggest?
> 
> Actually I was hoping that you answer to my question was going to be "yes it will be working correctly" ;)
> 
> Would this work?
> 
> config RT2X00_LIB_RFKILL
> 	tristate
>   	depends on RFKILL
>   	default y
>   
> config RT2X00_LIB_LEDS
> 	tristate
>   	depends on NEW_LEDS
>   	depends on LEDS_CLASS
> 	default y
> 
> config RT2X00_LIB
> 	tristate
> 	depends on RT2X00_LIB_RFKILL if (RT2X00_LIB_RFKILL != n)
> 	depends on RT2X00_LIB_LEDS if (RT2X00_LIB_LEDS != n)
> 
> It's ugly, and I can't test this right now, but perhaps you have an idea if this could do the trick?

I tried it:

drivers/net/wireless/rt2x00/Kconfig:22: invalid option
drivers/net/wireless/rt2x00/Kconfig:23: invalid option

"depends ... if ..." is invalid.  Would be nice to have that.
Maybe there is some other way to express that...


> > Currently kconfig is converting an =m to =y because of tristate -> boolean.
> > This is not good.  It breaks things, as demonstrated here.
> > The Kconfig cannot stay like this AFAIK.
> 
> Agreed.


---
~Randy

Re: [PATCH -mm] rt2x00: fix Kconfig dependencies

[Larry Finger]

Randy Dunlap wrote:
> On Tue, 23 Sep 2008 19:51:00 +0200 Ivo van Doorn wrote:
> 
>> On Tuesday 23 September 2008, Randy Dunlap wrote:
>>> Ivo van Doorn wrote:
>>>> On Tuesday 23 September 2008, Randy Dunlap wrote:
>>>>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>>>>
>>>>> If RT2X00=y but RFKILL=m, these build errors happen:
>>>>>
>>>>> (.text+0x7c7d6): undefined reference to `rfkill_free'
>>>>> rt2x00rfkill.c:(.text+0x7c830): undefined reference to `rfkill_force_state'
>>>>> (.text+0x7c88d): undefined reference to `rfkill_unregister'
>>>>> (.text+0x7c8cd): undefined reference to `rfkill_register'
>>>>> (.text+0x7ca1a): undefined reference to `rfkill_allocate'
>>>>>
>>>>> so restrict RT2X00's RFKILL config level to that of the main RFKILL option.
>>>>> This is done by making the former a tristate instead of a bool
>>>>> config option.
>>>>>
>>>>>
>>>>> If RT2X00=y but LEDS_CLASS=m, these build errors happen:
>>>>>
>>>>> (.text+0x11859f): undefined reference to `led_classdev_resume'
>>>>> (.text+0x1185b3): undefined reference to `led_classdev_resume'
>>>>> (.text+0x1185c7): undefined reference to `led_classdev_resume'
>>>>> (.text+0x1185e4): undefined reference to `led_classdev_suspend'
>>>>> (.text+0x1185f8): undefined reference to `led_classdev_suspend'
>>>>> (.text+0x11860c): undefined reference to `led_classdev_suspend'
>>>>> rt2x00leds.c:(.text+0x118620): undefined reference to `led_classdev_unregister'
>>>>> rt2x00leds.c:(.text+0x118695): undefined reference to `led_classdev_register'
>>>>>
>>>>> so restrict RT2X00's LEDS config level to that of the main LEDS_CLASS option.
>>>>> This is done by making the former a tristate instead of a bool
>>>>> config option.
>>>> Is that really going to work correctly?
>>>> rfkill and leds support should be compiled into rt2x00lib.ko, which means that
>>>> should become a module instead of the rfkill/leds support part only.
>>> I wondered about that lib.ko.  Any working build fix is OK with me.
>>> What do you suggest?
>> Actually I was hoping that you answer to my question was going to be "yes it will be working correctly" ;)
>>
>> Would this work?
>>
>> config RT2X00_LIB_RFKILL
>> 	tristate
>>   	depends on RFKILL
>>   	default y
>>   
>> config RT2X00_LIB_LEDS
>> 	tristate
>>   	depends on NEW_LEDS
>>   	depends on LEDS_CLASS
>> 	default y
>>
>> config RT2X00_LIB
>> 	tristate
>> 	depends on RT2X00_LIB_RFKILL if (RT2X00_LIB_RFKILL != n)
>> 	depends on RT2X00_LIB_LEDS if (RT2X00_LIB_LEDS != n)
>>
>> It's ugly, and I can't test this right now, but perhaps you have an idea if this could do the trick?
> 
> I tried it:
> 
> drivers/net/wireless/rt2x00/Kconfig:22: invalid option
> drivers/net/wireless/rt2x00/Kconfig:23: invalid option
> 
> "depends ... if ..." is invalid.  Would be nice to have that.
> Maybe there is some other way to express that...

Wouldn't this do it?

depends on (RT2X00_LIB_RFKILL == m) || (RT2X00_LIB_RFKILL == y)

In b43, what I think is a similar configuration statement is written as

depends on B43 && (RFKILL = y || RFKILL = B43) && RFKILL_INPUT &&
(INPUT_POLLDEV = y || INPUT_POLLDEV = B43)

Larry

Re: [PATCH -mm] rt2x00: fix Kconfig dependencies

[Ivo van Doorn]

On Tuesday 23 September 2008, Larry Finger wrote:
> Randy Dunlap wrote:
> > On Tue, 23 Sep 2008 19:51:00 +0200 Ivo van Doorn wrote:
> > 
> >> On Tuesday 23 September 2008, Randy Dunlap wrote:
> >>> Ivo van Doorn wrote:
> >>>> On Tuesday 23 September 2008, Randy Dunlap wrote:
> >>>>> From: Randy Dunlap <randy.dunlap@oracle.com>
> >>>>>
> >>>>> If RT2X00=y but RFKILL=m, these build errors happen:
> >>>>>
> >>>>> (.text+0x7c7d6): undefined reference to `rfkill_free'
> >>>>> rt2x00rfkill.c:(.text+0x7c830): undefined reference to `rfkill_force_state'
> >>>>> (.text+0x7c88d): undefined reference to `rfkill_unregister'
> >>>>> (.text+0x7c8cd): undefined reference to `rfkill_register'
> >>>>> (.text+0x7ca1a): undefined reference to `rfkill_allocate'
> >>>>>
> >>>>> so restrict RT2X00's RFKILL config level to that of the main RFKILL option.
> >>>>> This is done by making the former a tristate instead of a bool
> >>>>> config option.
> >>>>>
> >>>>>
> >>>>> If RT2X00=y but LEDS_CLASS=m, these build errors happen:
> >>>>>
> >>>>> (.text+0x11859f): undefined reference to `led_classdev_resume'
> >>>>> (.text+0x1185b3): undefined reference to `led_classdev_resume'
> >>>>> (.text+0x1185c7): undefined reference to `led_classdev_resume'
> >>>>> (.text+0x1185e4): undefined reference to `led_classdev_suspend'
> >>>>> (.text+0x1185f8): undefined reference to `led_classdev_suspend'
> >>>>> (.text+0x11860c): undefined reference to `led_classdev_suspend'
> >>>>> rt2x00leds.c:(.text+0x118620): undefined reference to `led_classdev_unregister'
> >>>>> rt2x00leds.c:(.text+0x118695): undefined reference to `led_classdev_register'
> >>>>>
> >>>>> so restrict RT2X00's LEDS config level to that of the main LEDS_CLASS option.
> >>>>> This is done by making the former a tristate instead of a bool
> >>>>> config option.
> >>>> Is that really going to work correctly?
> >>>> rfkill and leds support should be compiled into rt2x00lib.ko, which means that
> >>>> should become a module instead of the rfkill/leds support part only.
> >>> I wondered about that lib.ko.  Any working build fix is OK with me.
> >>> What do you suggest?
> >> Actually I was hoping that you answer to my question was going to be "yes it will be working correctly" ;)
> >>
> >> Would this work?
> >>
> >> config RT2X00_LIB_RFKILL
> >> 	tristate
> >>   	depends on RFKILL
> >>   	default y
> >>   
> >> config RT2X00_LIB_LEDS
> >> 	tristate
> >>   	depends on NEW_LEDS
> >>   	depends on LEDS_CLASS
> >> 	default y
> >>
> >> config RT2X00_LIB
> >> 	tristate
> >> 	depends on RT2X00_LIB_RFKILL if (RT2X00_LIB_RFKILL != n)
> >> 	depends on RT2X00_LIB_LEDS if (RT2X00_LIB_LEDS != n)
> >>
> >> It's ugly, and I can't test this right now, but perhaps you have an idea if this could do the trick?
> > 
> > I tried it:
> > 
> > drivers/net/wireless/rt2x00/Kconfig:22: invalid option
> > drivers/net/wireless/rt2x00/Kconfig:23: invalid option
> > 
> > "depends ... if ..." is invalid.  Would be nice to have that.
> > Maybe there is some other way to express that...
> 
> Wouldn't this do it?
> 
> depends on (RT2X00_LIB_RFKILL == m) || (RT2X00_LIB_RFKILL == y)
> 
> In b43, what I think is a similar configuration statement is written as
> 
> depends on B43 && (RFKILL = y || RFKILL = B43) && RFKILL_INPUT &&
> (INPUT_POLLDEV = y || INPUT_POLLDEV = B43)

Wouldn't that completely disable the config option when the rfkill is build
as module and b43 buildin? I think what you want in that scenario would be
building b43 as module instead.
On the other hand, such Kconfig expression is apparently not possible,
which means your approach would be the closest match.

Ivo

Re: [PATCH -mm] rt2x00: fix Kconfig dependencies

[Randy Dunlap]

On Wed, 24 Sep 2008 00:09:31 +0200 Ivo van Doorn wrote:

> On Tuesday 23 September 2008, Larry Finger wrote:
> > Randy Dunlap wrote:
> > > On Tue, 23 Sep 2008 19:51:00 +0200 Ivo van Doorn wrote:
> > > 
> > >> On Tuesday 23 September 2008, Randy Dunlap wrote:
> > >>> Ivo van Doorn wrote:
> > >>>> On Tuesday 23 September 2008, Randy Dunlap wrote:
> > >>>>> From: Randy Dunlap <randy.dunlap@oracle.com>
> > >>>>>
> > >>>>> If RT2X00=y but RFKILL=m, these build errors happen:
> > >>>>>
> > >>>>> (.text+0x7c7d6): undefined reference to `rfkill_free'
> > >>>>> rt2x00rfkill.c:(.text+0x7c830): undefined reference to `rfkill_force_state'
> > >>>>> (.text+0x7c88d): undefined reference to `rfkill_unregister'
> > >>>>> (.text+0x7c8cd): undefined reference to `rfkill_register'
> > >>>>> (.text+0x7ca1a): undefined reference to `rfkill_allocate'
> > >>>>>
> > >>>>> so restrict RT2X00's RFKILL config level to that of the main RFKILL option.
> > >>>>> This is done by making the former a tristate instead of a bool
> > >>>>> config option.
> > >>>>>
> > >>>>>
> > >>>>> If RT2X00=y but LEDS_CLASS=m, these build errors happen:
> > >>>>>
> > >>>>> (.text+0x11859f): undefined reference to `led_classdev_resume'
> > >>>>> (.text+0x1185b3): undefined reference to `led_classdev_resume'
> > >>>>> (.text+0x1185c7): undefined reference to `led_classdev_resume'
> > >>>>> (.text+0x1185e4): undefined reference to `led_classdev_suspend'
> > >>>>> (.text+0x1185f8): undefined reference to `led_classdev_suspend'
> > >>>>> (.text+0x11860c): undefined reference to `led_classdev_suspend'
> > >>>>> rt2x00leds.c:(.text+0x118620): undefined reference to `led_classdev_unregister'
> > >>>>> rt2x00leds.c:(.text+0x118695): undefined reference to `led_classdev_register'
> > >>>>>
> > >>>>> so restrict RT2X00's LEDS config level to that of the main LEDS_CLASS option.
> > >>>>> This is done by making the former a tristate instead of a bool
> > >>>>> config option.
> > >>>> Is that really going to work correctly?
> > >>>> rfkill and leds support should be compiled into rt2x00lib.ko, which means that
> > >>>> should become a module instead of the rfkill/leds support part only.
> > >>> I wondered about that lib.ko.  Any working build fix is OK with me.
> > >>> What do you suggest?
> > >> Actually I was hoping that you answer to my question was going to be "yes it will be working correctly" ;)
> > >>
> > >> Would this work?
> > >>
> > >> config RT2X00_LIB_RFKILL
> > >> 	tristate
> > >>   	depends on RFKILL
> > >>   	default y
> > >>   
> > >> config RT2X00_LIB_LEDS
> > >> 	tristate
> > >>   	depends on NEW_LEDS
> > >>   	depends on LEDS_CLASS
> > >> 	default y
> > >>
> > >> config RT2X00_LIB
> > >> 	tristate
> > >> 	depends on RT2X00_LIB_RFKILL if (RT2X00_LIB_RFKILL != n)
> > >> 	depends on RT2X00_LIB_LEDS if (RT2X00_LIB_LEDS != n)
> > >>
> > >> It's ugly, and I can't test this right now, but perhaps you have an idea if this could do the trick?
> > > 
> > > I tried it:
> > > 
> > > drivers/net/wireless/rt2x00/Kconfig:22: invalid option
> > > drivers/net/wireless/rt2x00/Kconfig:23: invalid option
> > > 
> > > "depends ... if ..." is invalid.  Would be nice to have that.
> > > Maybe there is some other way to express that...
> > 
> > Wouldn't this do it?
> > 
> > depends on (RT2X00_LIB_RFKILL == m) || (RT2X00_LIB_RFKILL == y)
> > 
> > In b43, what I think is a similar configuration statement is written as
> > 
> > depends on B43 && (RFKILL = y || RFKILL = B43) && RFKILL_INPUT &&
> > (INPUT_POLLDEV = y || INPUT_POLLDEV = B43)
> 
> Wouldn't that completely disable the config option when the rfkill is build
> as module and b43 buildin? I think what you want in that scenario would be

Yes, it does.

> building b43 as module instead.
> On the other hand, such Kconfig expression is apparently not possible,
> which means your approach would be the closest match.

Ivo, please explain what rt2x00 module(s) you want to be built.  In English
if possible, not in Kconfig language...

Thanks.

---
~Randy

Re: [PATCH -mm] rt2x00: fix Kconfig dependencies

[Ivo van Doorn]

On Wednesday 24 September 2008, Randy Dunlap wrote:
> On Wed, 24 Sep 2008 00:09:31 +0200 Ivo van Doorn wrote:
> 
> > On Tuesday 23 September 2008, Larry Finger wrote:
> > > Randy Dunlap wrote:
> > > > On Tue, 23 Sep 2008 19:51:00 +0200 Ivo van Doorn wrote:
> > > > 
> > > >> On Tuesday 23 September 2008, Randy Dunlap wrote:
> > > >>> Ivo van Doorn wrote:
> > > >>>> On Tuesday 23 September 2008, Randy Dunlap wrote:
> > > >>>>> From: Randy Dunlap <randy.dunlap@oracle.com>
> > > >>>>>
> > > >>>>> If RT2X00=y but RFKILL=m, these build errors happen:
> > > >>>>>
> > > >>>>> (.text+0x7c7d6): undefined reference to `rfkill_free'
> > > >>>>> rt2x00rfkill.c:(.text+0x7c830): undefined reference to `rfkill_force_state'
> > > >>>>> (.text+0x7c88d): undefined reference to `rfkill_unregister'
> > > >>>>> (.text+0x7c8cd): undefined reference to `rfkill_register'
> > > >>>>> (.text+0x7ca1a): undefined reference to `rfkill_allocate'
> > > >>>>>
> > > >>>>> so restrict RT2X00's RFKILL config level to that of the main RFKILL option.
> > > >>>>> This is done by making the former a tristate instead of a bool
> > > >>>>> config option.
> > > >>>>>
> > > >>>>>
> > > >>>>> If RT2X00=y but LEDS_CLASS=m, these build errors happen:
> > > >>>>>
> > > >>>>> (.text+0x11859f): undefined reference to `led_classdev_resume'
> > > >>>>> (.text+0x1185b3): undefined reference to `led_classdev_resume'
> > > >>>>> (.text+0x1185c7): undefined reference to `led_classdev_resume'
> > > >>>>> (.text+0x1185e4): undefined reference to `led_classdev_suspend'
> > > >>>>> (.text+0x1185f8): undefined reference to `led_classdev_suspend'
> > > >>>>> (.text+0x11860c): undefined reference to `led_classdev_suspend'
> > > >>>>> rt2x00leds.c:(.text+0x118620): undefined reference to `led_classdev_unregister'
> > > >>>>> rt2x00leds.c:(.text+0x118695): undefined reference to `led_classdev_register'
> > > >>>>>
> > > >>>>> so restrict RT2X00's LEDS config level to that of the main LEDS_CLASS option.
> > > >>>>> This is done by making the former a tristate instead of a bool
> > > >>>>> config option.
> > > >>>> Is that really going to work correctly?
> > > >>>> rfkill and leds support should be compiled into rt2x00lib.ko, which means that
> > > >>>> should become a module instead of the rfkill/leds support part only.
> > > >>> I wondered about that lib.ko.  Any working build fix is OK with me.
> > > >>> What do you suggest?
> > > >> Actually I was hoping that you answer to my question was going to be "yes it will be working correctly" ;)
> > > >>
> > > >> Would this work?
> > > >>
> > > >> config RT2X00_LIB_RFKILL
> > > >> 	tristate
> > > >>   	depends on RFKILL
> > > >>   	default y
> > > >>   
> > > >> config RT2X00_LIB_LEDS
> > > >> 	tristate
> > > >>   	depends on NEW_LEDS
> > > >>   	depends on LEDS_CLASS
> > > >> 	default y
> > > >>
> > > >> config RT2X00_LIB
> > > >> 	tristate
> > > >> 	depends on RT2X00_LIB_RFKILL if (RT2X00_LIB_RFKILL != n)
> > > >> 	depends on RT2X00_LIB_LEDS if (RT2X00_LIB_LEDS != n)
> > > >>
> > > >> It's ugly, and I can't test this right now, but perhaps you have an idea if this could do the trick?
> > > > 
> > > > I tried it:
> > > > 
> > > > drivers/net/wireless/rt2x00/Kconfig:22: invalid option
> > > > drivers/net/wireless/rt2x00/Kconfig:23: invalid option
> > > > 
> > > > "depends ... if ..." is invalid.  Would be nice to have that.
> > > > Maybe there is some other way to express that...
> > > 
> > > Wouldn't this do it?
> > > 
> > > depends on (RT2X00_LIB_RFKILL == m) || (RT2X00_LIB_RFKILL == y)
> > > 
> > > In b43, what I think is a similar configuration statement is written as
> > > 
> > > depends on B43 && (RFKILL = y || RFKILL = B43) && RFKILL_INPUT &&
> > > (INPUT_POLLDEV = y || INPUT_POLLDEV = B43)
> > 
> > Wouldn't that completely disable the config option when the rfkill is build
> > as module and b43 buildin? I think what you want in that scenario would be
> 
> Yes, it does.
> 
> > building b43 as module instead.
> > On the other hand, such Kconfig expression is apparently not possible,
> > which means your approach would be the closest match.
> 
> Ivo, please explain what rt2x00 module(s) you want to be built.  In English
> if possible, not in Kconfig language...

There are 3 kind of rt2x00 modules:
	rt2x00lib
	rt2x00pci/usb
	rt2x00 driver (rt2400pci, rt2500pci, rt61pci, rt2500usb, rt73usb)

When the user selects any of the rt2x00 drivers, the rt2x00pci/usb and rt2x00lib
are selected. For rt2x00lib there are some additional configuration options like
RT2X00_LIB_RFKILL and RT2X00_LIB_LEDS which will build into rt2x00lib.

This means that when rt2400pci is selected as module, rt2x00pci and rt2x00lib
must be built as modules as well and when rt2400pci is selected as buildin
rt2x00pci and rt2x00lib must be buildin as well.

But with the optional rt2x00lib configuration options the breakage you reported
is possible. So we either need:
	1) Force rt2x00lib / driver to be compiled as module when RFKILL/LEDS were
	    compiled as module
	2) Disable config option when invalid config combination is found

Personally I would favor 1), because 2) could lead to confusion to users
who think they selected everything they needed to enable support for it in
rt2x00.

Ivo

Re: [PATCH -mm] rt2x00: fix Kconfig dependencies

[Gertjan van Wingerde]

[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]

Ivo,

Ivo van Doorn wrote:
>> Ivo, please explain what rt2x00 module(s) you want to be built. In 
>> English
>> if possible, not in Kconfig language...
>>      
>
> There are 3 kind of rt2x00 modules:
> 	rt2x00lib
> 	rt2x00pci/usb
> 	rt2x00 driver (rt2400pci, rt2500pci, rt61pci, rt2500usb, rt73usb)
>
> When the user selects any of the rt2x00 drivers, the rt2x00pci/usb and rt2x00lib
> are selected. For rt2x00lib there are some additional configuration options like
> RT2X00_LIB_RFKILL and RT2X00_LIB_LEDS which will build into rt2x00lib.
>
> This means that when rt2400pci is selected as module, rt2x00pci and rt2x00lib
> must be built as modules as well and when rt2400pci is selected as buildin
> rt2x00pci and rt2x00lib must be buildin as well.
>
> But with the optional rt2x00lib configuration options the breakage you reported
> is possible. So we either need:
> 	1) Force rt2x00lib / driver to be compiled as module when RFKILL/LEDS were
> 	    compiled as module
> 	2) Disable config option when invalid config combination is found
>
> Personally I would favor 1), because 2) could lead to confusion to users
> who think they selected everything they needed to enable support for it in
> rt2x00.
>    

Find attached a patch that implements option 2, along with adding a 
warning to the user when rfkill support in rt2x00 is disabled due to the 
invalid config combination. I've looked at implementing option 1, but 
couldn't find a way to do it without disabling the entire rt2x00 module 
when rfkill wasn't available.

I guess we can live with this option for now, until we have figured out 
how to do option 1.

---
Gertjan.

[-- Attachment #2: 0001-rt2x00-Fix-build-errors-due-to-modularized-RFKILL-a.patch --]
[-- Type: text/plain, Size: 1240 bytes --]

>From bcdd7594bf24a813387c908198de4d74906d196a Mon Sep 17 00:00:00 2001
From: Gertjan van Wingerde <gwingerde@kpnplanet.nl>
Date: Sun, 28 Sep 2008 10:53:46 +0200
Subject: [PATCH] rt2x00: Fix build errors due to modularized RFKILL and built-in rt2x00.

Fix by disabling rt2x00 rfkill support when rt2x00 is built-in and RFKILL has been modularized.
Also, give a warning to the end-user when rfkill-support is supported this way, so that the end-user
has at least some clues on what is going on.

Signed-off-by: Gertjan van Wingerde <gwingerde@kpnplanet.nl>
---
 drivers/net/wireless/rt2x00/Kconfig |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/rt2x00/Kconfig b/drivers/net/wireless/rt2x00/Kconfig
index b686dc4..64c94d7 100644
--- a/drivers/net/wireless/rt2x00/Kconfig
+++ b/drivers/net/wireless/rt2x00/Kconfig
@@ -39,9 +39,10 @@ config RT2X00_LIB_CRYPTO
 
 config RT2X00_LIB_RFKILL
 	boolean
-	depends on RT2X00_LIB
-	depends on RFKILL
-	default y
+	default y if (RT2X00=y && RFKILL=y) || (RT2X00=m && RFKILL!=n)
+
+comment "rt2x00 rfkill support disabled due to modularized RFKILL and built-in rt2x00"
+	depends on RT2X00=y && RFKILL=m
 
 config RT2X00_LIB_LEDS
 	boolean
-- 
1.5.6.5

Re: [PATCH -mm] rt2x00: fix Kconfig dependencies

[Ivo van Doorn]

On Sunday 28 September 2008, Gertjan van Wingerde wrote:
> Ivo,
> 
> Ivo van Doorn wrote:
> >> Ivo, please explain what rt2x00 module(s) you want to be built. In 
> >> English
> >> if possible, not in Kconfig language...
> >>      
> >
> > There are 3 kind of rt2x00 modules:
> > 	rt2x00lib
> > 	rt2x00pci/usb
> > 	rt2x00 driver (rt2400pci, rt2500pci, rt61pci, rt2500usb, rt73usb)
> >
> > When the user selects any of the rt2x00 drivers, the rt2x00pci/usb and rt2x00lib
> > are selected. For rt2x00lib there are some additional configuration options like
> > RT2X00_LIB_RFKILL and RT2X00_LIB_LEDS which will build into rt2x00lib.
> >
> > This means that when rt2400pci is selected as module, rt2x00pci and rt2x00lib
> > must be built as modules as well and when rt2400pci is selected as buildin
> > rt2x00pci and rt2x00lib must be buildin as well.
> >
> > But with the optional rt2x00lib configuration options the breakage you reported
> > is possible. So we either need:
> > 	1) Force rt2x00lib / driver to be compiled as module when RFKILL/LEDS were
> > 	    compiled as module
> > 	2) Disable config option when invalid config combination is found
> >
> > Personally I would favor 1), because 2) could lead to confusion to users
> > who think they selected everything they needed to enable support for it in
> > rt2x00.
> >    
> 
> Find attached a patch that implements option 2, along with adding a 
> warning to the user when rfkill support in rt2x00 is disabled due to the 
> invalid config combination. I've looked at implementing option 1, but 
> couldn't find a way to do it without disabling the entire rt2x00 module 
> when rfkill wasn't available.
> 
> I guess we can live with this option for now, until we have figured out 
> how to do option 1.

Sounds good, but please change RT2X00 in RT2X00_LIB

	default y if (RT2X00=y && RFKILL=y) || (RT2X00=m && RFKILL!=n)

Could you also do a similar thing for the LED handling?
That way we can fix the entire thing with a single patch. :)

Thanks,

Ivo

Re: [PATCH -mm] rt2x00: fix Kconfig dependencies

[Gertjan van Wingerde]

[-- Attachment #1: Type: text/plain, Size: 2271 bytes --]

Ivo van Doorn wrote:
> On Sunday 28 September 2008, Gertjan van Wingerde wrote:
>    
>> Ivo,
>>
>> Ivo van Doorn wrote:
>>      
>>>> Ivo, please explain what rt2x00 module(s) you want to be built. In
>>>> English
>>>> if possible, not in Kconfig language...
>>>>
>>>>          
>>> There are 3 kind of rt2x00 modules:
>>> 	rt2x00lib
>>> 	rt2x00pci/usb
>>> 	rt2x00 driver (rt2400pci, rt2500pci, rt61pci, rt2500usb, rt73usb)
>>>
>>> When the user selects any of the rt2x00 drivers, the rt2x00pci/usb and rt2x00lib
>>> are selected. For rt2x00lib there are some additional configuration options like
>>> RT2X00_LIB_RFKILL and RT2X00_LIB_LEDS which will build into rt2x00lib.
>>>
>>> This means that when rt2400pci is selected as module, rt2x00pci and rt2x00lib
>>> must be built as modules as well and when rt2400pci is selected as buildin
>>> rt2x00pci and rt2x00lib must be buildin as well.
>>>
>>> But with the optional rt2x00lib configuration options the breakage you reported
>>> is possible. So we either need:
>>> 	1) Force rt2x00lib / driver to be compiled as module when RFKILL/LEDS were
>>> 	    compiled as module
>>> 	2) Disable config option when invalid config combination is found
>>>
>>> Personally I would favor 1), because 2) could lead to confusion to users
>>> who think they selected everything they needed to enable support for it in
>>> rt2x00.
>>>
>>>        
>> Find attached a patch that implements option 2, along with adding a
>> warning to the user when rfkill support in rt2x00 is disabled due to the
>> invalid config combination. I've looked at implementing option 1, but
>> couldn't find a way to do it without disabling the entire rt2x00 module
>> when rfkill wasn't available.
>>
>> I guess we can live with this option for now, until we have figured out
>> how to do option 1.
>>      
>
> Sounds good, but please change RT2X00 in RT2X00_LIB
>
> 	default y if (RT2X00=y&&  RFKILL=y) || (RT2X00=m&&  RFKILL!=n)
>
> Could you also do a similar thing for the LED handling?
> That way we can fix the entire thing with a single patch. :)

Here is an updated patch. This required some more surgery to the Kconfig 
file, as symbols had to be moved in the file.
This patch fixes the build issues for both rfkill and leds support.

---
Gertjan.

[-- Attachment #2: 0001-rt2x00-Fix-build-errors-due-to-modularized-rfkill-o.patch --]
[-- Type: text/plain, Size: 3019 bytes --]

>From 0638bdd1e7b578c9fb0a91c768c105a369ff6ac1 Mon Sep 17 00:00:00 2001
From: Gertjan van Wingerde <gwingerde@kpnplanet.nl>
Date: Sun, 28 Sep 2008 15:11:38 +0200
Subject: [PATCH] rt2x00: Fix build errors due to modularized rfkill or leds and built-in rt2x00.

Fix by disabling rt2x00 rfkill support when rt2x00 is built-in and rfkill has been modularized, and
a similar scheme for the relationship between leds_class and rt2x00..
Also, give a warning to the end-user when rfkill-/leds-support is disabled this way, so that the
end-user has at least some clues on what is going on.

Proper fixing required some general updates of the Kconfig-structure for the rt2x00 driver, whereby
internal configuration symbols had to be moved to after the user-visible configuration symbols.

Signed-off-by: Gertjan van Wingerde <gwingerde@kpnplanet.nl>
---
 drivers/net/wireless/rt2x00/Kconfig |   69 +++++++++++++++++------------------
 1 files changed, 34 insertions(+), 35 deletions(-)

diff --git a/drivers/net/wireless/rt2x00/Kconfig b/drivers/net/wireless/rt2x00/Kconfig
index b686dc4..f839ce0 100644
--- a/drivers/net/wireless/rt2x00/Kconfig
+++ b/drivers/net/wireless/rt2x00/Kconfig
@@ -1,5 +1,5 @@
-config RT2X00
-	tristate "Ralink driver support"
+menuconfig RT2X00
+	bool "Ralink driver support"
 	depends on MAC80211 && WLAN_80211 && EXPERIMENTAL
 	---help---
 	  This will enable the experimental support for the Ralink drivers,
@@ -17,39 +17,6 @@ config RT2X00
 
 if RT2X00
 
-config RT2X00_LIB
-	tristate
-
-config RT2X00_LIB_PCI
-	tristate
-	select RT2X00_LIB
-
-config RT2X00_LIB_USB
-	tristate
-	select RT2X00_LIB
-
-config RT2X00_LIB_FIRMWARE
-	boolean
-	depends on RT2X00_LIB
-	select FW_LOADER
-
-config RT2X00_LIB_CRYPTO
-	boolean
-	depends on RT2X00_LIB
-
-config RT2X00_LIB_RFKILL
-	boolean
-	depends on RT2X00_LIB
-	depends on RFKILL
-	default y
-
-config RT2X00_LIB_LEDS
-	boolean
-	depends on RT2X00_LIB
-	depends on NEW_LEDS
-	depends on LEDS_CLASS
-	default y
-
 config RT2400PCI
 	tristate "Ralink rt2400 (PCI/PCMCIA) support"
 	depends on PCI
@@ -109,6 +76,38 @@ config RT73USB
 
 	  When compiled as a module, this driver will be called "rt73usb.ko".
 
+config RT2X00_LIB_PCI
+	tristate
+	select RT2X00_LIB
+
+config RT2X00_LIB_USB
+	tristate
+	select RT2X00_LIB
+
+config RT2X00_LIB
+	tristate
+
+config RT2X00_LIB_FIRMWARE
+	boolean
+	select FW_LOADER
+
+config RT2X00_LIB_CRYPTO
+	boolean
+
+config RT2X00_LIB_RFKILL
+	boolean
+	default y if (RT2X00_LIB=y && RFKILL=y) || (RT2X00_LIB=m && RFKILL!=n)
+
+comment "rt2x00 rfkill support disabled due to modularized RFKILL and built-in rt2x00"
+	depends on RT2X00_LIB=y && RFKILL=m
+
+config RT2X00_LIB_LEDS
+	boolean
+	default y if (RT2X00_LIB=y && LEDS_CLASS=y) || (RT2X00_LIB=m && LEDS_CLASS!=n)
+
+comment "rt2x00 leds support disabled due to modularized LEDS_CLASS and built-in rt2x00"
+	depends on RT2X00_LIB=y && LEDS_CLASS=m
+
 config RT2X00_LIB_DEBUGFS
 	bool "Ralink debugfs support"
 	depends on RT2X00_LIB && MAC80211_DEBUGFS
-- 
1.5.6.5

Re: [PATCH -mm] rt2x00: fix Kconfig dependencies

[Ivo van Doorn]

On Sunday 28 September 2008, Gertjan van Wingerde wrote:
> Ivo van Doorn wrote:
> > On Sunday 28 September 2008, Gertjan van Wingerde wrote:
> >    
> >> Ivo,
> >>
> >> Ivo van Doorn wrote:
> >>      
> >>>> Ivo, please explain what rt2x00 module(s) you want to be built. In
> >>>> English
> >>>> if possible, not in Kconfig language...
> >>>>
> >>>>          
> >>> There are 3 kind of rt2x00 modules:
> >>> 	rt2x00lib
> >>> 	rt2x00pci/usb
> >>> 	rt2x00 driver (rt2400pci, rt2500pci, rt61pci, rt2500usb, rt73usb)
> >>>
> >>> When the user selects any of the rt2x00 drivers, the rt2x00pci/usb and rt2x00lib
> >>> are selected. For rt2x00lib there are some additional configuration options like
> >>> RT2X00_LIB_RFKILL and RT2X00_LIB_LEDS which will build into rt2x00lib.
> >>>
> >>> This means that when rt2400pci is selected as module, rt2x00pci and rt2x00lib
> >>> must be built as modules as well and when rt2400pci is selected as buildin
> >>> rt2x00pci and rt2x00lib must be buildin as well.
> >>>
> >>> But with the optional rt2x00lib configuration options the breakage you reported
> >>> is possible. So we either need:
> >>> 	1) Force rt2x00lib / driver to be compiled as module when RFKILL/LEDS were
> >>> 	    compiled as module
> >>> 	2) Disable config option when invalid config combination is found
> >>>
> >>> Personally I would favor 1), because 2) could lead to confusion to users
> >>> who think they selected everything they needed to enable support for it in
> >>> rt2x00.
> >>>
> >>>        
> >> Find attached a patch that implements option 2, along with adding a
> >> warning to the user when rfkill support in rt2x00 is disabled due to the
> >> invalid config combination. I've looked at implementing option 1, but
> >> couldn't find a way to do it without disabling the entire rt2x00 module
> >> when rfkill wasn't available.
> >>
> >> I guess we can live with this option for now, until we have figured out
> >> how to do option 1.
> >>      
> >
> > Sounds good, but please change RT2X00 in RT2X00_LIB
> >
> > 	default y if (RT2X00=y&&  RFKILL=y) || (RT2X00=m&&  RFKILL!=n)
> >
> > Could you also do a similar thing for the LED handling?
> > That way we can fix the entire thing with a single patch. :)
> 
> Here is an updated patch. This required some more surgery to the Kconfig 
> file, as symbols had to be moved in the file.
> This patch fixes the build issues for both rfkill and leds support.

Thanks, you can add my:
	Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>

John, can you merge the patch into wireless-testing?

Thanks,

Ivo