Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
On Saturday 23 February 2008, Sebastian Siewior wrote: so select it. Signed-off-by: Sebastian Siewior [EMAIL PROTECTED] --- drivers/net/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index f337800..a116056 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2363,6 +2363,7 @@ config GELIC_NET config GELIC_WIRELESS bool PS3 Wireless support depends on GELIC_NET + select MAC80211 help This option adds the support for the wireless feature of PS3. If you have the wireless-less model of PS3 or have no plan to Is there any particular reason why this driver is in drivers/net instead of drivers/net/wireless (along with all other wireless drivers? Additionally, all other mac80211 drivers depend on mac80211 instead of selecting it. So I think for consistency it might be better to also make this driver depend on it, rather then selecting. Ivo -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
On Saturday 23 February 2008, Ivo van Doorn wrote: On Saturday 23 February 2008, Sebastian Siewior wrote: so select it. Signed-off-by: Sebastian Siewior [EMAIL PROTECTED] --- drivers/net/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index f337800..a116056 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2363,6 +2363,7 @@ config GELIC_NET config GELIC_WIRELESS bool PS3 Wireless support depends on GELIC_NET + select MAC80211 help This option adds the support for the wireless feature of PS3. If you have the wireless-less model of PS3 or have no plan to Is there any particular reason why this driver is in drivers/net instead of drivers/net/wireless (along with all other wireless drivers? Additionally, all other mac80211 drivers depend on mac80211 instead of selecting it. So I think for consistency it might be better to also make this driver depend on it, rather then selecting. Additionally, what part of the driver actually uses mac80211? I just browsed to the code, and it seems to work completely without using mac80211. Instead it seems to work directly by registering a net_device structure... Ivo -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
On Saturday 23 February 2008, Sebastian Siewior wrote: * Ivo van Doorn | 2008-02-23 20:50:34 [+0100]: Additionally, what part of the driver actually uses mac80211? I just browsed to the code, and it seems to work completely without using mac80211. Instead it seems to work directly by registering a net_device structure... CC drivers/net/ps3_gelic_wireless.o /home/bigeasy/git/linux-2.6/drivers/net/ps3_gelic_wireless.c: In function 'gelic_wl_setup_netdev_ops': /home/bigeasy/git/linux-2.6/drivers/net/ps3_gelic_wireless.c:2660: error: 'struct net_device' has no member named 'wireless_data' /home/bigeasy/git/linux-2.6/drivers/net/ps3_gelic_wireless.c:2661: error: 'struct net_device' has no member named 'wireless_handlers' make[3]: *** [drivers/net/ps3_gelic_wireless.o] Error 1 make[2]: *** [drivers/net] Error 2 make[1]: *** [drivers] Error 2 make[1]: *** Waiting for unfinished jobs make: *** [sub-make] Error 2 I add this to the patch desctiption and post a depends on patach Looking at include/linux/netdevice.h: #ifdef CONFIG_WIRELESS_EXT /* List of functions to handle Wireless Extensions (instead of ioctl). * See net/iw_handler.h for details. Jean II */ const struct iw_handler_def * wireless_handlers; /* Instance data managed by the core of Wireless Extensions. */ struct iw_public_data * wireless_data; #endif There is no dependency on mac80211 but on WIRELESS_EXT. That is a config option most other drivers select, so you best change your patch to select WIRELESS_EXT instead of MAC80211. Ivo -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
On Saturday 23 February 2008, Sebastian Siewior wrote: * Sebastian Siewior | 2008-02-23 21:06:37 [+0100]: I add this to the patch desctiption and post a depends on patach ARGH, this was CONFIG_WIRELESS_EXT and not MAC80211. You would like to see a select or depend statement on that one? Other drivers do a select on WIRELESS_EXT, so selecting it would be fine. Ivo -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
On Saturday 23 February 2008, Sebastian Siewior wrote: * Ivo van Doorn | 2008-02-23 20:44:59 [+0100]: Is there any particular reason why this driver is in drivers/net instead of drivers/net/wireless (along with all other wireless drivers? My understanding is/was that the wireless device and the eth device are exposed by the hypervisor to the system and they share ressources. Ah ok, makes sense. :) Thanks. Ivo -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] rfkill: Move rfkill_switch_all out of global header
rfkill_switch_all shouldn't be called by drivers directly, instead they should send a signal over the input device. To prevent confusion for driver developers, move the function into a rfkill private header. Signed-off-by: Ivo van Doorn [EMAIL PROTECTED] --- diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h index f9a50da..67096b5 100644 --- a/include/linux/rfkill.h +++ b/include/linux/rfkill.h @@ -2,7 +2,7 @@ #define __RFKILL_H /* - * Copyright (C) 2006 Ivo van Doorn + * Copyright (C) 2006 - 2007 Ivo van Doorn * Copyright (C) 2007 Dmitry Torokhov * * This program is free software; you can redistribute it and/or modify @@ -84,6 +84,4 @@ void rfkill_free(struct rfkill *rfkill); int rfkill_register(struct rfkill *rfkill); void rfkill_unregister(struct rfkill *rfkill); -void rfkill_switch_all(enum rfkill_type type, enum rfkill_state state); - #endif /* RFKILL_H */ diff --git a/net/rfkill/rfkill-input.c b/net/rfkill/rfkill-input.c index 8e4516a..eaabf08 100644 --- a/net/rfkill/rfkill-input.c +++ b/net/rfkill/rfkill-input.c @@ -17,6 +17,8 @@ #include linux/init.h #include linux/rfkill.h +#include rfkill-input.h + MODULE_AUTHOR(Dmitry Torokhov [EMAIL PROTECTED]); MODULE_DESCRIPTION(Input layer to RF switch connector); MODULE_LICENSE(GPL); diff --git a/net/rfkill/rfkill-input.h b/net/rfkill/rfkill-input.h new file mode 100644 index 000..4dae500 --- /dev/null +++ b/net/rfkill/rfkill-input.h @@ -0,0 +1,16 @@ +/* + * Copyright (C) 2007 Ivo van Doorn + */ + +/* + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#ifndef __RFKILL_INPUT_H +#define __RFKILL_INPUT_H + +void rfkill_switch_all(enum rfkill_type type, enum rfkill_state state); + +#endif /* __RFKILL_INPUT_H */ diff --git a/net/rfkill/rfkill.c b/net/rfkill/rfkill.c index 03ed7fd..00ee534 100644 --- a/net/rfkill/rfkill.c +++ b/net/rfkill/rfkill.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2006 Ivo van Doorn + * Copyright (C) 2006 - 2007 Ivo van Doorn * Copyright (C) 2007 Dmitry Torokhov * * This program is free software; you can redistribute it and/or modify - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please pull 'rt2x00' branch of wireless-2.6
Hi, This patch adds the rt2x00 drivers for Ralink wireless hardware. This collection of drivers has seen lots of action in Fedora (both F7 and rawhide) and many people are using them with good results (although some problems do remain). Ivo in particular has been very helpful in responding to bug reports for these drivers, including bugs reported at kernel.org and in distro bugzillas. I extend my thanks to him for both his past and future support of these drivers. I'm sure he and the rest of the rt2x00 team will continue to support the community and their userbase. Ivo and his team may feel I am jumping the gun a bit -- they have a few more random bugs they wanted to squash before going upstream. But since they are bugs, any fixes should still be able to be applied in the -rc phase of 2.6.24. In the meantime, I definitely think it would be better to get this code into mainline rather than keeping it out of stream. With 2.6.23 not yet released, I assume we still have a few months to get rt2x00 shaped up to be really ready for 2.6.24? Because I am indeed not really happy with this early merge, but I'll do my best to resolve the last outstanding bugs as soon as possible. Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please pull 'rt2x00' branch of wireless-2.6
On Wednesday 19 September 2007, David Miller wrote: From: Ivo van Doorn [EMAIL PROTECTED] Date: Wed, 19 Sep 2007 20:31:19 +0200 Because I am indeed not really happy with this early merge, but I'll do my best to resolve the last outstanding bugs as soon as possible. Relax :-) :) A merge upstream doesn't mean bug free, it means significantly better than no driver at all and that is undoubtedly the case here. Well I am happy rt2x00 is being considered good enough for upstream already, but I have the habbit of wanting things bug-free before pushing it further upstream. Well most users are happy with current rt2x00 version anyway, so the remaining issues probably aren't that big anyway. (Except for the 2 panics, which should be resolved soon anyway) ;) Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please pull 'rt2x00' branch of wireless-2.6
On Wednesday 19 September 2007, Michael Buesch wrote: On Wednesday 19 September 2007 20:47:59 Ivo van Doorn wrote: On Wednesday 19 September 2007, David Miller wrote: From: Ivo van Doorn [EMAIL PROTECTED] Date: Wed, 19 Sep 2007 20:31:19 +0200 Because I am indeed not really happy with this early merge, but I'll do my best to resolve the last outstanding bugs as soon as possible. Relax :-) :) A merge upstream doesn't mean bug free, it means significantly better than no driver at all and that is undoubtedly the case here. Well I am happy rt2x00 is being considered good enough for upstream already, but I have the habbit of wanting things bug-free before pushing it further upstream. Well most users are happy with current rt2x00 version anyway, so the remaining issues probably aren't that big anyway. (Except for the 2 panics, which should be resolved soon anyway) ;) Well, you have nothing to lose, basically. It's impossible for you to create a regression. So everything is fine, even if it's buggy and doesn't work at all. ;) Hehe. Thanks. I'll keep that in mind. ;) Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please pull 'rt2x00' branch of wireless-2.6
On Wednesday 19 September 2007, John W. Linville wrote: On Wed, Sep 19, 2007 at 08:31:19PM +0200, Ivo van Doorn wrote: Ivo and his team may feel I am jumping the gun a bit -- they have a few more random bugs they wanted to squash before going upstream. But since they are bugs, any fixes should still be able to be applied in the -rc phase of 2.6.24. In the meantime, I definitely think it would be better to get this code into mainline rather than keeping it out of stream. With 2.6.23 not yet released, I assume we still have a few months to get rt2x00 shaped up to be really ready for 2.6.24? Because I am indeed not really happy with this early merge, but I'll do my best to resolve the last outstanding bugs as soon as possible. Ivo, Having failed to ask for permission, this is where I ask for your forgiveness. Please forgive me! :-) Not a problem. :) As Dave said, merging rt2x00 now is undoubtedly better than having no driver at all. I appreciate your understanding and cooperation! I was just surprised to see the pull request floating by, but you were right, there should be enough time to resolve the remaining issues and it is actually a good thing to start moving rt2x00 further upstream. Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3 v4] rfkill: Remove IRDA
As Dmitry pointed out earlier, rfkill-input.c
doesn't support irda because there are no users
and we shouldn't add unrequired KEY_ defines.
However, RFKILL_TYPE_IRDA was defined in the
rfkill.h header file and would confuse people
about whether it is implemented or not.
This patch removes IRDA support completely,
so it can be added whenever a driver wants the
feature.
Signed-off-by: Ivo van Doorn [EMAIL PROTECTED]
CC: Dmitry Torokhov [EMAIL PROTECTED]
CC: Inaky Perez-Gonzalez [EMAIL PROTECTED]
---
include/linux/rfkill.h |8 +++-
net/rfkill/Kconfig |2 +-
net/rfkill/rfkill.c|5 +
3 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
index a8a6ea8..c4546e1 100644
--- a/include/linux/rfkill.h
+++ b/include/linux/rfkill.h
@@ -31,13 +31,11 @@
* enum rfkill_type - type of rfkill switch.
* RFKILL_TYPE_WLAN: switch is no a Wireless network devices.
* RFKILL_TYPE_BlUETOOTH: switch is on a bluetooth device.
- * RFKILL_TYPE_IRDA: switch is on an infrared devices.
*/
enum rfkill_type {
- RFKILL_TYPE_WLAN = 0,
- RFKILL_TYPE_BLUETOOTH = 1,
- RFKILL_TYPE_IRDA = 2,
- RFKILL_TYPE_MAX = 3,
+ RFKILL_TYPE_WLAN ,
+ RFKILL_TYPE_BLUETOOTH,
+ RFKILL_TYPE_MAX,
};
enum rfkill_state {
diff --git a/net/rfkill/Kconfig b/net/rfkill/Kconfig
index 8b31759..d28a6d9 100644
--- a/net/rfkill/Kconfig
+++ b/net/rfkill/Kconfig
@@ -5,7 +5,7 @@ menuconfig RFKILL
tristate RF switch subsystem support
help
Say Y here if you want to have control over RF switches
- found on many WiFi, Bluetooth and IRDA cards.
+ found on many WiFi and Bluetooth cards.
To compile this driver as a module, choose M here: the
module will be called rfkill.
diff --git a/net/rfkill/rfkill.c b/net/rfkill/rfkill.c
index db3395b..50e0102 100644
--- a/net/rfkill/rfkill.c
+++ b/net/rfkill/rfkill.c
@@ -106,9 +106,6 @@ static ssize_t rfkill_type_show(struct device *dev,
case RFKILL_TYPE_BLUETOOTH:
type = bluetooth;
break;
- case RFKILL_TYPE_IRDA:
- type = irda;
- break;
default:
BUG();
}
@@ -281,7 +278,7 @@ static void rfkill_remove_switch(struct rfkill *rfkill)
/**
* rfkill_allocate - allocate memory for rfkill structure.
* @parent: device that has rf switch on it
- * @type: type of the switch (wlan, bluetooth, irda)
+ * @type: type of the switch (RFKILL_TYPE_*)
*
* This function should be called by the network driver when it needs
* rfkill structure. Once the structure is allocated the driver shoud
--
1.5.3
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3 v4] rfkill: Add support for ultrawideband
This patch will add support for UWB keys to rfkill,
support for this has been requested by Inaky.
Signed-off-by: Ivo van Doorn [EMAIL PROTECTED]
CC: Dmitry Torokhov [EMAIL PROTECTED]
CC: Inaky Perez-Gonzalez [EMAIL PROTECTED]
---
include/linux/input.h |1 +
include/linux/rfkill.h|2 ++
net/rfkill/rfkill-input.c |9 +
net/rfkill/rfkill.c |3 +++
4 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/include/linux/input.h b/include/linux/input.h
index cf2b561..8e5828d 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -360,6 +360,7 @@ struct input_absinfo {
#define KEY_BLUETOOTH 237
#define KEY_WLAN 238
+#define KEY_UWB239
#define KEY_UNKNOWN240
diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
index c4546e1..f9a50da 100644
--- a/include/linux/rfkill.h
+++ b/include/linux/rfkill.h
@@ -31,10 +31,12 @@
* enum rfkill_type - type of rfkill switch.
* RFKILL_TYPE_WLAN: switch is no a Wireless network devices.
* RFKILL_TYPE_BlUETOOTH: switch is on a bluetooth device.
+ * RFKILL_TYPE_UWB: switch is on a Ultra wideband device.
*/
enum rfkill_type {
RFKILL_TYPE_WLAN ,
RFKILL_TYPE_BLUETOOTH,
+ RFKILL_TYPE_UWB,
RFKILL_TYPE_MAX,
};
diff --git a/net/rfkill/rfkill-input.c b/net/rfkill/rfkill-input.c
index 9f746be..8e4516a 100644
--- a/net/rfkill/rfkill-input.c
+++ b/net/rfkill/rfkill-input.c
@@ -81,6 +81,7 @@ static void rfkill_schedule_toggle(struct rfkill_task *task)
static DEFINE_RFKILL_TASK(rfkill_wlan, RFKILL_TYPE_WLAN);
static DEFINE_RFKILL_TASK(rfkill_bt, RFKILL_TYPE_BLUETOOTH);
+static DEFINE_RFKILL_TASK(rfkill_uwb, RFKILL_TYPE_UWB);
static void rfkill_event(struct input_handle *handle, unsigned int type,
unsigned int code, int down)
@@ -93,6 +94,9 @@ static void rfkill_event(struct input_handle *handle,
unsigned int type,
case KEY_BLUETOOTH:
rfkill_schedule_toggle(rfkill_bt);
break;
+ case KEY_UWB:
+ rfkill_schedule_toggle(rfkill_uwb);
+ break;
default:
break;
}
@@ -148,6 +152,11 @@ static const struct input_device_id rfkill_ids[] = {
.evbit = { BIT(EV_KEY) },
.keybit = { [LONG(KEY_BLUETOOTH)] = BIT(KEY_BLUETOOTH) },
},
+ {
+ .flags = INPUT_DEVICE_ID_MATCH_EVBIT |
INPUT_DEVICE_ID_MATCH_KEYBIT,
+ .evbit = { BIT(EV_KEY) },
+ .keybit = { [LONG(KEY_UWB)] = BIT(KEY_UWB) },
+ },
{ }
};
diff --git a/net/rfkill/rfkill.c b/net/rfkill/rfkill.c
index 50e0102..03ed7fd 100644
--- a/net/rfkill/rfkill.c
+++ b/net/rfkill/rfkill.c
@@ -106,6 +106,9 @@ static ssize_t rfkill_type_show(struct device *dev,
case RFKILL_TYPE_BLUETOOTH:
type = bluetooth;
break;
+ case RFKILL_TYPE_UWB:
+ type = ultrawideband;
+ break;
default:
BUG();
}
--
1.5.3
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3 v4] rfkill: Add rfkill documentation
Add a documentation file which contains a short description about rfkill with some notes about drivers and the userspace interface. Changes since v1 and v2: - Spellchecking Signed-off-by: Ivo van Doorn [EMAIL PROTECTED] Acked-by: Dmitry Torokhov [EMAIL PROTECTED] Acked-by: Randy Dunlap [EMAIL PROTECTED] --- Documentation/rfkill.txt | 89 ++ 1 files changed, 89 insertions(+), 0 deletions(-) create mode 100644 Documentation/rfkill.txt diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt new file mode 100644 index 000..a83ff23 --- /dev/null +++ b/Documentation/rfkill.txt @@ -0,0 +1,89 @@ +rfkill - RF switch subsystem support + + +1 Implementation details +2 Driver support +3 Userspace support + +=== +1: Implementation details + +The rfkill switch subsystem offers support for keys often found on laptops +to enable wireless devices like WiFi and Bluetooth. + +This is done by providing the user 3 possibilities: + 1 - The rfkill system handles all events; userspace is not aware of events. + 2 - The rfkill system handles all events; userspace is informed about the events. + 3 - The rfkill system does not handle events; userspace handles all events. + +The buttons to enable and disable the wireless radios are important in +situations where the user is for example using his laptop on a location where +wireless radios _must_ be disabled (e.g. airplanes). +Because of this requirement, userspace support for the keys should not be +made mandatory. Because userspace might want to perform some additional smarter +tasks when the key is pressed, rfkill still provides userspace the possibility +to take over the task to handle the key events. + +The system inside the kernel has been split into 2 separate sections: + 1 - RFKILL + 2 - RFKILL_INPUT + +The first option enables rfkill support and will make sure userspace will +be notified of any events through the input device. It also creates several +sysfs entries which can be used by userspace. See section Userspace support. + +The second option provides an rfkill input handler. This handler will +listen to all rfkill key events and will toggle the radio accordingly. +With this option enabled userspace could either do nothing or simply +perform monitoring tasks. + + +2: Driver support + +To build a driver with rfkill subsystem support, the driver should +depend on the Kconfig symbol RFKILL; it should _not_ depend on +RKFILL_INPUT. + +Unless key events trigger an interrupt to which the driver listens, polling +will be required to determine the key state changes. For this the input +layer providers the input-polldev handler. + +A driver should implement a few steps to correctly make use of the +rfkill subsystem. First for non-polling drivers: + + - rfkill_allocate() + - input_allocate_device() + - rfkill_register() + - input_register_device() + +For polling drivers: + + - rfkill_allocate() + - input_allocate_polled_device() + - rfkill_register() + - input_register_polled_device() + +When a key event has been detected, the correct event should be +sent over the input device which has been registered by the driver. + + +3: Userspace support + +For each key an input device will be created which will send out the correct +key event when the rfkill key has been pressed. + +The following sysfs entries will be created: + + name: Name assigned by driver to this key (interface or driver name). + type: Name of the key type (wlan, bluetooth, etc). + state: Current state of the key. 1: On, 0: Off. + claim: 1: Userspace handles events, 0: Kernel handles events + +Both the state and claim entries are also writable. For the state entry +this means that when 1 or 0 is written all radios, not yet in the requested +state, will be will be toggled accordingly. +For the claim entry writing 1 to it means that the kernel no longer handles +key events even though RFKILL_INPUT input was enabled. When claim has been +set to 0, userspace should make sure that it listens for the input events or +check the sysfs state entry regularly to correctly perform the required +tasks when the rkfill key is pressed. -- 1.5.3 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] rfkill: Add rfkill documentation
On Monday 10 September 2007, Randy Dunlap wrote: On Mon, 10 Sep 2007 19:56:03 +0200 Ivo van Doorn wrote: Add a documentation file which contains a short description about rfkill with some notes about drivers and the userspace interface. Thanks. I have noted a few typo/editorial changes below. Thanks! I'll resend this patch within a few minutes. :) Ivo Signed-off-by: Ivo van Doorn [EMAIL PROTECTED] Acked-by: Dmitry Torokhov [EMAIL PROTECTED] --- Documentation/rfkill.txt | 88 ++ 1 files changed, 88 insertions(+), 0 deletions(-) create mode 100644 Documentation/rfkill.txt diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt new file mode 100644 index 000..93c76fc --- /dev/null +++ b/Documentation/rfkill.txt @@ -0,0 +1,88 @@ +rfkill - RF switch subsystem support + + +1 Implementation details +2 Driver support +3 Userspace support + +=== +1: Implementation details + +The rfkill switch subsystem offers support for keys often found on laptops +to enable wireless devices like WiFi and Bluetooth. + +This is done by providing the user 3 possibilities: + - The rfkill system handles all events, userspace is not aware of events. + - The rfkill system handles all events, userspace is informed about the event. + - The rfkill system does not handle events, userspace handles all events. I would s/,/;/ in the 3 lines above. +The buttons to enable and disable the wireless radios are important in +situations where the user is for example using his laptop on a location where +wireless radios _must_ be disabled (e.g airplanes). +Because of this requirement, userspace support for the keys should not be +made mandatory. Because userspace might want to perform some additional smarter +tasks when the key is pressed, rfkill still provides userspace the possibility +to take over the task to handle the key events. + +The system inside the kernel has been split into 2 seperate sections: separate + 1 - RFKILL + 2 - RFKILL_INPUT + +The first option enables rfkill support and will make sure userspace will +be notified of any events through the input device. It also creates several +sysfs entries which can be used by userspace. See section Userspace support. + +The second option provides a rfkill input handler. This handler will an +listen to all rfkill key events and will toggle the radio accordingly, end above with ; or . If '.', s/with/With/ on next line. +with this option enabled userspace could either do nothing or simply +perform monitoring tasks. + + +2: Driver support + +Drivers who wish to build in rfkill subsystem support should Drivers that But, drivers can't/don't wish, so it would be better to say something like: To build a driver with rfkill subsystem support, the driver should depend on the Kconfig symbol RFKILL; it should _not_ depend on RKFILL_INPUT. +make sure their driver depends of the Kconfig option RFKILL, it should +_not_ depend on RFKILL_INPUT. + +Unless key events trigger a interrupt to which the driver listens, polling an interrupt +will be required to determine the key state changes. For this the input +layer providers the input-polldev handler. + +A driver should implement a few steps to correctly make use of the +rfkill subsystem. First for non-polling drivers: + + - rfkill_allocate() + - input_allocate_device() + - rfkill_register() + - input_register_device() + +For polling drivers: + + - rfkill_allocate() + - input_allocate_polled_device() + - rfkill_register() + - input_register_polled_device() + +When a key event has been detected, the correct event should be +send over the input device which has been registered by the driver. sent + + +3: Userspace support + +For each key a input device will be created which will send out the correct an +key event when the rfkill key has been pressed. + +The following sysfs entries will be created: + + name: Name assigned by driver to this key (interface or driver name). + type: Name of the key type (wlan, bluetooth, etc). + state: Current state of the key. 1: On, 0: Off. + claim: 1: Userspace handles events, 0: Kernel handles events + +Both the state and claim entries are also writable. For the state entry +this means that when 1 or 0 is written all radios will be toggled accordingly. will be written even if they are already in that state? +For the claim entry writing 1
[PATCH 3/3 v2] rfkill: Add rfkill documentation
Add a documentation file which contains a short description about rfkill with some notes about drivers and the userspace interface. Changes since v1: - Spellchecking Signed-off-by: Ivo van Doorn [EMAIL PROTECTED] Acked-by: Dmitry Torokhov [EMAIL PROTECTED] --- Only patch 3 was updated, patches 1 and 2 remain the same. Documentation/rfkill.txt | 89 ++ 1 files changed, 89 insertions(+), 0 deletions(-) create mode 100644 Documentation/rfkill.txt diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt new file mode 100644 index 000..0f35134 --- /dev/null +++ b/Documentation/rfkill.txt @@ -0,0 +1,89 @@ +rfkill - RF switch subsystem support + + +1 Implementation details +2 Driver support +3 Userspace support + +=== +1: Implementation details + +The rfkill switch subsystem offers support for keys often found on laptops +to enable wireless devices like WiFi and Bluetooth. + +This is done by providing the user 3 possibilities: + 1 - The rfkill system handles all events, userspace is not aware of events; + 2 - The rfkill system handles all events, userspace is informed about the event; + 3 - The rfkill system does not handle events, userspace handles all events; + +The buttons to enable and disable the wireless radios are important in +situations where the user is for example using his laptop on a location where +wireless radios _must_ be disabled (e.g. airplanes). +Because of this requirement, userspace support for the keys should not be +made mandatory. Because userspace might want to perform some additional smarter +tasks when the key is pressed, rfkill still provides userspace the possibility +to take over the task to handle the key events. + +The system inside the kernel has been split into 2 separate sections: + 1 - RFKILL + 2 - RFKILL_INPUT + +The first option enables rfkill support and will make sure userspace will +be notified of any events through the input device. It also creates several +sysfs entries which can be used by userspace. See section Userspace support. + +The second option provides an rfkill input handler. This handler will +listen to all rfkill key events and will toggle the radio accordingly. +With this option enabled userspace could either do nothing or simply +perform monitoring tasks. + + +2: Driver support + +To build a driver with rfkill subsystem support, the driver should +depend on the Kconfig symbol RFKILL; it should _not_ depend on +RKFILL_INPUT. + +Unless key events trigger an interrupt to which the driver listens, polling +will be required to determine the key state changes. For this the input +layer providers the input-polldev handler. + +A driver should implement a few steps to correctly make use of the +rfkill subsystem. First for non-polling drivers: + + - rfkill_allocate() + - input_allocate_device() + - rfkill_register() + - input_register_device() + +For polling drivers: + + - rfkill_allocate() + - input_allocate_polled_device() + - rfkill_register() + - input_register_polled_device() + +When a key event has been detected, the correct event should be +sent over the input device which has been registered by the driver. + + +3: Userspace support + +For each key an input device will be created which will send out the correct +key event when the rfkill key has been pressed. + +The following sysfs entries will be created: + + name: Name assigned by driver to this key (interface or driver name). + type: Name of the key type (wlan, bluetooth, etc). + state: Current state of the key. 1: On, 0: Off. + claim: 1: Userspace handles events, 0: Kernel handles events + +Both the state and claim entries are also writable. For the state entry +this means that when 1 or 0 is written all radios, not yet in the requested +state, will be will be toggled accordingly. +For the claim entry writing 1 to it means that the kernel no longer handles +handle key events even though RFKILL_INPUT input was enabled. When claim has +been set to 0, userspace should make sure that it listens for the input events +or check the sysfs state entry regularly to correctly perform the required +tasks when the rkfill key is pressed. -- 1.5.3 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3 v3] rfkill: Add rfkill documentation
Add a documentation file which contains a short description about rfkill with some notes about drivers and the userspace interface. Changes since v1 and v2: - Spellchecking Signed-off-by: Ivo van Doorn [EMAIL PROTECTED] Acked-by: Dmitry Torokhov [EMAIL PROTECTED] --- Only patch 3 was updated, patches 1 and 2 remain the same. Documentation/rfkill.txt | 89 ++ 1 files changed, 89 insertions(+), 0 deletions(-) create mode 100644 Documentation/rfkill.txt diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt new file mode 100644 index 000..a83ff23 --- /dev/null +++ b/Documentation/rfkill.txt @@ -0,0 +1,89 @@ +rfkill - RF switch subsystem support + + +1 Implementation details +2 Driver support +3 Userspace support + +=== +1: Implementation details + +The rfkill switch subsystem offers support for keys often found on laptops +to enable wireless devices like WiFi and Bluetooth. + +This is done by providing the user 3 possibilities: + 1 - The rfkill system handles all events; userspace is not aware of events. + 2 - The rfkill system handles all events; userspace is informed about the events. + 3 - The rfkill system does not handle events; userspace handles all events. + +The buttons to enable and disable the wireless radios are important in +situations where the user is for example using his laptop on a location where +wireless radios _must_ be disabled (e.g. airplanes). +Because of this requirement, userspace support for the keys should not be +made mandatory. Because userspace might want to perform some additional smarter +tasks when the key is pressed, rfkill still provides userspace the possibility +to take over the task to handle the key events. + +The system inside the kernel has been split into 2 separate sections: + 1 - RFKILL + 2 - RFKILL_INPUT + +The first option enables rfkill support and will make sure userspace will +be notified of any events through the input device. It also creates several +sysfs entries which can be used by userspace. See section Userspace support. + +The second option provides an rfkill input handler. This handler will +listen to all rfkill key events and will toggle the radio accordingly. +With this option enabled userspace could either do nothing or simply +perform monitoring tasks. + + +2: Driver support + +To build a driver with rfkill subsystem support, the driver should +depend on the Kconfig symbol RFKILL; it should _not_ depend on +RKFILL_INPUT. + +Unless key events trigger an interrupt to which the driver listens, polling +will be required to determine the key state changes. For this the input +layer providers the input-polldev handler. + +A driver should implement a few steps to correctly make use of the +rfkill subsystem. First for non-polling drivers: + + - rfkill_allocate() + - input_allocate_device() + - rfkill_register() + - input_register_device() + +For polling drivers: + + - rfkill_allocate() + - input_allocate_polled_device() + - rfkill_register() + - input_register_polled_device() + +When a key event has been detected, the correct event should be +sent over the input device which has been registered by the driver. + + +3: Userspace support + +For each key an input device will be created which will send out the correct +key event when the rfkill key has been pressed. + +The following sysfs entries will be created: + + name: Name assigned by driver to this key (interface or driver name). + type: Name of the key type (wlan, bluetooth, etc). + state: Current state of the key. 1: On, 0: Off. + claim: 1: Userspace handles events, 0: Kernel handles events + +Both the state and claim entries are also writable. For the state entry +this means that when 1 or 0 is written all radios, not yet in the requested +state, will be will be toggled accordingly. +For the claim entry writing 1 to it means that the kernel no longer handles +key events even though RFKILL_INPUT input was enabled. When claim has been +set to 0, userspace should make sure that it listens for the input events or +check the sysfs state entry regularly to correctly perform the required +tasks when the rkfill key is pressed. -- 1.5.3 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] rfkill: Remove IRDA
As Dmitry pointed out earlier, rfkill-input.c
doesn't support irda because there are no users
and we shouldn't add unrequired KEY_ defines.
However, RFKILL_TYPE_IRDA was defined in the
rfkill.h header file and would confuse people
about whether it is implemented or not.
This patch removes IRDA support completely,
so it can be added whenever a driver wants the
feature.
Signed-off-by: Ivo van Doorn [EMAIL PROTECTED]
Acked-by: Dmitry Torokhov [EMAIL PROTECTED]
---
include/linux/rfkill.h |8 +++-
net/rfkill/Kconfig |2 +-
net/rfkill/rfkill.c|5 +
3 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
index a8a6ea8..c4546e1 100644
--- a/include/linux/rfkill.h
+++ b/include/linux/rfkill.h
@@ -31,13 +31,11 @@
* enum rfkill_type - type of rfkill switch.
* RFKILL_TYPE_WLAN: switch is no a Wireless network devices.
* RFKILL_TYPE_BlUETOOTH: switch is on a bluetooth device.
- * RFKILL_TYPE_IRDA: switch is on an infrared devices.
*/
enum rfkill_type {
- RFKILL_TYPE_WLAN = 0,
- RFKILL_TYPE_BLUETOOTH = 1,
- RFKILL_TYPE_IRDA = 2,
- RFKILL_TYPE_MAX = 3,
+ RFKILL_TYPE_WLAN ,
+ RFKILL_TYPE_BLUETOOTH,
+ RFKILL_TYPE_MAX,
};
enum rfkill_state {
diff --git a/net/rfkill/Kconfig b/net/rfkill/Kconfig
index 8b31759..d28a6d9 100644
--- a/net/rfkill/Kconfig
+++ b/net/rfkill/Kconfig
@@ -5,7 +5,7 @@ menuconfig RFKILL
tristate RF switch subsystem support
help
Say Y here if you want to have control over RF switches
- found on many WiFi, Bluetooth and IRDA cards.
+ found on many WiFi and Bluetooth cards.
To compile this driver as a module, choose M here: the
module will be called rfkill.
diff --git a/net/rfkill/rfkill.c b/net/rfkill/rfkill.c
index db3395b..50e0102 100644
--- a/net/rfkill/rfkill.c
+++ b/net/rfkill/rfkill.c
@@ -106,9 +106,6 @@ static ssize_t rfkill_type_show(struct device *dev,
case RFKILL_TYPE_BLUETOOTH:
type = bluetooth;
break;
- case RFKILL_TYPE_IRDA:
- type = irda;
- break;
default:
BUG();
}
@@ -281,7 +278,7 @@ static void rfkill_remove_switch(struct rfkill *rfkill)
/**
* rfkill_allocate - allocate memory for rfkill structure.
* @parent: device that has rf switch on it
- * @type: type of the switch (wlan, bluetooth, irda)
+ * @type: type of the switch (RFKILL_TYPE_*)
*
* This function should be called by the network driver when it needs
* rfkill structure. Once the structure is allocated the driver shoud
--
1.5.3
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] rfkill: Add support for ultrawideband
This patch will add support for UWB keys to rfkill,
support for this has been requested by Inaky.
Signed-off-by: Ivo van Doorn [EMAIL PROTECTED]
Acked-by: Dmitry Torokhov [EMAIL PROTECTED]
---
include/linux/input.h |1 +
include/linux/rfkill.h|2 ++
net/rfkill/rfkill-input.c |9 +
net/rfkill/rfkill.c |3 +++
4 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/include/linux/input.h b/include/linux/input.h
index cf2b561..8e5828d 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -360,6 +360,7 @@ struct input_absinfo {
#define KEY_BLUETOOTH 237
#define KEY_WLAN 238
+#define KEY_UWB239
#define KEY_UNKNOWN240
diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
index c4546e1..f9a50da 100644
--- a/include/linux/rfkill.h
+++ b/include/linux/rfkill.h
@@ -31,10 +31,12 @@
* enum rfkill_type - type of rfkill switch.
* RFKILL_TYPE_WLAN: switch is no a Wireless network devices.
* RFKILL_TYPE_BlUETOOTH: switch is on a bluetooth device.
+ * RFKILL_TYPE_UWB: switch is on a Ultra wideband device.
*/
enum rfkill_type {
RFKILL_TYPE_WLAN ,
RFKILL_TYPE_BLUETOOTH,
+ RFKILL_TYPE_UWB,
RFKILL_TYPE_MAX,
};
diff --git a/net/rfkill/rfkill-input.c b/net/rfkill/rfkill-input.c
index 9f746be..8e4516a 100644
--- a/net/rfkill/rfkill-input.c
+++ b/net/rfkill/rfkill-input.c
@@ -81,6 +81,7 @@ static void rfkill_schedule_toggle(struct rfkill_task *task)
static DEFINE_RFKILL_TASK(rfkill_wlan, RFKILL_TYPE_WLAN);
static DEFINE_RFKILL_TASK(rfkill_bt, RFKILL_TYPE_BLUETOOTH);
+static DEFINE_RFKILL_TASK(rfkill_uwb, RFKILL_TYPE_UWB);
static void rfkill_event(struct input_handle *handle, unsigned int type,
unsigned int code, int down)
@@ -93,6 +94,9 @@ static void rfkill_event(struct input_handle *handle,
unsigned int type,
case KEY_BLUETOOTH:
rfkill_schedule_toggle(rfkill_bt);
break;
+ case KEY_UWB:
+ rfkill_schedule_toggle(rfkill_uwb);
+ break;
default:
break;
}
@@ -148,6 +152,11 @@ static const struct input_device_id rfkill_ids[] = {
.evbit = { BIT(EV_KEY) },
.keybit = { [LONG(KEY_BLUETOOTH)] = BIT(KEY_BLUETOOTH) },
},
+ {
+ .flags = INPUT_DEVICE_ID_MATCH_EVBIT |
INPUT_DEVICE_ID_MATCH_KEYBIT,
+ .evbit = { BIT(EV_KEY) },
+ .keybit = { [LONG(KEY_UWB)] = BIT(KEY_UWB) },
+ },
{ }
};
diff --git a/net/rfkill/rfkill.c b/net/rfkill/rfkill.c
index 50e0102..03ed7fd 100644
--- a/net/rfkill/rfkill.c
+++ b/net/rfkill/rfkill.c
@@ -106,6 +106,9 @@ static ssize_t rfkill_type_show(struct device *dev,
case RFKILL_TYPE_BLUETOOTH:
type = bluetooth;
break;
+ case RFKILL_TYPE_UWB:
+ type = ultrawideband;
+ break;
default:
BUG();
}
--
1.5.3
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] rfkill: Add rfkill documentation
Add a documentation file which contains a short description about rfkill with some notes about drivers and the userspace interface. Signed-off-by: Ivo van Doorn [EMAIL PROTECTED] Acked-by: Dmitry Torokhov [EMAIL PROTECTED] --- Documentation/rfkill.txt | 88 ++ 1 files changed, 88 insertions(+), 0 deletions(-) create mode 100644 Documentation/rfkill.txt diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt new file mode 100644 index 000..93c76fc --- /dev/null +++ b/Documentation/rfkill.txt @@ -0,0 +1,88 @@ +rfkill - RF switch subsystem support + + +1 Implementation details +2 Driver support +3 Userspace support + +=== +1: Implementation details + +The rfkill switch subsystem offers support for keys often found on laptops +to enable wireless devices like WiFi and Bluetooth. + +This is done by providing the user 3 possibilities: + - The rfkill system handles all events, userspace is not aware of events. + - The rfkill system handles all events, userspace is informed about the event. + - The rfkill system does not handle events, userspace handles all events. + +The buttons to enable and disable the wireless radios are important in +situations where the user is for example using his laptop on a location where +wireless radios _must_ be disabled (e.g airplanes). +Because of this requirement, userspace support for the keys should not be +made mandatory. Because userspace might want to perform some additional smarter +tasks when the key is pressed, rfkill still provides userspace the possibility +to take over the task to handle the key events. + +The system inside the kernel has been split into 2 seperate sections: + 1 - RFKILL + 2 - RFKILL_INPUT + +The first option enables rfkill support and will make sure userspace will +be notified of any events through the input device. It also creates several +sysfs entries which can be used by userspace. See section Userspace support. + +The second option provides a rfkill input handler. This handler will +listen to all rfkill key events and will toggle the radio accordingly, +with this option enabled userspace could either do nothing or simply +perform monitoring tasks. + + +2: Driver support + +Drivers who wish to build in rfkill subsystem support should +make sure their driver depends of the Kconfig option RFKILL, it should +_not_ depend on RFKILL_INPUT. + +Unless key events trigger a interrupt to which the driver listens, polling +will be required to determine the key state changes. For this the input +layer providers the input-polldev handler. + +A driver should implement a few steps to correctly make use of the +rfkill subsystem. First for non-polling drivers: + + - rfkill_allocate() + - input_allocate_device() + - rfkill_register() + - input_register_device() + +For polling drivers: + + - rfkill_allocate() + - input_allocate_polled_device() + - rfkill_register() + - input_register_polled_device() + +When a key event has been detected, the correct event should be +send over the input device which has been registered by the driver. + + +3: Userspace support + +For each key a input device will be created which will send out the correct +key event when the rfkill key has been pressed. + +The following sysfs entries will be created: + + name: Name assigned by driver to this key (interface or driver name). + type: Name of the key type (wlan, bluetooth, etc). + state: Current state of the key. 1: On, 0: Off. + claim: 1: Userspace handles events, 0: Kernel handles events + +Both the state and claim entries are also writable. For the state entry +this means that when 1 or 0 is written all radios will be toggled accordingly. +For the claim entry writing 1 to it will mean that the kernel will no longer +handle key events even though RFKILL_INPUT input was enabled. When claim has +been set to 0, userspace should make sure it will listen for the input events +or check the sysfs state entry regularly to correctly perform the required +tasks when the rkfill key is pressed. -- 1.5.3 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/3] rfkill
Hi Dmitry, I have a few rfkill related patches for which I would prefer if you to could take a look at before I send them for inclusion. Thanks. :) Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/3] rfkill: Remove IRDA
As Dmitry pointed out earlier, rfkill-input.c
doesn't support irda because there are no users
and we shouldn't add unrequired KEY_ defines.
However, RFKILL_TYPE_IRDA was defined in the
rfkill.h header file and would confuse people
about whether it is implemented or not.
This patch removes IRDA support completely,
so it can be added whenever a driver wants the
feature.
Signed-off-by: Ivo van Doorn [EMAIL PROTECTED]
---
include/linux/rfkill.h |8 +++-
net/rfkill/Kconfig |2 +-
net/rfkill/rfkill.c|5 +
3 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
index a8a6ea8..c4546e1 100644
--- a/include/linux/rfkill.h
+++ b/include/linux/rfkill.h
@@ -31,13 +31,11 @@
* enum rfkill_type - type of rfkill switch.
* RFKILL_TYPE_WLAN: switch is no a Wireless network devices.
* RFKILL_TYPE_BlUETOOTH: switch is on a bluetooth device.
- * RFKILL_TYPE_IRDA: switch is on an infrared devices.
*/
enum rfkill_type {
- RFKILL_TYPE_WLAN = 0,
- RFKILL_TYPE_BLUETOOTH = 1,
- RFKILL_TYPE_IRDA = 2,
- RFKILL_TYPE_MAX = 3,
+ RFKILL_TYPE_WLAN ,
+ RFKILL_TYPE_BLUETOOTH,
+ RFKILL_TYPE_MAX,
};
enum rfkill_state {
diff --git a/net/rfkill/Kconfig b/net/rfkill/Kconfig
index 8b31759..d28a6d9 100644
--- a/net/rfkill/Kconfig
+++ b/net/rfkill/Kconfig
@@ -5,7 +5,7 @@ menuconfig RFKILL
tristate RF switch subsystem support
help
Say Y here if you want to have control over RF switches
- found on many WiFi, Bluetooth and IRDA cards.
+ found on many WiFi and Bluetooth cards.
To compile this driver as a module, choose M here: the
module will be called rfkill.
diff --git a/net/rfkill/rfkill.c b/net/rfkill/rfkill.c
index db3395b..50e0102 100644
--- a/net/rfkill/rfkill.c
+++ b/net/rfkill/rfkill.c
@@ -106,9 +106,6 @@ static ssize_t rfkill_type_show(struct device *dev,
case RFKILL_TYPE_BLUETOOTH:
type = bluetooth;
break;
- case RFKILL_TYPE_IRDA:
- type = irda;
- break;
default:
BUG();
}
@@ -281,7 +278,7 @@ static void rfkill_remove_switch(struct rfkill *rfkill)
/**
* rfkill_allocate - allocate memory for rfkill structure.
* @parent: device that has rf switch on it
- * @type: type of the switch (wlan, bluetooth, irda)
+ * @type: type of the switch (RFKILL_TYPE_*)
*
* This function should be called by the network driver when it needs
* rfkill structure. Once the structure is allocated the driver shoud
--
1.5.3
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Rt2400-devel] [BUG] rt2x00: inconsistent lock state
Hi, If I'm reading the state bits and the message correcly dev_base_lock was aquired for write with IRQ enabled (via register_netdevice), but lockep also saw it aquired for read *in* IRQ (hardirq) context (rt2x00 code path, via rt2x00lib_beacondone - ieee80211_beacon_get); this means that a deadlock can occur if we take an interrupt while the lock is already held. So either the lock must be IRQ-safe (_irq() / _irq_save()) or rt2x00 must not take it in interrupt context. This has already been fixed in rt2x00.git I am still working on resolving some other issues, but the rt2x00 2.0.7 release will contain the fix for this. Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] rfkill: Make rfkill-name const
The rfkill name can be made const safely,
this makes the compiler happy when drivers make
it point to some const string used elsewhere.
Signed-off-by: Ivo van Doorn [EMAIL PROTECTED]
---
diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
index 7c1ffba..a8a6ea8 100644
--- a/include/linux/rfkill.h
+++ b/include/linux/rfkill.h
@@ -63,7 +63,7 @@ enum rfkill_state {
* This structure represents a RF switch located on a network device.
*/
struct rfkill {
- char *name;
+ const char *name;
enum rfkill_type type;
enum rfkill_state state;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] rfkill: Fix check for correct rfkill allocation
coverity has spotted a bug in rfkill.c (bug id #1627), in rfkill_allocate() NULL was returns if the kzalloc() works, and deref the NULL pointer if it fails, Signed-off-by: Ivo van Doorn [EMAIL PROTECTED] --- diff --git a/net/rfkill/rfkill.c b/net/rfkill/rfkill.c index a973603..f3986d4 100644 --- a/net/rfkill/rfkill.c +++ b/net/rfkill/rfkill.c @@ -296,7 +296,7 @@ struct rfkill *rfkill_allocate(struct device *parent, enum rfkill_type type) struct device *dev; rfkill = kzalloc(sizeof(struct rfkill), GFP_KERNEL); - if (rfkill) + if (!rfkill) return NULL; mutex_init(rfkill-mutex); - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mac80211 ad-hoc: carrier not set up [was: Panic in ieee_80211_ibss_add_sta]
Hi,
However, ad-hoc still does not work, since the network device's
carrier status does not seem to be properly set. (It remains
in NO-CARRIER even after wlan0: Selected IBSS BSSID
92:68:a2:db:de:45 based on configured SSID. I dirtily hacked
around that with the following two-liner:
I was aware of the recent rt2x00 adhoc breakage but hadn't looked into it yet,
the below suggestion about the netif_carrier does make sense though,
since the last report it was working was before rt2x00 removed the
ieee80211_netif
calls, and the first report of its breakage was some time after the removal.
(Since a lot of code has been moved around in between the ieee80211_netif wasn't
the first thing that I would have thought of as a probable cause. ;) )
--- wireless-dev/net/mac80211/ieee80211_sta.c.orig2007-05-15
20:19:55.0 +0200
+++ wireless-dev/net/mac80211/ieee80211_sta.c 2007-05-15 21:19:38.362587215
+0200
@@ -2448,6 +2448,7 @@
mod_timer(ifsta-timer, jiffies + IEEE80211_IBSS_MERGE_INTERVAL);
ieee80211_rx_bss_put(dev, bss);
+ netif_carrier_on(dev);
return res;
}
@@ -2648,6 +2649,7 @@
ifsta-ssid_set = len ? 1 : 0;
if (sdata-type == IEEE80211_IF_TYPE_IBSS !ifsta-bssid_set) {
+ netif_carrier_off(dev);
ifsta-ibss_join_req = jiffies;
ifsta-state = IEEE80211_IBSS_SEARCH;
return ieee80211_sta_find_ibss(dev, ifsta);
However, I have NO CLUE WHAT I'M DOING THERE! Make a proper fix!
(Especially, I think it needs more netif_carrier_off calls in
different places.)
Anyway, thanks for my now-working wireless,
Ivo
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Add 93cx6 eeprom library
On Monday 07 May 2007 09:46, Michael Wu wrote:
From: Ivo van Doorn [EMAIL PROTECTED]
This patch adds a library for reading from and writing to 93cx6 eeproms.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
Signed-off-by: Ivo van Doorn [EMAIL PROTECTED]
---
drivers/misc/Kconfig |6 +
drivers/misc/Makefile|1
drivers/misc/eeprom_93cx6.c | 347
++
include/linux/eeprom_93cx6.h | 77 +
4 files changed, 431 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index a3c525b..607a180 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -178,4 +178,10 @@ config THINKPAD_ACPI_BAY
If you are not sure, say Y here.
+config EEPROM_93CX6
+ tristate EEPROM 93CX6 support
+ ---help---
+ This is a driver for the EEPROM chipsets 93c46 and 93c66.
+ The driver supports both read as well as write commands.
+
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e325164..42b34a9 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_TIFM_7XX1) += tifm_7
obj-$(CONFIG_SGI_IOC4) += ioc4.o
obj-$(CONFIG_SONY_LAPTOP)+= sony-laptop.o
obj-$(CONFIG_THINKPAD_ACPI) += thinkpad_acpi.o
+obj-$(CONFIG_EEPROM_93CX6) += eeprom_93cx6.o
diff --git a/drivers/misc/eeprom_93cx6.c b/drivers/misc/eeprom_93cx6.c
new file mode 100644
index 000..a948ddc
--- /dev/null
+++ b/drivers/misc/eeprom_93cx6.c
@@ -0,0 +1,347 @@
+/*
+ Copyright (C) 2004 - 2006 rt2x00 SourceForge Project
+ http://rt2x00.serialmonkey.com
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+/*
+ Module: eeprom_93cx6
+ Abstract: EEPROM reader routines for 93cx6 chipsets.
+ Supported chipsets: 93c46 93c66.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/version.h
+#include linux/delay.h
+#include linux/eeprom_93cx6.h
+
+MODULE_AUTHOR(http://rt2x00.serialmonkey.com;);
+MODULE_VERSION(1.0);
+MODULE_DESCRIPTION(EEPROM 93cx6 chip driver);
+MODULE_LICENSE(GPL);
+
+static inline void eeprom_93cx6_pulse_high(struct eeprom_93cx6 *eeprom)
+{
+ eeprom-reg_data_clock = 1;
+ eeprom-register_write(eeprom);
+ udelay(1);
+}
+
+static inline void eeprom_93cx6_pulse_low(struct eeprom_93cx6 *eeprom)
+{
+ eeprom-reg_data_clock = 0;
+ eeprom-register_write(eeprom);
+ udelay(1);
+}
+
+static void eeprom_93cx6_startup(struct eeprom_93cx6 *eeprom)
+{
+ /*
+ * Clear all flags, and enable chip select.
+ */
+ eeprom-register_read(eeprom);
+ eeprom-reg_data_in = 0;
+ eeprom-reg_data_out = 0;
+ eeprom-reg_data_clock = 0;
+ eeprom-reg_chip_select = 1;
+ eeprom-register_write(eeprom);
+
+ /*
+ * kick a pulse.
+ */
+ eeprom_93cx6_pulse_high(eeprom);
+ eeprom_93cx6_pulse_low(eeprom);
+}
+
+static void eeprom_93cx6_cleanup(struct eeprom_93cx6 *eeprom)
+{
+ /*
+ * Clear chip_select and data_in flags.
+ */
+ eeprom-register_read(eeprom);
+ eeprom-reg_data_in = 0;
+ eeprom-reg_chip_select = 0;
+ eeprom-register_write(eeprom);
+
+ /*
+ * kick a pulse.
+ */
+ eeprom_93cx6_pulse_high(eeprom);
+ eeprom_93cx6_pulse_low(eeprom);
+}
+
+static void eeprom_93cx6_write_bits(struct eeprom_93cx6 *eeprom,
+ const u16 data, const u16 count)
+{
+ unsigned int i;
+
+ eeprom-register_read(eeprom);
+
+ /*
+ * Clear data flags.
+ */
+ eeprom-reg_data_in = 0;
+ eeprom-reg_data_out = 0;
+
+ /*
+ * Start writing all bits.
+ */
+ for (i = count; i 0; i--) {
+ /*
+ * Check if this bit needs to be set.
+ */
+ eeprom-reg_data_in = !!(data (1 (i - 1)));
+
+ /*
+ * Write the bit to the eeprom register.
+ */
+ eeprom-register_write(eeprom);
+
+ /*
+ * Kick a pulse.
+ */
+ eeprom_93cx6_pulse_high(eeprom);
+ eeprom_93cx6_pulse_low(eeprom
Re: [RFC] rfkill - Add support for input key to control wireless radio
Well in drivers/net are the network drivers but not the irda and bluetooth drivers, those are located in different folders in drivers/ so I think misc would be the most suitable location. We could also consider the ./net itself. rfkill is not a driver, it is a facility. True, in that case ./net would be good. Does this make sense? Yes, but what if the user loads both modules or has them both compiled in? Shouldn't there be some protection against that, since both handlers should not be active at the same time. Why not? evdev is just a delivery transport for input events to userspace. Even if user wants the kernel to control state of RF switches (which I expect most users woudl want) there still could be applications interested in knowing that used turned off wireless. And if userspace really wishes to control switch all by itself it can claim it. Right, I forgot about that user_claim thingy. ;) I guess what you are missing is that input event generated by a device is pushed through every handler bound to the device so there is no way for a wrong handler to steals an event from right handler. They all work simultaneously. personally I would prefer enforcing drivers to call allocate() register() unregister() free() Especially with unregister() doing the same steps as free() (put_device) might be somwhat confusing. But might be just me. ;) I know but for refcounted objects you can't really tell when they will actually be freed. It depends when their last user drops off. Then perhaps rfkill_register could call put_device() when it fails, and free() can be removed entirely. That way it would we prevent some driver to call free() anyway. That would make error handling in -probe() methods a bit unwieldy I think - if you are using the standard goto err_xxx; goto err_yyy; technique then you have to conditionally call rfkill_free(). Hovewer if register simply fails and does not free anything and you call rfkill_register() last (which you need to do because driver has to be almost fully functional to be able to serve toggle_radio calls) you can always call rfkill_free() if something fails. Ok. Well that would mean rfkill would be ready to applied to one of the kernel trees right? :) The first user of rfkill would be rt2x00, which is in wireless-dev as well as -mm. The second user could be the driver from Lennart, but I haven't heard from him quite a while (although he is on the CC list) so I am not sure if his MSI driver can be fixed to use rfkill. His MSI driver is already in the linus' tree. A third user could be bcm43xx but I don't know how far they are with hardware key detection and status reading (to make it work with rfkill), perhaps Larry could give more information about that. Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] rfkill - Add support for input key to control wireless radio
Hi,
I am very sorry for taking so much time to respond but finally I went
through the patch and I still have the same objection as before -
it mixes two logically (and often physically) separated objects into
a single entity. I think that RF switch and button should be separate
entities, created and destroyed independently of each other. This way
everything handled uniformly by the kernel.
ok. Sounds good as well. :)
I attempted to rework the rfkill core supprt and simplify it and
came up with the patch below. Network card drivers that are able
to control state of their RF transmitters allocate and register
rfkill structures. Every rfkill structure belongs to one of
RF classes (WLAN, Bluetooth or IRDA) and exports its name, type,
state and user_claim through sysfs.
There is also an input handler that catces KEY_WLAN and KEY_BLUETOOTH
events passing through input system and toggles state of all RF
switches of appropriate type registered with rfkill system (unless
a switch was claimed by userspace in which case it is left alone).
I think this provides basic functionality that most of the users need
and any advanced control will have to be done from userspace.
Shouldn't a KEY_IRDA be added as well?
It isn't currently defined in input.h yet, but perhaps it actually should?
Or is IRDA treated differently for a specific reason?
In a followup patch there is a skeleton code for creating polled
input devices. For cards that have button physically connected
their drivers will have to register a separate input device and
let either input handler or userspace application take care of
switching RF state appropriately.
My only concern is where rfkill code should live. Since it is no
longer dependent on input core (embedded systems might disable
rfkill-input and use bare rfkill and control state from userspace)
it does not need to live in drivers/input.
How about:
rfkill - drivers/misc
rfkill_input - input/misc
input_polldev - lib/ (perhaps small namechange to rfkill_polldev?)
It would scatter the components a bit, but since each of those modules
has its own specific task this would make the most sense.
And by setting the depends and select fields for the menu entries correctly
it shouldn't be too big of a problem.
Please let me know what you think.
Just to get it straight on how these 3 modules would cooperate (before I start
mixing things up) ;)
- rfkill
- Drivers register to the rfkill module, rfkill
- Provides the sysfs interface
- Drivers that don't require polling should report the events to this
module
- rfkill_input
- Provides input device visible to userspace
- input_polldev
- Handlers polling, where the driver should check what the previous
state was and the driver
should send the event to rfkill.
Could input_polldev perhaps not be setup to poll, and keep track of the current
button status
and send the signal directly to rfkill?
What I am also not sure of is that input_polldev and rfkill_input both register
a input device.
Instead of starting and stopping the polling through the input device it would
perhaps make more
sense to either use the input device from rfkill_input and/or make use of a
sysfs attribute.
+/**
+ * rfkill_unregister - Uegister a rfkill structure.
+ * @rfkill: rfkill structure to be unregistered
+ *
+ * This function should be called by the network driver during device
+ * teardown to destroy rfkill structure. Note that rfkill_free() should
+ * _not_ be called after rfkill_unregister().
+ */
+void rfkill_unregister(struct rfkill *rfkill)
+{
+ device_del(rfkill-dev);
+ rfkill_remove_switch(rfkill);
+ put_device(rfkill-dev);
+}
+EXPORT_SYMBOL(rfkill_unregister);
personally I would prefer enforcing drivers to call
allocate()
register()
unregister()
free()
Especially with unregister() doing the same steps as free() (put_device)
might be somwhat confusing. But might be just me. ;)
The remainder looks good, unfortunately I can't test it since the laptop with
an rfkill button I have
requires isn't in a state for testing at this moment, and I would need to
figure out how button status
reading happens in bcm43xx.
Ivo
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] rfkill - Add support for input key to control wireless radio
There is also an input handler that catces KEY_WLAN and KEY_BLUETOOTH events passing through input system and toggles state of all RF switches of appropriate type registered with rfkill system (unless a switch was claimed by userspace in which case it is left alone). I think this provides basic functionality that most of the users need and any advanced control will have to be done from userspace. Shouldn't a KEY_IRDA be added as well? It isn't currently defined in input.h yet, but perhaps it actually should? Or is IRDA treated differently for a specific reason? Do we actually have cards with IRDA switches? We are kind of tight in input KEY_ namespace so I am hesitant to add defines before there actual users. Ah ok. Well that shouldn't be a problem, IRDA could be added once there are users for it. I am not sure if there are any devices with IRDA switches, so it shouldn't be a big problem. In a followup patch there is a skeleton code for creating polled input devices. For cards that have button physically connected their drivers will have to register a separate input device and let either input handler or userspace application take care of switching RF state appropriately. My only concern is where rfkill code should live. Since it is no longer dependent on input core (embedded systems might disable rfkill-input and use bare rfkill and control state from userspace) it does not need to live in drivers/input. How about: rfkill - drivers/misc Not in net? Well in drivers/net are the network drivers but not the irda and bluetooth drivers, those are located in different folders in drivers/ so I think misc would be the most suitable location. rfkill_input - input/misc I can go both ways on this one as it crosses line between input and rfkill. I think from user/Kconfig point of view it is better to keep it together with rfkill: user woudl select rfkill option and right then and there decide if he wants to give the kernel ability to automatically control RF switche Makes sense. input_polldev - lib/ (perhaps small namechange to rfkill_polldev?) No, I do not want to change name - I have bunch of drivers that can me converted to use this skeleton - wistron, aaedkbd, hdaps, ams, cobalt_btns. It is also pure input-related function so it is the only module that definitely belongs to drivers/input/misc. Ok. :) It would scatter the components a bit, but since each of those modules has its own specific task this would make the most sense. And by setting the depends and select fields for the menu entries correctly it shouldn't be too big of a problem. Please let me know what you think. Just to get it straight on how these 3 modules would cooperate (before I start mixing things up) ;) - rfkill - Drivers register to the rfkill module, rfkill - Provides the sysfs interface - Drivers that don't require polling should report the events to this module Not quite. Drivers that have buttons do not require polling still should create an input device and register it with input layer. Except that with interrupt-driven devices there is not much you can stub out so you just have to do input_allocate_device/input_register_device. - rfkill_input - Provides input device visible to userspace No, rfkill-input is not an input device but input handler (or input interface). It routes input events from buttons into switches (see below). - input_polldev - Handlers polling, where the driver should check what the previous state was and the driver should send the event to rfkill. This is the input device visible to userspace and kernel. It polls state of the button and sends KEY_WLAN/KEY_BLUETOOTH events through input layer. They get distributed through various input handlers such as evdev and rfkill-input. Evdev provides route for events to userspace where application can listen to events and then toggle RF switches according to the current policy via /sys/class/rfkill/rfkillXXX/state. Rfkill-input provides in-kernel route for events into rfkill system. If rfkill-input is loaded switches that are not claimed by userspace will be toggled automatically. Does this make sense? Yes, but what if the user loads both modules or has them both compiled in? Shouldn't there be some protection against that, since both handlers should not be active at the same time. Note that we don't start polling the state of button until tare are users of that input device. If rfkill-input is loaded then there is a user right away. Otherwise we wait for userspace to open evdev node. Sounds good. personally I would prefer enforcing drivers to call allocate() register() unregister() free() Especially with unregister() doing the same steps as free() (put_device) might be somwhat confusing. But might be just me. ;) I know but for
[PATCH v3] d80211: Add control structure for beacontemplates
Previous send v2 had a null pointer error in it.
When rt2500usb and rt73usb will start using beacontemplates,
they would also need a control structure to be passed along to
correctly set the tx parameters.
This patch will add a ieee80211_tx_control pointer to the
ieee80211_if_init_conf structure. This pointer is only a reference
to a local variable so drivers will not need to call kfree() on it.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rpU3 dscape/include/net/d80211.h dscape.control/include/net/d80211.h
--- dscape/include/net/d80211.h 2007-02-06 00:19:37.0 +0100
+++ dscape.control/include/net/d80211.h 2007-02-06 16:57:35.0 +0100
@@ -374,6 +374,8 @@ struct ieee80211_if_init_conf {
* @beacon: beacon template. Valid only if @host_gen_beacon_template in
* struct ieee80211_hw is set. The driver is responsible of freeing
* the sk_buff.
+ * @beacon_control: tx_control for the beacon template, this field is only
+ * valid when the @beacon field was set.
*
* This structure is passed to the config_interface() callback of
* struct ieee80211_hw.
@@ -386,6 +388,7 @@ struct ieee80211_if_conf {
u8 *generic_elem;
size_t generic_elem_len;
struct sk_buff *beacon;
+ struct ieee80211_tx_control *beacon_control;
};
typedef enum { ALG_NONE, ALG_WEP, ALG_TKIP, ALG_CCMP, ALG_NULL }
diff -rpU3 dscape/net/d80211/ieee80211.c dscape.control/net/d80211/ieee80211.c
--- dscape/net/d80211/ieee80211.c 2007-02-06 00:19:38.0 +0100
+++ dscape.control/net/d80211/ieee80211.c 2007-02-06 16:58:04.0
+0100
@@ -1857,7 +1857,8 @@ ieee80211_get_buffered_bc(struct ieee802
EXPORT_SYMBOL(ieee80211_get_buffered_bc);
static int __ieee80211_if_config(struct net_device *dev,
-struct sk_buff *beacon)
+struct sk_buff *beacon,
+struct ieee80211_tx_control *control)
{
struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
struct ieee80211_local *local = dev-ieee80211_ptr;
@@ -1881,6 +1882,7 @@ static int __ieee80211_if_config(struct
conf.generic_elem = sdata-u.ap.generic_elem;
conf.generic_elem_len = sdata-u.ap.generic_elem_len;
conf.beacon = beacon;
+ conf.beacon_control = control;
}
return local-ops-config_interface(local_to_hw(local),
dev-ifindex, conf);
@@ -1888,20 +1890,21 @@ static int __ieee80211_if_config(struct
int ieee80211_if_config(struct net_device *dev)
{
- return __ieee80211_if_config(dev, NULL);
+ return __ieee80211_if_config(dev, NULL, NULL);
}
int ieee80211_if_config_beacon(struct net_device *dev)
{
struct ieee80211_local *local = dev-ieee80211_ptr;
+ struct ieee80211_tx_control control;
struct sk_buff *skb;
if (!(local-hw.flags IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE))
return 0;
- skb = ieee80211_beacon_get(local_to_hw(local), dev-ifindex, NULL);
+ skb = ieee80211_beacon_get(local_to_hw(local), dev-ifindex, control);
if (!skb)
return -ENOMEM;
- return __ieee80211_if_config(dev, skb);
+ return __ieee80211_if_config(dev, skb, control);
}
int ieee80211_hw_config(struct ieee80211_local *local)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] d80211: respect extra_tx_headroom
When a driver requested additional header room
through the extra_tx_headroom field, the stack
should respect that and make sure that all frames
that are being send to the stack actually have
that extra header room.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 dscape/net/d80211/ieee80211.c dscape.hdr/net/d80211/ieee80211.c
--- dscape/net/d80211/ieee80211.c 2007-02-05 16:20:04.0 +0100
+++ dscape.hdr/net/d80211/ieee80211.c 2007-02-05 16:24:01.0 +0100
@@ -472,10 +472,9 @@
/* reserve enough extra head and tail room for possible
* encryption */
-#define IEEE80211_ENCRYPT_HEADROOM 8
-#define IEEE80211_ENCRYPT_TAILROOM 12
frag = frags[i] =
- dev_alloc_skb(frag_threshold +
+ dev_alloc_skb(tx-local-hw.extra_tx_headroom +
+ frag_threshold +
IEEE80211_ENCRYPT_HEADROOM +
IEEE80211_ENCRYPT_TAILROOM);
if (!frag)
@@ -483,7 +482,8 @@
/* Make sure that all fragments use the same priority so
* that they end up using the same TX queue */
frag-priority = first-priority;
- skb_reserve(frag, IEEE80211_ENCRYPT_HEADROOM);
+ skb_reserve(frag, tx-local-hw.extra_tx_headroom +
+ IEEE80211_ENCRYPT_HEADROOM);
fhdr = (struct ieee80211_hdr *) skb_put(frag, hdrlen);
memcpy(fhdr, first-data, hdrlen);
if (i == num_fragm - 2)
@@ -858,10 +858,13 @@
hdr_len = ieee80211_get_hdrlen(old_hdr-frame_control);
- tx-u.tx.rts_frame = dev_alloc_skb(hdr_len);
+ tx-u.tx.rts_frame = dev_alloc_skb(hdr_len +
+ tx-local-hw.extra_tx_headroom);
if (!tx-u.tx.rts_frame)
return TXRX_DROP;
+ skb_reserve(tx-u.tx.rts_frame, tx-local-hw.extra_tx_headroom);
+
new_hdr = (struct ieee80211_hdr*)skb_put(tx-u.tx.rts_frame, hdr_len);
memcpy(new_hdr, old_hdr, hdr_len);
@@ -1427,6 +1430,7 @@
struct ieee80211_tx_packet_data *pkt_data;
struct net_device *odev = NULL;
struct ieee80211_sub_if_data *osdata;
+ int headroom;
int ret;
/*
@@ -1451,6 +1455,15 @@
}
osdata = IEEE80211_DEV_TO_SUB_IF(odev);
+ headroom = osdata-local-hw.extra_tx_headroom +
+ IEEE80211_ENCRYPT_HEADROOM;
+ if (skb_headroom(skb) headroom) {
+ if (pskb_expand_head(skb, headroom, 0, GFP_ATOMIC)) {
+ dev_kfree_skb(skb);
+ return 0;
+ }
+ }
+
control.ifindex = odev-ifindex;
control.type = osdata-type;
if (pkt_data-req_tx_status)
@@ -1680,6 +1693,14 @@
return 0;
}
+ if (skb_headroom(skb) sdata-local-hw.extra_tx_headroom) {
+ if (pskb_expand_head(skb,
+ sdata-local-hw.extra_tx_headroom, 0, GFP_ATOMIC)) {
+ dev_kfree_skb(skb);
+ return 0;
+ }
+ }
+
hdr = (struct ieee80211_hdr *) skb-data;
fc = le16_to_cpu(hdr-frame_control);
@@ -1813,10 +1834,12 @@
bh_len = ap-beacon_head_len;
bt_len = ap-beacon_tail_len;
- skb = dev_alloc_skb(bh_len + bt_len + 256 /* maximum TIM len */);
+ skb = dev_alloc_skb(local-hw.extra_tx_headroom +
+ bh_len + bt_len + 256 /* maximum TIM len */);
if (!skb)
return NULL;
+ skb_reserve(skb, local-hw.extra_tx_headroom);
memcpy(skb_put(skb, bh_len), b_head, bh_len);
if (hw-flags IEEE80211_HW_SOFTWARE_SEQUENCE)
diff -rU3 dscape/net/d80211/ieee80211_i.h dscape.hdr/net/d80211/ieee80211_i.h
--- dscape/net/d80211/ieee80211_i.h 2007-02-05 16:20:01.0 +0100
+++ dscape.hdr/net/d80211/ieee80211_i.h 2007-02-05 16:24:19.0 +0100
@@ -49,6 +49,9 @@
* frame can be up to about 2 kB long. */
#define TOTAL_MAX_TX_BUFFER 512
+/* Required encryption head and tailroom */
+#define IEEE80211_ENCRYPT_HEADROOM 8
+#define IEEE80211_ENCRYPT_TAILROOM 12
/* IEEE 802.11 (Ch. 9.5 Defragmentation) requires support for concurrent
* reception of at least three fragmented frames. This limit can be increased
diff -rU3 dscape/net/d80211/ieee80211_scan.c
dscape.hdr/net/d80211/ieee80211_scan.c
--- dscape/net/d80211/ieee80211_scan.c 2007-02-05 16:18:41.0 +0100
+++ dscape.hdr/net/d80211/ieee80211_scan.c 2007-02-05 16:24:49.0
+0100
@@ -280,7 +280,7 @@
{
struct ieee80211_hdr hdr;
u16 fc;
- int len = 10;
+ int len = 10 + local-hw.extra_tx_headroom;
struct rate_control_extra extra;
/* Only initialize passive scanning if the hardware supports it */
@@ -309,6 +309,7 @@
passive scan\n, local-mdev-name
Re: [PATCH 1/2] d80211: Add software RTS support
On Monday 05 February 2007 18:28, Jiri Benc wrote: On Wed, 31 Jan 2007 20:16:50 +0100, Ivo van Doorn wrote: Not all hardware are capable of generating their own RTS frames. This patch will add support for creating the RTS frame in software, when the driver requests this through the flag IEEE80211_HW_SOFTWARE_RTS It seems this is not the ideal solution. Most of drivers needing software RTS would need to remember the RTS frame somewhere (as they need to pass it together with the actual frame). Well in case of rt2x00 (I am not sure which other drivers also need software RTS) the rts packet is just inserted inside the packet ring and is treated as a regular packet/fragment that has just been inserted by the driver. This patch just adds this additional packet just before the real packet, and in case the real packet could not be send the rts packet is stored in the ieee80211_tx_stored_packet structure to be send later. A better solution would be either to pass a pointer to RTS frame data in tx_control or to create a function returning RTS frame. In case of rt2x00 this would deliver more problems, especially since it will use a ring entry to send the rts frame and in case of rt2500usb and rt73usb it will need a sk_buff structure since it needs to pass it to the device (where the sk_buff will have some free tx_header_room for the descriptor.) Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] d80211: Add software sequence support
On Monday 05 February 2007 18:37, Jiri Benc wrote: On Sat, 3 Feb 2007 12:45:26 +0100, Ivo van Doorn wrote: --- dscape/net/d80211/ieee80211_i.h 2007-01-31 19:41:53.0 +0100 +++ dscape_seq/net/d80211/ieee80211_i.h 2007-01-31 20:06:26.0 +0100 @@ -405,6 +405,7 @@ int *supp_rates[NUM_IEEE80211_MODES]; int *basic_rates[NUM_IEEE80211_MODES]; + u16 seq_counter; Shouldn't this be per-BSS? Ok I'll try to get a per-BSS sequence counter working, I'll need some time to figure out how the per-BSS code is working. Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] d80211: Add software RTS support
Hi, Not all hardware are capable of generating their own RTS frames. This patch will add support for creating the RTS frame in software, when the driver requests this through the flag IEEE80211_HW_SOFTWARE_RTS It seems this is not the ideal solution. Most of drivers needing software RTS would need to remember the RTS frame somewhere (as they need to pass it together with the actual frame). Well in case of rt2x00 (I am not sure which other drivers also need software RTS) the rts packet is just inserted inside the packet ring and is treated as a regular packet/fragment that has just been inserted by the driver. This patch just adds this additional packet just before the real packet, and in case the real packet could not be send the rts packet is stored in the ieee80211_tx_stored_packet structure to be send later. Ok, I see. But this is not going to work with bcm43xx. I also sent a fix for rt2x00 to work with my patchset. Did you already send that patchset to the netdev list? Because I haven't seen a patch series about rts for d80211 yet. A better solution would be either to pass a pointer to RTS frame data in tx_control or to create a function returning RTS frame. In case of rt2x00 this would deliver more problems, especially since it will use a ring entry to send the rts frame and in case of rt2500usb and rt73usb it will need a sk_buff structure since it needs to pass it to the device (where the sk_buff will have some free tx_header_room for the descriptor.) I don't understand this. You need to put in into the ring either way. The new rt2500usb and rt73usb packet ring handling no longer use a DMA buffer but instead send the sk_buffer-data pointer to the USB layer. The solution as suggested by Jiri could be handled by making sure the rts allocated buffer will also have a tx header room as set in the tx_header_room field. But I am not sure if that would be a better solution than putting the rts packet in a sk_buffer that is being send out just before the real packet... For the timing problem you mentioned, another solution could be implemented, like already mentioned on the d80211 TODO list, the dscape stack should be able to send a signal to the driver that the last fragment was handed over, this signal can be used by the driver to start sending out the queued packets. This would at least work for rt2x00 where especially for PCI devices _no_ packets are being send until the TX ring has been kicked. Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] d80211: Add software RTS support
On Monday 05 February 2007 19:08, Jiri Benc wrote: On Mon, 5 Feb 2007 18:43:06 +0100, Michael Buesch wrote: I also think that sending RTS in software is not going to work, as the timing can not be guaranteed. And timing is why we do it in the first place. If the HW is not capable of sending RTS frames, we should not try to emulate them in SW, as it might make the situation even worse by messing up the NAVs by wrong timing. That's not emulation in the software, it's just similar approach as with sending fragmented frames - you need (more or less) precise timing there as well and many cards still want them enqueued one-by-one. The firmware takes care of the precise timing. The same could apply to RTS frames (i. e. the firmware recognize them and doesn't send them before it has the next frame ready). And even for a dumb device like rt2x00 (no firmware for rt2400pci, rt2500pci or rt2500usb) it still has rts capabilities. It is just not capable of creating the frame, but the descriptor has a special field that should be set in case of a rts frame. So that would suggest that the device will treat the frame a little bit different than a regular frame. Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] d80211: Add software RTS support
Hi, Did you already send that patchset to the netdev list? Because I haven't seen a patch series about rts for d80211 yet. No, [EMAIL PROTECTED] Hmm, wasn't subscribed to that list yet. :( But now I am. :) The new rt2500usb and rt73usb packet ring handling no longer use a DMA buffer but instead send the sk_buffer-data pointer to the USB layer. The solution as suggested by Jiri could be handled by making sure the rts allocated buffer will also have a tx header room as set in the tx_header_room field. But I am not sure if that would be a better solution than putting the rts packet in a sk_buffer that is being send out just before the real packet... In my patchset you can put it into anything you like. I put it into an skb. Sounds good, I'll look that patchset up in the mailarchive. Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] d80211: respect extra_tx_headroom
On Monday 05 February 2007 22:37, Jiri Benc wrote:
On Mon, 5 Feb 2007 16:32:24 +0100, Ivo van Doorn wrote:
When a driver requested additional header room
through the extra_tx_headroom field, the stack
should respect that and make sure that all frames
that are being send to the stack actually have
that extra header room.
[...]
--- dscape/net/d80211/ieee80211_sta.c 2007-02-05 16:18:41.0
+0100
[...]
@@ -2007,6 +2017,8 @@
if (!skb)
break;
+ skb_reserve(skb, local-hw.extra_tx_headroom);
+
mgmt = (struct ieee80211_mgmt *)
skb_put(skb, 24 + sizeof(mgmt-u.beacon));
memset(mgmt, 0, 24 + sizeof(mgmt-u.beacon));
Please enlarge that dev_alloc_skb(400) few lines above by
extra_tx_headroom as well.
Ok.
Btw, it would be nice if you could use -p option for diff as it makes
reviewing easier for me.
Not a problem, I'll try to remember it for future patches.
Here is the updated patch.
When a driver requested additional header room
through the extra_tx_headroom field, the stack
should respect that and make sure that all frames
that are being send to the stack actually have
that extra header room.
Besides the additional bytes for the beacon template, this patch
is no longer depends on the rts patch to be applied.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rpU3 dscape.control/net/d80211/ieee80211.c
dscape.skb/net/d80211/ieee80211.c
--- dscape.control/net/d80211/ieee80211.c 2007-02-06 00:25:26.0
+0100
+++ dscape.skb/net/d80211/ieee80211.c 2007-02-06 00:39:07.0 +0100
@@ -470,10 +470,9 @@ ieee80211_tx_h_fragment(struct ieee80211
/* reserve enough extra head and tail room for possible
* encryption */
-#define IEEE80211_ENCRYPT_HEADROOM 8
-#define IEEE80211_ENCRYPT_TAILROOM 12
frag = frags[i] =
- dev_alloc_skb(frag_threshold +
+ dev_alloc_skb(tx-local-hw.extra_tx_headroom +
+ frag_threshold +
IEEE80211_ENCRYPT_HEADROOM +
IEEE80211_ENCRYPT_TAILROOM);
if (!frag)
@@ -481,7 +480,8 @@ ieee80211_tx_h_fragment(struct ieee80211
/* Make sure that all fragments use the same priority so
* that they end up using the same TX queue */
frag-priority = first-priority;
- skb_reserve(frag, IEEE80211_ENCRYPT_HEADROOM);
+ skb_reserve(frag, tx-local-hw.extra_tx_headroom +
+ IEEE80211_ENCRYPT_HEADROOM);
fhdr = (struct ieee80211_hdr *) skb_put(frag, hdrlen);
memcpy(fhdr, first-data, hdrlen);
if (i == num_fragm - 2)
@@ -1362,6 +1362,7 @@ static int ieee80211_master_start_xmit(s
struct ieee80211_tx_packet_data *pkt_data;
struct net_device *odev = NULL;
struct ieee80211_sub_if_data *osdata;
+ int headroom;
int ret;
/*
@@ -1386,6 +1387,15 @@ static int ieee80211_master_start_xmit(s
}
osdata = IEEE80211_DEV_TO_SUB_IF(odev);
+ headroom = osdata-local-hw.extra_tx_headroom +
+ IEEE80211_ENCRYPT_HEADROOM;
+ if (skb_headroom(skb) headroom) {
+ if (pskb_expand_head(skb, headroom, 0, GFP_ATOMIC)) {
+ dev_kfree_skb(skb);
+ return 0;
+ }
+ }
+
control.ifindex = odev-ifindex;
control.type = osdata-type;
if (pkt_data-req_tx_status)
@@ -1615,6 +1625,14 @@ ieee80211_mgmt_start_xmit(struct sk_buff
return 0;
}
+ if (skb_headroom(skb) sdata-local-hw.extra_tx_headroom) {
+ if (pskb_expand_head(skb,
+ sdata-local-hw.extra_tx_headroom, 0, GFP_ATOMIC)) {
+ dev_kfree_skb(skb);
+ return 0;
+ }
+ }
+
hdr = (struct ieee80211_hdr *) skb-data;
fc = le16_to_cpu(hdr-frame_control);
@@ -1748,10 +1766,12 @@ struct sk_buff * ieee80211_beacon_get(st
bh_len = ap-beacon_head_len;
bt_len = ap-beacon_tail_len;
- skb = dev_alloc_skb(bh_len + bt_len + 256 /* maximum TIM len */);
+ skb = dev_alloc_skb(local-hw.extra_tx_headroom +
+ bh_len + bt_len + 256 /* maximum TIM len */);
if (!skb)
return NULL;
+ skb_reserve(skb, local-hw.extra_tx_headroom);
memcpy(skb_put(skb, bh_len), b_head, bh_len);
ieee80211_beacon_add_tim(local, ap, skb);
diff -rpU3 dscape.control/net/d80211/ieee80211_i.h
dscape.skb/net/d80211/ieee80211_i.h
--- dscape.control/net/d80211/ieee80211_i.h 2007-02-06 00:19:38.0
+0100
+++ dscape.skb/net/d80211/ieee80211_i.h 2007-02-06 00:39:28.0 +0100
@@ -49,6 +49,9 @@ struct
Re: [PATCH 2/2] d80211: Add software sequence support
On Wednesday 31 January 2007 20:16, Ivo van Doorn wrote:
Most hardware can keep track of sequence numbers themselves,
unfortunately *most* doesn't cover all devices. ;)
This patch will keep track of the sequence number if the flag
IEEE80211_HW_SOFTWARE_SEQUENCE has been set.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
Previous version had a small bug in it.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rNU3 dscape/include/net/d80211.h dscape_seq/include/net/d80211.h
--- dscape/include/net/d80211.h 2007-01-31 19:38:14.0 +0100
+++ dscape_seq/include/net/d80211.h 2007-01-31 19:55:55.0 +0100
@@ -534,6 +534,9 @@
/* Does the device need the stack to create a RTS frame */
#define IEEE80211_HW_SOFTWARE_RTS (115)
+ /* Does the HOST need to insert the frame sequence counter */
+#define IEEE80211_HW_SOFTWARE_SEQUENCE (116)
+
u32 flags; /* hardware flags defined above */
/* Set to the size of a needed device specific skb headroom for TX
skbs. */
diff -rNU3 dscape/net/d80211/ieee80211.c dscape_seq/net/d80211/ieee80211.c
--- dscape/net/d80211/ieee80211.c 2007-01-31 19:41:18.0 +0100
+++ dscape_seq/net/d80211/ieee80211.c 2007-02-03 12:42:25.0 +0100
@@ -441,6 +441,7 @@
size_t hdrlen, per_fragm, num_fragm, payload_len, left;
struct sk_buff **frags, *first, *frag;
int i;
+ u16 seq;
u8 *pos;
int frag_threshold = tx-local-fragmentation_threshold;
@@ -458,6 +459,7 @@
if (!frags)
goto fail;
+ seq = le16_to_cpu(hdr-seq_ctrl) IEEE80211_SCTL_SEQ;
hdr-frame_control |= cpu_to_le16(IEEE80211_FCTL_MOREFRAGS);
pos = first-data + hdrlen + per_fragm;
left = payload_len - per_fragm;
@@ -486,7 +488,7 @@
memcpy(fhdr, first-data, hdrlen);
if (i == num_fragm - 2)
fhdr-frame_control =
cpu_to_le16(~IEEE80211_FCTL_MOREFRAGS);
- fhdr-seq_ctrl = cpu_to_le16(i + 1);
+ fhdr-seq_ctrl = cpu_to_le16(seq + ((i + 1)
IEEE80211_SCTL_FRAG));
copylen = left per_fragm ? per_fragm : left;
memcpy(skb_put(frag, copylen), pos, copylen);
@@ -933,6 +935,17 @@
return TXRX_CONTINUE;
}
+static ieee80211_txrx_result
+ieee80211_tx_h_sequence(struct ieee80211_txrx_data *tx)
+{
+ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx-skb-data;
+
+ if ((tx-local-hw.flags IEEE80211_HW_SOFTWARE_SEQUENCE)
+ ieee80211_get_hdrlen(le16_to_cpu(hdr-frame_control)) 24)
+ ieee80211_include_sequence(tx-local, hdr);
+
+ return TXRX_CONTINUE;
+}
/* This function is called whenever the AP is about to exceed the maximum limit
* of buffered frames for power saving STAs. This situation should not really
@@ -1806,6 +1819,10 @@
memcpy(skb_put(skb, bh_len), b_head, bh_len);
+ if (hw-flags IEEE80211_HW_SOFTWARE_SEQUENCE)
+ ieee80211_include_sequence(local,
+ (struct ieee80211_hdr *)skb-data);
+
ieee80211_beacon_add_tim(local, ap, skb);
if (b_tail) {
@@ -4323,6 +4340,7 @@
static ieee80211_tx_handler ieee80211_tx_handlers[] =
{
ieee80211_tx_h_check_assoc,
+ ieee80211_tx_h_sequence,
ieee80211_tx_h_ps_buf,
ieee80211_tx_h_select_key,
ieee80211_tx_h_michael_mic_add,
@@ -4497,6 +4515,7 @@
local-bridge_packets = 1;
+ local-seq_counter = 0;
local-rts_threshold = IEEE80211_MAX_RTS_THRESHOLD;
local-fragmentation_threshold = IEEE80211_MAX_FRAG_THRESHOLD;
local-short_retry_limit = 7;
diff -rNU3 dscape/net/d80211/ieee80211_i.h dscape_seq/net/d80211/ieee80211_i.h
--- dscape/net/d80211/ieee80211_i.h 2007-01-31 19:41:53.0 +0100
+++ dscape_seq/net/d80211/ieee80211_i.h 2007-01-31 20:06:26.0 +0100
@@ -405,6 +405,7 @@
int *supp_rates[NUM_IEEE80211_MODES];
int *basic_rates[NUM_IEEE80211_MODES];
+ u16 seq_counter;
int rts_threshold;
int cts_protect_erp_frames;
int fragmentation_threshold;
@@ -601,6 +602,20 @@
spin_unlock_bh(local-sta_lock);
}
+static inline void ieee80211_include_sequence(struct ieee80211_local *local,
+ struct ieee80211_hdr *hdr)
+{
+ /*
+* Set the sequence number for this frame.
+*/
+ hdr-seq_ctrl = cpu_to_le16(local-seq_counter IEEE80211_SCTL_SEQ);
+
+ /*
+* Increase the sequence number.
+*/
+ local-seq_counter = (local-seq_counter + 0x10) IEEE80211_SCTL_SEQ;
+}
+
/* ieee80211.c */
void ieee80211_release_hw(struct ieee80211_local *local);
int ieee80211_hw_config(struct ieee80211_local *local);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
[PATCH] eeprom_93cx6 little endian fix
This patch makes sure the multiread/multiwrite
functions for eeprom_93cx6 work with little endian
data. The singleread still works with host endian.
Most drivers still want the multiread to work with little
endian because this is used for data like the MAC address.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff --git a/include/linux/eeprom_93cx6.h b/include/linux/eeprom_93cx6.h
index 6cbf7c7..4b9be59 100644
--- a/include/linux/eeprom_93cx6.h
+++ b/include/linux/eeprom_93cx6.h
@@ -67,11 +67,11 @@ struct eeprom_93cx6 {
};
extern void eeprom_93cx6_read(struct eeprom_93cx6 *eeprom,
- const u8 word, __le16 *data);
+ const u8 word, u16 *data);
extern void eeprom_93cx6_multiread(struct eeprom_93cx6 *eeprom,
const u8 word, __le16 *data, const u16 words);
extern void eeprom_93cx6_write(struct eeprom_93cx6 *eeprom,
- const u8 word, __le16 *data);
+ const u8 word, u16 data);
extern void eeprom_93cx6_multiwrite(struct eeprom_93cx6 *eeprom,
const u8 word, __le16 *data, const u16 words);
diff --git a/lib/eeprom_93cx6.c b/lib/eeprom_93cx6.c
index 122767e..e5d016b 100644
--- a/lib/eeprom_93cx6.c
+++ b/lib/eeprom_93cx6.c
@@ -203,14 +203,13 @@ static void eeprom_93cx6_ewds(struct eeprom_93cx6 *eeprom)
* @word: Word index from where we should start reading
* @data: target pointer where the information will have to be stored
*
- * This function will read the eeprom data as little endian word
+ * This function will read the eeprom data as host-endian word
* into the given data pointer.
*/
void eeprom_93cx6_read(struct eeprom_93cx6 *eeprom, const u8 word,
- __le16 *data)
+ u16 *data)
{
u16 command;
- u16 buffer = 0;
/*
* Initialize the eeprom register
@@ -227,19 +226,12 @@ void eeprom_93cx6_read(struct eeprom_93cx6 *eeprom, const
u8 word,
/*
* Read the requested 16 bits.
*/
- eeprom_93cx6_read_bits(eeprom, buffer, 16);
+ eeprom_93cx6_read_bits(eeprom, data, 16);
/*
* Cleanup eeprom register.
*/
eeprom_93cx6_cleanup(eeprom);
-
- /*
-* The data from the eeprom is stored as little endian,
-* so we don't need to byteorder. To prevent sparse from
-* complaining we need to force the type to __le16.
-*/
- *data = (__force __le16)buffer;
}
EXPORT_SYMBOL_GPL(eeprom_93cx6_read);
@@ -252,14 +244,21 @@ EXPORT_SYMBOL_GPL(eeprom_93cx6_read);
*
* This function will read all requested words from the eeprom,
* this is done by calling eeprom_93cx6_read() multiple times.
+ * But with the additional change that while the eeprom_93cx6_read
+ * will return host ordered bytes, this method will return little
+ * endian words.
*/
void eeprom_93cx6_multiread(struct eeprom_93cx6 *eeprom, const u8 word,
__le16 *data, const u16 words)
{
unsigned int i;
+ u16 tmp;
- for (i = 0; i words; i++)
- eeprom_93cx6_read(eeprom, word + i, data++);
+ for (i = 0; i words; i++) {
+ tmp = 0;
+ eeprom_93cx6_read(eeprom, word + i, tmp);
+ data[i] = cpu_to_le16(tmp);
+ }
}
EXPORT_SYMBOL_GPL(eeprom_93cx6_multiread);
@@ -267,13 +266,13 @@ EXPORT_SYMBOL_GPL(eeprom_93cx6_multiread);
* eeprom_93cx6_write - Write multiple words to the eeprom
* @eeprom: Pointer to eeprom structure
* @word: Word index from where we should start writing
- * @data: Pointer where the information will be read from
+ * @data: Data that will be written
*
- * This function will write the eeprom data as little endian word
+ * This function will write the eeprom data as host-endian word
* from the given data pointer.
*/
void eeprom_93cx6_write(struct eeprom_93cx6 *eeprom, const u8 word,
- __le16 *data)
+ u16 data)
{
u16 command;
@@ -297,7 +296,7 @@ void eeprom_93cx6_write(struct eeprom_93cx6 *eeprom, const
u8 word,
/*
* Write the requested 16 bits.
*/
- eeprom_93cx6_write_bits(eeprom, (__force u16)*data, 16);
+ eeprom_93cx6_write_bits(eeprom, data, 16);
/*
* Cleanup eeprom register.
@@ -331,6 +330,8 @@ EXPORT_SYMBOL_GPL(eeprom_93cx6_write);
*
* This function will write all requested words to the eeprom,
* this is done by calling eeprom_93cx6_write() multiple times.
+ * This method accepts little endian data, so it will first be
+ * converted into host endian.
*/
void eeprom_93cx6_multiwrite(struct eeprom_93cx6 *eeprom, const u8 word,
__le16 *data, const u16 words)
@@ -338,6 +339,6 @@ void eeprom_93cx6_multiwrite(struct eeprom_93cx6 *eeprom,
const u8 word,
unsigned int i;
for (i = 0; i words; i++)
- eeprom_93cx6_write(eeprom, word + i, data++);
+ eeprom_93cx6_write(eeprom, word + i, le16_to_cpu(data[i]));
}
EXPORT_SYMBOL_GPL(eeprom_93cx6_multiwrite);
-
To unsubscribe from this list: send the line
[PATCH 1/3] d80211: Add control structure for beacontemplates
When rt2500usb and rt73usb will start using beacontemplates,
they would also need a control structure to be passed along to
correctly set the tx parameters.
This patch will add the allocation an initialization of a
ieee80211_tx_control especially for the beacontemplate.
This does require drivers that have the BEACON_TEMPLATE flag
set to also free the control structure. (bcm43xx and p54 will be
fixed in the next 2 patches)
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff --git a/include/net/d80211.h b/include/net/d80211.h
index 65a5d36..b1b40f0 100644
--- a/include/net/d80211.h
+++ b/include/net/d80211.h
@@ -374,6 +374,9 @@ struct ieee80211_if_init_conf {
* @beacon: beacon template. Valid only if @host_gen_beacon_template in
* struct ieee80211_hw is set. The driver is responsible of freeing
* the sk_buff.
+ * @beacon_control: tx_control for the beacon template, this field is only
+ * valid when the @beacon field was set. The driver is responsible of
+ * freeing the buffer.
*
* This structure is passed to the config_interface() callback of
* struct ieee80211_hw.
@@ -386,6 +389,7 @@ struct ieee80211_if_conf {
u8 *generic_elem;
size_t generic_elem_len;
struct sk_buff *beacon;
+ struct ieee80211_tx_control *beacon_control;
};
typedef enum { ALG_NONE, ALG_WEP, ALG_TKIP, ALG_CCMP, ALG_NULL }
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index 7353ed3..3e79f0c 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -1857,7 +1857,8 @@ ieee80211_get_buffered_bc(struct ieee80211_hw *hw, int
if_id,
EXPORT_SYMBOL(ieee80211_get_buffered_bc);
static int __ieee80211_if_config(struct net_device *dev,
-struct sk_buff *beacon)
+struct sk_buff *beacon,
+struct ieee80211_tx_control *control)
{
struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
struct ieee80211_local *local = dev-ieee80211_ptr;
@@ -1881,6 +1882,7 @@ static int __ieee80211_if_config(struct net_device *dev,
conf.generic_elem = sdata-u.ap.generic_elem;
conf.generic_elem_len = sdata-u.ap.generic_elem_len;
conf.beacon = beacon;
+ conf.beacon_control = control;
}
return local-ops-config_interface(local_to_hw(local),
dev-ifindex, conf);
@@ -1888,20 +1890,27 @@ static int __ieee80211_if_config(struct net_device *dev,
int ieee80211_if_config(struct net_device *dev)
{
- return __ieee80211_if_config(dev, NULL);
+ return __ieee80211_if_config(dev, NULL, NULL);
}
int ieee80211_if_config_beacon(struct net_device *dev)
{
struct ieee80211_local *local = dev-ieee80211_ptr;
+ struct ieee80211_tx_control *control;
struct sk_buff *skb;
if (!(local-hw.flags IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE))
return 0;
- skb = ieee80211_beacon_get(local_to_hw(local), dev-ifindex, NULL);
+
+ control = kzalloc(sizeof(struct ieee80211_tx_control), GFP_KERNEL);
+ if (!control)
+ return -ENOMEM;
+
+ skb = ieee80211_beacon_get(local_to_hw(local), dev-ifindex, control);
if (!skb)
return -ENOMEM;
- return __ieee80211_if_config(dev, skb);
+
+ return __ieee80211_if_config(dev, skb, control);
}
int ieee80211_hw_config(struct ieee80211_local *local)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] d80211-bcm43xx: Add control structure for beacontemplates
Drivers that require beacon templates will also have the
control structure at their disposal and should always free it.
bcm43xx doesn't use the control structure, but should still free it.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
index 9f4d51d..24be8f5 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
@@ -2732,8 +2732,10 @@ static int bcm43xx_config_interface(struct ieee80211_hw
*hw,
if (bcm43xx_is_mode(wl, IEEE80211_IF_TYPE_AP)) {
assert(conf-type == IEEE80211_IF_TYPE_AP);
bcm43xx_set_ssid(dev, conf-ssid, conf-ssid_len);
- if (conf-beacon)
+ if (conf-beacon) {
bcm43xx_refresh_templates(dev, conf-beacon);
+ kfree(conf-beacon_control);
+ }
}
}
spin_unlock_irqrestore(wl-irq_lock, flags);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] d80211-p54: Add control structure for beacontemplates
Drivers that require beacon templates will also have the control structure at their disposal and should always free it. p54 seems to ignore the beacon that is being passed, even though it is requesting the BEACON_TEMPLATE. That is why I not only added a line to free the control structure but also the beacon itself. Signed-off-by Ivo van Doorn [EMAIL PROTECTED] --- diff --git a/drivers/net/wireless/d80211/p54/prism54common.c b/drivers/net/wireless/d80211/p54/prism54common.c index fd4ea5d..5a00d65 100644 --- a/drivers/net/wireless/d80211/p54/prism54common.c +++ b/drivers/net/wireless/d80211/p54/prism54common.c @@ -714,6 +714,8 @@ static int p54_config_interface(struct ieee80211_hw *dev, int if_id, p54_set_filter(dev, 0, dev-perm_addr, conf-bssid, 0, 1, 0, 0xF642); p54_set_filter(dev, 0, dev-perm_addr, conf-bssid, 2, 0, 0, 0); p54_set_leds(dev, 1, !is_multicast_ether_addr(conf-bssid), 0); + dev_kfree_skb(conf-beacon); + kfree(conf-beacon_control); return 0; } - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] d80211-p54: Add control structure for beacontemplates
On Saturday 03 February 2007 17:33, Michael Wu wrote: On Saturday 03 February 2007 11:25, Ivo van Doorn wrote: p54 seems to ignore the beacon that is being passed, even though it is requesting the BEACON_TEMPLATE. That is why I not only added a line to free the control structure but also the beacon itself. Yeah, beacons aren't actually handled yet. BEACON_TEMPLATE can just be turned off for now if it's causing problems, though I don't see a reason why a beacon would be generated for managed mode. It would only be generated for AP mode. In any case, the new patch: Signed-off-by Ivo van Doorn [EMAIL PROTECTED] --- diff --git a/drivers/net/wireless/d80211/p54/prism54common.c b/drivers/net/wireless/d80211/p54/prism54common.c index fd4ea5d..8335f99 100644 --- a/drivers/net/wireless/d80211/p54/prism54common.c +++ b/drivers/net/wireless/d80211/p54/prism54common.c @@ -766,8 +766,7 @@ struct ieee80211_hw *p54_init_common(size_t priv_data_len) priv-modes[0].rates = priv-rates; priv-modes[0].num_channels = ARRAY_SIZE(p54_channels); priv-modes[0].channels = priv-channels; - dev-flags = IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE | - IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING | /* not sure */ + dev-flags = IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING | /* not sure */ IEEE80211_HW_RX_INCLUDES_FCS | IEEE80211_HW_WEP_INCLUDE_IV | IEEE80211_HW_DATA_NULLFUNC_ACK; /* TODO: check */ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] d80211: Add software RTS support
Not all hardware are capable of generating their own RTS frames.
This patch will add support for creating the RTS frame in software,
when the driver requests this through the flag
IEEE80211_HW_SOFTWARE_RTS
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff --git a/include/net/d80211.h b/include/net/d80211.h
index 65a5d36..17e0530 100644
--- a/include/net/d80211.h
+++ b/include/net/d80211.h
@@ -531,6 +531,9 @@ struct ieee80211_hw {
* per-packet RC4 key with each TX frame when doing hwcrypto */
#define IEEE80211_HW_TKIP_REQ_PHASE2_KEY (114)
+ /* Does the device need the stack to create a RTS frame */
+#define IEEE80211_HW_SOFTWARE_RTS (115)
+
u32 flags; /* hardware flags defined above */
/* Set to the size of a needed device specific skb headroom for TX
skbs. */
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index 7353ed3..43d91bf 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -760,8 +760,7 @@ ieee80211_tx_h_misc(struct ieee80211_txrx_data *tx)
struct ieee80211_tx_control *control = tx-u.tx.control;
if (!is_multicast_ether_addr(hdr-addr1)) {
- if (tx-skb-len + FCS_LEN tx-local-rts_threshold
- tx-local-rts_threshold IEEE80211_MAX_RTS_THRESHOLD) {
+ if (tx-u.tx.rts_required) {
control-flags |= IEEE80211_TXCTL_USE_RTS_CTS;
control-retry_limit =
tx-local-long_retry_limit;
@@ -843,6 +842,35 @@ ieee80211_tx_h_misc(struct ieee80211_txrx_data *tx)
return TXRX_CONTINUE;
}
+static ieee80211_txrx_result
+ieee80211_tx_h_rts(struct ieee80211_txrx_data *tx)
+{
+ struct ieee80211_tx_control *control = tx-u.tx.control;
+ struct ieee80211_hdr *old_hdr = (struct ieee80211_hdr *) tx-skb-data;
+ struct ieee80211_hdr *new_hdr;
+ int hdr_len;
+
+ if (!tx-u.tx.rts_required ||
+ !(tx-local-hw.flags IEEE80211_HW_SOFTWARE_RTS))
+ return TXRX_CONTINUE;
+
+ hdr_len = ieee80211_get_hdrlen(old_hdr-frame_control);
+
+ tx-u.tx.rts_frame = dev_alloc_skb(hdr_len);
+ if (!tx-u.tx.rts_frame)
+ return TXRX_DROP;
+
+ new_hdr = (struct ieee80211_hdr*)skb_put(tx-u.tx.rts_frame, hdr_len);
+
+ memcpy(new_hdr, old_hdr, hdr_len);
+
+ new_hdr-frame_control = cpu_to_le16(
+ IEEE80211_FTYPE_CTL | IEEE80211_STYPE_RTS);
+ new_hdr-duration_id = cpu_to_le16(control-rts_cts_duration);
+ new_hdr-seq_ctrl = 0;
+
+ return TXRX_CONTINUE;
+}
static ieee80211_txrx_result
ieee80211_tx_h_check_assoc(struct ieee80211_txrx_data *tx)
@@ -1072,8 +1100,12 @@ __ieee80211_tx_prepare(struct ieee80211_txrx_data *tx,
tx-u.tx.unicast = !is_multicast_ether_addr(hdr-addr1);
if (is_multicast_ether_addr(hdr-addr1))
control-flags |= IEEE80211_TXCTL_NO_ACK;
- else
+ else {
control-flags = ~IEEE80211_TXCTL_NO_ACK;
+ if (tx-skb-len + FCS_LEN tx-local-rts_threshold
+ tx-local-rts_threshold IEEE80211_MAX_RTS_THRESHOLD)
+ tx-u.tx.rts_required = 1;
+ }
tx-fragmented = local-fragmentation_threshold
IEEE80211_MAX_FRAG_THRESHOLD tx-u.tx.unicast
skb-len + FCS_LEN local-fragmentation_threshold
@@ -1149,7 +1181,21 @@ static int __ieee80211_tx(struct ieee80211_local *local,
struct sk_buff *skb,
struct ieee80211_tx_control *control = tx-u.tx.control;
int ret, i;
+ if (tx-u.tx.rts_frame) {
+ ieee80211_dump_frame(local-mdev-name,
+RTS to low-level driver,
+tx-u.tx.rts_frame);
+ ret = local-ops-tx(local_to_hw(local), tx-u.tx.rts_frame,
control);
+ if (ret)
+ return IEEE80211_TX_AGAIN;
+ ieee80211_led_tx(local, 1);
+
+ control-flags = ~IEEE80211_TXCTL_USE_RTS_CTS;
+ tx-u.tx.rts_frame = NULL;
+ }
if (skb) {
+ if (__ieee80211_queue_stopped(local, control-queue))
+ return IEEE80211_TX_FRAG_AGAIN;
ieee80211_dump_frame(local-mdev-name, TX to low-level
driver, skb);
ret = local-ops-tx(local_to_hw(local), skb, control);
if (ret)
@@ -1287,6 +1333,7 @@ retry:
store-last_frag_hwrate = tx.u.tx.last_frag_hwrate;
store-last_frag_rateidx = tx.u.tx.last_frag_rateidx;
store-last_frag_rate_ctrl_probe = tx.u.tx.probe_last_frag;
+ store-rts_frame = tx.u.tx.rts_frame;
}
return 0;
@@ -1296,7 +1343,9 @@ retry:
for (i = 0; i tx.u.tx.num_extra_frag; i++)
if (tx.u.tx.extra_frag[i])
dev_kfree_skb(tx.u.tx.extra_frag[i]);
-kfree
[PATCH 2/2] d80211: Add software sequence support
Most hardware can keep track of sequence numbers themselves,
unfortunately *most* doesn't cover all devices. ;)
This patch will keep track of the sequence number if the flag
IEEE80211_HW_SOFTWARE_SEQUENCE has been set.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rNU3 dscape/include/net/d80211.h dscape_seq/include/net/d80211.h
--- dscape/include/net/d80211.h 2007-01-31 19:38:14.0 +0100
+++ dscape_seq/include/net/d80211.h 2007-01-31 19:55:55.0 +0100
@@ -534,6 +534,9 @@
/* Does the device need the stack to create a RTS frame */
#define IEEE80211_HW_SOFTWARE_RTS (115)
+ /* Does the HOST need to insert the frame sequence counter */
+#define IEEE80211_HW_SOFTWARE_SEQUENCE (116)
+
u32 flags; /* hardware flags defined above */
/* Set to the size of a needed device specific skb headroom for TX
skbs. */
diff -rNU3 dscape/net/d80211/ieee80211.c dscape_seq/net/d80211/ieee80211.c
--- dscape/net/d80211/ieee80211.c 2007-01-31 19:41:18.0 +0100
+++ dscape_seq/net/d80211/ieee80211.c 2007-01-31 20:04:36.0 +0100
@@ -441,6 +441,7 @@
size_t hdrlen, per_fragm, num_fragm, payload_len, left;
struct sk_buff **frags, *first, *frag;
int i;
+ u16 seq;
u8 *pos;
int frag_threshold = tx-local-fragmentation_threshold;
@@ -458,6 +459,7 @@
if (!frags)
goto fail;
+ seq = le16_to_cpu(hdr-seq_ctrl) IEEE80211_SCTL_SEQ;
hdr-frame_control |= cpu_to_le16(IEEE80211_FCTL_MOREFRAGS);
pos = first-data + hdrlen + per_fragm;
left = payload_len - per_fragm;
@@ -486,7 +488,7 @@
memcpy(fhdr, first-data, hdrlen);
if (i == num_fragm - 2)
fhdr-frame_control =
cpu_to_le16(~IEEE80211_FCTL_MOREFRAGS);
- fhdr-seq_ctrl = cpu_to_le16(i + 1);
+ fhdr-seq_ctrl = cpu_to_le16(seq + ((i + 1)
IEEE80211_SCTL_FRAG));
copylen = left per_fragm ? per_fragm : left;
memcpy(skb_put(frag, copylen), pos, copylen);
@@ -933,6 +935,19 @@
return TXRX_CONTINUE;
}
+static ieee80211_txrx_result
+ieee80211_tx_h_sequence(struct ieee80211_txrx_data *tx)
+{
+ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx-skb-data;
+
+ if (!(tx-local-hw.flags IEEE80211_HW_SOFTWARE_SEQUENCE) ||
+ ieee80211_get_hdrlen(le16_to_cpu(hdr-frame_control)) 24)
+ return TXRX_CONTINUE;
+
+ ieee80211_include_sequence(tx-local, hdr);
+
+ return TXRX_CONTINUE;
+}
/* This function is called whenever the AP is about to exceed the maximum limit
* of buffered frames for power saving STAs. This situation should not really
@@ -1806,6 +1821,10 @@
memcpy(skb_put(skb, bh_len), b_head, bh_len);
+ if (!(hw-flags IEEE80211_HW_SOFTWARE_SEQUENCE))
+ ieee80211_include_sequence(local,
+ (struct ieee80211_hdr *)skb-data);
+
ieee80211_beacon_add_tim(local, ap, skb);
if (b_tail) {
@@ -4323,6 +4342,7 @@
static ieee80211_tx_handler ieee80211_tx_handlers[] =
{
ieee80211_tx_h_check_assoc,
+ ieee80211_tx_h_sequence,
ieee80211_tx_h_ps_buf,
ieee80211_tx_h_select_key,
ieee80211_tx_h_michael_mic_add,
@@ -4497,6 +4517,7 @@
local-bridge_packets = 1;
+ local-seq_counter = 0;
local-rts_threshold = IEEE80211_MAX_RTS_THRESHOLD;
local-fragmentation_threshold = IEEE80211_MAX_FRAG_THRESHOLD;
local-short_retry_limit = 7;
diff -rNU3 dscape/net/d80211/ieee80211_i.h dscape_seq/net/d80211/ieee80211_i.h
--- dscape/net/d80211/ieee80211_i.h 2007-01-31 19:41:53.0 +0100
+++ dscape_seq/net/d80211/ieee80211_i.h 2007-01-31 20:06:26.0 +0100
@@ -405,6 +405,7 @@
int *supp_rates[NUM_IEEE80211_MODES];
int *basic_rates[NUM_IEEE80211_MODES];
+ u16 seq_counter;
int rts_threshold;
int cts_protect_erp_frames;
int fragmentation_threshold;
@@ -601,6 +602,20 @@
spin_unlock_bh(local-sta_lock);
}
+static inline void ieee80211_include_sequence(struct ieee80211_local *local,
+ struct ieee80211_hdr *hdr)
+{
+ /*
+* Set the sequence number for this frame.
+*/
+ hdr-seq_ctrl = cpu_to_le16(local-seq_counter IEEE80211_SCTL_SEQ);
+
+ /*
+* Increase the sequence number.
+*/
+ local-seq_counter = (local-seq_counter + 0x10) IEEE80211_SCTL_SEQ;
+}
+
/* ieee80211.c */
void ieee80211_release_hw(struct ieee80211_local *local);
int ieee80211_hw_config(struct ieee80211_local *local);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] rfkill - Add support for input key to control wireless radio
Hi, + /* +* Pointer to rfkill structure +* that was filled in by key driver. +*/ + struct rfkill *rfkill; Since rfkill is basically a function pointer table, can it be made const? Sounds good to me. + /* +* Once key status change has been detected, the toggled +* field should be set to indicate a notification to +* user or driver should be performed. +*/ + int toggled; + + /* +* Current state of the device radio, this state will +* change after the radio has actually been toggled since +* receiving the radio key event. +*/ + int radio_status; + + /* +* Current status of the key which controls the radio, +* this value will change after the key state has changed +* after polling, or the key driver has send the new state +* manually. +*/ + int key_status; Maybe turn these bits into a bit values (set_bit/clear_bit) in an unsigned long. Will do. + /* +* Input device for this key, +* we also keep track of the number of +* times this input device is open. This +* is important for determining to whom we +* should report key events. +*/ + struct input_dev *input; + unsigned int open_count; atomic on open_count? There seems to have gone something wrong with the patch, latest version should have had this field removed. + /* +* Name of this radio type. +*/ + char *name; const? Will do. + /* +* All access to the master structure +* and its children (the keys) are protected +* by this key lock. +*/ + struct semaphore key_sem; mutex instead of semaphort Strange, this should have already be fixed. :S + /* +* Work structures for periodic polling, +* as well as the scheduled radio toggling. +*/ + struct work_struct toggle_work; + struct work_struct poll_work; delayed_rearming_work instead? Same here, rfkill should already have the new workqueue api... I'll resubmit this within a few moments. Thanks Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] rfkill - Add support for input key to control wireless radio
Hope you will be resubmitting this.
And here is the new version,
I didn't make the name const as requested
that field is being passed to the class_device_create
method which requires a char* argument.
But I have made the flag field.
And now this time the patch actually includes the
changes I promised in last mail.
(mutex, workqueue api, etc)
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ba0e88c..6986d59 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,19 @@ config HP_SDC_RTC
Say Y here if you want to support the built-in real time clock
of the HP SDC controller.
+config RFKILL
+ tristate RF button support
+ help
+ If you say yes here, the rfkill driver will be build
+ which allowed network devices to register their hardware
+ RF button which controls the radio state. This driver
+ will then create an input device for it.
+
+ When the input device is not used, the rfkill driver
+ will make sure that when the RF button is pressed the radio
+ is enabled or disabled accordingly. When the input device
+ has been opened by the user this radio control will be left
+ to the user, and rfkill will only send the RF button status
+ change to userspace.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e788a1b 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o
+obj-$(CONFIG_RFKILL) += rfkill.o
diff --git a/drivers/input/misc/rfkill.c b/drivers/input/misc/rfkill.c
new file mode 100644
index 000..d8fda73
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,999 @@
+/*
+ Copyright (C) 2006 Ivo van Doorn
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/workqueue.h
+#include linux/list.h
+#include linux/mutex.h
+#include linux/input.h
+#include linux/rfkill.h
+
+MODULE_AUTHOR(Ivo van Doorn [EMAIL PROTECTED]);
+MODULE_VERSION(1.0);
+MODULE_DESCRIPTION(RF key support);
+MODULE_LICENSE(GPL);
+
+/*
+ * rfkill key structure.
+ */
+struct rfkill_key {
+ /*
+* For sysfs representation.
+*/
+ struct class_device *cdev;
+
+ /*
+* Pointer to rfkill structure
+* that was filled in by key driver.
+*/
+ const struct rfkill *rfkill;
+
+ /*
+* Pointer to type structure
+* that this key belongs to.
+*/
+ struct rfkill_type *type;
+
+ /*
+* Current status of the key which controls the radio,
+* this value will change after the key state has changed
+* after polling, or the key driver has send the new state
+* manually.
+*/
+#define RFKILL_KEY_RADIO_STATUS1
+
+ unsigned long flags;
+
+ /*
+* Input device for this key.
+*/
+ struct input_dev *input;
+
+ /*
+* List head structure to be used
+* to add this structure to the list.
+*/
+ struct list_head entry;
+};
+
+/*
+ * rfkill type structure.
+ */
+struct rfkill_type {
+ /*
+* For sysfs representation.
+*/
+ struct class_device *cdev;
+
+ /*
+* All access to the type structure and its
+* children (the keys) are protected by this mutex.
+*/
+ struct mutex mutex;
+
+ /*
+* Name of this radio type.
+*/
+ char *name;
+
+ /*
+* Key type identification. Value must be any
+* in the key_type enum.
+*/
+ unsigned int key_type;
+
+ /*
+* List of rfkill_key structures.
+*/
+ struct list_head key_list;
+
+ /*
+* Number of registered keys of this type.
+*/
+ unsigned int key_count;
+
+ /*
+* The claim the user has
Re: [RFC] rfkill - Add support for input key to control wireless radio
Well it's been a while, but here is an updated version of rfkill.
The changes since the version that was originally send are:
Spelling fixes (Thanks to Randy Dunlap)
THIS_MODULE is now a field in the rkfill_master (Suggested by Christoph Hellwig)
Move to the new Workqueue API
The open_count has been completely removed, decision making on which action
should
be taken is now handled by the user_claim field, which can be set through sysfs.
The possible choice include
1 - let rfkill handle everything without bothering the user
2 - let rfkill handle everything but send a notification to the user
3 - let rfkill send a notification only
The toggling of the keys is now type based, this means that if 1 key is being
toggled
all keys of the same type will be toggled.
As optimization and clearly seperate the keys per type, the rfkill_type
structure
now holds the list of the keys that belong to him. This has greatly reduced
the size of the rfkill_master structure.
sysfs will hold the following entries:
- The main folder: rfkill
- The main folder contains the type folders wlan, bluetooth and irda.
- Each type folder contains the files
- claim where the user claim can be read/written
- status The radio status of this type
- The folders for each key belonging to this type
- Each key folder contains the files
- status The status of this key
- idev The symlink to the input device entry in sysfs
- dev The symlink to the drivers device entry in sysfs
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ba0e88c..6986d59 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,19 @@ config HP_SDC_RTC
Say Y here if you want to support the built-in real time clock
of the HP SDC controller.
+config RFKILL
+ tristate RF button support
+ help
+ If you say yes here, the rfkill driver will be build
+ which allowed network devices to register their hardware
+ RF button which controls the radio state. This driver
+ will then create an input device for it.
+
+ When the input device is not used, the rfkill driver
+ will make sure that when the RF button is pressed the radio
+ is enabled or disabled accordingly. When the input device
+ has been opened by the user this radio control will be left
+ to the user, and rfkill will only send the RF button status
+ change to userspace.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e788a1b 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o
+obj-$(CONFIG_RFKILL) += rfkill.o
diff --git a/drivers/input/misc/rfkill.c b/drivers/input/misc/rfkill.c
new file mode 100644
index 000..6719962
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,988 @@
+/*
+ Copyright (C) 2006 Ivo van Doorn
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/workqueue.h
+#include linux/list.h
+#include linux/mutex.h
+#include linux/input.h
+#include linux/rfkill.h
+
+MODULE_AUTHOR(Ivo van Doorn [EMAIL PROTECTED]);
+MODULE_VERSION(1.0);
+MODULE_DESCRIPTION(RF key support);
+MODULE_LICENSE(GPL);
+
+/*
+ * rfkill key structure.
+ */
+struct rfkill_key {
+ /*
+* For sysfs representation.
+*/
+ struct class_device *cdev;
+
+ /*
+* Pointer to rfkill structure
+* that was filled in by key driver.
+*/
+ struct rfkill *rfkill;
+
+ /*
+* Pointer to type structure
+* that this key belongs to.
+*/
+ struct rfkill_type *type;
+
+ /*
+* Current status of the key which controls the radio,
+* this value will change after the key state has changed
+* after polling, or the key driver has send
Re: d80211: a patch for standalone d80211 tarball
Hi, This patch should be enough to allow creation of standalone d80211 tarball (i.e. version of d80211 that could be compiled without patching the vanilla kernel) after invisible master interface patches. That looks very nice indeed, that saves me quite a big patch I usually apply to the rt2x00-cvs version of d80211. :) It is completely untested. I will put this patch into the rt2x00-cvs version of d80211 to see if it works. :) Thanks. Ivo P.S. I have some d80211 patches in testing that would add support for: - software rts - software sequence - tx_header_room fixes As soon as they are tested I'll send them to the list. :) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] bcm43xx: set channel when the interface is brought up
Hi, I have discovered that while I can indeed associate without wpa_supplicant using bcm43xx_d80211 driver, I have to set the channel every time the interface is brought down and up. It turns out d80211 uses the config method of the hardware drivers very sparingly. It's only used for scanning and in ioctl commands. It is not called after the interface has been brought up with the open method. Correct, similar problems have been detected in rt2x00. The temporary solution in there is to demand a scanning operation after the interface has been brought up. I don't know whose responsibility it should be to apply the configuration when the interface is brought up. I'm not familiar with d80211 design principles. Well my personal preference would be if the dscape stack handles it, unless the stack guarentees the conf structure has been initialized and contains valid data when the interface is being brought up. Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] bcm43xx: set channel when the interface is brought up
Hi, Correct, similar problems have been detected in rt2x00. The temporary solution in there is to demand a scanning operation after the interface has been brought up. Scanning? No no no, please! That would be a clear bug and misbehaviour. Hmm, I think I forgot to add one little thing in my comment. The scanning operation is demanded in the rt2x00 README, so the driver doesn't start the scanning automatically and just awaits the user commands. The user is also free to change the channel to make the configuration active. But a scanning command will also display if it has at least found some AP, so without scanning results attempting to scan will very likely fail. ;) Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND 0/4]
Hi John, These patches have been send during 2006 but never have been applied or rejected. Even after sending requests for updates on these patches. So I have no idea if you had rejected them, simply overlooked them, or if they are still in your pending list. Short summary of which patches are being resend: - crc-itu-t This has been send to the list during the summer around the same time as the initial patch for rfkill. It had also been send to the linux-kernel list with a CC to you with a request for comment. - eeprom_93cx6 This has been send to the list1 or 2 months ago. After the initial patch a feature request for eeprom write support was made. Those 2 patches have now been merged into a single patch. Both of the libraries come from rt2x00, and this patch merely moves them to the location for more generic routines. Both the crc as the eeprom handling can be used by different drivers (some drivers also use the same implementation, which in my opinion would jusitify these 2 modules to be in the lib folder). Do you have any status update for these 4 patches? Are they pending, or have they been rejected? Thanks, Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] d80211: Fix inconsistent sta_lock usage
Bit ordering, I see. Then go for my original patch + comments why this
is open-coded in __bss_tim_set/clear + removed unused arguments from
those functions, OK?
Sounds good to me, care to send a new patch?
This patch returns to the original format for setting and clearing the tim bit,
as the IEEE specs mandate. (Comment has been added to prevent future
attempts to use the __set_bit and __clear_bit)
And the local argument has been removed.
Signed-off-by Jan Kiszka [EMAIL PROTECTED]
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index ef303da..64d881c 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -558,20 +558,38 @@ struct sta_attribute {
ssize_t (*store)(struct sta_info *, const char *buf, size_t count);
};
+static inline void __bss_tim_set(struct ieee80211_if_ap *bss, int aid)
+{
+ /*
+* This format has ben mandated by the IEEE specifications,
+* so this line may not be changed to use the __set_bit() format.
+*/
+ bss-tim[(aid)/8] |= 1((aid) % 8);
+}
+
static inline void bss_tim_set(struct ieee80211_local *local,
struct ieee80211_if_ap *bss, int aid)
{
- spin_lock(local-sta_lock);
- bss-tim[(aid)/8] |= 1((aid) % 8);
- spin_unlock(local-sta_lock);
+ spin_lock_bh(local-sta_lock);
+ __bss_tim_set(bss, aid);
+ spin_unlock_bh(local-sta_lock);
+}
+
+static inline void __bss_tim_clear(struct ieee80211_if_ap *bss, int aid)
+{
+ /*
+* This format has ben mandated by the IEEE specifications,
+* so this line may not be changed to use the __clear_bit() format.
+*/
+ bss-tim[(aid)/8] = !(1((aid) % 8));
}
static inline void bss_tim_clear(struct ieee80211_local *local,
struct ieee80211_if_ap *bss, int aid)
{
- spin_lock(local-sta_lock);
- bss-tim[(aid)/8] = !(1((aid) % 8));
- spin_unlock(local-sta_lock);
+ spin_lock_bh(local-sta_lock);
+ __bss_tim_clear(bss, aid);
+ spin_unlock_bh(local-sta_lock);
}
/* ieee80211.c */
diff --git a/net/d80211/ieee80211_ioctl.c b/net/d80211/ieee80211_ioctl.c
index c74b431..1363a01 100644
--- a/net/d80211/ieee80211_ioctl.c
+++ b/net/d80211/ieee80211_ioctl.c
@@ -285,7 +285,9 @@ static int ieee80211_ioctl_add_sta(struct net_device *dev,
if (sta-dev != dev) {
/* Binding STA to a new interface, so remove all references to
* the old BSS. */
+ spin_lock_bh(local-sta_lock);
sta_info_remove_aid_ptr(sta);
+ spin_unlock_bh(local-sta_lock);
}
/* TODO
@@ -359,7 +361,7 @@ static int ieee80211_ioctl_remove_sta(struct
net_device *dev,
sta = sta_info_get(local, param-sta_addr);
if (sta) {
sta_info_put(sta);
- sta_info_free(sta, 1);
+ sta_info_free(sta, 0);
}
return sta ? 0 : -ENOENT;
diff --git a/net/d80211/sta_info.c b/net/d80211/sta_info.c
index 0c42ae8..f27bd0e 100644
--- a/net/d80211/sta_info.c
+++ b/net/d80211/sta_info.c
@@ -439,7 +439,7 @@ void sta_info_remove_aid_ptr(struct sta_info *sta)
sdata-local-ops-set_tim(local_to_hw(sdata-local),
sta-aid, 0);
if (sdata-bss)
- bss_tim_clear(sdata-local, sdata-bss, sta-aid);
+ __bss_tim_clear(sdata-bss, sta-aid);
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] d80211: Fix inconsistent sta_lock usage
On Tuesday 02 January 2007 17:22, Christoph Hellwig wrote:
On Tue, Jan 02, 2007 at 04:30:41PM +0100, Ivo Van Doorn wrote:
+static inline void __bss_tim_set(struct ieee80211_local *local,
+struct ieee80211_if_ap *bss, int aid)
+{
+ bss-tim[(aid)/8] |= 1((aid) % 8);
+}
This really screams to be converted to __set_bit. Also the local
argument is entirely unused. I'd probaby not even add a helper for
this but just opencode it as:
__set_bit(bss-time, aid);
+static inline void __bss_tim_clear(struct ieee80211_local *local,
+ struct ieee80211_if_ap *bss, int aid)
+{
+ bss-tim[(aid)/8] = !(1((aid) % 8));
Similarly this should just be __clear_bit
This patch uses the __set_bit and __clear_but as suggested by Christoph.
It also removes the local argument since it was unused.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index 6ba6a61..c5c04d2 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -560,19 +560,23 @@ struct sta_attribute {
ssize_t (*store)(struct sta_info *, const char *buf, size_t count);
};
+#define __bss_tim_set(__bss, __aid)__set_bit((__aid), (__bss)-tim)
+
static inline void bss_tim_set(struct ieee80211_local *local,
struct ieee80211_if_ap *bss, int aid)
{
- spin_lock(local-sta_lock);
- bss-tim[(aid)/8] |= 1((aid) % 8);
- spin_unlock(local-sta_lock);
+ spin_lock_bh(local-sta_lock);
+ __bss_tim_set(bss, aid);
+ spin_unlock_bh(local-sta_lock);
}
+#define __bss_tim_clear(__bss, __aid) __clear_bit((__aid), (__bss)-tim)
+
static inline void bss_tim_clear(struct ieee80211_local *local,
struct ieee80211_if_ap *bss, int aid)
{
spin_lock(local-sta_lock);
- bss-tim[(aid)/8] = !(1((aid) % 8));
+ __bss_tim_clear(bss, aid);
spin_unlock(local-sta_lock);
}
diff --git a/net/d80211/ieee80211_ioctl.c b/net/d80211/ieee80211_ioctl.c
index 81a6e82..5a21b2d 100644
--- a/net/d80211/ieee80211_ioctl.c
+++ b/net/d80211/ieee80211_ioctl.c
@@ -286,7 +286,9 @@ static int ieee80211_ioctl_add_sta(struct net_device *dev,
if (sta-dev != dev) {
/* Binding STA to a new interface, so remove all references to
* the old BSS. */
+ spin_lock_bh(local-sta_lock);
sta_info_remove_aid_ptr(sta);
+ spin_unlock_bh(local-sta_lock);
}
/* TODO
@@ -360,7 +362,7 @@ static int ieee80211_ioctl_remove_sta(struct net_device
*dev,
sta = sta_info_get(local, param-sta_addr);
if (sta) {
sta_info_put(sta);
- sta_info_free(sta, 1);
+ sta_info_free(sta, 0);
}
return sta ? 0 : -ENOENT;
diff --git a/net/d80211/sta_info.c b/net/d80211/sta_info.c
index 0c42ae8..f27bd0e 100644
--- a/net/d80211/sta_info.c
+++ b/net/d80211/sta_info.c
@@ -439,7 +439,7 @@ void sta_info_remove_aid_ptr(struct sta_info *sta)
sdata-local-ops-set_tim(local_to_hw(sdata-local),
sta-aid, 0);
if (sdata-bss)
- bss_tim_clear(sdata-local, sdata-bss, sta-aid);
+ __bss_tim_clear(sdata-bss, sta-aid);
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND 0/4]
Hi John, These patches have been send during 2006 but never have been applied or rejected. Even after sending requests for updates on these patches. So I have no idea if you had rejected them, simply overlooked them, or if they are still in your pending list. Short summary of which patches are being resend: - crc-itu-t This has been send to the list during the summer around the same time as the initial patch for rfkill. It had also been send to the linux-kernel list with a CC to you with a request for comment. - eeprom_93cx6 This has been send to the list1 or 2 months ago. After the initial patch a feature request for eeprom write support was made. Those 2 patches have now been merged into a single patch. Both of the libraries come from rt2x00, and this patch merely moves them to the location for more generic routines. Both the crc as the eeprom handling can be used by different drivers (some drivers also use the same implementation, which in my opinion would jusitify these 2 modules to be in the lib folder). Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND 1/4] eeprom_93cx6
This patch adds the eeprom_93cx6 module to the lib folder.
This module provides a generic approach for reading and
writing words from the eeprom chipsets 93c46 and 93c66.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rNU3 wireless-dev/include/linux/eeprom_93cx6.h
wireless-dev_eeprom/include/linux/eeprom_93cx6.h
--- wireless-dev/include/linux/eeprom_93cx6.h 1970-01-01 01:00:00.0
+0100
+++ wireless-dev_eeprom/include/linux/eeprom_93cx6.h2006-12-30
16:49:02.0 +0100
@@ -0,0 +1,77 @@
+/*
+ Copyright (C) 2004 - 2006 rt2x00 SourceForge Project
+ http://rt2x00.serialmonkey.com
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+/*
+ Module: eeprom_93cx6
+ Abstract: EEPROM reader datastructures for 93cx6 chipsets.
+ Supported chipsets: 93c46 93c66.
+ */
+
+/*
+ * EEPROM operation defines.
+ */
+#define PCI_EEPROM_WIDTH_93C46 6
+#define PCI_EEPROM_WIDTH_93C66 8
+#define PCI_EEPROM_WIDTH_OPCODE3
+#define PCI_EEPROM_WRITE_OPCODE0x05
+#define PCI_EEPROM_READ_OPCODE 0x06
+#define PCI_EEPROM_EWDS_OPCODE 0x10
+#define PCI_EEPROM_EWEN_OPCODE 0x13
+
+/**
+ * struct eeprom_93cx6 - control structure for setting the commands
+ * for reading the eeprom data.
+ * @data: private pointer for the driver.
+ * @register_read(struct eeprom_93cx6 *eeprom): handler to
+ * read the eeprom register, this function should set all reg_* fields.
+ * @register_write(struct eeprom_93cx6 *eeprom): handler to
+ * write to the eeprom register by using all reg_* fields.
+ * @width: eeprom width, should be one of the PCI_EEPROM_WIDTH_* defines
+ * @reg_data_in: register field to indicate data input
+ * @reg_data_out: register field to indicate data output
+ * @reg_data_clock: register field to set the data clock
+ * @reg_chip_select: register field to set the chip select
+ *
+ * This structure is used for the communication between the driver
+ * and the eeprom_93cx6 handlers for reading the eeprom.
+ */
+struct eeprom_93cx6 {
+ void *data;
+
+ void (*register_read)(struct eeprom_93cx6 *eeprom);
+ void (*register_write)(struct eeprom_93cx6 *eeprom);
+
+ int width;
+
+ char reg_data_in;
+ char reg_data_out;
+ char reg_data_clock;
+ char reg_chip_select;
+};
+
+extern void eeprom_93cx6_read(struct eeprom_93cx6 *eeprom,
+ const u8 word, __le16 *data);
+extern void eeprom_93cx6_multiread(struct eeprom_93cx6 *eeprom,
+ const u8 word, __le16 *data, const u16 words);
+
+extern void eeprom_93cx6_write(struct eeprom_93cx6 *eeprom,
+ const u8 word, __le16 *data);
+extern void eeprom_93cx6_multiwrite(struct eeprom_93cx6 *eeprom,
+ const u8 word, __le16 *data, const u16 words);
diff -rNU3 wireless-dev/lib/Kconfig wireless-dev_eeprom/lib/Kconfig
--- wireless-dev/lib/Kconfig2007-01-03 20:54:00.0 +0100
+++ wireless-dev_eeprom/lib/Kconfig 2007-01-03 21:04:42.0 +0100
@@ -38,6 +38,14 @@
require M here. See Castagnoli93.
Module will be libcrc32c.
+config EEPROM_93CX6
+ tristate EEPROM 93CX6 support
+ ---help---
+ This is a driver for the EEPROM chipsets 93c46 and 93c66.
+ The driver supports both read as well as write commands.
+
+ When compiled as a module, this driver will be called eeprom_93c6.ko.
+
config AUDIT_GENERIC
bool
depends on AUDIT !AUDIT_ARCH
diff -rNU3 wireless-dev/lib/Makefile wireless-dev_eeprom/lib/Makefile
--- wireless-dev/lib/Makefile 2007-01-03 20:54:00.0 +0100
+++ wireless-dev_eeprom/lib/Makefile2007-01-03 21:05:01.0 +0100
@@ -53,6 +53,8 @@
obj-$(CONFIG_SMP) += percpu_counter.o
obj-$(CONFIG_AUDIT_GENERIC) += audit.o
+obj-$(CONFIG_EEPROM_93CX6) += eeprom_93cx6.o
+
obj-$(CONFIG_SWIOTLB) += swiotlb.o
hostprogs-y:= gen_crc32table
diff -rNU3 wireless-dev/lib/eeprom_93cx6.c
wireless-dev_eeprom/lib/eeprom_93cx6.c
--- wireless-dev/lib/eeprom_93cx6.c 1970-01-01 01:00:00.0 +0100
+++ wireless-dev_eeprom/lib/eeprom_93cx6.c 2006-12-30 16:49:02.0
+0100
@@ -0,0 +1,343 @@
+/*
+ Copyright (C) 2004 - 2006 rt2x00 SourceForge Project
+ http://rt2x00.serialmonkey.com
+
+ This program is free software; you can redistribute
[PATCH RESEND 3/4] crc-itu-t
This patch add the crc-itu-t implementation to the
lib folder.
This crc handler uses the CRC ITU-T V.41 routine
that is used in multiple drivers.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rNU3 wireless-dev/include/linux/crc-itu-t.h
wireless-dev_crc/include/linux/crc-itu-t.h
--- wireless-dev/include/linux/crc-itu-t.h 1970-01-01 01:00:00.0
+0100
+++ wireless-dev_crc/include/linux/crc-itu-t.h 2006-08-01 13:18:16.0
+0200
@@ -0,0 +1,27 @@
+/*
+ * crc-itu-t.h - CRC ITU-T V.41 routine
+ *
+ * Implements the standard CRC ITU-T V.41:
+ * Width 16
+ * Poly 0x1021 (x^16 + x^12 + x^15 + 1)
+ * Init 0
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2. See the file COPYING for more details.
+ */
+
+#ifndef CRC_ITU_T_H
+#define CRC_ITU_T_H
+
+#include linux/types.h
+
+extern u16 const crc_itu_t_table[256];
+
+extern u16 crc_itu_t(u16 crc, const u8 *buffer, size_t len);
+
+static inline u16 crc_itu_t_byte(u16 crc, const u8 data)
+{
+ return (crc 8) ^ crc_itu_t_table[((crc 8) ^ data) 0xff];
+}
+
+#endif /* CRC_ITU_T_H */
diff -rNU3 wireless-dev/lib/Kconfig wireless-dev_crc/lib/Kconfig
--- wireless-dev/lib/Kconfig2007-01-03 21:04:42.0 +0100
+++ wireless-dev_crc/lib/Kconfig2007-01-03 21:13:10.0 +0100
@@ -29,6 +29,14 @@
kernel tree does. Such modules that use library CRC32 functions
require M here.
+config CRC_ITU_T
+ tristate CRC ITU-T V.41 functions
+ help
+ This option is provided for the case where no in-kernel-tree
+ modules require CRC ITU-T V.41 functions, but a module built outside
+ the kernel tree does. Such modules that use library CRC ITU-T V.41
+ functions require M here.
+
config LIBCRC32C
tristate CRC32c (Castagnoli, et al) Cyclic Redundancy-Check
help
diff -rNU3 wireless-dev/lib/Makefile wireless-dev_crc/lib/Makefile
--- wireless-dev/lib/Makefile 2007-01-03 21:05:01.0 +0100
+++ wireless-dev_crc/lib/Makefile 2007-01-03 21:13:20.0 +0100
@@ -38,6 +38,7 @@
obj-$(CONFIG_CRC_CCITT)+= crc-ccitt.o
obj-$(CONFIG_CRC16)+= crc16.o
obj-$(CONFIG_CRC32)+= crc32.o
+obj-$(CONFIG_CRC_ITU_T)+= crc-itu-t.o
obj-$(CONFIG_LIBCRC32C)+= libcrc32c.o
obj-$(CONFIG_GENERIC_IOMAP) += iomap.o
obj-$(CONFIG_GENERIC_ALLOCATOR) += genalloc.o
diff -rNU3 wireless-dev/lib/crc-itu-t.c wireless-dev_crc/lib/crc-itu-t.c
--- wireless-dev/lib/crc-itu-t.c1970-01-01 01:00:00.0 +0100
+++ wireless-dev_crc/lib/crc-itu-t.c2006-08-01 13:18:16.0 +0200
@@ -0,0 +1,64 @@
+/*
+ * crc-itu-t.c
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2. See the file COPYING for more details.
+ */
+
+#include linux/types.h
+#include linux/module.h
+#include linux/crc-itu-t.h
+
+/** CRC table for the CRC ITU-T V.41 0x0x1021 (x^16 + x^12 + x^15 + 1) */
+const u16 crc_itu_t_table[256] = {
+ 0x, 0x1021, 0x2042, 0x3063, 0x4084, 0x50a5, 0x60c6, 0x70e7,
+ 0x8108, 0x9129, 0xa14a, 0xb16b, 0xc18c, 0xd1ad, 0xe1ce, 0xf1ef,
+ 0x1231, 0x0210, 0x3273, 0x2252, 0x52b5, 0x4294, 0x72f7, 0x62d6,
+ 0x9339, 0x8318, 0xb37b, 0xa35a, 0xd3bd, 0xc39c, 0xf3ff, 0xe3de,
+ 0x2462, 0x3443, 0x0420, 0x1401, 0x64e6, 0x74c7, 0x44a4, 0x5485,
+ 0xa56a, 0xb54b, 0x8528, 0x9509, 0xe5ee, 0xf5cf, 0xc5ac, 0xd58d,
+ 0x3653, 0x2672, 0x1611, 0x0630, 0x76d7, 0x66f6, 0x5695, 0x46b4,
+ 0xb75b, 0xa77a, 0x9719, 0x8738, 0xf7df, 0xe7fe, 0xd79d, 0xc7bc,
+ 0x48c4, 0x58e5, 0x6886, 0x78a7, 0x0840, 0x1861, 0x2802, 0x3823,
+ 0xc9cc, 0xd9ed, 0xe98e, 0xf9af, 0x8948, 0x9969, 0xa90a, 0xb92b,
+ 0x5af5, 0x4ad4, 0x7ab7, 0x6a96, 0x1a71, 0x0a50, 0x3a33, 0x2a12,
+ 0xdbfd, 0xcbdc, 0xfbbf, 0xeb9e, 0x9b79, 0x8b58, 0xbb3b, 0xab1a,
+ 0x6ca6, 0x7c87, 0x4ce4, 0x5cc5, 0x2c22, 0x3c03, 0x0c60, 0x1c41,
+ 0xedae, 0xfd8f, 0xcdec, 0xddcd, 0xad2a, 0xbd0b, 0x8d68, 0x9d49,
+ 0x7e97, 0x6eb6, 0x5ed5, 0x4ef4, 0x3e13, 0x2e32, 0x1e51, 0x0e70,
+ 0xff9f, 0xefbe, 0xdfdd, 0xcffc, 0xbf1b, 0xaf3a, 0x9f59, 0x8f78,
+ 0x9188, 0x81a9, 0xb1ca, 0xa1eb, 0xd10c, 0xc12d, 0xf14e, 0xe16f,
+ 0x1080, 0x00a1, 0x30c2, 0x20e3, 0x5004, 0x4025, 0x7046, 0x6067,
+ 0x83b9, 0x9398, 0xa3fb, 0xb3da, 0xc33d, 0xd31c, 0xe37f, 0xf35e,
+ 0x02b1, 0x1290, 0x22f3, 0x32d2, 0x4235, 0x5214, 0x6277, 0x7256,
+ 0xb5ea, 0xa5cb, 0x95a8, 0x8589, 0xf56e, 0xe54f, 0xd52c, 0xc50d,
+ 0x34e2, 0x24c3, 0x14a0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405,
+ 0xa7db, 0xb7fa, 0x8799, 0x97b8, 0xe75f, 0xf77e, 0xc71d, 0xd73c,
+ 0x26d3, 0x36f2, 0x0691, 0x16b0, 0x6657, 0x7676, 0x4615, 0x5634,
+ 0xd94c, 0xc96d, 0xf90e, 0xe92f, 0x99c8, 0x89e9, 0xb98a, 0xa9ab,
+ 0x5844, 0x4865, 0x7806, 0x6827, 0x18c0, 0x08e1, 0x3882, 0x28a3,
+ 0xcb7d, 0xdb5c, 0xeb3f, 0xfb1e, 0x8bf9, 0x9bd8, 0xabbb, 0xbb9a,
+ 0x4a75, 0x5a54, 0x6a37, 0x7a16, 0x0af1
[PATCH RESEND 2/4] rt2x00 should use generic eeprom_93cx6
This patch removes the eeprom_93cx6 files from rt2x00
and makes sure rt2x00 will use the generic eeprom_93cx6
implementation inside the lib folder.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rNU3 wireless-dev/drivers/net/wireless/d80211/rt2x00/Kconfig
wireless-dev_eeprom/drivers/net/wireless/d80211/rt2x00/Kconfig
--- wireless-dev/drivers/net/wireless/d80211/rt2x00/Kconfig 2007-01-03
20:53:57.0 +0100
+++ wireless-dev_eeprom/drivers/net/wireless/d80211/rt2x00/Kconfig
2007-01-03 21:02:41.0 +0100
@@ -82,15 +82,6 @@
---help---
Enable debugging output.
-config EEPROM_93CX6
- tristate EEPROM 93CX6 support
- depends on RT2x00
- ---help---
- This is an experimental driver for EEPROM chipsets 93c46 and 93c66.
- These chipsets are found inside the Ralink wireless cards.
-
- When compiled as a module, this driver will be called eeprom_93c6.ko.
-
config CRC_ITU_T
tristate CRC ITU-T V.41 functions
help
diff -rNU3 wireless-dev/drivers/net/wireless/d80211/rt2x00/Makefile
wireless-dev_eeprom/drivers/net/wireless/d80211/rt2x00/Makefile
--- wireless-dev/drivers/net/wireless/d80211/rt2x00/Makefile2007-01-03
20:53:57.0 +0100
+++ wireless-dev_eeprom/drivers/net/wireless/d80211/rt2x00/Makefile
2007-01-03 21:08:49.0 +0100
@@ -4,4 +4,3 @@
obj-$(CONFIG_RT2500USB)+= rt2500usb.o
obj-$(CONFIG_RT73USB) += rt73usb.o
obj-$(CONFIG_CRC_ITU_T)+= crc-itu-t.o
-obj-$(CONFIG_EEPROM_93CX6) += eeprom_93cx6.o
diff -rNU3 wireless-dev/drivers/net/wireless/d80211/rt2x00/eeprom_93cx6.c
wireless-dev_eeprom/drivers/net/wireless/d80211/rt2x00/eeprom_93cx6.c
--- wireless-dev/drivers/net/wireless/d80211/rt2x00/eeprom_93cx6.c
2007-01-03 20:53:57.0 +0100
+++ wireless-dev_eeprom/drivers/net/wireless/d80211/rt2x00/eeprom_93cx6.c
1970-01-01 01:00:00.0 +0100
@@ -1,189 +0,0 @@
-/*
- Copyright (C) 2004 - 2006 rt2x00 SourceForge Project
- http://rt2x00.serialmonkey.com
-
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
- (at your option) any later version.
-
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the
- Free Software Foundation, Inc.,
- 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-/*
- Module: eeprom_93cx6
- Abstract: EEPROM reader routines for 93cx6 chipsets.
- Supported chipsets: 93c46 93c66.
- */
-
-#include linux/kernel.h
-#include linux/module.h
-#include linux/version.h
-#include linux/delay.h
-
-#include eeprom_93cx6.h
-
-MODULE_AUTHOR(http://rt2x00.serialmonkey.com;);
-MODULE_DESCRIPTION(EEPROM 93cx6 chip driver);
-MODULE_LICENSE(GPL);
-
-static inline void eeprom_93cx6_pulse_high(struct eeprom_93cx6 *eeprom)
-{
- eeprom-reg_data_clock = 1;
- eeprom-register_write(eeprom);
- udelay(1);
-}
-
-static inline void eeprom_93cx6_pulse_low(struct eeprom_93cx6 *eeprom)
-{
- eeprom-reg_data_clock = 0;
- eeprom-register_write(eeprom);
- udelay(1);
-}
-
-static void eeprom_93cx6_write_bits(struct eeprom_93cx6 *eeprom,
- const u16 data, const u16 count)
-{
- unsigned int i;
-
- eeprom-register_read(eeprom);
-
- /*
-* Clear data flags.
-*/
- eeprom-reg_data_in = 0;
- eeprom-reg_data_out = 0;
-
- /*
-* Start writing all bits.
-*/
- for (i = count; i 0; i--) {
- /*
-* Check if this bit needs to be set.
-*/
- eeprom-reg_data_in = !!(data (1 (i - 1)));
-
- /*
-* Write the bit to the eeprom register.
-*/
- eeprom-register_write(eeprom);
-
- /*
-* Kick a pulse.
-*/
- eeprom_93cx6_pulse_high(eeprom);
- eeprom_93cx6_pulse_low(eeprom);
- }
-
- eeprom-reg_data_in = 0;
- eeprom-register_write(eeprom);
-}
-
-static void eeprom_93cx6_read_bits(struct eeprom_93cx6 *eeprom,
- u16 *data, const u16 count)
-{
- unsigned int i;
-
- eeprom-register_read(eeprom);
-
- /*
-* Clear data flags.
-*/
- eeprom-reg_data_in = 0;
- eeprom-reg_data_out = 0;
-
- /*
-* Start reading all bits.
-*/
- for (i = count; i 0; i--) {
- eeprom_93cx6_pulse_high(eeprom
[PATCH RESEND 4/4] rt2x00 should use generic crc-itu-t
This patch removes the crc-itu-t files from rt2x00
and makes sure rt2x00 will use the generic crc-itu-t
implementation inside the lib folder.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rNU3 wireless-dev/drivers/net/wireless/d80211/rt2x00/Kconfig
wireless-dev_crc/drivers/net/wireless/d80211/rt2x00/Kconfig
--- wireless-dev/drivers/net/wireless/d80211/rt2x00/Kconfig 2007-01-03
21:02:41.0 +0100
+++ wireless-dev_crc/drivers/net/wireless/d80211/rt2x00/Kconfig 2007-01-03
21:14:18.0 +0100
@@ -81,11 +81,3 @@
depends on RT73USB
---help---
Enable debugging output.
-
-config CRC_ITU_T
- tristate CRC ITU-T V.41 functions
- help
- This option is provided for the case where no in-kernel-tree
- modules require CRC ITU-T V.41 functions, but a module built outside
- the kernel tree does. Such modules that use library CRC ITU-T V.41
- functions require M here.
diff -rNU3 wireless-dev/drivers/net/wireless/d80211/rt2x00/Makefile
wireless-dev_crc/drivers/net/wireless/d80211/rt2x00/Makefile
--- wireless-dev/drivers/net/wireless/d80211/rt2x00/Makefile2007-01-03
21:08:49.0 +0100
+++ wireless-dev_crc/drivers/net/wireless/d80211/rt2x00/Makefile
2007-01-03 21:14:26.0 +0100
@@ -3,4 +3,3 @@
obj-$(CONFIG_RT61PCI) += rt61pci.o
obj-$(CONFIG_RT2500USB)+= rt2500usb.o
obj-$(CONFIG_RT73USB) += rt73usb.o
-obj-$(CONFIG_CRC_ITU_T)+= crc-itu-t.o
diff -rNU3 wireless-dev/drivers/net/wireless/d80211/rt2x00/crc-itu-t.c
wireless-dev_crc/drivers/net/wireless/d80211/rt2x00/crc-itu-t.c
--- wireless-dev/drivers/net/wireless/d80211/rt2x00/crc-itu-t.c 2007-01-03
20:53:57.0 +0100
+++ wireless-dev_crc/drivers/net/wireless/d80211/rt2x00/crc-itu-t.c
1970-01-01 01:00:00.0 +0100
@@ -1,66 +0,0 @@
-/*
- * crc-itu-t.c
- *
- * This source code is licensed under the GNU General Public License,
- * Version 2. See the file COPYING for more details.
- */
-
-#include linux/types.h
-#include linux/module.h
-
-#include crc-itu-t.h
-
-MODULE_AUTHOR(http://rt2x00.serialmonkey.com;);
-MODULE_DESCRIPTION(CRC ITU-T V.41 calculations);
-MODULE_LICENSE(GPL);
-
-/** CRC table for the CRC ITU-T V.41 0x0x1021 (x^16 + x^12 + x^15 + 1) */
-const u16 crc_itu_t_table[256] = {
- 0x, 0x1021, 0x2042, 0x3063, 0x4084, 0x50a5, 0x60c6, 0x70e7,
- 0x8108, 0x9129, 0xa14a, 0xb16b, 0xc18c, 0xd1ad, 0xe1ce, 0xf1ef,
- 0x1231, 0x0210, 0x3273, 0x2252, 0x52b5, 0x4294, 0x72f7, 0x62d6,
- 0x9339, 0x8318, 0xb37b, 0xa35a, 0xd3bd, 0xc39c, 0xf3ff, 0xe3de,
- 0x2462, 0x3443, 0x0420, 0x1401, 0x64e6, 0x74c7, 0x44a4, 0x5485,
- 0xa56a, 0xb54b, 0x8528, 0x9509, 0xe5ee, 0xf5cf, 0xc5ac, 0xd58d,
- 0x3653, 0x2672, 0x1611, 0x0630, 0x76d7, 0x66f6, 0x5695, 0x46b4,
- 0xb75b, 0xa77a, 0x9719, 0x8738, 0xf7df, 0xe7fe, 0xd79d, 0xc7bc,
- 0x48c4, 0x58e5, 0x6886, 0x78a7, 0x0840, 0x1861, 0x2802, 0x3823,
- 0xc9cc, 0xd9ed, 0xe98e, 0xf9af, 0x8948, 0x9969, 0xa90a, 0xb92b,
- 0x5af5, 0x4ad4, 0x7ab7, 0x6a96, 0x1a71, 0x0a50, 0x3a33, 0x2a12,
- 0xdbfd, 0xcbdc, 0xfbbf, 0xeb9e, 0x9b79, 0x8b58, 0xbb3b, 0xab1a,
- 0x6ca6, 0x7c87, 0x4ce4, 0x5cc5, 0x2c22, 0x3c03, 0x0c60, 0x1c41,
- 0xedae, 0xfd8f, 0xcdec, 0xddcd, 0xad2a, 0xbd0b, 0x8d68, 0x9d49,
- 0x7e97, 0x6eb6, 0x5ed5, 0x4ef4, 0x3e13, 0x2e32, 0x1e51, 0x0e70,
- 0xff9f, 0xefbe, 0xdfdd, 0xcffc, 0xbf1b, 0xaf3a, 0x9f59, 0x8f78,
- 0x9188, 0x81a9, 0xb1ca, 0xa1eb, 0xd10c, 0xc12d, 0xf14e, 0xe16f,
- 0x1080, 0x00a1, 0x30c2, 0x20e3, 0x5004, 0x4025, 0x7046, 0x6067,
- 0x83b9, 0x9398, 0xa3fb, 0xb3da, 0xc33d, 0xd31c, 0xe37f, 0xf35e,
- 0x02b1, 0x1290, 0x22f3, 0x32d2, 0x4235, 0x5214, 0x6277, 0x7256,
- 0xb5ea, 0xa5cb, 0x95a8, 0x8589, 0xf56e, 0xe54f, 0xd52c, 0xc50d,
- 0x34e2, 0x24c3, 0x14a0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405,
- 0xa7db, 0xb7fa, 0x8799, 0x97b8, 0xe75f, 0xf77e, 0xc71d, 0xd73c,
- 0x26d3, 0x36f2, 0x0691, 0x16b0, 0x6657, 0x7676, 0x4615, 0x5634,
- 0xd94c, 0xc96d, 0xf90e, 0xe92f, 0x99c8, 0x89e9, 0xb98a, 0xa9ab,
- 0x5844, 0x4865, 0x7806, 0x6827, 0x18c0, 0x08e1, 0x3882, 0x28a3,
- 0xcb7d, 0xdb5c, 0xeb3f, 0xfb1e, 0x8bf9, 0x9bd8, 0xabbb, 0xbb9a,
- 0x4a75, 0x5a54, 0x6a37, 0x7a16, 0x0af1, 0x1ad0, 0x2ab3, 0x3a92,
- 0xfd2e, 0xed0f, 0xdd6c, 0xcd4d, 0xbdaa, 0xad8b, 0x9de8, 0x8dc9,
- 0x7c26, 0x6c07, 0x5c64, 0x4c45, 0x3ca2, 0x2c83, 0x1ce0, 0x0cc1,
- 0xef1f, 0xff3e, 0xcf5d, 0xdf7c, 0xaf9b, 0xbfba, 0x8fd9, 0x9ff8,
- 0x6e17, 0x7e36, 0x4e55, 0x5e74, 0x2e93, 0x3eb2, 0x0ed1, 0x1ef0
-};
-EXPORT_SYMBOL(crc_itu_t_table);
-
-/**
- * crc_itu_t - Compute the CRC-ITU-T for the data buffer
- * @crc: previous CRC value
- * @buffer: data pointer
- * @len: number of bytes in the buffer
- */
-u16 crc_itu_t(u16 crc, const u8 *buffer, size_t len)
-{
- while (len--)
- crc = crc_itu_t_byte(crc, *buffer
Re: [PATCH] d80211: Fix inconsistent sta_lock usage
On 1/1/07, Jan Kiszka [EMAIL PROTECTED] wrote:
Hacking a bit on rt2x00 to make it work in master and ad-hoc mode, lockdep
popped up on some hostapd ioctls, pointing out remaining inconsistencies
related to sta_lock:
1. sta_lock holders must always be protected against softirq
2. bss_tim_set/clear must not be called with sta_lock held, rather an
unprotected variant
3. ieee80211_ioctl_remove_sta is not already holding the lock when calling
sta_info_free
As I was not sure if sta_info_remove_aid_ptr needs lock protection or
not, I played safe and moved it always under the lock. Please correct me
if this is overkill.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
[Sorry, patch is against rt2x00 CVS. I'm lacking time and bandwidth to pull
the d80211 git repos and rebase.]
To make it easier for everybody, here is the same patch
only this time applied to the dscape git tree. ;)
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
Signed-off-by: Ivo van Doorn [EMAIL PROTECTED]
---
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index ef303da..b132ae0 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -558,20 +558,32 @@ struct sta_attribute {
ssize_t (*store)(struct sta_info *, const char *buf, size_t count);
};
+static inline void __bss_tim_set(struct ieee80211_local *local,
+struct ieee80211_if_ap *bss, int aid)
+{
+ bss-tim[(aid)/8] |= 1((aid) % 8);
+}
+
static inline void bss_tim_set(struct ieee80211_local *local,
struct ieee80211_if_ap *bss, int aid)
{
- spin_lock(local-sta_lock);
- bss-tim[(aid)/8] |= 1((aid) % 8);
- spin_unlock(local-sta_lock);
+ spin_lock_bh(local-sta_lock);
+ __bss_tim_set(local, bss, aid);
+ spin_unlock_bh(local-sta_lock);
+}
+
+static inline void __bss_tim_clear(struct ieee80211_local *local,
+ struct ieee80211_if_ap *bss, int aid)
+{
+ bss-tim[(aid)/8] = !(1((aid) % 8));
}
static inline void bss_tim_clear(struct ieee80211_local *local,
struct ieee80211_if_ap *bss, int aid)
{
- spin_lock(local-sta_lock);
- bss-tim[(aid)/8] = !(1((aid) % 8));
- spin_unlock(local-sta_lock);
+ spin_lock_bh(local-sta_lock);
+ __bss_tim_clear(local, bss, aid);
+ spin_unlock_bh(local-sta_lock);
}
/* ieee80211.c */
diff --git a/net/d80211/ieee80211_ioctl.c b/net/d80211/ieee80211_ioctl.c
index c74b431..1363a01 100644
--- a/net/d80211/ieee80211_ioctl.c
+++ b/net/d80211/ieee80211_ioctl.c
@@ -285,7 +285,9 @@ static int ieee80211_ioctl_add_sta(struct net_device *dev,
if (sta-dev != dev) {
/* Binding STA to a new interface, so remove all references to
* the old BSS. */
+ spin_lock_bh(local-sta_lock);
sta_info_remove_aid_ptr(sta);
+ spin_unlock_bh(local-sta_lock);
}
/* TODO
@@ -359,7 +361,7 @@ static int ieee80211_ioctl_remove_sta(struct
net_device *dev,
sta = sta_info_get(local, param-sta_addr);
if (sta) {
sta_info_put(sta);
- sta_info_free(sta, 1);
+ sta_info_free(sta, 0);
}
return sta ? 0 : -ENOENT;
diff --git a/net/d80211/sta_info.c b/net/d80211/sta_info.c
index 0c42ae8..e120a4f 100644
--- a/net/d80211/sta_info.c
+++ b/net/d80211/sta_info.c
@@ -439,7 +439,7 @@ void sta_info_remove_aid_ptr(struct sta_info *sta)
sdata-local-ops-set_tim(local_to_hw(sdata-local),
sta-aid, 0);
if (sdata-bss)
- bss_tim_clear(sdata-local, sdata-bss, sta-aid);
+ __bss_tim_clear(sdata-local, sdata-bss, sta-aid);
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] d80211: Reinit keys on mode change
On 1/1/07, Jan Kiszka [EMAIL PROTECTED] wrote: Switching the interface mode with some encryption keys set and then later touching any key, triggers an oops because ieee80211_if_reinit fails to NULL'ify the related pointers after free'ing the key on mode change. Long explanation, simple fix below. Signed-off-by: Jan Kiszka [EMAIL PROTECTED] [Sorry, yet another rt2x00 CVS patch...] To make it easier for everybody, here is the same patch only this time applied to the dscape git tree. ;) Signed-off-by: Jan Kiszka [EMAIL PROTECTED] Signed-off-by: Ivo van Doorn [EMAIL PROTECTED] --- diff --git a/net/d80211/ieee80211_iface.c b/net/d80211/ieee80211_iface.c index 3e9d531..7d4ec56 100644 --- a/net/d80211/ieee80211_iface.c +++ b/net/d80211/ieee80211_iface.c @@ -229,6 +229,7 @@ void ieee80211_if_reinit(struct net_device *dev) local-keys[i], 0); #endif ieee80211_key_free(sdata-keys[i]); + sdata-keys[i] = NULL; } /* Shouldn't be necessary but won't hurt */ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] eeprom_93cx6: Add write support
Hi, This patch addes support for writing to the eeprom, this also moves some duplicate code into seperate functions. John: Do you want me to merge this path with the eeprom merge patch, and move the patch that moves rt2x00 to use this eeprom module into a separate patch or all these 2 patches good enough? I shouldn't write mails while tired. Let met explain myself. ;) eeprom_93cx6 has now 2 patches pending: 1 - move eeprom_93cx6 out of rt2x00 and into /lib 2 - add write support for eeprom_93cx6 Should patch 1 be split into a patch to add eeprom_93cx6 to the /lib folder and a seperate patch to remove the module from rt2x00? And while redoing the patch, merge patch 2 with the patch to add eeprom_93cx6 to /lib? Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] eeprom_93cx6: Add write support
Hi, This patch addes support for writing to the eeprom, this also moves some duplicate code into seperate functions. John: Do you want me to merge this path with the eeprom merge patch, and move the patch that moves rt2x00 to use this eeprom module into a separate patch or all these 2 patches good enough? Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] rfkill - Add support for input key to control wireless radio
This is the latest version of rfkill.
The changes since the version that was originally send are:
Spelling fixes (Thanks to Randy Dunlap)
THIS_MODULE is now a field in the rkfill_master (Suggested by Christoph Hellwig)
The open_count has been completely removed, decision making on which action
should
be taken is now handled by the user_claim field, which can be set through sysfs.
The possible choice include
1 - let rfkill handle everything without bothering the user
2 - let rfkill handle everything but send a notification to the user
3 - let rfkill send a notification only
The toggling of the keys is now type based, this means that if 1 key is being
toggled
all keys of the same type will be toggled.
As optimization and clearly seperate the keys per type, the rfkill_type
structure
now holds the list of the keys that belong to him. This has greatly reduced
the size of the rfkill_master structure.
sysfs will hold the following entries:
- The main folder: rfkill
- The main folder contains the type folders wlan, bluetooth and irda.
- Each type folder contains the files
- claim where the user claim can be read/written
- status The radio status of this type
- The folders for each key belonging to this type
- Each key folder contains the files
- status The status of this key
- idev The symlink to the input device entry in sysfs
- dev The symlink to the drivers device entry in sysfs
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ba0e88c..e58c0bf 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,20 @@ config HP_SDC_RTC
Say Y here if you want to support the built-in real time clock
of the HP SDC controller.
+config RFKILL
+ tristate RF button support
+ depends on SYSFS
+ help
+ If you say yes here, the rfkill driver will be built
+ which allows network devices to register their hardware
+ RF button which controls the radio state. This driver
+ will then create an input device for it.
+
+ When the input device is not used, the rfkill driver
+ will make sure that when the RF button is pressed the radio
+ is enabled or disabled accordingly. When the input device
+ has been opened by the user this radio control will be left
+ to the user, and rfkill will only send the RF button status
+ change to userspace.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e788a1b 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o
+obj-$(CONFIG_RFKILL) += rfkill.o
diff --git a/drivers/input/misc/rfkill.c b/drivers/input/misc/rfkill.c
new file mode 100644
index 000..065ff56
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,986 @@
+/*
+ Copyright (C) 2006 Ivo van Doorn
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/workqueue.h
+#include linux/list.h
+#include linux/mutex.h
+#include linux/input.h
+#include linux/rfkill.h
+
+MODULE_AUTHOR(Ivo van Doorn [EMAIL PROTECTED]);
+MODULE_VERSION(1.0);
+MODULE_DESCRIPTION(RF key support);
+MODULE_LICENSE(GPL);
+
+/*
+ * rfkill key structure.
+ */
+struct rfkill_key {
+ /*
+* For sysfs representation.
+*/
+ struct class_device *cdev;
+
+ /*
+* Pointer to rfkill structure
+* that was filled in by key driver.
+*/
+ struct rfkill *rfkill;
+
+ /*
+* Pointer to type structure
+* that this key belongs to.
+*/
+ struct rfkill_type *type;
+
+ /*
+* Current status of the key which controls the radio,
+* this value will change after the key state has changed
+* after polling, or the key driver has send the new state
+* manually
Re: [Rt2400-devel] [PATCH] rt2x00: Fix compilation for d80211 hwmode API change
Hi, This fixes compilation for the d80211 hwmode API change. I haven't had time yet to look closely at more of the benefits of the new hwmode API change, but this patch looks good. Thanks! Signed-off-by: Michael Buesch [EMAIL PROTECTED] Signed-off-by: Ivo van Doorn [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Rt2400-devel] [PATCH] rt2x00: Fix PKT_PROBE_RESP breakage
Hi, On Friday 15 December 2006 20:39, Michael Buesch wrote: Fix breakage from removal of PKT_PROBE_RESP. Jiri had already send a patch to the netdev list to cover this breakage. ([PATCH 1/2] rt2x00: fix breakage after pkt_type field was removed) And I personally favour the patch from Jiri. Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d80211: The struct ieee80211_hw_modes array is a pain
Hi, I am currently porting the bcm43xx driver to my new Sonics Silicon Backplane busdriver. I am having a major pain implementing the hw-modes field for this. In particular, the problem is allocation. I always felt sick about hw-modes, but with my new code it's damn complicated to get allocation of the stuff right. The problem is, that I do not know in advance which PHYMODEs my device supports (in fact, we never knew that, but we worked around it (in a broken way)). We have the following scenario: The PHYs are probed one after each other. We have one data structure per PHY. This bites the static hw-modes array in its ass. I would either have to allocate it big enough at the first time (wasting lots of memory) or I'd have to re-allocate it every time a new PHY is probed. Another (much harder to fix) problem is the opposite of the probing: Removing the PHYs. So, what I'd like to have is: One struct ieee802111_hw_mode which I can embed into the PHY data structure. This struct is now dynamically registered to the ieee80211 subsystem (instead of doing a static array pain). Registering and unregistering would be done with simple linked lists, perhaps, in d80211. Sounds good to me. This would also solve the issue where the dscape stack would always select the first mode in the array as the default mode. Which means that the array should always be allocated in a specific order since if B is first followed by G, then B would always be used (even if G is supported by the AP). Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] rt2x00: fix breakage after pkt_type field was removed
On Wednesday 13 December 2006 18:00, Jiri Benc wrote: Fix breakage after pkt_type field was removed from ieee80211_tx_control. Hmm, I must have missed that patch. Your patch looks good to me. Thanks Signed-off-by: Jiri Benc [EMAIL PROTECTED] Signed-off-by: Ivo van Doorn [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] rt2x00: Fix crc-itu-t dependency
crc-itu-t should only appear in the kernel configuration menu when rt2x00 is enabled. The module should only be build when rt2x00 is used, otherwise crc-itu-t is simply in the wrong location since it is not a network driver. Signed-off-by Ivo van Doorn [EMAIL PROTECTED] --- diff --git a/drivers/net/wireless/d80211/rt2x00/Kconfig b/drivers/net/wireless/d80211/rt2x00/Kconfig index c2c2a60..18d61c3 100644 --- a/drivers/net/wireless/d80211/rt2x00/Kconfig +++ b/drivers/net/wireless/d80211/rt2x00/Kconfig @@ -93,6 +93,7 @@ config EEPROM_93CX6 config CRC_ITU_T tristate CRC ITU-T V.41 functions + depends on RT2X00 help This option is provided for the case where no in-kernel-tree modules require CRC ITU-T V.41 functions, but a module built outside - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/26] rt2x00: EEPROM 93Cx6
On Wednesday 13 December 2006 18:05, Lennart Sorensen wrote: On Wed, Dec 13, 2006 at 05:47:41PM +0100, Ivo van Doorn wrote: Do you need to actually write data to the eeprom chip? Currently the module does not support writing to the eeprom, this is something I could add (The original Ralink code, where this module is based on also contains the code to write to the EEPROM). I am going to use it to write the custom pci vendor ID to the eeprom, so yes I intend to write to it. The code appears as if it has the ability to write to the eeprom but I didn't look at all of it carefully yet. I don't actually have any need to read it back, although I intend to do so to verify the contents. Currently the module does not contain any code to actually write to the eeprom. I'll create a patch to add support for the writing. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] d80211, rt2x00: fixes
On Wednesday 13 December 2006 18:12, Lennart Sorensen wrote: On Wed, Dec 13, 2006 at 06:00:35PM +0100, Jiri Benc wrote: John, in addition to the previous pull request, please also apply the following two fixes. What is the state of the rx2x00 driver by now? I have been playing around with an rt2500 based card, with some success but not enough for me to switch over from wired ethernet yet on my machine. I used to get lots of hard lockups, but with the latest cvs snapshot in debian's rt2x00-source package, it no longer seems to lockup. It also now works with WPA without using wpa_supplicant (Yay! Good work.), it does however very frequently pause the transfer, and then after a while (20 or 30 seconds probably) it will start moving data again and my transfer will continue. Is this considered normal for now? My card happens to be a linksys WMP54G version 4.0. At least pauses beat crashes. It's going the right way for a work in progress. I guess I should go read the bug tracking system and try out newer cvs versions. :) Well results seem to vary between users. Since recently users have started reporting panics and freezes with rt2x00. I have not yet traced that problem to the source, because the panics I have received don't contain any rt2x00 or d80211 functions. But the presence of the rt2x00 module is the important factor in reproducing the crash. :( Others however seem to have more success with rt2x00, master mode seems to work with reasonable speed. Association with managed mode is still very shortlifed. People who manage to get associated are being kicked from the AP quite quickly. (This could be because d80211 is not sending NULL-frames every once in a while). But since results vary much between users, I can still descrive the rt2x00 state as experimental driver Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] d80211, rt2x00: fixes
Hi, How, by private ioctls? That's just wrong; I believe you still need to go through the 4-way handshake to get the right keying information even if you use PSK, which means you still need the supplicant, right? All I did was add this to /etc/network/interfaces: iface wlan0 inet static address 192.168.1.51 network 192.168.1.0 netmask 255.255.255.0 gateway 192.168.1.254 broadcast 192.168.1.255 pre-up ifconfig wlan0 up pre-up iwpriv wlan0 set AuthMode=WPAPSK pre-up iwpriv wlan0 set EncrypType=TKIP pre-up iwconfig wlan0 essid USR8054 pre-up iwpriv wlan0 set WPAPSK=My WPA passphrase... That is definately the rt2500 legacy driver and _not_ the rt2x00 driver. It seems to work, although I guess I could be wrong. It was what I found in the documentation for the rt2x00 driver for doing WPA. It looks nothing like the wpa_supplicant stuff I used to have with an older version of the driver. My understanding was that the rt2x00 driver and/or d80211 stack took care of it now. Correct, that is why those iwpriv commands are the clear evidence you are not using rt2x00 but rt2500 legacy. Check which driver is loaded rt2500 means legacy rt2500pci means rt2x00. Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] rfkill - Add support for input key to control wireless radio
Hi, 2 - Hardware key that does not control the hardware radio and does not report anything to userspace Kind of uninteresting button ;) And this is the button that rfkill was originally designed for. Laptops with integrated WiFi cards from Ralink have a hardware button that don't send anything to userspace (unless the ACPI event is read) and does not directly control the radio itself. So what does such a button do? I am confused here... Without a handler like rfkill, it does nothing besides toggling a bit in a register. The Ralink chipsets have a couple of registers that represent the state of that key. Besides that, there are no notifications to the userspace nor does it directly control the radio. That is where rfkill came in with the toggle handler that will listen to the register to check if the key has been pressed and properly process the key event. In this case the driver can make the button state available to userspace so thsi is really type 2) driver as far as I can see. The fact that the button is not reported to userspace yet should not get into our way of classifying it. I was indeed considering it as a type 2) device. I am currently working on revising the rfkill driver to work as you suggested, so I hope to have a new patch ready for you soon. Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/26] rt2x00: EEPROM 93Cx6
Hi I have checked the adm80211 code as well, it seems to behave quite the same, with the most notable difference the fact that adm80211 writes the READ_OPCODE and the word index within a single command, while in eeprom_93cx6 this is split into 2 seperate write commands. I have not yet tested the exact impact for rt2x00 devices when they would combine the write commands, but if that has no impact (or the adm80211 suffers no impact when the write commands are being split) then rt2x00 and adm80211 could indeed share the eeprom_93cx6 module. Hm, which way is the correct way? (is there a correct way?) I have tested rt2x00 with combining the read command and word index writing, and it is working perfectly. If eeprom_93cx6 is moved to the /lib folder of the kernel, should it be approved by a different maintainer first? I don't think so, but I'm not sure. BTW, I think there can actually be another user of this code. Take a look at drivers/scsi/aic7xxx/aic7xxx_93cx6.c I'm not sure who the maintainer for this is. Should be okay to just have adm8211 and rt2x00 using eeprom_93cx6 for now, unless you have a spare aic7xxx supported device lying around. ;) Nope, don't have that device. I'll create a patch that will place the eeprom module in the /lib folder. I'll send that to the list as soon as possible. Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/26] rt2x00: EEPROM 93Cx6
On Sunday 03 December 2006 19:39, Michael Wu wrote: On Sunday 03 December 2006 13:19, Ivo van Doorn wrote: rt2400pci, rt2500pci and rt61pci share exactly the same code for the eeprom reading. The only difference is that rt61pci has a slightly different register reading approach. In any case we have a lot of duplicate code. Create a new module eeprom_93cx6 inside the rt2x00 folder and make rt2x00 use that. Interesting. adm8211 has code to read 93C66 and 93C46 eeproms, and it looks similar, albeit smaller and simpler, to your 93cx6 reading code. However, it looks like your new eeprom reading code is general enough for adm8211 to use too. I'll have to try it.. I have checked the adm80211 code as well, it seems to behave quite the same, with the most notable difference the fact that adm80211 writes the READ_OPCODE and the word index within a single command, while in eeprom_93cx6 this is split into 2 seperate write commands. I have not yet tested the exact impact for rt2x00 devices when they would combine the write commands, but if that has no impact (or the adm80211 suffers no impact when the write commands are being split) then rt2x00 and adm80211 could indeed share the eeprom_93cx6 module. If eeprom_93cx6 is moved to the /lib folder of the kernel, should it be approved by a different maintainer first? Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] rfkill - Add support for input key to control wireless radio
Hi, 2 - Hardware key that does not control the hardware radio and does not report anything to userspace Kind of uninteresting button ;) And this is the button that rfkill was originally designed for. Laptops with integrated WiFi cards from Ralink have a hardware button that don't send anything to userspace (unless the ACPI event is read) and does not directly control the radio itself. My take: if there is a button on your keyboard or laptop labeled Kill my radio now, it _NEEDS_ to be somehow communicated to userspace what happened when the user just pressed it a second ago. Personally, I don't particularly care how that happens, and I don't particularly care what the driver does. But if the driver, or the hardware, decides that the button press means turning off the transmitter on whatever device that button is for, a tool like NetworkManager needs to know this somehow. Ideally, this would be a HAL event, and HAL would get it from somewhere. The current situation with NM is unacceptable, and I can't do anything about it because there is no standard interface for determining whether the wireless card was disabled/enabled via rfkill. I simply refuse to code solutions to every vendor's rfkill mechanism (for ipw, reading iwpriv or sysfs, for example). I don't care how HAL gets the event, but when HAL gets the event, it needs to broadcast it and NM needs to tear down the connection and release the device. That means (a) an event gets sent to userspace in some way that HAL can read it, and (b) the event is clearly associated with specific piece[s] of hardware on your system. If HAL can't easily figure out what device the event is for, then the event is also useless to both HAL and NetworkManager and whatever else might use it. This would be possible with rfkill and the ideas from Dmitry. The vendors that have a button that directly toggle the radio, should create an input device themselves and just send the KEY_RFKILL event when toggled. All other types should use rfkill for the toggling handling, that way HAL only needs to listen to KEY_RFKILL coming from the input devices that are associated to the keys. Again, I don't care how that happens, but I like the fact that there's renewed interest in getting this fixed. Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] rfkill - Add support for input key to control wireless radio
Hi, 2 - Hardware key that does not control the hardware radio and does not report anything to userspace Kind of uninteresting button ;) And this is the button that rfkill was originally designed for. Laptops with integrated WiFi cards from Ralink have a hardware button that don't send anything to userspace (unless the ACPI event is read) and does not directly control the radio itself. So what does such a button do? I am confused here... Without a handler like rfkill, it does nothing besides toggling a bit in a register. The Ralink chipsets have a couple of registers that represent the state of that key. Besides that, there are no notifications to the userspace nor does it directly control the radio. That is where rfkill came in with the toggle handler that will listen to the register to check if the key has been pressed and properly process the key event. And this event should be reported by a generic approach right? So it should be similar as with your point 2 below. But this would mean that the driver should create the input device. Or can a driver send the KEY_WIFI event over a main layer without the need of a personal input device? I am not that familiar with the input device layer in the kernel, and this is my first attempt on creating something for it, so I might have missed something. ;) Yes, I think the driver should just create an input device. You may provide a generic implementation for a polled button and have driver instantiate it but I do not think that a single RFkill button device is needed - you won't have too many of them in a single system anyway (I think you will normally have 1, 2 at the most). Ok, this is something that can be added as notice in the rfkill description to make sure drivers which supports keys that handle the radio event themselves should handle everything themselves and just use the KEY_RFKILL event for the input device. 3. A device without transmitter but with a button - just register with input core. Userspace will have to manage state of other devices with transmitters in response to button presses. This is clear too. Rfkill is only intended for drivers that control a device with a transmitter (WiFi, Bluetooth, IRDA) that have a button that is intended to do something with the radio/transmitter. Does this make sense? Yes, this was what I intended to do with rfkill, so at that point we have the same goal. I think it is almost the same. I also want support RF devices that can control radio state but lack a button. This is covered by mixing 2) and 3) in kernel and for userspace looks exactly like 2) with a button. Ok, this means making the change in rfkill to instead support 1) and 2) and change it into 2) and 3) that would be possible and would make it possible again to change the radio state to something different then the key indicates. That was previously removed because of support for 1) devices. ... I don't think a config option is a good idea unless by config option you mean a sysfs attribute. I indeed meant a sysfs attribute. I should have been more clear on this. :) OK :) Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Wednesday 06 December 2006 15:37, Dmitry Torokhov wrote: On 12/4/06, Ivo van Doorn [EMAIL PROTECTED] wrote: I am still not sure that tight coupling of input device with rfkill structure is such a good idea. Quite often the button is separated from the device itself and radio control is done via BIOS SMM (see wistron driver) or there is no special button at all and users might want to assign one of their standard keyboard buttons to be an RF switch. Making sure rfkill supports keys that are not handled by the driver is a bit hard. Just as drivers that can only check if the button is toggled and not what the current state is. The problem is that it is hard to make a clean split between the 2 different button controls. Not all drivers allow the radio to be enabled while the button status are indicating the radio should be off. If they do not allow controlling the state of the radio programmatically then it should not be part of rfkill I am afraid. It is like the power switch - if you hold it for so long it kills the power to the box and there is nothing you can do about it. Ok, this will give rfkill more possibilities as I could in that case also allow the user to toggle the radio to the state that is different than indicated by the key. Currently this was not possible since I had to keep in mind that there were keys that would directly control the radio. The buttons that are already integrated into the keyboard, by example by using a Fn key combo don't control the device directly. So the driver cannot offer anything to the rfkill driver. Such buttons should be mapped in userspace without the help of rfkill, since the kernel cannot detect if that key belonged to a radio control key or not. That is my point. Given the fact that there are keys that are not directly connected with the radio switch userspace will have to handle them (wait for events then turn off radios somehow). You are advocating that userspace should also implement 2nd method for buttons that belong to rfkill interface. I do not understand the need for 2nd interface. If you separate radio switch from button code then userspace only need to implement 1st interface and be done with it. You will have set of cards that provide interface to enable/disable their transmitters and set of buttons that signal userspace desired state change. If both switch and button is implemented by the same driver then the driver can implement automatic button handling. Otherwise userspace help is necessary. Well there are 3 possible hardware key approaches: 1 - Hardware key that controls the hardware radio, and does not report anything to userspace 2 - Hardware key that does not control the hardware radio and does not report anything to userspace 3 - Hardware key that does not control the hardware radio and reports the key to userspace So rfkill should not be used in the case of (1) and (3), but we still need something to support (2) or should the keys not be handled by userspace and always by the driver? This is making rfkill moving slowly away from the generic approach for all rfkill keys as the initial intention was. attribute should be a tri-state on/off/auto, auto meaning the driver itself manages radio state. This would avoid another tacky IMHO point that in your implementation mere opening of an input device takes over RF driver. Explicit control allow applications snoop RF state without disturbing it. Currently userspace can always check the state of the button whenever they like by checking the sysfs entry. Unless the key is not directly connected to the driver (so there is no sysfs entry). Again you force 2 different interfaces. Ok, so input device opening should not block the rfkill signal and the rfkill handler should still go through with its work unless a different config option indicates that userspace wants to handle the event. Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] rfkill - Add support for input key to control wireless radio
Hi, That is my point. Given the fact that there are keys that are not directly connected with the radio switch userspace will have to handle them (wait for events then turn off radios somehow). You are advocating that userspace should also implement 2nd method for buttons that belong to rfkill interface. I do not understand the need for 2nd interface. If you separate radio switch from button code then userspace only need to implement 1st interface and be done with it. You will have set of cards that provide interface to enable/disable their transmitters and set of buttons that signal userspace desired state change. If both switch and button is implemented by the same driver then the driver can implement automatic button handling. Otherwise userspace help is necessary. Well there are 3 possible hardware key approaches: 1 - Hardware key that controls the hardware radio, and does not report anything to userspace Can't do anything here so just ignore it. Ok. 2 - Hardware key that does not control the hardware radio and does not report anything to userspace Kind of uninteresting button ;) And this is the button that rfkill was originally designed for. Laptops with integrated WiFi cards from Ralink have a hardware button that don't send anything to userspace (unless the ACPI event is read) and does not directly control the radio itself. 3 - Hardware key that does not control the hardware radio and reports the key to userspace So rfkill should not be used in the case of (1) and (3), but we still need something to support (2) or should the keys not be handled by userspace and always by the driver? This is making rfkill moving slowly away from the generic approach for all rfkill keys as the initial intention was. I my vision rfkill would represent userspace namageable radio switch. We have the followng possible configurations: 1. A device that does not allow controlling its transmitter from userspace. The driver should not use/register with rfkill subsystem as userspace can't do anyhting with it. If device has a button killing the transmitter the driver can still signal userspace appropriate event (KEY_WIFI, KEY_BLUETOOTH, etc) if it can detect that button was presssed so userspace can monitor state of the transmitter and probably shut down other transmitters to keep everything in sync. And this event should be reported by a generic approach right? So it should be similar as with your point 2 below. But this would mean that the driver should create the input device. Or can a driver send the KEY_WIFI event over a main layer without the need of a personal input device? I am not that familiar with the input device layer in the kernel, and this is my first attempt on creating something for it, so I might have missed something. ;) Because it could still register with rfkill, only not give the callback functions for changing the radio or polling. Then the driver can use the send_event function to inform rfkill of the event and process it further. The sysfs attributes could even be reduced to only add the change_status attribute when the radio_enable and radio_disable callback functions are implemented. 2. A device that does allow controlling its transmitter. The driver may (should) register with rfkill subsystem. Additionally, if there is a button, the driver should register it with input subsystem. Driver should manage transmitter state in response to button presses unless userspace takes over the process. This is indeed the main goal of rfkill. :) 3. A device without transmitter but with a button - just register with input core. Userspace will have to manage state of other devices with transmitters in response to button presses. This is clear too. Rfkill is only intended for drivers that control a device with a transmitter (WiFi, Bluetooth, IRDA) that have a button that is intended to do something with the radio/transmitter. Does this make sense? Yes, this was what I intended to do with rfkill, so at that point we have the same goal. attribute should be a tri-state on/off/auto, auto meaning the driver itself manages radio state. This would avoid another tacky IMHO point that in your implementation mere opening of an input device takes over RF driver. Explicit control allow applications snoop RF state without disturbing it. Currently userspace can always check the state of the button whenever they like by checking the sysfs entry. Unless the key is not directly connected to the driver (so there is no sysfs entry). Again you force 2 different interfaces. Ok, so input device opening should not block the rfkill signal and the rfkill handler should still go through with its work unless a different config option indicates that userspace wants to handle the event. I don't think a config option is a good idea unless by config option
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Tuesday 05 December 2006 11:32, Christoph Hellwig wrote:
+/*
+ * Function called by the key driver when the rfkill structure
+ * needs to be registered.
+ */
+int rfkill_register_key(struct rfkill *rfkill, int init_status)
+{
+ struct rfkill_type *type = master-type[rfkill-key_type];
+ struct rfkill_key *key;
+ int status;
+
+ if (!rfkill)
+ return -EINVAL;
+
+ if (rfkill-key_type = KEY_TYPE_MAX)
+ return -EINVAL;
+
+ /*
+* Increase module use count to prevent this
+* module to be unloaded while there are still
+* registered keys.
+*/
+ if (!try_module_get(THIS_MODULE))
+ return -EBUSY;
This is obviously broken. Please add a struct module *owner;
field to struct rfkill instead.
Thanks, will fix this asap.
Ivo
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] rfkill - Add support for input key to control wireless radio
[snip]
+/*
+ * Function called by the key driver to report the new status
+ * of the key.
+ */
+void rfkill_report_event(struct rfkill *rfkill, int new_status)
+{
+ mutex_lock(master-mutex);
+
+ if (rfkill_check_key(rfkill-key, new_status))
+ schedule_work(master-toggle_work);
+
+ mutex_unlock(master-mutex);
+}
+EXPORT_SYMBOL_GPL(rfkill_report_event);
Please use kernel-doc notation for non-static functions.
See Documentation/kernel-doc-nano-HOWTO.txt for more info.
All kernel-doc notations were placed in the rfkill.h header.
I'll move them to the rfkill.c file.
[snip]
+ * @rfkill: rfkill structure to be deregistered
+ * @init_status: initial status of the key at the time this function is
called
+ *
+ * This function should be called by the key driver when the rfkill
structure
+ * needs to be registered. Immediately from registration the key driver
+ * should be able to receive calls through the poll, enable_radio and
+ * disable_radio handlers if those were registered.
+ */
+int rfkill_register_key(struct rfkill *rfkill, int init_status);
+
+/**
+ * rfkill_deregister_key - Deregister a previously registered rfkill
structre.
structure
Thanks for the pointers. I'll fix them asap.
Ivo
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] rfkill - Add support for input key to control wireless radio
Hi, This patch is a resend of a patch I has been send to the linux kernel and netdev list earlier. The most recent version of a few weeks back didn't compile since I missed 1 line in my patch that changed include/linux/input.h. This patch will offer the handling of radiokeys on a laptop. Such keys often control the wireless devices on the radio like the wifi, bluetooth and irda. The rfkill works as follows, when the user presses the hardware key to control the wireless (wifi, bluetooth or irda) radio a signal will go to rfkill. This happens by the hardware driver sending a signal to rfkill, or rfkill polling for the button status. The key signal will then be processed by rfkill, each key will have its own input device, if this input device has not been openened by the user, rfkill will keep the signal and either turn the radio on or off based on the key status. If the input device has been opened, rfkill will send the signal to userspace and do nothing further. The user is in charge of controlling the radio. This driver (if accepted and applied) will be usefull for the rt2x00 drivers (rt2400pci, rt2500pci, rt2500usb, rt61pci and rt73usb) in the wireless-dev tree and the MSI laptop driver from Lennart Poettering in the main linux kernel tree. Before this patch can be applied to any tree, I first wish to hear if the patch is acceptable. Since the previous time it was send I have made several fixes based on the feedback like adding the sysfs entries for reading the status. Hi Ivo, I apologize for not responding to your post earlier, it was a busy week. No problem, it didn't compile anyway. And this time I have CC'ed all people that have previously shown interest in rfkill, so they are now updated about rfkill as well. ;) I am still not sure that tight coupling of input device with rfkill structure is such a good idea. Quite often the button is separated from the device itself and radio control is done via BIOS SMM (see wistron driver) or there is no special button at all and users might want to assign one of their standard keyboard buttons to be an RF switch. Making sure rfkill supports keys that are not handled by the driver is a bit hard. Just as drivers that can only check if the button is toggled and not what the current state is. The problem is that it is hard to make a clean split between the 2 different button controls. Not all drivers allow the radio to be enabled while the button status are indicating the radio should be off. The buttons that are already integrated into the keyboard, by example by using a Fn key combo don't control the device directly. So the driver cannot offer anything to the rfkill driver. Such buttons should be mapped in userspace without the help of rfkill, since the kernel cannot detect if that key belonged to a radio control key or not. I think it would be better if there was an rfkill class listing all controlled devices (preferrably grouped by their type - WiFi, BT, IRDA, etc) and if every group would provide an attribute allowing to control state of the whole group (do we realistically need to kill just one interface? Wouldn't ifconfig be suitable for that?). The There have been mixed feelings on the netdev list about what should exactly happen when the button is pressed. The possible options are: 1 - rfkill will kill all interfaces 2 - rfkill will kill all interfaces of the same type (wifi, bt, irda) 3 - rfkill will kill the interface it belongs to Personally I would favour the second option, but used the third after hearing objections to the second method. So since there are also fans of the third option I think there should be a decision made about what the correct option is, so rfkill can follow that method. attribute should be a tri-state on/off/auto, auto meaning the driver itself manages radio state. This would avoid another tacky IMHO point that in your implementation mere opening of an input device takes over RF driver. Explicit control allow applications snoop RF state without disturbing it. Currently userspace can always check the state of the button whenever they like by checking the sysfs entry. If there are concerns that drivers will have to re-implement most of the button handling you are still free to create a simple implementation of polled RF button (I don't think that interrupt driver RF buttons would share alot of code) so that users would only need to implement a polling function. Isn't the current interface to the driver not clean enough? It only asks for the (optional) poll method, and the enable/disable method. I believe this should not add too much code into the drivers, especially when all methods are optional. Ivo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/26] rt2x00: device IDs
Add new rt2500usb and rt73usb device id numbers.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-base/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
wireless-dev-base-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
--- wireless-dev-base/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-12-03 16:04:27.0 +0100
+++ wireless-dev-base-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-12-03 16:04:14.0 +0100
@@ -2888,6 +2888,8 @@
{ USB_DEVICE(0x148f, 0x2570) },
{ USB_DEVICE(0x148f, 0x2573) },
{ USB_DEVICE(0x148f, 0x9020) },
+ /* Siemens */
+ { USB_DEVICE(0x0681, 0x3c06) },
/* SMC */
{ USB_DEVICE(0x0707, 0xee13) },
/* Spairon */
Only in wireless-dev-base-rt2x00/drivers/net/wireless/d80211/rt2x00:
rt2500usb.c.orig
diff -rU3 wireless-dev-base/drivers/net/wireless/d80211/rt2x00/rt73usb.c
wireless-dev-base-rt2x00/drivers/net/wireless/d80211/rt2x00/rt73usb.c
--- wireless-dev-base/drivers/net/wireless/d80211/rt2x00/rt73usb.c
2006-12-03 16:04:27.0 +0100
+++ wireless-dev-base-rt2x00/drivers/net/wireless/d80211/rt2x00/rt73usb.c
2006-12-03 16:04:14.0 +0100
@@ -3219,9 +3219,20 @@
DRV_NAME - DRV_VERSION ( DRV_RELDATE ) by DRV_PROJECT;
static struct usb_device_id rt73usb_device_table[] = {
+ /* AboCom */
+ { USB_DEVICE(0x07b8, 0xb21d) },
+ /* Askey */
+ { USB_DEVICE(0x1690, 0x0722) },
+ /* ASUS */
+ { USB_DEVICE(0x0b05, 0x1723) },
/* Belkin */
{ USB_DEVICE(0x050d, 0x7050) },
{ USB_DEVICE(0x050d, 0x705a) },
+ /* Billionton */
+ { USB_DEVICE(0x1631, 0xc019) },
+ /* CNet */
+ { USB_DEVICE(0x1371, 0x9022) },
+ { USB_DEVICE(0x1371, 0x9032) },
/* Conceptronic */
{ USB_DEVICE(0x14b2, 0x3c22) },
/* D-Link */
@@ -3229,18 +3240,29 @@
{ USB_DEVICE(0x07d1, 0x3c04) },
/* Gigabyte */
{ USB_DEVICE(0x1044, 0x8008) },
+ { USB_DEVICE(0x1044, 0x800a) },
+ /* Huawei-3Com */
+ { USB_DEVICE(0x1472, 0x0009) },
+ /* Hercules */
+ { USB_DEVICE(0x06f8, 0xe010) },
/* Linksys */
{ USB_DEVICE(0x13b1, 0x0020) },
+ { USB_DEVICE(0x13b1, 0x0023) },
/* MSI */
{ USB_DEVICE(0x0db0, 0x6877) },
+ { USB_DEVICE(0x0db0, 0xa861) },
{ USB_DEVICE(0x0db0, 0xa874) },
/* Ralink */
{ USB_DEVICE(0x148f, 0x2573) },
{ USB_DEVICE(0x148f, 0x2671) },
/* Qcom */
{ USB_DEVICE(0x18e8, 0x6196) },
+ { USB_DEVICE(0x18e8, 0x6229) },
/* Sitecom */
{ USB_DEVICE(0x0df6, 0x9712) },
+ { USB_DEVICE(0x0df6, 0x90ac) },
+ /* Surecom */
+ { USB_DEVICE(0x0769, 0x31f3) },
{ 0, }
};
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 22/26] rt2x00: Fix various initialization problems
Always use kzalloc instead of kmalloc.
Remove duplicate init functions.
And destroy the workqueue before freeing
resources, otherwise a thread on the queue might
still want to access that resource.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-ringfull/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-init/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-ringfull/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-12-03 15:14:07.0 +0100
+++ wireless-dev-init/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-12-03 15:21:22.0 +0100
@@ -771,7 +771,7 @@
/*
* Allocate all ring entries.
*/
- ring-entry = kmalloc(ring-stats.limit * sizeof(struct data_entry),
+ ring-entry = kzalloc(ring-stats.limit * sizeof(struct data_entry),
GFP_KERNEL);
if (!ring-entry)
return -ENOMEM;
@@ -791,6 +791,7 @@
* addresses.
*/
for (i = 0; i ring-stats.limit; i++) {
+ ring-entry[i].flags = 0;
ring-entry[i].ring = ring;
ring-entry[i].skb = NULL;
ring-entry[i].priv = ring-data_addr
@@ -1174,16 +1175,6 @@
}
/*
-* Initialize all registers.
-*/
- if (rt2400pci_init_rings(rt2x00dev) ||
- rt2400pci_init_registers(rt2x00dev) ||
- rt2400pci_init_bbp(rt2x00dev)) {
- ERROR(Register initialization failed.\n);
- goto exit_fail;
- }
-
- /*
* Reset the channel_change_time value
* to make sure it will be correctly initialized
* after the radio has been enabled.
@@ -2677,6 +2668,14 @@
static void rt2400pci_free_dev(struct rt2x00_dev *rt2x00dev)
{
/*
+* Free workqueue.
+*/
+ if (likely(rt2x00dev-workqueue)) {
+ destroy_workqueue(rt2x00dev-workqueue);
+ rt2x00dev-workqueue = NULL;
+ }
+
+ /*
* Free ring structures.
*/
kfree(rt2x00dev-ring);
@@ -2696,14 +2695,6 @@
}
/*
-* Free workqueue.
-*/
- if (likely(rt2x00dev-workqueue)) {
- destroy_workqueue(rt2x00dev-workqueue);
- rt2x00dev-workqueue = NULL;
- }
-
- /*
* Free ieee80211_hw memory.
*/
if (likely(rt2x00dev-hw-modes)) {
diff -rU3 wireless-dev-ringfull/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
wireless-dev-init/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
--- wireless-dev-ringfull/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-12-03 15:14:05.0 +0100
+++ wireless-dev-init/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-12-03 15:21:27.0 +0100
@@ -864,7 +864,7 @@
/*
* Allocate all ring entries.
*/
- ring-entry = kmalloc(ring-stats.limit * sizeof(struct data_entry),
+ ring-entry = kzalloc(ring-stats.limit * sizeof(struct data_entry),
GFP_KERNEL);
if (!ring-entry)
return -ENOMEM;
@@ -884,6 +884,7 @@
* addresses.
*/
for (i = 0; i ring-stats.limit; i++) {
+ ring-entry[i].flags = 0;
ring-entry[i].ring = ring;
ring-entry[i].skb = NULL;
ring-entry[i].priv = ring-data_addr
@@ -1299,16 +1300,6 @@
}
/*
-* Initialize all registers.
-*/
- if (rt2500pci_init_rings(rt2x00dev) ||
- rt2500pci_init_registers(rt2x00dev) ||
- rt2500pci_init_bbp(rt2x00dev)) {
- ERROR(Register initialization failed.\n);
- goto exit_fail;
- }
-
- /*
* Reset the channel_change_time value
* to make sure it will be correctly initialized
* after the radio has been enabled.
@@ -2978,6 +2969,14 @@
static void rt2500pci_free_dev(struct rt2x00_dev *rt2x00dev)
{
/*
+* Free workqueue.
+*/
+ if (likely(rt2x00dev-workqueue)) {
+ destroy_workqueue(rt2x00dev-workqueue);
+ rt2x00dev-workqueue = NULL;
+ }
+
+ /*
* Free ring structures.
*/
kfree(rt2x00dev-ring);
@@ -2997,14 +2996,6 @@
}
/*
-* Free workqueue.
-*/
- if (likely(rt2x00dev-workqueue)) {
- destroy_workqueue(rt2x00dev-workqueue);
- rt2x00dev-workqueue = NULL;
- }
-
- /*
* Free ieee80211_hw memory.
*/
if (likely(rt2x00dev-hw-modes)) {
diff -rU3 wireless-dev-ringfull/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
wireless-dev-init/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
--- wireless-dev-ringfull/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-12-03 15:14:10.0 +0100
+++ wireless-dev-init/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-12-03 15:21:33.0
[PATCH 19/26] rt2x00: Fix channel_change_time calculation
Correctly initialize the channel_change_time. Make sure that channel is reset afterwards, otherwise the channel is not correctly initialized and rx/tx will fail. Signed-off-by Ivo van Doorn [EMAIL PROTECTED] --- diff -rU3 wireless-dev-mac/drivers/net/wireless/d80211/rt2x00/rt2400pci.c wireless-dev-channel/drivers/net/wireless/d80211/rt2x00/rt2400pci.c --- wireless-dev-mac/drivers/net/wireless/d80211/rt2x00/rt2400pci.c 2006-12-03 14:45:46.0 +0100 +++ wireless-dev-channel/drivers/net/wireless/d80211/rt2x00/rt2400pci.c 2006-12-03 14:52:04.0 +0100 @@ -1124,6 +1124,19 @@ unsigned long jiffies_end; /* +* Only initialize the channel_change_time +* if it has not been set previously. +*/ + if (rt2x00dev-hw-channel_change_time) + return 0; + + /* +* Invalidate the rx_params.channel value to make sure +* the config channel will be correctly executed. +*/ + rt2x00dev-rx_params.channel = 0; + + /* * Determine channel_change_time * by measuring the time it takes * to switch the channel. @@ -1171,10 +1184,11 @@ } /* -* Determine channel change time. +* Reset the channel_change_time value +* to make sure it will be correctly initialized +* after the radio has been enabled. */ - if (rt2400pci_init_channel_time(rt2x00dev)) - goto exit_fail; + rt2x00dev-hw-channel_change_time = 0; /* * Register interrupt handler. diff -rU3 wireless-dev-mac/drivers/net/wireless/d80211/rt2x00/rt2500pci.c wireless-dev-channel/drivers/net/wireless/d80211/rt2x00/rt2500pci.c --- wireless-dev-mac/drivers/net/wireless/d80211/rt2x00/rt2500pci.c 2006-12-03 14:46:09.0 +0100 +++ wireless-dev-channel/drivers/net/wireless/d80211/rt2x00/rt2500pci.c 2006-12-03 14:52:32.0 +0100 @@ -1248,6 +1248,19 @@ unsigned long jiffies_end; /* +* Only initialize the channel_change_time +* if it has not been set previously. +*/ + if (rt2x00dev-hw-channel_change_time) + return 0; + + /* +* Invalidate the rx_params.channel value to make sure +* the config channel will be correctly executed. +*/ + rt2x00dev-rx_params.channel = 0; + + /* * Determine channel_change_time * by measuring the time it takes * to switch the channel. @@ -1296,10 +1309,11 @@ } /* -* Determine channel change time. +* Reset the channel_change_time value +* to make sure it will be correctly initialized +* after the radio has been enabled. */ - if (rt2500pci_init_channel_time(rt2x00dev)) - goto exit_fail; + rt2x00dev-hw-channel_change_time = 0; /* * Register interrupt handler. diff -rU3 wireless-dev-mac/drivers/net/wireless/d80211/rt2x00/rt2500usb.c wireless-dev-channel/drivers/net/wireless/d80211/rt2x00/rt2500usb.c --- wireless-dev-mac/drivers/net/wireless/d80211/rt2x00/rt2500usb.c 2006-12-03 14:46:19.0 +0100 +++ wireless-dev-channel/drivers/net/wireless/d80211/rt2x00/rt2500usb.c 2006-12-03 14:52:36.0 +0100 @@ -1214,6 +1214,19 @@ unsigned long jiffies_end; /* +* Only initialize the channel_change_time +* if it has not been set previously. +*/ + if (rt2x00dev-hw-channel_change_time) + return 0; + + /* +* Invalidate the rx_params.channel value to make sure +* the config channel will be correctly executed. +*/ + rt2x00dev-rx_params.channel = 0; + + /* * Determine channel_change_time * by measuring the time it takes * to switch the channel. @@ -1262,10 +1275,11 @@ } /* -* Determine channel change time. +* Reset the channel_change_time value +* to make sure it will be correctly initialized +* after the radio has been enabled. */ - if (rt2500usb_init_channel_time(rt2x00dev)) - goto exit_fail; + rt2x00dev-hw-channel_change_time = 0; SET_FLAG(rt2x00dev, DEVICE_INITIALIZED); diff -rU3 wireless-dev-mac/drivers/net/wireless/d80211/rt2x00/rt61pci.c wireless-dev-channel/drivers/net/wireless/d80211/rt2x00/rt61pci.c --- wireless-dev-mac/drivers/net/wireless/d80211/rt2x00/rt61pci.c 2006-12-03 14:46:31.0 +0100 +++ wireless-dev-channel/drivers/net/wireless/d80211/rt2x00/rt61pci.c 2006-12-03 14:52:40.0 +0100 @@ -1681,6 +1681,19 @@ unsigned long jiffies_end; /* +* Only initialize the channel_change_time +* if it has not been set previously. +*/ + if (rt2x00dev-hw-channel_change_time) + return 0; + + /* +* Invalidate the rx_params.channel value to make sure
[PATCH 26/26] rt2x00: Move CRC into seperate module
Move the crc handling of rt61pci and rt73usb into a seperate module.
This will create the crc-itu-t module inside the rt2x00 folder.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rNU3 wireless-dev-base/drivers/net/wireless/d80211/rt2x00/Kconfig
wireless-dev-crc/drivers/net/wireless/d80211/rt2x00/Kconfig
--- wireless-dev-base/drivers/net/wireless/d80211/rt2x00/Kconfig
2006-12-03 16:13:58.0 +0100
+++ wireless-dev-crc/drivers/net/wireless/d80211/rt2x00/Kconfig 2006-12-03
16:17:48.0 +0100
@@ -40,6 +40,7 @@
config RT61PCI
tristate Ralink rt61 pci/pcmcia support
depends on RT2X00 FW_LOADER PCI
+ select CRC_ITU_T
select EEPROM_93CX6
---help---
This is an experimental driver for the Ralink rt61 wireless chip.
@@ -69,6 +70,7 @@
config RT73USB
tristate Ralink rt73 usb support
depends on RT2X00 FW_LOADER USB
+ select CRC_ITU_T
---help---
This is an experimental driver for the Ralink rt73 wireless chip.
@@ -88,3 +90,11 @@
These chipsets are found inside the Ralink wireless cards.
When compiled as a module, this driver will be called eeprom_93c6.ko.
+
+config CRC_ITU_T
+ tristate CRC ITU-T V.41 functions
+ help
+ This option is provided for the case where no in-kernel-tree
+ modules require CRC ITU-T V.41 functions, but a module built outside
+ the kernel tree does. Such modules that use library CRC ITU-T V.41
+ functions require M here.
diff -rNU3 wireless-dev-base/drivers/net/wireless/d80211/rt2x00/Makefile
wireless-dev-crc/drivers/net/wireless/d80211/rt2x00/Makefile
--- wireless-dev-base/drivers/net/wireless/d80211/rt2x00/Makefile
2006-12-03 16:13:58.0 +0100
+++ wireless-dev-crc/drivers/net/wireless/d80211/rt2x00/Makefile
2006-12-03 16:17:19.0 +0100
@@ -3,4 +3,5 @@
obj-$(CONFIG_RT61PCI) += rt61pci.o
obj-$(CONFIG_RT2500USB)+= rt2500usb.o
obj-$(CONFIG_RT73USB) += rt73usb.o
+obj-$(CONFIG_CRC_ITU_T)+= crc-itu-t.o
obj-$(CONFIG_EEPROM_93CX6) += eeprom_93cx6.o
diff -rNU3 wireless-dev-base/drivers/net/wireless/d80211/rt2x00/crc-itu-t.c
wireless-dev-crc/drivers/net/wireless/d80211/rt2x00/crc-itu-t.c
--- wireless-dev-base/drivers/net/wireless/d80211/rt2x00/crc-itu-t.c
1970-01-01 01:00:00.0 +0100
+++ wireless-dev-crc/drivers/net/wireless/d80211/rt2x00/crc-itu-t.c
2006-12-03 16:15:35.0 +0100
@@ -0,0 +1,66 @@
+/*
+ * crc-itu-t.c
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2. See the file COPYING for more details.
+ */
+
+#include linux/types.h
+#include linux/module.h
+
+#include crc-itu-t.h
+
+MODULE_AUTHOR(http://rt2x00.serialmonkey.com;);
+MODULE_DESCRIPTION(CRC ITU-T V.41 calculations);
+MODULE_LICENSE(GPL);
+
+/** CRC table for the CRC ITU-T V.41 0x0x1021 (x^16 + x^12 + x^15 + 1) */
+const u16 crc_itu_t_table[256] = {
+ 0x, 0x1021, 0x2042, 0x3063, 0x4084, 0x50a5, 0x60c6, 0x70e7,
+ 0x8108, 0x9129, 0xa14a, 0xb16b, 0xc18c, 0xd1ad, 0xe1ce, 0xf1ef,
+ 0x1231, 0x0210, 0x3273, 0x2252, 0x52b5, 0x4294, 0x72f7, 0x62d6,
+ 0x9339, 0x8318, 0xb37b, 0xa35a, 0xd3bd, 0xc39c, 0xf3ff, 0xe3de,
+ 0x2462, 0x3443, 0x0420, 0x1401, 0x64e6, 0x74c7, 0x44a4, 0x5485,
+ 0xa56a, 0xb54b, 0x8528, 0x9509, 0xe5ee, 0xf5cf, 0xc5ac, 0xd58d,
+ 0x3653, 0x2672, 0x1611, 0x0630, 0x76d7, 0x66f6, 0x5695, 0x46b4,
+ 0xb75b, 0xa77a, 0x9719, 0x8738, 0xf7df, 0xe7fe, 0xd79d, 0xc7bc,
+ 0x48c4, 0x58e5, 0x6886, 0x78a7, 0x0840, 0x1861, 0x2802, 0x3823,
+ 0xc9cc, 0xd9ed, 0xe98e, 0xf9af, 0x8948, 0x9969, 0xa90a, 0xb92b,
+ 0x5af5, 0x4ad4, 0x7ab7, 0x6a96, 0x1a71, 0x0a50, 0x3a33, 0x2a12,
+ 0xdbfd, 0xcbdc, 0xfbbf, 0xeb9e, 0x9b79, 0x8b58, 0xbb3b, 0xab1a,
+ 0x6ca6, 0x7c87, 0x4ce4, 0x5cc5, 0x2c22, 0x3c03, 0x0c60, 0x1c41,
+ 0xedae, 0xfd8f, 0xcdec, 0xddcd, 0xad2a, 0xbd0b, 0x8d68, 0x9d49,
+ 0x7e97, 0x6eb6, 0x5ed5, 0x4ef4, 0x3e13, 0x2e32, 0x1e51, 0x0e70,
+ 0xff9f, 0xefbe, 0xdfdd, 0xcffc, 0xbf1b, 0xaf3a, 0x9f59, 0x8f78,
+ 0x9188, 0x81a9, 0xb1ca, 0xa1eb, 0xd10c, 0xc12d, 0xf14e, 0xe16f,
+ 0x1080, 0x00a1, 0x30c2, 0x20e3, 0x5004, 0x4025, 0x7046, 0x6067,
+ 0x83b9, 0x9398, 0xa3fb, 0xb3da, 0xc33d, 0xd31c, 0xe37f, 0xf35e,
+ 0x02b1, 0x1290, 0x22f3, 0x32d2, 0x4235, 0x5214, 0x6277, 0x7256,
+ 0xb5ea, 0xa5cb, 0x95a8, 0x8589, 0xf56e, 0xe54f, 0xd52c, 0xc50d,
+ 0x34e2, 0x24c3, 0x14a0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405,
+ 0xa7db, 0xb7fa, 0x8799, 0x97b8, 0xe75f, 0xf77e, 0xc71d, 0xd73c,
+ 0x26d3, 0x36f2, 0x0691, 0x16b0, 0x6657, 0x7676, 0x4615, 0x5634,
+ 0xd94c, 0xc96d, 0xf90e, 0xe92f, 0x99c8, 0x89e9, 0xb98a, 0xa9ab,
+ 0x5844, 0x4865, 0x7806, 0x6827, 0x18c0, 0x08e1, 0x3882, 0x28a3,
+ 0xcb7d, 0xdb5c, 0xeb3f, 0xfb1e, 0x8bf9, 0x9bd8, 0xabbb, 0xbb9a,
+ 0x4a75, 0x5a54, 0x6a37, 0x7a16, 0x0af1
[PATCH 10/26] rt2x00: WMM ring priority
rt61pci and rt73usb have the WMM ring priorities
backwards. RING_AC_VO is the most important ring
while RING_AC_BK the least important ring.
Lets reorder the ring handling.
(And fix some small typos in the comments regarding
the rings)
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-usbeeprom/drivers/net/wireless/d80211/rt2x00/rt2400pci.h
wireless-dev-ringindex/drivers/net/wireless/d80211/rt2x00/rt2400pci.h
--- wireless-dev-usbeeprom/drivers/net/wireless/d80211/rt2x00/rt2400pci.h
2006-12-03 12:49:55.0 +0100
+++ wireless-dev-ringindex/drivers/net/wireless/d80211/rt2x00/rt2400pci.h
2006-12-03 13:04:38.0 +0100
@@ -870,7 +870,7 @@
#define RXD_W7_RESERVEDFIELD32(0x)
/*
- * TX ring index number for rt2x00_pci structure.
+ * TX ring index number for rt2x00_dev structure.
*/
enum ring_index {
RING_PRIO = 0,
diff -rU3 wireless-dev-usbeeprom/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
wireless-dev-ringindex/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
--- wireless-dev-usbeeprom/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
2006-12-03 12:50:28.0 +0100
+++ wireless-dev-ringindex/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
2006-12-03 13:04:44.0 +0100
@@ -1145,7 +1145,7 @@
#define RXD_W10_DROP FIELD32(0x0001)
/*
- * TX ring index number for rt2x00_pci structure.
+ * TX ring index number for rt2x00_dev structure.
*/
enum ring_index {
RING_PRIO = 0,
diff -rU3 wireless-dev-usbeeprom/drivers/net/wireless/d80211/rt2x00/rt2500usb.h
wireless-dev-ringindex/drivers/net/wireless/d80211/rt2x00/rt2500usb.h
--- wireless-dev-usbeeprom/drivers/net/wireless/d80211/rt2x00/rt2500usb.h
2006-12-03 13:00:52.0 +0100
+++ wireless-dev-ringindex/drivers/net/wireless/d80211/rt2x00/rt2500usb.h
2006-12-03 13:04:50.0 +0100
@@ -652,7 +652,7 @@
#define RXD_W3_EIV FIELD32(0x)
/*
- * TX ring index number for rt2x00_usb structure.
+ * TX ring index number for rt2x00_dev structure.
*/
enum ring_index {
RING_PRIO = 0,
diff -rU3 wireless-dev-usbeeprom/drivers/net/wireless/d80211/rt2x00/rt61pci.c
wireless-dev-ringindex/drivers/net/wireless/d80211/rt2x00/rt61pci.c
--- wireless-dev-usbeeprom/drivers/net/wireless/d80211/rt2x00/rt61pci.c
2006-12-03 12:48:43.0 +0100
+++ wireless-dev-ringindex/drivers/net/wireless/d80211/rt2x00/rt61pci.c
2006-12-03 13:08:21.0 +0100
@@ -1320,16 +1320,16 @@
if (rt61pci_alloc_dma_ring(rt2x00dev, RING_RX,
rt61pci_rxdone, RX_ENTRIES, DATA_FRAME_SIZE,
RXD_DESC_SIZE) ||
- rt61pci_alloc_dma_ring(rt2x00dev, RING_AC_BK,
+ rt61pci_alloc_dma_ring(rt2x00dev, RING_AC_VO,
rt61pci_txdone, TX_ENTRIES, DATA_FRAME_SIZE,
TXD_DESC_SIZE) ||
- rt61pci_alloc_dma_ring(rt2x00dev, RING_AC_BE,
+ rt61pci_alloc_dma_ring(rt2x00dev, RING_AC_VI,
rt61pci_txdone, TX_ENTRIES, DATA_FRAME_SIZE,
TXD_DESC_SIZE) ||
- rt61pci_alloc_dma_ring(rt2x00dev, RING_AC_VI,
+ rt61pci_alloc_dma_ring(rt2x00dev, RING_AC_BE,
rt61pci_txdone, TX_ENTRIES, DATA_FRAME_SIZE,
TXD_DESC_SIZE) ||
- rt61pci_alloc_dma_ring(rt2x00dev, RING_AC_VO,
+ rt61pci_alloc_dma_ring(rt2x00dev, RING_AC_BK,
rt61pci_txdone, TX_ENTRIES, DATA_FRAME_SIZE,
TXD_DESC_SIZE) ||
rt61pci_alloc_dma_ring(rt2x00dev, RING_PRIO,
@@ -1347,10 +1347,10 @@
static void rt61pci_free_rings(struct rt2x00_dev *rt2x00dev)
{
rt61pci_free_ring(rt2x00dev, RING_RX);
- rt61pci_free_ring(rt2x00dev, RING_AC_BK);
- rt61pci_free_ring(rt2x00dev, RING_AC_BE);
- rt61pci_free_ring(rt2x00dev, RING_AC_VI);
rt61pci_free_ring(rt2x00dev, RING_AC_VO);
+ rt61pci_free_ring(rt2x00dev, RING_AC_VI);
+ rt61pci_free_ring(rt2x00dev, RING_AC_BE);
+ rt61pci_free_ring(rt2x00dev, RING_AC_BK);
rt61pci_free_ring(rt2x00dev, RING_PRIO);
rt61pci_free_ring(rt2x00dev, RING_BEACON);
}
@@ -1429,10 +1429,10 @@
* Initialize rings.
*/
rt61pci_init_rxring(rt2x00dev, RING_RX);
- rt61pci_init_txring(rt2x00dev, RING_AC_BK);
- rt61pci_init_txring(rt2x00dev, RING_AC_BE);
- rt61pci_init_txring(rt2x00dev, RING_AC_VI);
rt61pci_init_txring(rt2x00dev, RING_AC_VO);
+ rt61pci_init_txring(rt2x00dev, RING_AC_VI);
+ rt61pci_init_txring(rt2x00dev, RING_AC_BE);
+ rt61pci_init_txring(rt2x00dev, RING_AC_BK);
rt61pci_init_txring(rt2x00dev, RING_PRIO);
rt61pci_init_txring(rt2x00dev, RING_BEACON);
@@ -1441,40 +1441,40 @@
*/
reg = 0;
rt2x00_set_field32(reg, TX_RING_CSR0_AC0_RING_SIZE,
- rt2x00dev-ring[RING_AC_BK].stats.limit);
+ rt2x00dev-ring[RING_AC_VO].stats.limit
[PATCH 13/26] rt2x00: RX rate conversion
Each received packet has a signal field, this field
can be translated into the rate with which the frame
has been received.
Create a seperate function for this since the
conversion is equal for all drivers.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-interface/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-signal/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-interface/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-12-03 13:45:34.0 +0100
+++ wireless-dev-signal/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-12-03 13:49:47.0 +0100
@@ -1571,6 +1571,11 @@
memcpy(skb_put(skb, size), rt2x00_data_addr(entry),
size);
+ rt2x00dev-rx_params.rate = device_signal_to_rate(
+ rt2x00dev-hw-modes[0],
+ rt2x00_get_field32(word2, RXD_W2_SIGNAL),
+ 0);
+
rt2x00dev-rx_params.ssi =
rt2x00_get_field32(word2, RXD_W2_RSSI);
diff -rU3 wireless-dev-interface/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
wireless-dev-signal/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
--- wireless-dev-interface/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-12-03 13:46:02.0 +0100
+++ wireless-dev-signal/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-12-03 13:52:24.0 +0100
@@ -1728,6 +1728,11 @@
memcpy(skb_put(skb, size), rt2x00_data_addr(entry),
size);
+ rt2x00dev-rx_params.rate = device_signal_to_rate(
+ rt2x00dev-hw-modes[0],
+ rt2x00_get_field32(word2, RXD_W2_SIGNAL),
+ rt2x00_get_field32(word0, RXD_W0_OFDM));
+
rt2x00dev-rx_params.ssi =
rt2x00_get_field32(word2, RXD_W2_RSSI);
diff -rU3 wireless-dev-interface/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
wireless-dev-signal/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
--- wireless-dev-interface/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-12-03 13:46:16.0 +0100
+++ wireless-dev-signal/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-12-03 13:52:23.0 +0100
@@ -1683,6 +1683,11 @@
memcpy(skb_put(skb, size),
rt2x00_rxdata_addr(entry), size);
+ rt2x00dev-rx_params.rate = device_signal_to_rate(
+ rt2x00dev-hw-modes[0],
+ rt2x00_get_field32(word1, RXD_W1_SIGNAL),
+ rt2x00_get_field32(word0, RXD_W0_OFDM));
+
rt2x00dev-rx_params.ssi =
rt2x00_get_field32(word1, RXD_W1_RSSI);
diff -rU3 wireless-dev-interface/drivers/net/wireless/d80211/rt2x00/rt2x00.h
wireless-dev-signal/drivers/net/wireless/d80211/rt2x00/rt2x00.h
--- wireless-dev-interface/drivers/net/wireless/d80211/rt2x00/rt2x00.h
2006-12-03 13:42:23.0 +0100
+++ wireless-dev-signal/drivers/net/wireless/d80211/rt2x00/rt2x00.h
2006-12-03 13:48:57.0 +0100
@@ -1118,6 +1118,39 @@
entry-min_rssi_ack_delta = 0;
}
+static inline int device_signal_to_rate(struct ieee80211_hw_modes *mode,
+ u8 signal, u8 ofdm)
+{
+ unsigned int i;
+ u8 plcp;
+ u8 rate;
+
+ for (i = 0; i mode-num_rates; i++) {
+ /*
+* When frame was received with an OFDM bitrate,
+* the signal is the PLCP value. If it was received with
+* a CCK bitrate the signal is the rate in 0.5kbit/s.
+*/
+ if (!ofdm) {
+ rate = DEVICE_GET_RATE_FIELD(mode-rates[i].val, RATE);
+ if (rate == signal)
+ return mode-rates[i].val;
+ } else {
+ plcp = DEVICE_GET_RATE_FIELD(mode-rates[i].val, PLCP);
+ if (plcp == signal) {
+ /*
+* Check for preamble bit.
+*/
+ if (signal 0x08)
+ return mode-rates[i].val2;
+ return mode-rates[i].val;
+ }
+ }
+ }
+
+ return 0;
+}
+
/*
* Sequence number handlers.
*/
diff -rU3 wireless-dev-interface/drivers/net/wireless/d80211/rt2x00/rt61pci.c
wireless-dev-signal/drivers/net/wireless/d80211/rt2x00/rt61pci.c
--- wireless-dev-interface/drivers/net/wireless/d80211/rt2x00/rt61pci.c
2006-12-03 13:46:30.0 +0100
+++ wireless-dev-signal/drivers/net/wireless/d80211/rt2x00/rt61pci.c
2006-12-03 13:52:24.0
[PATCH 12/26] rt2x00: Interface initialization
Correctly let the non-monitor and monitor interfaces excist peacefully together. Make sure the configuration is always accurate and allows the correct packets to come through, let the interface enable the radio at the correct time etc. etc. Signed-off-by Ivo van Doorn [EMAIL PROTECTED] --- http://www.mendiosus.nl/rt2x00/12_interface.diff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/26] rt2x00: Byte ordering
Overhaul the byteordering mechanism. All byteordering happens at the reading and writing of the register/eeprom/descriptor instead of the get/set_field functions. This makes sparse very happy and reduces the errors significantly. Signed-off-by Ivo van Doorn [EMAIL PROTECTED] --- http://www.mendiosus.nl/rt2x00/05_byteorder.diff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/26] rt2x00: Put link tuning on workqueue
Put the link tuning in a workqueue, this prevents
the interrupthandlers from being busy for a too long
period and blocking new inetrrupt handling.
To do this correctly we add a link structure containing
all information regarding the link status.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-ringindex/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-linktuning/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-ringindex/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-12-03 12:46:41.0 +0100
+++ wireless-dev-linktuning/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-12-03 13:25:32.0 +0100
@@ -624,12 +624,20 @@
/*
* Link tuning
*/
-static void rt2400pci_link_tuner(struct rt2x00_dev *rt2x00dev)
+static void rt2400pci_link_tuner(void *data)
{
+ struct rt2x00_dev *rt2x00dev = data;
u8 reg;
char false_cca_delta;
/*
+* Don't perform any tuning when it is disabled
+* in the EEPROM.
+*/
+ if (GET_FLAG(rt2x00dev, CONFIG_DISABLE_LINK_TUNING))
+ return;
+
+ /*
* Read false CCA counter.
*/
rt2x00_bbp_read(rt2x00dev, 39, reg);
@@ -653,6 +661,9 @@
if (reg 0x20)
rt2x00_bbp_write(rt2x00dev, 13, reg);
}
+
+ queue_delayed_work(rt2x00dev-workqueue, rt2x00dev-link.work,
+ LINK_TUNE_INTERVAL);
}
/*
@@ -1568,16 +1579,6 @@
rt2x00_desc_write(rxd, 0, word0);
rt2x00_ring_index_inc(ring);
}
-
- /*
-* Tune link for optimal performance.
-*/
- rt2400pci_link_tuner(rt2x00dev);
-
- /*
-* Update LED.
-*/
- rt2400pci_activity_led(rt2x00dev, 0);
}
static void rt2400pci_txdone(void *data)
@@ -1885,8 +1886,11 @@
* Enable radio when this is the first
* interface that is brought up.
*/
- if (!GET_FLAG(rt2x00dev, DEVICE_ENABLED_RADIO))
+ if (!GET_FLAG(rt2x00dev, DEVICE_ENABLED_RADIO)) {
+ queue_delayed_work(rt2x00dev-workqueue,
+ rt2x00dev-link.work, LINK_TUNE_INTERVAL);
return rt2400pci_enable_radio(rt2x00dev);
+ }
return 0;
}
@@ -1908,6 +1912,9 @@
*/
rt2x00_remove_interface(rt2x00dev-interface, conf);
+ cancel_rearming_delayed_workqueue(rt2x00dev-workqueue,
+ rt2x00dev-link.work);
+
/*
* When this is a non-monitor mode,
* clear the INTERFACE_INITIALIZED FLAG to allow
@@ -2694,6 +2701,11 @@
goto exit;
/*
+* Initialize configuration work.
+*/
+ INIT_WORK(rt2x00dev-link.work, rt2400pci_link_tuner, rt2x00dev);
+
+ /*
* Reset current working type.
*/
rt2x00dev-interface.type = -EINVAL;
diff -rU3 wireless-dev-ringindex/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
wireless-dev-linktuning/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
--- wireless-dev-ringindex/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-12-03 12:47:36.0 +0100
+++ wireless-dev-linktuning/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-12-03 13:25:36.0 +0100
@@ -698,18 +698,27 @@
/*
* Link tuning
*/
-static void rt2500pci_link_tuner(struct rt2x00_dev *rt2x00dev, char rssi)
+static void rt2500pci_link_tuner(void *data)
{
+ struct rt2x00_dev *rt2x00dev = data;
u32 reg;
+ u32 rssi;
u8 reg_r17;
/*
* Don't perform any tuning when it is disabled
* in the EEPROM.
*/
- if (GET_FLAG(rt2x00dev, CONFIG_DISABLE_BBP_TUNING))
+ if (GET_FLAG(rt2x00dev, CONFIG_DISABLE_LINK_TUNING))
return;
+ /*
+* Retreive link quality.
+*/
+ rssi = rt2x00_get_link_rssi(rt2x00dev-link);
+ if (!rssi)
+ goto exit;
+
rt2x00_register_read(rt2x00dev, CSR0, reg);
rt2x00_bbp_read(rt2x00dev, 17, reg_r17);
@@ -719,14 +728,14 @@
if (rssi 40) {
if (reg_r17 = 0x41)
rt2x00_bbp_write(rt2x00dev, 17, reg_r17);
- return;
+ goto exit;
} else if (rssi = 62) {
if (reg_r17 != 0x50)
rt2x00_bbp_write(rt2x00dev, 17, 0x50);
- return;
+ goto exit;
} else if (reg_r17 = 0x41) {
rt2x00_bbp_write(rt2x00dev, 17, reg_r17);
- return;
+ goto exit;
}
dynamic_cca_tune:
@@ -738,6 +747,16 @@
rt2x00_bbp_write(rt2x00dev, 17, ++reg_r17);
else if (reg 100 reg_r17 0x32)
rt2x00_bbp_write(rt2x00dev, 17, --reg_r17);
+
+exit:
+ /*
+* Update noise statistics.
+*/
+ if (reg_r17)
+ rt2x00_update_link_noise(rt2x00dev-link, reg_r17
[PATCH 25/26] rt2x00: Compile fixes
As usual, when I make a large patch series,
I overlook important bits...
This will fix all issues that have arisen from this
patch series.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-misc/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
wireless-dev-compile/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
--- wireless-dev-misc/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-12-03 15:48:55.0 +0100
+++ wireless-dev-compile/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-12-03 15:56:14.0 +0100
@@ -1959,6 +1959,7 @@
entry = rt2x00_get_data_entry(ring);
txd = rt2x00_desc_addr(entry);
+ rt2x00_desc_read(txd, 0, word);
if (rt2x00_get_field32(word, TXD_W0_OWNER_NIC) ||
rt2x00_get_field32(word, TXD_W0_VALID)) {
diff -rU3 wireless-dev-misc/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
wireless-dev-compile/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
--- wireless-dev-misc/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-12-03 15:48:36.0 +0100
+++ wireless-dev-compile/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-12-03 15:52:39.0 +0100
@@ -1746,6 +1746,7 @@
struct data_desc *txd;
struct urb *urb;
u32 word;
+ int tx_status;
int ack;
int rts;
diff -rU3 wireless-dev-misc/drivers/net/wireless/d80211/rt2x00/rt2500usb.h
wireless-dev-compile/drivers/net/wireless/d80211/rt2x00/rt2500usb.h
--- wireless-dev-misc/drivers/net/wireless/d80211/rt2x00/rt2500usb.h
2006-12-03 15:08:28.0 +0100
+++ wireless-dev-compile/drivers/net/wireless/d80211/rt2x00/rt2500usb.h
2006-12-03 15:53:13.0 +0100
@@ -270,11 +270,14 @@
#define TXRX_CSR9 0x0452
/*
- * Auto responder registers.
* TXRX_CSR10: Auto responder control.
- * TXRX_CSR11: Auto responder basic rate.
*/
#define TXRX_CSR10 0x0454
+#define TXRX_CSR10_AUTORESPOND_PREAMBLE FIELD16(0x0004)
+
+/*
+ * TXRX_CSR11: Auto responder basic rate.
+ */
#define TXRX_CSR11 0x0456
/*
diff -rU3 wireless-dev-misc/drivers/net/wireless/d80211/rt2x00/rt2x00.h
wireless-dev-compile/drivers/net/wireless/d80211/rt2x00/rt2x00.h
--- wireless-dev-misc/drivers/net/wireless/d80211/rt2x00/rt2x00.h
2006-12-03 15:44:04.0 +0100
+++ wireless-dev-compile/drivers/net/wireless/d80211/rt2x00/rt2x00.h
2006-12-03 15:56:43.0 +0100
@@ -174,6 +174,23 @@
};
/*
+ * Cipher types for hardware encryption
+ */
+enum cipher {
+ CIPHER_NONE = 0,
+ CIPHER_WEP64 = 1,
+ CIPHER_WEP128 = 2,
+ CIPHER_TKIP = 3,
+ CIPHER_AES = 4,
+/*
+ * The following fields were added by rt61pci and rt73usb.
+ */
+ CIPHER_CKIP64 = 5,
+ CIPHER_CKIP128 = 6,
+ CIPHER_TKIP_NO_MIC = 7,
+};
+
+/*
* Macros for determining which is the lowest or highest bit
* set in a 16 or 32 bit variable.
*/
diff -rU3 wireless-dev-misc/drivers/net/wireless/d80211/rt2x00/rt2x00pci.h
wireless-dev-compile/drivers/net/wireless/d80211/rt2x00/rt2x00pci.h
--- wireless-dev-misc/drivers/net/wireless/d80211/rt2x00/rt2x00pci.h
2006-12-02 14:24:40.0 +0100
+++ wireless-dev-compile/drivers/net/wireless/d80211/rt2x00/rt2x00pci.h
2006-12-03 15:53:59.0 +0100
@@ -37,11 +37,8 @@
#define REGISTER_BUSY_DELAY100
/*
- * EEPROM operation defines.
+ * Link tuning at 1 second intervals
*/
-#define EEPROM_WIDTH_93C46 6
-#define EEPROM_WIDTH_93C66 8
-#define EEPROM_WRITE_OPCODE0x05
-#define EEPROM_READ_OPCODE 0x06
+#define LINK_TUNE_INTERVAL ( 1 * HZ )
#endif /* RT2X00PCI_H */
diff -rU3 wireless-dev-misc/drivers/net/wireless/d80211/rt2x00/rt2x00usb.h
wireless-dev-compile/drivers/net/wireless/d80211/rt2x00/rt2x00usb.h
--- wireless-dev-misc/drivers/net/wireless/d80211/rt2x00/rt2x00usb.h
2006-12-03 14:30:31.0 +0100
+++ wireless-dev-compile/drivers/net/wireless/d80211/rt2x00/rt2x00usb.h
2006-12-03 15:54:08.0 +0100
@@ -73,4 +73,9 @@
#define USB_MODE_FIRMWARE 0x08/* RT73USB */
#define USB_MODE_WAKEUP0x09/* RT73USB */
+/*
+ * Link tuning at 1 second intervals
+ */
+#define LINK_TUNE_INTERVAL ( 1 * HZ )
+
#endif /* RT2X00USB_H */
diff -rU3 wireless-dev-misc/drivers/net/wireless/d80211/rt2x00/rt61pci.c
wireless-dev-compile/drivers/net/wireless/d80211/rt2x00/rt61pci.c
--- wireless-dev-misc/drivers/net/wireless/d80211/rt2x00/rt61pci.c
2006-12-03 15:48:35.0 +0100
+++ wireless-dev-compile/drivers/net/wireless/d80211/rt2x00/rt61pci.c
2006-12-03 15:57:55.0 +0100
@@ -2281,8 +2281,7 @@
* we must make sure the packet queue in the d80211 stack
* is reenabled when the txdone handler has finished.
*/
- entry = ring-entry;
- if (!rt2x00_ring_full(ring))
+ if (!rt2x00_ring_full(entry-ring))
ieee80211_wake_queue(rt2x00dev-hw,
entry
[PATCH 23/26] rt2x00: Fix USB packet length and block promisc mode
The length of a packet that needs to be send over a USB device,
needs to have an even length. odd lengths will cause problems.
At the moment there is no solution for the enabling of promisc
mode on usb devices. The function is called from interrupt
context which means the driver cannot access a register.
Scheduling the request is required, but a clean solution
needs to be found.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-init/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
wireless-dev-usb/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
--- wireless-dev-init/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-12-03 15:21:33.0 +0100
+++ wireless-dev-usb/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-12-03 15:28:17.0 +0100
@@ -1846,6 +1846,7 @@
struct sk_buff *skb_rts;
u16 frame_control;
int res;
+ int length;
/*
* Determine which ring to put packet on.
@@ -1903,13 +1904,21 @@
SET_FLAG(entry, ENTRY_RTS_FRAME);
entry-skb = skb;
+ /*
+* Length passed to usb_fill_urb cannot be an odd number,
+* so add 1 byte to make it even.
+*/
+ length = skb-len + ring-desc_size;
+ if (length % 2)
+ length++;
+
SET_FLAG(entry, ENTRY_OWNER_NIC);
usb_fill_bulk_urb(
rt2x00_urb(entry),
usb_dev,
usb_sndbulkpipe(usb_dev, 1),
entry-data_addr,
- skb-len + ring-desc_size,
+ length,
rt2500usb_interrupt,
entry);
usb_submit_urb(rt2x00_urb(entry), GFP_ATOMIC);
@@ -2138,9 +2147,11 @@
* Monitor mode works with PROMISC mode forced on,
* so there is nothing to be done here.
*/
- if (update !GET_FLAG(rt2x00dev, INTERFACE_INITIALIZED_MONITOR))
- queue_work(rt2x00dev-workqueue,
- rt2x00dev-interface.work);
+ if (update !GET_FLAG(rt2x00dev, INTERFACE_INITIALIZED_MONITOR)) {
+ NOTICE(For the moment promisc mode is ignored);
+ /* queue_work(rt2x00dev-workqueue,
+ rt2x00dev-interface.work);*/
+ }
}
static void rt2500usb_scan(void *data)
diff -rU3 wireless-dev-init/drivers/net/wireless/d80211/rt2x00/rt73usb.c
wireless-dev-usb/drivers/net/wireless/d80211/rt2x00/rt73usb.c
--- wireless-dev-init/drivers/net/wireless/d80211/rt2x00/rt73usb.c
2006-12-03 15:21:44.0 +0100
+++ wireless-dev-usb/drivers/net/wireless/d80211/rt2x00/rt73usb.c
2006-12-03 15:27:24.0 +0100
@@ -2118,6 +2118,7 @@
struct sk_buff *skb_rts;
u16 frame_control;
int res;
+ int length;
/*
* Determine which ring to put packet on.
@@ -2175,13 +2176,21 @@
SET_FLAG(entry, ENTRY_RTS_FRAME);
entry-skb = skb;
+ /*
+* Length passed to usb_fill_urb cannot be an odd number,
+* so add 1 byte to make it even.
+*/
+ length = skb-len + ring-desc_size;
+ if (length % 2)
+ length++;
+
SET_FLAG(entry, ENTRY_OWNER_NIC);
usb_fill_bulk_urb(
rt2x00_urb(entry),
usb_dev,
usb_sndbulkpipe(usb_dev, 1),
entry-data_addr,
- skb-len + ring-desc_size,
+ length,
rt73usb_interrupt,
entry);
usb_submit_urb(rt2x00_urb(entry), GFP_ATOMIC);
@@ -2410,9 +2419,11 @@
* Monitor mode works with PROMISC mode forced on,
* so there is nothing to be done here.
*/
- if (update !GET_FLAG(rt2x00dev, INTERFACE_INITIALIZED_MONITOR))
- queue_work(rt2x00dev-workqueue,
- rt2x00dev-interface.work);
+ if (update !GET_FLAG(rt2x00dev, INTERFACE_INITIALIZED_MONITOR)) {
+ NOTICE(For the moment promisc mode is ignored);
+ /* queue_work(rt2x00dev-workqueue,
+ rt2x00dev-interface.work);*/
+ }
}
static void rt73usb_scan(void *data)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/26] rt2x00: Rssi detection
Correctly detect the maxssi settings from the EEPROM where available, and correct the dummy values that had been added in the initial patch to support noise and signal measurement. MAX_RX_SSI is a value that is different on each chipset, so it should be a driver specific define. Signed-off-by Ivo van Doorn [EMAIL PROTECTED] --- diff -rU3 wireless-dev-bbp/drivers/net/wireless/d80211/rt2x00/rt2400pci.c wireless-dev-rssi/drivers/net/wireless/d80211/rt2x00/rt2400pci.c --- wireless-dev-bbp/drivers/net/wireless/d80211/rt2x00/rt2400pci.c 2006-12-03 12:38:28.0 +0100 +++ wireless-dev-rssi/drivers/net/wireless/d80211/rt2x00/rt2400pci.c 2006-12-03 12:46:41.0 +0100 @@ -1550,13 +1550,15 @@ rt2x00dev-rx_params.ssi = rt2x00_get_field32(word2, RXD_W2_RSSI); -/* FIXME: The following set of assignments supply additional data for wireless statistics. The - necessary quantities are (1) the noise value in dBm, and (2) the signal value in dBm. - The present code supplies dummy values for these quantities. */ - - rt2x00dev-rx_params.noise = -85; /* FIXME */ - rt2x00dev-rx_params.signal = - rt2x00dev-rx_params.ssi - RT2X00_RX_MAX_SSI; /* FIXME */ + /* +* The following set of assignments supply +* additional data for wireless statistics. The +* necessary quantities are (1) the noise value +* in dBm, and (2) the signal value in dBm. +*/ + rt2x00dev-rx_params.noise = 0; + rt2x00dev-rx_params.signal = rt2x00dev-rx_params.ssi + - rt2x00dev-hw-maxssi; __ieee80211_rx(rt2x00dev-hw, skb, rt2x00dev-rx_params); diff -rU3 wireless-dev-bbp/drivers/net/wireless/d80211/rt2x00/rt2400pci.h wireless-dev-rssi/drivers/net/wireless/d80211/rt2x00/rt2400pci.h --- wireless-dev-bbp/drivers/net/wireless/d80211/rt2x00/rt2400pci.h 2006-12-02 23:22:43.0 +0100 +++ wireless-dev-rssi/drivers/net/wireless/d80211/rt2x00/rt2400pci.h 2006-12-03 12:49:55.0 +0100 @@ -39,6 +39,11 @@ #define RF2421 0x0001 /* + * Max RSSI value, required for RSSI - dBm conversion. + */ +#define MAX_RX_SSI 100 + +/* * Register layout information. */ #define CSR_REG_BASE 0x diff -rU3 wireless-dev-bbp/drivers/net/wireless/d80211/rt2x00/rt2500pci.c wireless-dev-rssi/drivers/net/wireless/d80211/rt2x00/rt2500pci.c --- wireless-dev-bbp/drivers/net/wireless/d80211/rt2x00/rt2500pci.c 2006-12-03 12:34:39.0 +0100 +++ wireless-dev-rssi/drivers/net/wireless/d80211/rt2x00/rt2500pci.c 2006-12-03 12:47:36.0 +0100 @@ -1707,13 +1707,16 @@ rt2x00dev-rx_params.ssi = rt2x00_get_field32(word2, RXD_W2_RSSI); -/* FIXME: The following set of assignments supply additional data for wireless statistics. The - necessary quantities are (1) the noise value in dBm, and (2) the signal value in dBm. - The present code supplies dummy values for these quantities. */ - - rt2x00dev-rx_params.noise = -85; /* FIXME */ - rt2x00dev-rx_params.signal = - rt2x00dev-rx_params.ssi - RT2X00_RX_MAX_SSI; /* FIXME */ + /* +* The following set of assignments supply +* additional data for wireless statistics. The +* necessary quantities are (1) the noise value +* in dBm, and (2) the signal value in dBm. +*/ + rt2x00dev-rx_params.noise = + rt2x00_get_link_noise(rt2x00dev-link); + rt2x00dev-rx_params.signal = rt2x00dev-rx_params.ssi + - rt2x00dev-hw-maxssi; __ieee80211_rx(rt2x00dev-hw, skb, rt2x00dev-rx_params); @@ -2588,6 +2591,15 @@ if (rt2x00_get_field16(eeprom, EEPROM_NIC_DYN_BBP_TUNE)) SET_FLAG(rt2x00dev, CONFIG_DISABLE_LINK_TUNING); + /* +* Read the RSSI - dBm offset information. +*/ + rt2x00_eeprom_read(rt2x00dev, EEPROM_CALIBRATE_OFFSET, eeprom); + rt2x00dev-hw-maxssi = + rt2x00_get_field16(eeprom, EEPROM_CALIBRATE_OFFSET_RSSI); + if (rt2x00dev-hw-maxssi == 0x00 || rt2x00dev-hw-maxssi == 0xff) + rt2x00dev-hw-maxssi = MAX_RX_SSI; + return 0; } diff -rU3 wireless-dev-bbp/drivers/net/wireless/d80211/rt2x00/rt2500pci.h wireless-dev-rssi/drivers/net/wireless/d80211/rt2x00/rt2500pci.h --- wireless-dev-bbp
[PATCH 01/26] rt2x00: ethtool
Latest d80211 stack no longer provides any ethtool support.
At the moment there is no quick replacement possible for
the ethtool features (debugfs is under investigation, but
requires more work).
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-base/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-ethtool/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-base/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-12-02 14:24:40.0 +0100
+++ wireless-dev-ethtool/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-12-02 14:52:12.0 +0100
@@ -35,7 +35,6 @@
#include linux/netdevice.h
#include linux/etherdevice.h
#include linux/wireless.h
-#include linux/ethtool.h
#include net/iw_handler.h
#include net/d80211.h
@@ -343,81 +342,6 @@
}
/*
- * Ethtool handlers.
- */
-static void rt2400pci_get_drvinfo(struct net_device *net_dev,
- struct ethtool_drvinfo *drvinfo)
-{
- struct rt2x00_dev *rt2x00dev = ieee80211_dev_hw_data(net_dev);
-
- strcpy(drvinfo-driver, DRV_NAME);
- strcpy(drvinfo-version, DRV_VERSION);
- strcpy(drvinfo-fw_version, N/A);
- strcpy(drvinfo-bus_info, pci_name(rt2x00dev_pci(rt2x00dev)));
- drvinfo-eedump_len = EEPROM_SIZE;
- drvinfo-regdump_len = CSR_REG_SIZE;
-}
-
-static int rt2400pci_get_regs_len(struct net_device *net_dev)
-{
- return CSR_REG_SIZE;
-}
-
-static void rt2400pci_get_regs(struct net_device *net_dev,
- struct ethtool_regs *regs, void *data)
-{
- struct rt2x00_dev *rt2x00dev = ieee80211_dev_hw_data(net_dev);
-
- rt2x00_register_multiread(rt2x00dev, CSR_REG_BASE, data, CSR_REG_SIZE);
- regs-version = rt2x00_rev(rt2x00dev-chip);
- regs-len = CSR_REG_SIZE;
-}
-
-#ifdef CONFIG_RT2400PCI_DEBUG
-static u32 rt2400pci_get_msglevel(struct net_device *net_dev)
-{
- return rt2x00_debug_level;
-}
-
-static void rt2400pci_set_msglevel(struct net_device *net_dev, u32 msg)
-{
- rt2x00_debug_level = !!msg;
-}
-#endif /* CONFIG_RT2400PCI_DEBUG */
-
-static int rt2400pci_get_eeprom_len(struct net_device *net_dev)
-{
- return EEPROM_SIZE;
-}
-
-static int rt2400pci_get_eeprom(struct net_device *net_dev,
- struct ethtool_eeprom *eeprom, u8 *data)
-{
- struct rt2x00_dev *rt2x00dev = ieee80211_dev_hw_data(net_dev);
-
- eeprom-magic = 0xbad;
-
- rt2x00_eeprom_multiread(rt2x00dev,
- eeprom-offset / sizeof(u16), (void*)data, eeprom-len);
-
- return 0;
-}
-
-static struct ethtool_ops rt2400pci_ethtool_ops = {
- .get_drvinfo= rt2400pci_get_drvinfo,
- .get_regs_len = rt2400pci_get_regs_len,
- .get_regs = rt2400pci_get_regs,
-#ifdef CONFIG_RT2400PCI_DEBUG
- .get_msglevel = rt2400pci_get_msglevel,
- .set_msglevel = rt2400pci_set_msglevel,
-#endif /* CONFIG_RT2400PCI_DEBUG */
- .get_link = ethtool_op_get_link,
- .get_eeprom_len = rt2400pci_get_eeprom_len,
- .get_eeprom = rt2400pci_get_eeprom,
- .get_perm_addr = ethtool_op_get_perm_addr,
-};
-
-/*
* Configuration handlers.
*/
static void rt2400pci_config_bssid(struct rt2x00_dev *rt2x00dev, u8 *bssid)
@@ -2861,7 +2785,6 @@
goto exit_disable_device;
}
- SET_ETHTOOL_OPS(net_dev, rt2400pci_ethtool_ops);
SET_NETDEV_DEV(net_dev, pci_dev-dev);
pci_set_drvdata(pci_dev, net_dev);
diff -rU3 wireless-dev-base/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
wireless-dev-ethtool/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
--- wireless-dev-base/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-12-02 14:24:40.0 +0100
+++ wireless-dev-ethtool/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-12-02 14:52:11.0 +0100
@@ -35,7 +35,6 @@
#include linux/netdevice.h
#include linux/etherdevice.h
#include linux/wireless.h
-#include linux/ethtool.h
#include net/iw_handler.h
#include net/d80211.h
@@ -343,81 +342,6 @@
}
/*
- * Ethtool handlers.
- */
-static void rt2500pci_get_drvinfo(struct net_device *net_dev,
- struct ethtool_drvinfo *drvinfo)
-{
- struct rt2x00_dev *rt2x00dev = ieee80211_dev_hw_data(net_dev);
-
- strcpy(drvinfo-driver, DRV_NAME);
- strcpy(drvinfo-version, DRV_VERSION);
- strcpy(drvinfo-fw_version, N/A);
- strcpy(drvinfo-bus_info, pci_name(rt2x00dev_pci(rt2x00dev)));
- drvinfo-eedump_len = EEPROM_SIZE;
- drvinfo-regdump_len = CSR_REG_SIZE;
-}
-
-static int rt2500pci_get_regs_len(struct net_device *net_dev)
-{
- return CSR_REG_SIZE;
-}
-
-static void rt2500pci_get_regs(struct net_device *net_dev,
- struct ethtool_regs *regs, void *data)
-{
- struct rt2x00_dev *rt2x00dev = ieee80211_dev_hw_data(net_dev);
-
- rt2x00_register_multiread(rt2x00dev, CSR_REG_BASE, data, CSR_REG_SIZE);
- regs-version = rt2x00_rev(rt2x00dev-chip);
- regs-len = CSR_REG_SIZE;
-}
-
-#ifdef CONFIG_RT2500PCI_DEBUG
-static u32
[PATCH 21/26] rt2x00: Fix txdone race condition
Always call ieee80211_wake_queue if the ring
is not full after the txrun. The ieee80211_wake_queue
is responsible for chacking if the queue was stopped
or not.
The current implementation of checking the ring_full
before the txdone run was flawed and race conditions
could occur that blocked all tx handling.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-led/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-ringfull/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-led/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-12-03 15:09:41.0 +0100
+++ wireless-dev-ringfull/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-12-03 15:14:07.0 +0100
@@ -1613,14 +1613,8 @@
u32 word;
int tx_status;
int ack;
- int ring_full;
int rts;
- /*
-* Store the current status of the ring.
-*/
- ring_full = rt2x00_ring_full(ring);
-
while (!rt2x00_ring_empty(ring)) {
entry = rt2x00_get_data_entry_done(ring);
txd = rt2x00_desc_addr(entry);
@@ -1687,7 +1681,7 @@
* is reenabled when the txdone handler has finished.
*/
entry = ring-entry;
- if (ring_full !rt2x00_ring_full(ring))
+ if (!rt2x00_ring_full(ring))
ieee80211_wake_queue(rt2x00dev-hw,
entry-tx_status.control.queue);
}
diff -rU3 wireless-dev-led/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
wireless-dev-ringfull/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
--- wireless-dev-led/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-12-03 15:09:55.0 +0100
+++ wireless-dev-ringfull/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-12-03 15:14:05.0 +0100
@@ -1776,14 +1776,8 @@
u32 word;
int tx_status;
int ack;
- int ring_full;
int rts;
- /*
-* Store the current status of the ring.
-*/
- ring_full = rt2x00_ring_full(ring);
-
while (!rt2x00_ring_empty(ring)) {
entry = rt2x00_get_data_entry_done(ring);
txd = rt2x00_desc_addr(entry);
@@ -1850,7 +1844,7 @@
* is reenabled when the txdone handler has finished.
*/
entry = ring-entry;
- if (ring_full !rt2x00_ring_full(ring))
+ if (!rt2x00_ring_full(ring))
ieee80211_wake_queue(rt2x00dev-hw,
entry-tx_status.control.queue);
}
diff -rU3 wireless-dev-led/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
wireless-dev-ringfull/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
--- wireless-dev-led/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-12-03 15:10:04.0 +0100
+++ wireless-dev-ringfull/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-12-03 15:14:10.0 +0100
@@ -1753,14 +1753,8 @@
struct urb *urb;
u32 word;
int ack;
- int ring_full;
int rts;
- /*
-* Store the current status of the ring.
-*/
- ring_full = rt2x00_ring_full(ring);
-
while (!rt2x00_ring_empty(ring)) {
entry = rt2x00_get_data_entry_done(ring);
txd = rt2x00_txdesc_addr(entry);
@@ -1821,7 +1815,7 @@
* is reenabled when the txdone handler has finished.
*/
entry = ring-entry;
- if (ring_full !rt2x00_ring_full(ring))
+ if (!rt2x00_ring_full(ring))
ieee80211_wake_queue(rt2x00dev-hw,
entry-tx_status.control.queue);
}
diff -rU3 wireless-dev-led/drivers/net/wireless/d80211/rt2x00/rt61pci.c
wireless-dev-ringfull/drivers/net/wireless/d80211/rt2x00/rt61pci.c
--- wireless-dev-led/drivers/net/wireless/d80211/rt2x00/rt61pci.c
2006-12-03 15:10:28.0 +0100
+++ wireless-dev-ringfull/drivers/net/wireless/d80211/rt2x00/rt61pci.c
2006-12-03 15:14:18.0 +0100
@@ -2235,7 +2235,6 @@
u32 word;
int tx_status;
int ack;
- int ring_full;
int rts;
txd = rt2x00_desc_addr(entry);
@@ -2285,11 +2284,6 @@
CLEAR_FLAG(entry, ENTRY_RTS_FRAME);
entry-skb = NULL;
- /*
-* Store the current status of the ring.
-*/
- ring_full = rt2x00_ring_full(entry-ring);
-
rt2x00_ring_index_done_inc(entry-ring);
/*
@@ -2297,7 +2291,8 @@
* we must make sure the packet queue in the d80211 stack
* is reenabled when the txdone handler has finished.
*/
- if (ring_full !rt2x00_ring_full(entry-ring))
+ entry = ring-entry;
+ if (!rt2x00_ring_full(ring))
ieee80211_wake_queue(rt2x00dev-hw,
entry-tx_status.control.queue);
}
diff -rU3 wireless-dev-led/drivers/net/wireless/d80211/rt2x00/rt73usb.c
wireless-dev-ringfull/drivers/net/wireless/d80211/rt2x00/rt73usb.c
--- wireless-dev-led/drivers/net/wireless/d80211/rt2x00/rt73usb.c
[PATCH 14/26] rt2x00: Add more statistics readin
Make sure all statistics the d80211 stack requires.
Some of this requires values to be read during
interrupt process (add a new function to handle this).
And other fields can be read from the registers at
request time.
Note that rt61pci and rt73usb had an invalid registername
the legacy drivers are suggesting the CRC_ERROR count is
actually the FCS_ERROR count.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-signal/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-stats/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-signal/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-12-03 13:49:47.0 +0100
+++ wireless-dev-stats/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-12-03 14:03:05.0 +0100
@@ -1624,14 +1624,7 @@
!rt2x00_get_field32(word, TXD_W0_VALID))
break;
- ack = rt2x00_get_field32(word, TXD_W0_ACK);
-
- entry-tx_status.flags = 0;
- /*
-* TODO: How can bit IEEE80211_TX_STATUS_TX_FILTERED of
-* entry-tx_status.flags be set correctly?
-*/
-
+ entry-tx_status.flags = 0;
entry-tx_status.queue_length = ring-stats.limit;
entry-tx_status.queue_number = entry-tx_status.control.queue;
@@ -1641,15 +1634,11 @@
* ACK response when ACK was requested and status
* was succesfull.
*/
+ ack = rt2x00_get_field32(word, TXD_W0_ACK);
+ rts = GET_FLAG(entry, ENTRY_RTS_FRAME);
tx_status = rt2x00_get_field32(word, TXD_W0_RESULT);
- entry-tx_status.excessive_retries = 0;
- if (ack (tx_status == TX_SUCCESS ||
- tx_status == TX_SUCCESS_RETRY))
- entry-tx_status.flags |= IEEE80211_TX_STATUS_ACK;
- else if (ack tx_status == TX_FAIL_RETRY) {
- rt2x00dev-low_level_stats.dot11ACKFailureCount++;
- entry-tx_status.excessive_retries = 1;
- }
+ rt2x00_update_tx_stats(rt2x00dev, entry-tx_status, tx_status,
+ ack, rts);
rt2x00_bbp_read(rt2x00dev, 32,
(u8*)entry-tx_status.ack_signal);
@@ -2183,10 +2172,8 @@
/*
* Update FCS error count from register.
-* The dot11ACKFailureCount is updated in interrupt time.
-* TODO: dot11RTSFailureCount and dot11RTSSuccessCount
-* are never updated, we need to find a method to see
-* where we can update those statistics from.
+* The dot11ACKFailureCount, dot11RTSFailureCount and
+* dot11RTSSuccessCount are updated in interrupt time.
*/
rt2x00_register_read(rt2x00dev, CNT0, reg);
rt2x00dev-low_level_stats.dot11FCSErrorCount +=
diff -rU3 wireless-dev-signal/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
wireless-dev-stats/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
--- wireless-dev-signal/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-12-03 13:52:24.0 +0100
+++ wireless-dev-stats/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-12-03 14:00:23.0 +0100
@@ -1787,14 +1787,7 @@
!rt2x00_get_field32(word, TXD_W0_VALID))
break;
- ack = rt2x00_get_field32(word, TXD_W0_ACK);
-
entry-tx_status.flags = 0;
- /*
-* TODO: How can the IEEE80211_TX_STATUS_TX_FILTERED bit of
-* entry-tx_status.flags be set correctly?
-*/
-
entry-tx_status.queue_length = ring-stats.limit;
entry-tx_status.queue_number = entry-tx_status.control.queue;
@@ -1804,15 +1797,11 @@
* ACK response when ACK was requested and status
* was succesfull.
*/
+ ack = rt2x00_get_field32(word, TXD_W0_ACK);
+ rts = GET_FLAG(entry, ENTRY_RTS_FRAME);
tx_status = rt2x00_get_field32(word, TXD_W0_RESULT);
- entry-tx_status.excessive_retries = 0;
- if (ack (tx_status == TX_SUCCESS ||
- tx_status == TX_SUCCESS_RETRY))
- entry-tx_status.flags |= IEEE80211_TX_STATUS_ACK;
- else if (ack tx_status == TX_FAIL_RETRY) {
- rt2x00dev-low_level_stats.dot11ACKFailureCount++;
- entry-tx_status.excessive_retries = 1;
- }
+ rt2x00_update_tx_stats(rt2x00dev, entry-tx_status, tx_status,
+ ack, rts);
rt2x00_bbp_read(rt2x00dev, 32,
(u8*)entry-tx_status.ack_signal);
@@ -2342,10 +2331,8 @@
/*
* Update FCS error count from register.
-* The dot11ACKFailureCount is updated in interrupt time
[PATCH 18/26] rt2x00: Simplify MAC copying
No set_field commands are required for the mac registers.
This was previously done for the byteordering.
But since the MAC is already read in the correct byteorder
this had never had to happen at all anyway.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-vendor/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-mac/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-vendor/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-12-03 14:19:54.0 +0100
+++ wireless-dev-mac/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-12-03 14:45:46.0 +0100
@@ -605,13 +605,11 @@
{
u32 reg[2] = { 0, 0 };
- rt2x00_set_field32(reg[0], CSR3_BYTE0, ((u8*)addr)[0]);
- rt2x00_set_field32(reg[0], CSR3_BYTE1, ((u8*)addr)[1]);
- rt2x00_set_field32(reg[0], CSR3_BYTE2, ((u8*)addr)[2]);
- rt2x00_set_field32(reg[0], CSR3_BYTE3, ((u8*)addr)[3]);
- rt2x00_set_field32(reg[1], CSR4_BYTE4, ((u8*)addr)[4]);
- rt2x00_set_field32(reg[1], CSR4_BYTE5, ((u8*)addr)[5]);
-
+ /*
+* The MAC address is passed to us as an array of bytes,
+* that array is little endian, so no need for byte ordering.
+*/
+ memcpy(reg, addr, ETH_ALEN);
rt2x00_register_multiwrite(rt2x00dev, CSR3, reg[0], sizeof(reg));
}
diff -rU3 wireless-dev-vendor/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
wireless-dev-mac/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
--- wireless-dev-vendor/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-12-03 14:21:13.0 +0100
+++ wireless-dev-mac/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-12-03 14:46:09.0 +0100
@@ -679,13 +679,11 @@
{
u32 reg[2] = { 0, 0 };
- rt2x00_set_field32(reg[0], CSR3_BYTE0, ((u8*)addr)[0]);
- rt2x00_set_field32(reg[0], CSR3_BYTE1, ((u8*)addr)[1]);
- rt2x00_set_field32(reg[0], CSR3_BYTE2, ((u8*)addr)[2]);
- rt2x00_set_field32(reg[0], CSR3_BYTE3, ((u8*)addr)[3]);
- rt2x00_set_field32(reg[1], CSR4_BYTE4, ((u8*)addr)[4]);
- rt2x00_set_field32(reg[1], CSR4_BYTE5, ((u8*)addr)[5]);
-
+ /*
+* The MAC address is passed to us as an array of bytes,
+* that array is little endian, so no need for byte ordering.
+*/
+ memcpy(reg, addr, ETH_ALEN);
rt2x00_register_multiwrite(rt2x00dev, CSR3, reg[0], sizeof(reg));
}
diff -rU3 wireless-dev-vendor/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
wireless-dev-mac/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
--- wireless-dev-vendor/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-12-03 14:36:31.0 +0100
+++ wireless-dev-mac/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-12-03 14:46:19.0 +0100
@@ -709,13 +709,11 @@
{
u16 reg[3] = { 0, 0, 0 };
- rt2x00_set_field16(reg[0], MAC_CSR2_BYTE0, ((u8*)addr)[0]);
- rt2x00_set_field16(reg[0], MAC_CSR2_BYTE1, ((u8*)addr)[1]);
- rt2x00_set_field16(reg[1], MAC_CSR3_BYTE2, ((u8*)addr)[2]);
- rt2x00_set_field16(reg[1], MAC_CSR3_BYTE3, ((u8*)addr)[3]);
- rt2x00_set_field16(reg[2], MAC_CSR4_BYTE4, ((u8*)addr)[4]);
- rt2x00_set_field16(reg[2], MAC_CSR4_BYTE5, ((u8*)addr)[5]);
-
+ /*
+* The MAC address is passed to us as an array of bytes,
+* that array is little endian, so no need for byte ordering.
+*/
+ memcpy(reg, addr, ETH_ALEN);
rt2x00_register_multiwrite(rt2x00dev, MAC_CSR2, reg[0], sizeof(reg));
}
diff -rU3 wireless-dev-vendor/drivers/net/wireless/d80211/rt2x00/rt61pci.c
wireless-dev-mac/drivers/net/wireless/d80211/rt2x00/rt61pci.c
--- wireless-dev-vendor/drivers/net/wireless/d80211/rt2x00/rt61pci.c
2006-12-03 14:22:40.0 +0100
+++ wireless-dev-mac/drivers/net/wireless/d80211/rt2x00/rt61pci.c
2006-12-03 14:46:31.0 +0100
@@ -910,14 +910,14 @@
{
u32 reg[2] = { 0, 0 };
- rt2x00_set_field32(reg[0], MAC_CSR2_BYTE0, ((u8*)addr)[0]);
- rt2x00_set_field32(reg[0], MAC_CSR2_BYTE1, ((u8*)addr)[1]);
- rt2x00_set_field32(reg[0], MAC_CSR2_BYTE2, ((u8*)addr)[2]);
- rt2x00_set_field32(reg[0], MAC_CSR2_BYTE3, ((u8*)addr)[3]);
- rt2x00_set_field32(reg[1], MAC_CSR3_BYTE4, ((u8*)addr)[4]);
- rt2x00_set_field32(reg[1], MAC_CSR3_BYTE5, ((u8*)addr)[5]);
+ /*
+* The MAC address is passed to us as an array of bytes,
+* that array is little endian, so no need for byte ordering.
+* We only need to set the MAC_CSR3_UNICAST_TO_ME_MASK
+* at the correct offset.
+*/
+ memcpy(reg, addr, ETH_ALEN);
rt2x00_set_field32(reg[1], MAC_CSR3_UNICAST_TO_ME_MASK, 0xff);
-
rt2x00_register_multiwrite(rt2x00dev, MAC_CSR2, reg[0], sizeof(reg));
}
diff -rU3 wireless-dev-vendor/drivers/net/wireless/d80211/rt2x00/rt73usb.c
wireless-dev-mac/drivers/net/wireless/d80211/rt2x00/rt73usb.c
--- wireless-dev-vendor/drivers/net/wireless/d80211/rt2x00
[PATCH 04/26] rt2x00: EEPROM 93Cx6
rt2400pci, rt2500pci and rt61pci share exactly the same code for the eeprom reading. The only difference is that rt61pci has a slightly different register reading approach. In any case we have a lot of duplicate code. Create a new module eeprom_93cx6 inside the rt2x00 folder and make rt2x00 use that. As a bonus the entire eeprom is read into an array to optimize eeprom usage. This also enables dummy eeprom writing where the temporary buffer can be manipulated by the user without permanently harming the eeprom. This feature should have been enabled through ethtool, but 3 days after this patch ethtool was removed from d80211. This feature will be used when debugfs has been implemented. Signed-off-by Ivo van Doorn [EMAIL PROTECTED] --- http://www.mendiosus.nl/rt2x00/04_eeprom.diff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/26] rt2x00: Move rt2x00usb_vendor_request out of header
Remove the rt2x00usb_vendor_request from the rt2x00usb.h
header, and place it into the rt2x00_vendor_request.
This means that the rt2x00_vendor_request function
needs a timeout value especially for commands that
require a lot of time (i.e. Firmware writing).
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 wireless-dev-rts/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
wireless-dev-vendor/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
--- wireless-dev-rts/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-12-03 14:21:53.0 +0100
+++ wireless-dev-vendor/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
2006-12-03 14:36:31.0 +0100
@@ -64,18 +64,31 @@
* the access attempt is considered to have failed,
* and we will print an error.
*/
-static void rt2x00_vendor_request(const struct rt2x00_dev *rt2x00dev,
+static int rt2x00_vendor_request(const struct rt2x00_dev *rt2x00dev,
const u8 request, const u8 type, const u16 offset,
- u32 value, void *buffer, const u16 buffer_length)
+ u32 value, void *buffer, const u16 buffer_length, const u16 timeout)
{
- int status = rt2x00usb_vendor_request(
- rt2x00dev, request, type, offset,
- value, buffer, buffer_length, REGISTER_TIMEOUT);
-
- if (status 0)
- ERROR(vendor request error. Request 0x%02x failed
- for offset 0x%04x with error %d.\n,
- request, offset, status);
+ struct usb_device *usb_dev = interface_to_usbdev(
+ rt2x00dev_usb(rt2x00dev));
+ int status;
+ unsigned int i;
+
+ for (i = 0; i REGISTER_BUSY_COUNT; i++) {
+ status = usb_control_msg(
+ usb_dev,
+ (type == USB_VENDOR_REQUEST_IN) ?
+ usb_rcvctrlpipe(usb_dev, 0) :
+ usb_sndctrlpipe(usb_dev, 0),
+ request, type, value, offset, buffer, buffer_length,
+ timeout);
+ if (status = 0)
+ return 0;
+ }
+
+ ERROR(vendor request error. Request 0x%02x failed
+ for offset 0x%04x with error %d.\n, request, offset, status);
+
+ return status;
}
static inline void rt2x00_register_read(
@@ -85,7 +98,7 @@
__le16 reg;
rt2x00_vendor_request(
rt2x00dev, USB_MULTI_READ, USB_VENDOR_REQUEST_IN,
- offset, 0x00, reg, 2);
+ offset, 0x00, reg, 2, REGISTER_TIMEOUT);
*value = le16_to_cpu(reg);
}
@@ -95,7 +108,7 @@
{
rt2x00_vendor_request(
rt2x00dev, USB_MULTI_READ, USB_VENDOR_REQUEST_IN,
- offset, 0x00, value, length);
+ offset, 0x00, value, length, REGISTER_TIMEOUT);
}
static inline void rt2x00_register_write(
@@ -105,7 +118,7 @@
__le16 reg = cpu_to_le16(value);
rt2x00_vendor_request(
rt2x00dev, USB_MULTI_WRITE, USB_VENDOR_REQUEST_OUT,
- offset, 0x00, reg, 2);
+ offset, 0x00, reg, 2, REGISTER_TIMEOUT);
}
static inline void rt2x00_register_multiwrite(
@@ -114,7 +127,7 @@
{
rt2x00_vendor_request(
rt2x00dev, USB_MULTI_WRITE, USB_VENDOR_REQUEST_OUT,
- offset, 0x00, value, length);
+ offset, 0x00, value, length, REGISTER_TIMEOUT);
}
static u16 rt2x00_bbp_check(const struct rt2x00_dev *rt2x00dev)
@@ -1071,9 +1084,11 @@
return -EBUSY;
rt2x00_vendor_request(rt2x00dev, USB_DEVICE_MODE,
- USB_VENDOR_REQUEST_OUT, 0x00, USB_MODE_TEST, NULL, 0);
+ USB_VENDOR_REQUEST_OUT, 0x, USB_MODE_TEST, NULL, 0,
+ REGISTER_TIMEOUT);
rt2x00_vendor_request(rt2x00dev, USB_SINGLE_WRITE,
- USB_VENDOR_REQUEST_OUT, 0x0308, 0xf0, NULL, 0);
+ USB_VENDOR_REQUEST_OUT, 0x0308, 0xf0, NULL, 0,
+ REGISTER_TIMEOUT);
rt2x00_register_write(rt2x00dev, MAC_CSR13, 0x);
rt2x00_register_write(rt2x00dev, MAC_CSR14, 0x1e11);
@@ -1392,7 +1407,7 @@
rt2x00_register_write(rt2x00dev, TXRX_CSR2, reg);
rt2x00_vendor_request(rt2x00dev, USB_RX_CONTROL,
- USB_VENDOR_REQUEST_OUT, 0x00, 0x00, NULL, 0);
+ USB_VENDOR_REQUEST_OUT, 0x00, 0x00, NULL, 0, REGISTER_TIMEOUT);
ring = rt2x00dev-ring[RING_RX];
for (i = 0; i ring-stats.limit; i++)
diff -rU3 wireless-dev-rts/drivers/net/wireless/d80211/rt2x00/rt2x00usb.h
wireless-dev-vendor/drivers/net/wireless/d80211/rt2x00/rt2x00usb.h
--- wireless-dev-rts/drivers/net/wireless/d80211/rt2x00/rt2x00usb.h
2006-12-02 14:24:40.0 +0100
+++ wireless-dev-vendor/drivers/net/wireless/d80211/rt2x00/rt2x00usb.h
2006-12-03 14:30:31.0 +0100
@@ -73,32 +73,4 @@
#define USB_MODE_FIRMWARE 0x08/* RT73USB */
#define USB_MODE_WAKEUP0x09/* RT73USB
