rt2x00: Create rt2x00lib module

Create rt2x00lib module, this module contains all generic code that is shared between the individual drivers. The following patches will start using the code provided by rt2x00lib.

---

index 491fe08..f793abe 100644
@@ -1,5 +1,5 @@
 config RT2X00
-	bool "Ralink driver support"
+	tristate "Ralink driver support"
 	depends on NET_RADIO && MAC80211 && EXPERIMENTAL
 	---help---
 	This will enable the experimental support for the Ralink drivers,

@@ -7,6 +7,10 @@ config RT2X00
 
 	These drivers will make use of the Devicescape ieee80211 stack.
 
+	This option will build the rt2x00 library which is required by
+	each individual driver, when compiled as a module,
+	this library will be called "rt2x00lib.ko".
+
 config RT2400PCI
 	tristate "Ralink rt2400 pci/pcmcia support"
 	depends on RT2X00 && PCI

index df706c7..24837d5 100644
@@ -1,3 +1,4 @@
+obj-$(CONFIG_RT2X00)		+= rt2x00lib.o
 obj-$(CONFIG_RT2400PCI)		+= rt2400pci.o
 obj-$(CONFIG_RT2500PCI)		+= rt2500pci.o
 obj-$(CONFIG_RT61PCI)		+= rt61pci.o

index e9ff871..06d8f2c 100644
@@ -48,6 +48,7 @@
 #define DRV_NAME "rt2400pci"
 
 #include "rt2x00.h"
+#include "rt2x00lib.h"
 #include "rt2x00pci.h"
 #include "rt2400pci.h"
 

index ab0bc97..6e20d42 100644
@@ -28,11 +28,6 @@
 #define RT2400PCI_H
 
 /*
- * RT chip defines.
- */
-#define RT2460				0x0101
-
-/*
  * RF chip defines.
  */
 #define RF2420				0x0000

index 73551b3..3c388d3 100644
@@ -48,6 +48,7 @@
 #define DRV_NAME "rt2500pci"
 
 #include "rt2x00.h"
+#include "rt2x00lib.h"
 #include "rt2x00pci.h"
 #include "rt2500pci.h"
 

index f4a51b1..faa1953 100644
@@ -28,11 +28,6 @@
 #define RT2500PCI_H
 
 /*
- * RT chip defines.
- */
-#define RT2560				0x0201
-
-/*
  * RF chip defines.
  */
 #define RF2522				0x0000

index c7ef5f8..9569875 100644
@@ -44,6 +44,7 @@
 #define DRV_NAME "rt2500usb"
 
 #include "rt2x00.h"
+#include "rt2x00lib.h"
 #include "rt2x00usb.h"
 #include "rt2500usb.h"
 

index 93e7b0d..316bf3a 100644
@@ -28,11 +28,6 @@
 #define RT2500USB_H
 
 /*
- * RT chip defines.
- */
-#define RT2570				0x1201
-
-/*
  * RF chip defines.
  */
 #define RF2522				0x0000

index 62c9131..dd2d2b8 100644
@@ -36,9 +36,4 @@
 #define REGISTER_BUSY_COUNT	5
 #define REGISTER_BUSY_DELAY	100
 
-/*
- * Link tuning at 1 second intervals
- */
-#define LINK_TUNE_INTERVAL	( 1 * HZ )
-
 #endif /* RT2X00PCI_H */

index b4f2961..3b9242a 100644
@@ -74,11 +74,6 @@
 #define USB_MODE_WAKEUP		0x09	/* RT73USB */
 
 /*
- * Link tuning at 1 second intervals
- */
-#define LINK_TUNE_INTERVAL	( 1 * HZ )
-
-/*
  * USB devices need an additional Beacon (guardian beacon) to be generated.
  */
 #undef BEACON_ENTRIES

index 9acae84..1142d5a 100644
@@ -50,6 +50,7 @@
 #define DRV_NAME "rt61pci"
 
 #include "rt2x00.h"
+#include "rt2x00lib.h"
 #include "rt2x00pci.h"
 #include "rt61pci.h"
 

index 12df048..a030e90 100644
@@ -28,13 +28,6 @@
 #define RT61PCI_H
 
 /*
- * RT chip defines.
- */
-#define RT2561				0x0301
-#define RT2561s				0x0302
-#define RT2661				0x0401
-
-/*
  * RF chip defines.
  */
 #define RF5225				0x0001

