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
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 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, 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: > 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
[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
#include
+#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
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
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, 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
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
[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
[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 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 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
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 ov
[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
[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
[RFC 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]>
---
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 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]>
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
[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
[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
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 state sysfs writable
The rfkill state Sysfs attribute should be made writable,
we already pass the argument for the store handler,
so we only need to update the permissions flag.
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
---
diff --git a/net/rfkill/rfkill.c b/net/rfkill/rfkill.c
index f3986d4..db3395b 100644
--- a/net/rfkill/rfkill.c
+++ b/net/rfkill/rfkill.c
@@ -187,7 +187,7 @@ static ssize_t rfkill_claim_store(struct device *dev,
static struct device_attribute rfkill_dev_attrs[] = {
__ATTR(name, S_IRUGO, rfkill_name_show, NULL),
__ATTR(type, S_IRUGO, rfkill_type_show, NULL),
- __ATTR(state, S_IRUGO, rfkill_state_show, rfkill_state_store),
+ __ATTR(state, S_IRUGO|S_IWUSR, rfkill_state_show, rfkill_state_store),
__ATTR(claim, S_IRUGO|S_IWUSR, rfkill_claim_show, rfkill_claim_store),
__ATTR_NULL
};
-
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
> +#include
> +#include
> +#include
> +#include
> +
> +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 fla
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
> > > 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()
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
[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
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
Re: [PATCH 1/3] d80211: Add control structure for beacontemplates
On Monday 05 February 2007 21:28, Jiri Benc wrote:
> On Sat, 3 Feb 2007 17:25:18 +0100, Ivo van Doorn wrote:
> > 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.
>
> Good catch, thanks.
>
> > 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)
>
> I would prefer using local variable for tx_control. Driver will be
> responsible for copying it somewhere if it needs to. I believe most
> drivers won't need to do that and it will prevent potential memory
> leaks as it's easy to forget to free the structure.
Sounds good to me, that would absolute the fix for bcm43xx I had send,
but the updated patch for p54 would still be required to make sure p54
no longer requests the beacon without ever using (or freeing it).
This is the updated patch to add the control structure to the beacontemplate.
This time no seperately allocated control structure, but a local variable
inside the ieee80211_if_conf structure.
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 00:23:45.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 00:25:26.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;
+ memcpy(&conf.beacon_control, control, sizeof(*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
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 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, > > > > 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 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
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
[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 r
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 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
[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] 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 unsubscr
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 (1<<15)
+ /* Does the HOST need to insert the frame sequence counter */
+#define IEEE80211_HW_SOFTWARE_SEQUENCE (1<<16)
+
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 *loc
[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 (1<<15)
+ /* Does the HOST need to insert the frame sequence counter */
+#define IEEE80211_HW_SOFTWARE_SEQUENCE (1<<16)
+
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
[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 (1<<14)
+ /* Does the device need the stack to create a RTS frame */
+#define IEEE80211_HW_SOFTWARE_RTS (1<<15)
+
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_rateid
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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+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 over the toggling of the
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
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 0000000..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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+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 chan
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, > 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: [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: [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 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
-#include
-
-#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--)
-
[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
-#include
-#include
-#include
-
-#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 bit
[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>
[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
+
+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
+#include
+#include
+
+/** 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, 0x0a
[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
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] 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] 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+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
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: [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: [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
[PATCH] eeprom_93cx6: Add write support
This patch addes support for writing to the eeprom,
this also moves some duplicate code into seperate functions.
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 2006-12-13 19:04:44.0
+0100
+++ wireless-dev-eeprom/include/linux/eeprom_93cx6.h2006-12-13
18:28:36.0 +0100
@@ -32,6 +32,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
@@ -68,3 +70,8 @@
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/eeprom_93cx6.c
wireless-dev-eeprom/lib/eeprom_93cx6.c
--- wireless-dev/lib/eeprom_93cx6.c 2006-12-13 19:04:44.0 +0100
+++ wireless-dev-eeprom/lib/eeprom_93cx6.c 2006-12-13 18:50:25.0
+0100
@@ -49,6 +49,42 @@
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)
{
@@ -123,6 +159,44 @@
}
}
+static void eeprom_93cx6_ewen(struct eeprom_93cx6 *eeprom)
+{
+ /*
+* Initialize the eeprom register
+*/
+ eeprom_93cx6_startup(eeprom);
+
+ /*
+* Select the read opcode and the word to be read.
+*/
+ eeprom_93cx6_write_bits(eeprom, PCI_EEPROM_EWEN_OPCODE, 5);
+ eeprom_93cx6_write_bits(eeprom, 0, 6);
+
+ /*
+* Cleanup eeprom register.
+*/
+ eeprom_93cx6_cleanup(eeprom);
+}
+
+static void eeprom_93cx6_ewds(struct eeprom_93cx6 *eeprom)
+{
+ /*
+* Initialize the eeprom register
+*/
+ eeprom_93cx6_startup(eeprom);
+
+ /*
+* Select the read opcode and the word to be read.
+*/
+ eeprom_93cx6_write_bits(eeprom, PCI_EEPROM_EWDS_OPCODE, 5);
+ eeprom_93cx6_write_bits(eeprom, 0, 6);
+
+ /*
+* Cleanup eeprom register.
+*/
+ eeprom_93cx6_cleanup(eeprom);
+}
+
/**
* eeprom_93cx6_read - Read multiple words from eeprom
* @eeprom: Pointer to eeprom structure
@@ -139,20 +213,9 @@
u16 buffer = 0;
/*
-* Clear all flags, and enable chip select.
+* Initialize the eeprom register
*/
- 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);
+ eeprom_93cx6_startup(eeprom);
/*
* Select the read opcode and the word to be read.
@@ -167,18 +230,9 @@
eeprom_93cx6_read_bits(eeprom, &buffer, 16);
/*
-* 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.
+* Cleanup eeprom register.
*/
- eeprom_93cx6_pulse_high(eeprom);
- eeprom_93cx6_pulse_low(eeprom);
+ eeprom_93cx6_cleanup(eeprom);
/*
* The data from the eeprom is stored as little endian,
@@ -208,3 +262,82 @@
eeprom_93cx6_read(eeprom, word + i, data++);
}
EXPORT_SYMBOL_GPL(eeprom_93cx6_multiread);
+
+/**
+ * eeprom_93cx6_write - Write multiple words to the eepr
Re: [PATCH 0/2] d80211, rt2x00: fixes
On Wednesday 13 December 2006 18:38, Dan Williams wrote: > On Wed, 2006-12-13 at 12:12 -0500, 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 > > 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? rt2x00 completely uses the dscape stack, so I am not sure how he is managing this wpa without wpa_supplicant with rt2x00. Lennart, are you using rt2x00 or the legacy rt2500 driver? > > 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. :) 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
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 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
[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 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
Re: [PATCH 04/26] rt2x00: EEPROM 93Cx6
On Wednesday 13 December 2006 16:44, Lennart Sorensen wrote: > On Sat, Dec 09, 2006 at 02:05:06PM +0100, Ivo Van Doorn wrote: > > 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. > > Hmm, I wonder if this will be of help for me trying to read/write a > 93c46 connected to an exar uart (jsm driver). So far I was trying to > bit bang the IO from user space through the PCI registers, but having a > proper support in the driver would probably work better (so far I didn't > get it to work although I haven't tried very hard yet). 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). 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: [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. > > > > 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
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, > > > 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
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
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:
Re: [RFC] rfkill - Add support for input key to control wireless radio
rfkill with the fixes as suggested by Arjan.
- instead of a semaphore a mutex is now being used.
- open_count changing is now locked by the mutex.
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..4777d73
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,887 @@
+/*
+ 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+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;
+
+ /*
+* 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;
+
+ /*
+* 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;
+
+ /*
+* Key index number.
+*/
+ unsigned int key_index;
+
+ /*
+* List head structure to be used
+* to add this structure to the list.
+*/
+ struct list_head entry;
+};
+
+/*
+ * rfkill key type structure.
+ */
+struct rfkill_type {
+ /*
+* For sysfs representation.
+*/
+ struct class_device *cdev;
+
+ /*
+* Name of this radio type.
+*/
+ char *name;
+
+ /*
+* Key type identification. Value must be any
+* in the key_type enum.
+*/
+
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. > > Ok, what was the conclusion on the following issues? > > 1) What about rfkill keys that aren't routed via software? There are > two modes here: (a) the key is not hardwired to the module and the > driver is responsible for disabling the radio, (b) the key is hardwired > to the module and firmware or some other mechanism disables the radio > without driver interaction. I thought I'd heard of some (b) hardware, > mostly on older laptops, but does anyone know how prevalent (b) hardware > is? If there isn't any, do we care about it for now? On condition a) The driver is supposed to read the button status by the method provided by the device. (i.e. reading the register) the rfkill will periodically poll the driver (if the polling method has been provided by the driver) and the rfkill will do its work when the status of the register has changed. With the input device open, the user can listen to the events and switch off the radio manually (by using a tool like ifconfig or through the sysfs field) When the input device is not open, rfkill will use the driver provided callback functions to enable or disable the radio. b) In this case an interrupt is usually send to the driver about the event, or still the register will be possible. On both occassions the signal can still be caught by rfkill and handled further. If the event is send to userspace so the user can still perform tasks, the user can however not use the sysfs field to change the radio status since it is only allowed to switch the radio to the status that the button indicates. But the user can still perform tasks that should be handled (like stopping programs that need the network). I have heard that the broadcom chipsets toggle the radio state without intervention of the driver, and instead only send an interrupt event. > 2) Is there hardware that has separate keys for separate radios? i.e., > one key for Bluetooth, and one key for WiFi? I know Bastien has a > laptop where the same rfkill key handles _both_ ipw2200 and the BT > module, but in different ways: it actually removes the BT USB device > from the USB bus, but uses the normal ipw rfkill mechanism. Don't know about this hardware, my laptop has 2 seperate buttons for wifi and bluetooth. But it would be quite hard to caught such events cleanly, in this case the option would be to register 2 seperate rfkill_key structures. That way the key is represented twice to the user. But the enable_radio and disable _radio callback functions from the driver would make the callback for the wifi and bluetooth radio individually possibly. > 3) How does this interact with HAL? What's the userspace interface that > HAL will listen to to receive the signals? NetworkManager will need to > listen to HAL for these, as rfkill switches are one big thing that NM > does not handle now due to lack of a standard mechanism. In userspace there are 2 ways to listen, either regularly check the sysfs entry for the status. Or the prefered way listen to the input device that is created for each key. > In any case, any movement on rfkill interface/handling standardization > is quite welcome :) True, there are currently a lot of methods floating around. And a single way to notify the user would be a nice idea. :) 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 Sunday 03 December 2006 20:20, Arjan van de Ven wrote: > this open_count thing smells fishy to me; what are the locking rules for > it? What guarantees that the readers of it don't get the value changed > underneath them between looking at the value and doing whatever action > depends on it's value ? Good point, a race condition could indeed occur in the only reader that sends the signal to the userspace through the input device. I'll fix this immediately. 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
On Sunday 03 December 2006 20:18, Arjan van de Ven wrote: > On Sun, 2006-12-03 at 19:36 +0100, Ivo van Doorn wrote: > > + > > + down(&master->key_sem); > > + > > Hi, > > this one seems to be used as a mutex only, please consider using a mutex > instead, as is the default for new code since 2.6.16 or so It was indeed intended to be a mutex, I had however missed the presence of the mutex header in the kernel. Will fix this immediately. 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 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.. Good to hear, I'll check it out as well. If they are indeed similar the eeprom_93cx6 could be moved to a more general location as well so the module can be shared. :) 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] 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.
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..2a896db
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,880 @@
+/*
+ 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
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+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;
+
+ /*
+* 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
[PATCH 15/26] rt2x00: Add SIFS/PIFS/DIFS/EIFS defines
Introduce new defines for the SIFS, PIFS, EIFS, DIFS,
and make use of it in the drivers.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rU3 wireless-dev-stats/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-timing/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-stats/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-12-03 14:03:05.0 +0100
+++ wireless-dev-timing/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-12-03 14:10:28.0 +0100
@@ -524,24 +524,22 @@
int short_slot_time)
{
u32 reg;
- u32 value;
-
- short_slot_time = short_slot_time ? SHORT_SLOT_TIME : SLOT_TIME;
rt2x00_register_read(rt2x00dev, CSR11, ®);
- rt2x00_set_field32(®, CSR11_SLOT_TIME, short_slot_time);
+ rt2x00_set_field32(®, CSR11_SLOT_TIME,
+ short_slot_time ? SHORT_SLOT_TIME : SLOT_TIME);
rt2x00_register_write(rt2x00dev, CSR11, reg);
rt2x00_register_read(rt2x00dev, CSR18, ®);
rt2x00_set_field32(®, CSR18_SIFS, SIFS);
- rt2x00_set_field32(®, CSR18_PIFS, SIFS + short_slot_time);
+ rt2x00_set_field32(®, CSR18_PIFS,
+ short_slot_time ? SHORT_PIFS : PIFS);
rt2x00_register_write(rt2x00dev, CSR18, reg);
rt2x00_register_read(rt2x00dev, CSR19, ®);
- value = SIFS + (2 * short_slot_time);
- rt2x00_set_field32(®, CSR19_DIFS, value);
- value = SIFS + get_duration(IEEE80211_HEADER + ACK_SIZE, 10);
- rt2x00_set_field32(®, CSR19_EIFS, value);
+ rt2x00_set_field32(®, CSR19_DIFS,
+ short_slot_time ? SHORT_DIFS : DIFS);
+ rt2x00_set_field32(®, CSR19_EIFS, EIFS);
rt2x00_register_write(rt2x00dev, CSR19, reg);
rt2x00_register_read(rt2x00dev, TXCSR1, ®);
@@ -553,36 +551,26 @@
static void rt2400pci_config_rate(struct rt2x00_dev *rt2x00dev, const int rate)
{
struct ieee80211_conf *conf = &rt2x00dev->hw->conf;
- u32 reg[4];
+ u32 reg;
u32 value;
u32 preamble;
preamble = DEVICE_GET_RATE_FIELD(rate, PREAMBLE)
? SHORT_PREAMBLE : PREAMBLE;
- /*
-* Extract the allowed ratemask from the device specific rate value,
-* We need to set ARCSR1 to the basic rate mask so we need to mask
-* off the non-basic rates.
-*/
- reg[0] = DEVICE_GET_RATE_FIELD(rate, RATEMASK) & DEV_BASIC_RATE;
-
- rt2x00_register_write(rt2x00dev, ARCSR1, reg[0]);
-
- rt2x00_register_read(rt2x00dev, TXCSR1, ®[0]);
- value = SIFS + PLCP
- + (2 * ((conf->flags & IEEE80211_CONF_SHORT_SLOT_TIME) ?
- SHORT_SLOT_TIME : SLOT_TIME))
- + preamble
- + get_duration(ACK_SIZE, 10);
- rt2x00_set_field32(®[0], TXCSR1_ACK_TIMEOUT, value);
- value = SIFS + PLCP
- + preamble
- + get_duration(ACK_SIZE, 10);
- rt2x00_set_field32(®[0], TXCSR1_ACK_CONSUME_TIME, value);
- rt2x00_register_write(rt2x00dev, TXCSR1, reg[0]);
+ reg = DEVICE_GET_RATE_FIELD(rate, RATEMASK) & DEV_BASIC_RATE;
+ rt2x00_register_write(rt2x00dev, ARCSR1, reg);
+
+ rt2x00_register_read(rt2x00dev, TXCSR1, ®);
+ value = ((conf->flags & IEEE80211_CONF_SHORT_SLOT_TIME) ?
+SHORT_DIFS : DIFS) +
+ PLCP + preamble + get_duration(ACK_SIZE, 10);
+ rt2x00_set_field32(®, TXCSR1_ACK_TIMEOUT, value);
+ value = SIFS + PLCP + preamble + get_duration(ACK_SIZE, 10);
+ rt2x00_set_field32(®, TXCSR1_ACK_CONSUME_TIME, value);
+ rt2x00_register_write(rt2x00dev, TXCSR1, reg);
- preamble = DEVICE_GET_RATE_FIELD(rate, PREAMBLE) ? 8 : 0;
+ preamble = DEVICE_GET_RATE_FIELD(rate, PREAMBLE) ? 0x08 : 0x00;
rt2x00_register_write(rt2x00dev, ARCSR2, 0x00700400 | preamble);
rt2x00_register_write(rt2x00dev, ARCSR3, 0x00380401 | preamble);
diff -rU3 wireless-dev-stats/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
wireless-dev-timing/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
--- wireless-dev-stats/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-12-03 14:00:23.0 +0100
+++ wireless-dev-timing/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
2006-12-03 14:10:52.0 +0100
@@ -590,24 +590,22 @@
int short_slot_time)
{
u32 reg;
- u32 value;
-
- short_slot_time = short_slot_time ? SHORT_SLOT_TIME : SLOT_TIME;
rt2x00_register_read(rt2x00dev, CSR11, ®);
- rt2x00_set_field32(®, CSR11_SLOT_TIME, short_slot_time);
+ rt2x00_set_field32(®, CSR11_SLOT_TIME,
+ short_slot_time ? SHORT_SLOT_TIME : SLOT_TIME);
rt2x00_register_write(rt2x00dev, CSR11, reg);
rt2x00_register_read(rt2x00dev, CSR18, ®);
rt2x00_set_field32(®, CSR18_SIFS, SIFS);
- rt2x00_set_field32(®, CSR18_PIFS, SIFS + short_slot_time);
+ rt2x00_set_field32(®, CSR18
[PATCH 03/26] rt2x00: descriptors
Remove txd and rxd descriptor structures. All access to the descriptors should be done by treating the descriptor as a register. For this we do add a desc structure containing a array, and several methods for reading and writing to that array. This is prepares rt2x00 for the overhaul of the byteordering mechanism. Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]> --- http://www.mendiosus.nl/rt2x00/03_descriptor.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 24/26] rt2x00: Misc. fixes
Misc fixes.
* Correctly set the RFCSR value using the setfield function.
* Remove the DISABLE_RX register setting during initialization.
* Changing the durationid should not add but overwrite. (sparse fix)
* Prevent false warnings about ignoring ring initialization,
by only mentioning which rings have been initialized.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rU3 wireless-dev-usb/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-misc/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-usb/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-12-03 15:21:22.0 +0100
+++ wireless-dev-misc/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
2006-12-03 15:48:37.0 +0100
@@ -188,7 +188,8 @@
return;
rf_write:
- reg = value;
+ reg = 0;
+ rt2x00_set_field32(®, RFCSR_VALUE, value);
rt2x00_set_field32(®, RFCSR_NUMBER_OF_BITS, 20);
rt2x00_set_field32(®, RFCSR_IF_SELECT, 0);
rt2x00_set_field32(®, RFCSR_BUSY, 1);
@@ -882,7 +883,6 @@
rt2x00_desc_read(rxd, 0, &word);
rt2x00_set_field32(&word, RXD_W0_OWNER_NIC, 1);
rt2x00_desc_write(rxd, 0, word);
-
}
rt2x00_ring_index_clear(ring);
@@ -1011,10 +1011,6 @@
rt2x00_register_write(rt2x00dev, CNT3, 0x3f08);
- rt2x00_register_read(rt2x00dev, RXCSR0, ®);
- rt2x00_set_field32(®, RXCSR0_DISABLE_RX, 0);
- rt2x00_register_write(rt2x00dev, RXCSR0, reg);
-
rt2x00_register_write(rt2x00dev, MACCSR0, 0x00217223);
rt2x00_register_write(rt2x00dev, MACCSR1, 0x00235518);
@@ -1372,7 +1368,7 @@
frame_control = IEEE80211_FTYPE_CTL | IEEE80211_STYPE_RTS;
ieee80211hdr->frame_control = cpu_to_le16(frame_control);
- ieee80211hdr->duration_id += cpu_to_le16(duration);
+ ieee80211hdr->duration_id = cpu_to_le16(duration);
ieee80211hdr->seq_ctrl = 0;
@@ -1984,7 +1980,7 @@
rt2400pci_config_txpower(rt2x00dev, conf->power_level);
rt2400pci_config_antenna(rt2x00dev, conf->antenna_sel);
rt2400pci_config_duration(rt2x00dev,
- conf->flags & IEEE80211_CONF_SHORT_SLOT_TIME);
+ (conf->flags & IEEE80211_CONF_SHORT_SLOT_TIME));
rt2400pci_config_phymode(rt2x00dev, conf->phymode);
/*
@@ -2127,7 +2123,7 @@
/*
* Allocate scanning structure to store scanning info.
*/
- rt2x00dev->scan = kmalloc(sizeof(struct scanning), GFP_ATOMIC);
+ rt2x00dev->scan = kzalloc(sizeof(struct scanning), GFP_ATOMIC);
if (!rt2x00dev->scan)
return -ENOMEM;
@@ -2206,10 +2202,8 @@
* per queue. So by default we only configure the TX queue,
* and ignore all other configurations.
*/
- if (queue != IEEE80211_TX_QUEUE_DATA0) {
- NOTICE("Ignoring configuration for queue %d.\n", queue);
+ if (queue != IEEE80211_TX_QUEUE_DATA0)
return -EINVAL;
- }
memcpy(&ring->tx_params, params, sizeof(*params));
@@ -2232,6 +2226,9 @@
*/
rt2400pci_config_cw(rt2x00dev, &ring->tx_params);
+ INFO("Configured TX ring %d - CWmin: %d, CWmax: %d.\n",
+ queue, ring->tx_params.cw_min, ring->tx_params.cw_max);
+
return 0;
}
@@ -2267,10 +2264,9 @@
static void rt2400pci_reset_tsf(struct ieee80211_hw *hw)
{
struct rt2x00_dev *rt2x00dev = hw->priv;
- u32 reg = 0;
- rt2x00_register_write(rt2x00dev, CSR16, reg);
- rt2x00_register_write(rt2x00dev, CSR17, reg);
+ rt2x00_register_write(rt2x00dev, CSR16, 0);
+ rt2x00_register_write(rt2x00dev, CSR17, 0);
}
static int rt2400pci_beacon_update(struct ieee80211_hw *hw,
@@ -2293,6 +2289,9 @@
*/
rt2x00_set_sequence(skb, &rt2x00dev->interface.sequence);
+ /*
+* Update the beacon entry.
+*/
memcpy(rt2x00_data_addr(entry), skb->data, skb->len);
rt2400pci_write_tx_desc(rt2x00dev, rt2x00_desc_addr(entry),
skb, control);
@@ -2470,7 +2469,7 @@
/*
* Check if the BBP tuning should be enabled.
*/
- if (!rt2x00_get_field16(eeprom, EEPROM_ANTENNA_RX_AGCVGC))
+ if (!rt2x00_get_field16(eeprom, EEPROM_ANTENNA_RX_AGCVGC_TUNING))
SET_FLAG(rt2x00dev, CONFIG_DISABLE_LINK_TUNING);
return 0;
@@ -2713,6 +2712,9 @@
rt2x00dev->dev = pci_dev;
rt2x00dev->hw = hw;
+ /*
+* Allocate the CSR memory.
+*/
rt2x00dev->csr_addr = ioremap(
pci_resource_start(rt2x00dev_pci(rt2x00dev), 0),
pci_resource_len(rt2x00dev_pci(rt2x00dev), 0));
diff -rU3 wireless-dev-usb/drivers/net/wireless/d80211/rt2x00/rt2400pci.h
wireless-dev-misc/drivers/net/w
[PATCH 06/26] rt2x00: compile fix for d80211 update
Fix rt2x00 compilation problems due to the d80211 update. Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]> --- http://www.mendiosus.nl/rt2x00/06_d80211.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 00/26] rt2x00
Hi, This patch series will bring rt2x00 completely up to date. This includes the compile fixes after last d80211 update, and brings so many fixes it is hard to summarize them. Basically what it comes down to is that with this version several people have managed to get the drivers working and even have master mode operational in some situations. Of course it is not yet bug free, after the last d80211 update several people have reported crashes when the driver was still loaded while doing a shutdown. The kernel traces are very vague and don't give a good clue on where the problem might come from, so there isn't much to say about that yet. Note that this patch series contains the crc-itu-t patch. I have intentionally put this patch at the end of the series, because its succes with that patch last time I had send it. This patch had earlier been send as a module for the /lib folder in the kernel, but besides Randy Dunlap on the linux-kernel mailing list nobody has responded either on this list or on the linux-kernel list. So instead of placing it in the /lib folder of the linux kernel, I have this time placed it in the rt2x00 folder where it should be acceptable. Another new module that has been added is the eeprom_93cx6 module, that has been generically build, which means that it is not rt2x00 specific. I kept it in the rt2x00 folder since only rt2x00 uses it, and I have not looked for other drivers that might need this module. Some of the patches are too big to be inlined into the seperate mails, so those have been placed online. 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
