rt2x00: fix Kconfig dependencies

From: Randy Dunlap <[email protected]>

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 <[email protected]>

---
 drivers/net/wireless/rt2x00/Kconfig |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/net/wireless/rt2x00/Kconfig +2 -3

@@ -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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 26 lines · Randy Dunlap

From: Randy Dunlap <[email protected]>

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'

Quoted 3 lines

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

Quoted 25 lines

Signed-off-by Randy Dunlap <[email protected]>

---
 drivers/net/wireless/rt2x00/Kconfig |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/net/wireless/rt2x00/Kconfig +2 -3

@@ -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
 
--

Quoted 31 lines · Ivo van Doorn

Quoted 29 lines · Randy Dunlap

From: Randy Dunlap <[email protected]>

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.

Quoted 3 lines

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.

Quoted 27 lines

Ivo

Quoted 25 lines

Signed-off-by Randy Dunlap <[email protected]>

---
 drivers/net/wireless/rt2x00/Kconfig |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/net/wireless/rt2x00/Kconfig +2 -3

@@ -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
 
--

Quoted 32 lines · Randy Dunlap

Quoted 31 lines · Ivo van Doorn

Quoted 29 lines · Randy Dunlap

From: Randy Dunlap <[email protected]>

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.

Quoted 6 lines

Quoted 3 lines

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?

Quoted 3 lines

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.

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

Quoted 28 lines · Randy Dunlap

Quoted 27 lines · Ivo van Doorn

Quoted 26 lines · Randy Dunlap

From: Randy Dunlap <[email protected]>

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'

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

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

Quoted 6 lines

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...

Quoted 61 lines · Randy Dunlap

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

Quoted 28 lines · Randy Dunlap

Quoted 27 lines · Ivo van Doorn

Quoted 26 lines · Randy Dunlap

From: Randy Dunlap <[email protected]>

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'

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

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

Quoted 6 lines

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?

Quoted 7 lines

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)

Quoted 74 lines · Larry Finger

Quoted 61 lines · Randy Dunlap

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

Quoted 28 lines · Randy Dunlap

Quoted 27 lines · Ivo van Doorn

Quoted 26 lines · Randy Dunlap

From: Randy Dunlap <[email protected]>

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'

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

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

Quoted 6 lines

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?

Quoted 7 lines

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)

Quoted 4 lines

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.

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

Quoted 74 lines · Larry Finger

Quoted 61 lines · Randy Dunlap

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

Quoted 28 lines · Randy Dunlap

Quoted 27 lines · Ivo van Doorn

Quoted 26 lines · Randy Dunlap

From: Randy Dunlap <[email protected]>

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'

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

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

Quoted 6 lines

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?

Quoted 7 lines

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)

Quoted 7 lines

Quoted 4 lines

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.

Quoted 3 lines

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...

Quoted 3 lines

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.

From bcdd7594bf24a813387c908198de4d74906d196a Mon Sep 17 00:00:00 2001

Ivo,

Quoted 24 lines · Ivo van Doorn

Quoted 4 lines

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

Quoted 4 lines

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.

Quoted 33 lines · Gertjan van Wingerde

Ivo,

Quoted 24 lines · Ivo van Doorn

Quoted 5 lines

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

Quoted 5 lines

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.

Quoted 9 lines

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. :)

From 0638bdd1e7b578c9fb0a91c768c105a369ff6ac1 Mon Sep 17 00:00:00 2001

Quoted 47 lines · Ivo van Doorn

Quoted 33 lines · Gertjan van Wingerde

Ivo,

Quoted 24 lines · Ivo van Doorn

Quoted 5 lines

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

Quoted 5 lines

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.

Quoted 9 lines

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

Quoted 4 lines

	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.