index 98f6595..fe1aeba 100644
@@ -46,6 +46,7 @@
 #define DRV_NAME "rt73usb"
 
 #include "rt2x00.h"
+#include "rt2x00lib.h"
 #include "rt2x00usb.h"
 #include "rt73usb.h"
 

index 32c04f9..dd32800 100644
@@ -28,11 +28,6 @@
 #define RT73USB_H
 
 /*
- * RT chip defines.
- */
-#define RT73				0x1300
-
-/*
  * RF chip defines.
  */
 #define RF5226				0x0001

Is there any particular reason for RT2X00 to be a config only option? When RT2X00 is a config only option, it would still require RT2X00 to be a tristate option. Otherwise it is possible to build d80211 as module and rt2400pci compiled in. And I am not sure if that is a desired possibility, escpecially with the compilation errors that would produce.

It would also mean that both RT2X00 and RT2X00_LIB are options the user can select (RT2X00_LIB depending on Rt2X00 off course), I can't really see the point in that.

Yeah, I seem to have send the patch mails itself in the wrong order. :( So the number in the subject line is correct, just the order of sending was reversed.
I'll try to do better next time. :)

Ivo

Not sure, maybe just preference. To me, when going through and not reading all the config entries, it appears as though rt2x00 is just a menu but selecting it still means code is built. Maybe there's the solution too, provide a new menu for all these options, rename RT2X00 to RT2X00_LIB and hide it by not providing a help text.

Good point.

No, that's not true, if RT2X00_LIB has no help text it would never show up to the user.

johannes

Nope, in my test it will show up in the menu. The help text has no influence. When the help text is not specified, selecting help on that entry will display "There is no help available for this kernel option." followed by the regular dependency information for that option.

Really?, I have just tested it and it does show up. There are 2 possibilities.

1) The drivers select RT2X00_LIB which is not listed in the KConfig file.
- This results in the warning message:
drivers/net/wireless/mac80211/rt2x00/Kconfig:18:warning: 'select' used by config symbol 'RT2400PCI' refer to undefined symbol 'RT2X00_LIB'

2) KConfig contains this entry:
config RT2X00_LIB
tristate "rt2x00 support"
depends on RT2X00

After this, "rt2x00 support" will show up in the menu for the user.

Ivo

I think that's only true if other things depend on it as opposed to selecting it. I know that cfg80211 used to not show up in Kconfig (and that was intentional)

Let me try this.

johannes

Nothing depended on RT2X00_LIB, I only had the drivers select RT2X00_LIB. So something has changed or I am missing something. ;)

Ivo

No, I found what's up.

You need to change it to

config RT2X00_LIB
tristate
depends on RT2X00

(note that it has no human-readable name)

Btw. It appears that you can build debugfs support as a module while drivers are built in. Not good.

johannes

Ah ok. Thanks.

Thanks for the tip. I'll try to fix this.

Both things will end up in a new patch which I will send as soon as I have that debugfs config option fixed. :)

Ivo

And another btw. How about using the wiphy debugfs node?

johannes

No, that's not true either. It's not a feature of the help text, but of the little description behind the bool or tristate option.

The following example would make a CONFIG_LIBERAS entry, that can be tristate, and is automatically set correctly. If I set LIBERTAS_CS to "m", it would be "m". If it is "y", it would be "y" as well. And if LIBERTAS_CS is "m", but LIBERTAS_USB is "y", it would still be "y". Kconfig is sane enought to find out what it should do.

config LIBERTAS
tristate
depends on NET_RADIO

config LIBERTAS_CS

        tristate "Marvell Libertas 8388 CF 802.11b/g cards"
        depends on PCMCIA && EXPERIMENTAL
        select FW_LOADER
	select LIBERTAS
        ---help---
          A driver for Marvell Libertas 8385 compact flash
          devices.

config LIBERTAS_USB
tristate "Marvell Libertas 8388 USB 802.11b/g cards" depends on USB
select FW_LOADER
select LIBERTAS
---help---
A driver for Marvell Libertas 8388 USB devices.

config LIBERTAS_DEBUG
bool "Enable full debugging in the Libertas library" depends on LIBERTAS
---help---
Debugging support

Good point, I had created debugfs before the entire wiphy integration into wireless-dev and hadn't noticed that entry yet. I'll fix that as soon as possible as well.

Ivo

Yeah, I was confused.

johannes