Re: [RFC] rfkill - Add support for input key to control wireless radio
On Saturday 31 March 2007 08:49, Ivo van Doorn wrote:
>
> Well that would mean rfkill would be ready to applied to one of the kernel
> trees right? :)
Well, that would be up to that particular tree maintainer. I am not sure
who maintains the net/... David Miller maybe? Anyway, below is the same
rfkill patch that I posted before except that everything is moved in
net/ instead of being in drivers/input/misc.
I will make sure that input-polldev will get into input three tough.
--
Dmitry
From: Ivo van Doorn <[EMAIL PROTECTED]>
Input: rfkill - Add support for input key to control wireless radio
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
include/linux/rfkill.h| 85 +
net/Kconfig |1
net/Makefile |1
net/rfkill/Kconfig| 24 ++
net/rfkill/Makefile |6
net/rfkill/rfkill-input.c | 169 +++
net/rfkill/rfkill.c | 400 ++
7 files changed, 686 insertions(+)
Index: work/include/linux/rfkill.h
===
--- /dev/null
+++ work/include/linux/rfkill.h
@@ -0,0 +1,85 @@
+#ifndef __RFKILL_H
+#define __RFKILL_H
+
+/*
+ * Copyright (C) 2006 Ivo van Doorn
+ * Copyright (C) 2007 Dmitry Torokhov
+ *
+ * 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
+
+/**
+ * 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,
+};
+
+enum rfkill_state {
+ RFKILL_STATE_OFF= 0,
+ RFKILL_STATE_ON = 1,
+};
+
+/**
+ * struct rfkill - rfkill control structure.
+ * @name: Name of the switch.
+ * @type: Radio type which the button controls, the value stored
+ * here should be a value from enum rfkill_type.
+ * @state: State of the switch (on/off).
+ * @user_claim: Set when the switch is controlled exlusively by userspace.
+ * @mutex: Guards switch state transitions
+ * @data: Pointer to the RF button drivers private data which will be
+ * passed along when toggling radio state.
+ * @toggle_radio(): Mandatory handler to control state of the radio.
+ * @dev: Device structure integrating the switch into device tree.
+ * @node: Used to place switch into list of all switches known to the
+ * the system.
+ *
+ * This structure represents a RF switch located on a network device.
+ */
+struct rfkill {
+ char *name;
+ enum rfkill_type type;
+
+ enum rfkill_state state;
+ bool user_claim;
+
+ struct mutex mutex;
+
+ void *data;
+ int (*toggle_radio)(void *data, enum rfkill_state state);
+
+ struct device dev;
+ struct list_head node;
+};
+#define to_rfkill(d) container_of(d, struct rfkill, dev)
+
+struct rfkill *rfkill_allocate(struct device *parent, enum rfkill_type type);
+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 */
Index: work/net/Kconfig
===
--- work.orig/net/Kconfig
+++ work/net/Kconfig
@@ -220,6 +220,7 @@ source "net/ax25/Kconfig"
source "net/irda/Kconfig"
source "net/bluetooth/Kconfig"
source "net/ieee80211/Kconfig"
+source "net/rfkill/Kconfig"
config WIRELESS_EXT
bool
Index: work/net/Makefile
===
--- work.orig/net/Makefile
+++ work/net/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_IEEE80211) += ieee80211/
obj-$(CONFIG_TIPC) += tipc/
obj-$(CONFIG_NETLABEL) += netlabel/
obj-$(CONFIG_IUCV) += iucv/
+obj-$(CONFIG_RFKILL) += rfkill/
ifeq ($(CONFIG_NET),y)
obj-$(CONFIG_SYSCTL) += sysctl_net.o
Index: work/net/rfkill/Kconfig
===
--- /dev/null
+++
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Saturday 31 March 2007 08:49, Ivo van Doorn wrote:
Well that would mean rfkill would be ready to applied to one of the kernel
trees right? :)
Well, that would be up to that particular tree maintainer. I am not sure
who maintains the net/... David Miller maybe? Anyway, below is the same
rfkill patch that I posted before except that everything is moved in
net/ instead of being in drivers/input/misc.
I will make sure that input-polldev will get into input three tough.
--
Dmitry
From: Ivo van Doorn [EMAIL PROTECTED]
Input: rfkill - Add support for input key to control wireless radio
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
include/linux/rfkill.h| 85 +
net/Kconfig |1
net/Makefile |1
net/rfkill/Kconfig| 24 ++
net/rfkill/Makefile |6
net/rfkill/rfkill-input.c | 169 +++
net/rfkill/rfkill.c | 400 ++
7 files changed, 686 insertions(+)
Index: work/include/linux/rfkill.h
===
--- /dev/null
+++ work/include/linux/rfkill.h
@@ -0,0 +1,85 @@
+#ifndef __RFKILL_H
+#define __RFKILL_H
+
+/*
+ * Copyright (C) 2006 Ivo van Doorn
+ * Copyright (C) 2007 Dmitry Torokhov
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the
+ * Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/device.h
+
+/**
+ * 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,
+};
+
+enum rfkill_state {
+ RFKILL_STATE_OFF= 0,
+ RFKILL_STATE_ON = 1,
+};
+
+/**
+ * struct rfkill - rfkill control structure.
+ * @name: Name of the switch.
+ * @type: Radio type which the button controls, the value stored
+ * here should be a value from enum rfkill_type.
+ * @state: State of the switch (on/off).
+ * @user_claim: Set when the switch is controlled exlusively by userspace.
+ * @mutex: Guards switch state transitions
+ * @data: Pointer to the RF button drivers private data which will be
+ * passed along when toggling radio state.
+ * @toggle_radio(): Mandatory handler to control state of the radio.
+ * @dev: Device structure integrating the switch into device tree.
+ * @node: Used to place switch into list of all switches known to the
+ * the system.
+ *
+ * This structure represents a RF switch located on a network device.
+ */
+struct rfkill {
+ char *name;
+ enum rfkill_type type;
+
+ enum rfkill_state state;
+ bool user_claim;
+
+ struct mutex mutex;
+
+ void *data;
+ int (*toggle_radio)(void *data, enum rfkill_state state);
+
+ struct device dev;
+ struct list_head node;
+};
+#define to_rfkill(d) container_of(d, struct rfkill, dev)
+
+struct rfkill *rfkill_allocate(struct device *parent, enum rfkill_type type);
+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 */
Index: work/net/Kconfig
===
--- work.orig/net/Kconfig
+++ work/net/Kconfig
@@ -220,6 +220,7 @@ source net/ax25/Kconfig
source net/irda/Kconfig
source net/bluetooth/Kconfig
source net/ieee80211/Kconfig
+source net/rfkill/Kconfig
config WIRELESS_EXT
bool
Index: work/net/Makefile
===
--- work.orig/net/Makefile
+++ work/net/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_IEEE80211) += ieee80211/
obj-$(CONFIG_TIPC) += tipc/
obj-$(CONFIG_NETLABEL) += netlabel/
obj-$(CONFIG_IUCV) += iucv/
+obj-$(CONFIG_RFKILL) += rfkill/
ifeq ($(CONFIG_NET),y)
obj-$(CONFIG_SYSCTL) += sysctl_net.o
Index: work/net/rfkill/Kconfig
===
--- /dev/null
+++
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 linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On 3/30/07, Ivo van Doorn <[EMAIL PROTECTED]> wrote: > > > > > > 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. We could also consider the ./net itself. rfkill is not a driver, it is a facility. > > - 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. 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. 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. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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
On 3/30/07, Ivo van Doorn <[EMAIL PROTECTED]> wrote: 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? 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. > 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? 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 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. 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? 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. 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(>dev);
> + rfkill_remove_switch(rfkill);
> + put_device(>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 linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On 3/30/07, Ivo van Doorn [EMAIL PROTECTED] wrote: 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? 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. 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? 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 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. 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? 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. personally I would prefer enforcing drivers to call allocate() register() unregister() free() Especially with unregister() doing
Re: [RFC] rfkill - Add support for input key to control wireless radio
There is also an input handler that catces KEY_WLAN and KEY_BLUETOOTH events passing through input system and toggles state of all RF switches of appropriate type registered with rfkill system (unless a switch was claimed by userspace in which case it is left alone). I think this provides basic functionality that most of the users need and any advanced control will have to be done from userspace. Shouldn't a KEY_IRDA be added as well? It isn't currently defined in input.h yet, but perhaps it actually should? Or is IRDA treated differently for a specific reason? Do we actually have cards with IRDA switches? We are kind of tight in input KEY_ namespace so I am hesitant to add defines before there actual users. Ah ok. Well that shouldn't be a problem, IRDA could be added once there are users for it. I am not sure if there are any devices with IRDA switches, so it shouldn't be a big problem. In a followup patch there is a skeleton code for creating polled input devices. For cards that have button physically connected their drivers will have to register a separate input device and let either input handler or userspace application take care of switching RF state appropriately. My only concern is where rfkill code should live. Since it is no longer dependent on input core (embedded systems might disable rfkill-input and use bare rfkill and control state from userspace) it does not need to live in drivers/input. How about: rfkill - drivers/misc Not in net? Well in drivers/net are the network drivers but not the irda and bluetooth drivers, those are located in different folders in drivers/ so I think misc would be the most suitable location. rfkill_input - input/misc I can go both ways on this one as it crosses line between input and rfkill. I think from user/Kconfig point of view it is better to keep it together with rfkill: user woudl select rfkill option and right then and there decide if he wants to give the kernel ability to automatically control RF switche Makes sense. input_polldev - lib/ (perhaps small namechange to rfkill_polldev?) No, I do not want to change name - I have bunch of drivers that can me converted to use this skeleton - wistron, aaedkbd, hdaps, ams, cobalt_btns. It is also pure input-related function so it is the only module that definitely belongs to drivers/input/misc. Ok. :) It would scatter the components a bit, but since each of those modules has its own specific task this would make the most sense. And by setting the depends and select fields for the menu entries correctly it shouldn't be too big of a problem. Please let me know what you think. Just to get it straight on how these 3 modules would cooperate (before I start mixing things up) ;) - rfkill - Drivers register to the rfkill module, rfkill - Provides the sysfs interface - Drivers that don't require polling should report the events to this module Not quite. Drivers that have buttons do not require polling still should create an input device and register it with input layer. Except that with interrupt-driven devices there is not much you can stub out so you just have to do input_allocate_device/input_register_device. - rfkill_input - Provides input device visible to userspace No, rfkill-input is not an input device but input handler (or input interface). It routes input events from buttons into switches (see below). - input_polldev - Handlers polling, where the driver should check what the previous state was and the driver should send the event to rfkill. This is the input device visible to userspace and kernel. It polls state of the button and sends KEY_WLAN/KEY_BLUETOOTH events through input layer. They get distributed through various input handlers such as evdev and rfkill-input. Evdev provides route for events to userspace where application can listen to events and then toggle RF switches according to the current policy via /sys/class/rfkill/rfkillXXX/state. Rfkill-input provides in-kernel route for events into rfkill system. If rfkill-input is loaded switches that are not claimed by userspace will be toggled automatically. Does this make sense? Yes, but what if the user loads both modules or has them both compiled in? Shouldn't there be some protection against that, since both handlers should not be active at the same time. Note that we don't start polling the state of button until tare are users of that input device. If rfkill-input is loaded then there is a user right away. Otherwise we wait for userspace to open evdev node. Sounds good. personally I would prefer enforcing drivers to call allocate() register() unregister() free() Especially with unregister() doing the same steps as free() (put_device) might be somwhat confusing. But might be just me. ;) I know but for
Re: [RFC] rfkill - Add support for input key to control wireless radio
On 3/30/07, Ivo van Doorn [EMAIL PROTECTED] wrote: 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. We could also consider the ./net itself. rfkill is not a driver, it is a facility. - 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. 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. 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. -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Wednesday 31 January 2007 06:20, Ivo van Doorn wrote: > > 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) > Hi Ivo, 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. 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. 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. Please let me know what you think. -- Dmitry From: Ivo van Doorn <[EMAIL PROTECTED]> Input: rfkill - Add support for input key to control wireless radio Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]> Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]> --- drivers/input/misc/Kconfig| 26 ++ drivers/input/misc/Makefile |2 drivers/input/misc/rfkill-input.c | 169 drivers/input/misc/rfkill.c | 400 ++ include/linux/rfkill.h| 85 5 files changed, 682 insertions(+) Index: work/drivers/input/misc/Kconfig === --- work.orig/drivers/input/misc/Kconfig +++ work/drivers/input/misc/Kconfig @@ -98,4 +98,30 @@ 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 switch support" + help + Say Y here if you want to have control over RF switches + found on many WiFi, Bluetooth and IRDA cards. + + To compile this driver as a module, choose M here: the + module will be called rfkill. + +if RFKILL + +config RFKILL_INPUT + tristate "Input layer to RF switch bridge" + depends on INPUT + help + Say Y here if you want kernel automatically toggle state + of RF switches on and off when user presses appropriate + button an a key on the keyboard. Without this module + you need a some kind of userspace application to control + state of the switches. + + To compile this driver as a module, choose M here: the + module will be called rfkill-input. + +endif + endif Index: work/drivers/input/misc/Makefile === --- work.orig/drivers/input/misc/Makefile +++ work/drivers/input/misc/Makefile @@ -13,3 +13,5 @@ obj-$(CONFIG_INPUT_WISTRON_BTNS) += wist obj-$(CONFIG_INPUT_ATLAS_BTNS) += atlas_btns.o obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o +obj-$(CONFIG_RFKILL) += rfkill.o +obj-$(CONFIG_RFKILL_INPUT) += rfkill-input.o Index: work/drivers/input/misc/rfkill.c === --- /dev/null +++ work/drivers/input/misc/rfkill.c @@ -0,0 +1,400 @@ +/* + * Copyright (C) 2006 Ivo van Doorn + * Copyright (C) 2007 Dmitry Torokhov + * + * 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, + *
Re: [RFC] rfkill - Add support for input key to control wireless radio
Input: polled device skeleton
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/input/misc/Kconfig | 11 ++
drivers/input/misc/Makefile|1
drivers/input/misc/input-polldev.c | 149 +
include/linux/input-polldev.h | 46 +++
4 files changed, 207 insertions(+)
Index: linux/drivers/input/misc/Kconfig
===
--- linux.orig/drivers/input/misc/Kconfig
+++ linux/drivers/input/misc/Kconfig
@@ -81,6 +81,17 @@ config INPUT_UINPUT
To compile this driver as a module, choose M here: the
module will be called uinput.
+config INPUT_POLLDEV
+ tristate "Polled input device skeleton"
+ help
+ Say Y here if you are using a driver for an input
+ device that periodically polls hardware state. This
+ option is only useful for out-of-tree drivers since
+ in-tree drivers select it automatically.
+
+ To compile this driver as a module, choose M here: the
+ module will be called input-polldev.
+
config HP_SDC_RTC
tristate "HP SDC Real Time Clock"
depends on GSC || HP300
Index: linux/drivers/input/misc/Makefile
===
--- linux.orig/drivers/input/misc/Makefile
+++ linux/drivers/input/misc/Makefile
@@ -4,6 +4,7 @@
# Each configuration option enables a list of files.
+obj-$(CONFIG_INPUT_POLLDEV)+= input-polldev.o
obj-$(CONFIG_INPUT_SPARCSPKR) += sparcspkr.o
obj-$(CONFIG_INPUT_PCSPKR) += pcspkr.o
obj-$(CONFIG_INPUT_M68K_BEEP) += m68kspkr.o
Index: linux/drivers/input/misc/input-polldev.c
===
--- /dev/null
+++ linux/drivers/input/misc/input-polldev.c
@@ -0,0 +1,149 @@
+/*
+ * Generic implementation of a polled input device
+
+ * Copyright (c) 2007 Dmitry Torokhov
+ *
+ * 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.
+ */
+
+#include
+#include
+
+static DEFINE_MUTEX(polldev_mutex);
+static int polldev_users;
+static struct workqueue_struct *polldev_wq;
+
+static void input_polled_device_work(struct work_struct *work)
+{
+ struct input_polled_dev *dev =
+ container_of(work, struct input_polled_dev, work.work);
+
+ dev->poll(dev);
+ queue_delayed_work(polldev_wq, >work,
+ msecs_to_jiffies(dev->poll_interval));
+}
+
+static int input_open_polled_device(struct input_dev *input)
+{
+ struct input_polled_dev *dev = input->private;
+ int retval;
+
+ retval = mutex_lock_interruptible(_mutex);
+ if (retval)
+ return retval;
+
+ if (!polldev_users++) {
+ polldev_wq = create_singlethread_workqueue("ipolldevd");
+ if (!polldev_wq) {
+ printk(KERN_ERR "input-polldev: failed to create "
+ "ipolldevd workqueue\n");
+ goto out;
+ }
+ }
+
+ if (dev->flush)
+ dev->flush(dev);
+ queue_delayed_work(polldev_wq, >work,
+ msecs_to_jiffies(dev->poll_interval));
+
+ out:
+ mutex_unlock(_mutex);
+ return retval;
+}
+
+static void input_close_polled_device(struct input_dev *input)
+{
+ struct input_polled_dev *dev = input->private;
+
+ cancel_rearming_delayed_workqueue(polldev_wq, >work);
+
+ mutex_lock(_mutex);
+ if (!--polldev_users)
+ destroy_workqueue(polldev_wq);
+ mutex_unlock(_mutex);
+}
+
+/**
+ * input_allocate_polled_device - allocated memory polled device
+ *
+ * The function allocates memory for a polled device and also
+ * for an input device associated with this polled device.
+ */
+struct input_polled_dev *input_allocate_polled_device(void)
+{
+ struct input_polled_dev *dev;
+
+ dev = kzalloc(sizeof(struct input_polled_dev), GFP_KERNEL);
+ if (!dev)
+ return NULL;
+
+ dev->input = input_allocate_device();
+ if (!dev->input) {
+ kfree(dev);
+ return NULL;
+ }
+
+ return dev;
+}
+EXPORT_SYMBOL(input_allocate_polled_device);
+
+/**
+ * input_free_polled_device - free memory allocated for polled device
+ * @dev: device to free
+ *
+ * The function frees memory allocated for pollign device and drops
+ * reference to the associated input device (if present).
+ */
+void input_free_polled_device(struct input_polled_dev *dev)
+{
+ if (dev) {
+ input_free_device(dev->input);
+ kfree(dev);
+ }
+}
+EXPORT_SYMBOL(input_free_polled_device);
+
+/**
+ * input_register_polled_device - register polled device
+ * @dev: device to register
+ *
+ * The function
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Wednesday 31 January 2007 06:20, Ivo van Doorn wrote: 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) Hi Ivo, 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. 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. 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. Please let me know what you think. -- Dmitry From: Ivo van Doorn [EMAIL PROTECTED] Input: rfkill - Add support for input key to control wireless radio Signed-off-by Ivo van Doorn [EMAIL PROTECTED] Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED] --- drivers/input/misc/Kconfig| 26 ++ drivers/input/misc/Makefile |2 drivers/input/misc/rfkill-input.c | 169 drivers/input/misc/rfkill.c | 400 ++ include/linux/rfkill.h| 85 5 files changed, 682 insertions(+) Index: work/drivers/input/misc/Kconfig === --- work.orig/drivers/input/misc/Kconfig +++ work/drivers/input/misc/Kconfig @@ -98,4 +98,30 @@ 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 switch support + help + Say Y here if you want to have control over RF switches + found on many WiFi, Bluetooth and IRDA cards. + + To compile this driver as a module, choose M here: the + module will be called rfkill. + +if RFKILL + +config RFKILL_INPUT + tristate Input layer to RF switch bridge + depends on INPUT + help + Say Y here if you want kernel automatically toggle state + of RF switches on and off when user presses appropriate + button an a key on the keyboard. Without this module + you need a some kind of userspace application to control + state of the switches. + + To compile this driver as a module, choose M here: the + module will be called rfkill-input. + +endif + endif Index: work/drivers/input/misc/Makefile === --- work.orig/drivers/input/misc/Makefile +++ work/drivers/input/misc/Makefile @@ -13,3 +13,5 @@ obj-$(CONFIG_INPUT_WISTRON_BTNS) += wist obj-$(CONFIG_INPUT_ATLAS_BTNS) += atlas_btns.o obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o +obj-$(CONFIG_RFKILL) += rfkill.o +obj-$(CONFIG_RFKILL_INPUT) += rfkill-input.o Index: work/drivers/input/misc/rfkill.c === --- /dev/null +++ work/drivers/input/misc/rfkill.c @@ -0,0 +1,400 @@ +/* + * Copyright (C) 2006 Ivo van Doorn + * Copyright (C) 2007 Dmitry Torokhov + * + * 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;
Re: [RFC] rfkill - Add support for input key to control wireless radio
Input: polled device skeleton
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/input/misc/Kconfig | 11 ++
drivers/input/misc/Makefile|1
drivers/input/misc/input-polldev.c | 149 +
include/linux/input-polldev.h | 46 +++
4 files changed, 207 insertions(+)
Index: linux/drivers/input/misc/Kconfig
===
--- linux.orig/drivers/input/misc/Kconfig
+++ linux/drivers/input/misc/Kconfig
@@ -81,6 +81,17 @@ config INPUT_UINPUT
To compile this driver as a module, choose M here: the
module will be called uinput.
+config INPUT_POLLDEV
+ tristate Polled input device skeleton
+ help
+ Say Y here if you are using a driver for an input
+ device that periodically polls hardware state. This
+ option is only useful for out-of-tree drivers since
+ in-tree drivers select it automatically.
+
+ To compile this driver as a module, choose M here: the
+ module will be called input-polldev.
+
config HP_SDC_RTC
tristate HP SDC Real Time Clock
depends on GSC || HP300
Index: linux/drivers/input/misc/Makefile
===
--- linux.orig/drivers/input/misc/Makefile
+++ linux/drivers/input/misc/Makefile
@@ -4,6 +4,7 @@
# Each configuration option enables a list of files.
+obj-$(CONFIG_INPUT_POLLDEV)+= input-polldev.o
obj-$(CONFIG_INPUT_SPARCSPKR) += sparcspkr.o
obj-$(CONFIG_INPUT_PCSPKR) += pcspkr.o
obj-$(CONFIG_INPUT_M68K_BEEP) += m68kspkr.o
Index: linux/drivers/input/misc/input-polldev.c
===
--- /dev/null
+++ linux/drivers/input/misc/input-polldev.c
@@ -0,0 +1,149 @@
+/*
+ * Generic implementation of a polled input device
+
+ * Copyright (c) 2007 Dmitry Torokhov
+ *
+ * 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.
+ */
+
+#include linux/jiffies.h
+#include linux/input-polldev.h
+
+static DEFINE_MUTEX(polldev_mutex);
+static int polldev_users;
+static struct workqueue_struct *polldev_wq;
+
+static void input_polled_device_work(struct work_struct *work)
+{
+ struct input_polled_dev *dev =
+ container_of(work, struct input_polled_dev, work.work);
+
+ dev-poll(dev);
+ queue_delayed_work(polldev_wq, dev-work,
+ msecs_to_jiffies(dev-poll_interval));
+}
+
+static int input_open_polled_device(struct input_dev *input)
+{
+ struct input_polled_dev *dev = input-private;
+ int retval;
+
+ retval = mutex_lock_interruptible(polldev_mutex);
+ if (retval)
+ return retval;
+
+ if (!polldev_users++) {
+ polldev_wq = create_singlethread_workqueue(ipolldevd);
+ if (!polldev_wq) {
+ printk(KERN_ERR input-polldev: failed to create
+ ipolldevd workqueue\n);
+ goto out;
+ }
+ }
+
+ if (dev-flush)
+ dev-flush(dev);
+ queue_delayed_work(polldev_wq, dev-work,
+ msecs_to_jiffies(dev-poll_interval));
+
+ out:
+ mutex_unlock(polldev_mutex);
+ return retval;
+}
+
+static void input_close_polled_device(struct input_dev *input)
+{
+ struct input_polled_dev *dev = input-private;
+
+ cancel_rearming_delayed_workqueue(polldev_wq, dev-work);
+
+ mutex_lock(polldev_mutex);
+ if (!--polldev_users)
+ destroy_workqueue(polldev_wq);
+ mutex_unlock(polldev_mutex);
+}
+
+/**
+ * input_allocate_polled_device - allocated memory polled device
+ *
+ * The function allocates memory for a polled device and also
+ * for an input device associated with this polled device.
+ */
+struct input_polled_dev *input_allocate_polled_device(void)
+{
+ struct input_polled_dev *dev;
+
+ dev = kzalloc(sizeof(struct input_polled_dev), GFP_KERNEL);
+ if (!dev)
+ return NULL;
+
+ dev-input = input_allocate_device();
+ if (!dev-input) {
+ kfree(dev);
+ return NULL;
+ }
+
+ return dev;
+}
+EXPORT_SYMBOL(input_allocate_polled_device);
+
+/**
+ * input_free_polled_device - free memory allocated for polled device
+ * @dev: device to free
+ *
+ * The function frees memory allocated for pollign device and drops
+ * reference to the associated input device (if present).
+ */
+void input_free_polled_device(struct input_polled_dev *dev)
+{
+ if (dev) {
+ input_free_device(dev-input);
+ kfree(dev);
+ }
+}
+EXPORT_SYMBOL(input_free_polled_device);
+
+/**
+ * input_register_polled_device - register polled device
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 radio,
+* this can be any value of the user_claim
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 linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
Hope you will be resubmitting this.
And here is the new version,
I didn't make the name const as requested
that field is being passed to the class_device_create
method which requires a char* argument.
But I have made the flag field.
And now this time the patch actually includes the
changes I promised in last mail.
(mutex, workqueue api, etc)
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ba0e88c..6986d59 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,19 @@ config HP_SDC_RTC
Say Y here if you want to support the built-in real time clock
of the HP SDC controller.
+config RFKILL
+ tristate RF button support
+ help
+ If you say yes here, the rfkill driver will be build
+ which allowed network devices to register their hardware
+ RF button which controls the radio state. This driver
+ will then create an input device for it.
+
+ When the input device is not used, the rfkill driver
+ will make sure that when the RF button is pressed the radio
+ is enabled or disabled accordingly. When the input device
+ has been opened by the user this radio control will be left
+ to the user, and rfkill will only send the RF button status
+ change to userspace.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e788a1b 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o
+obj-$(CONFIG_RFKILL) += rfkill.o
diff --git a/drivers/input/misc/rfkill.c b/drivers/input/misc/rfkill.c
new file mode 100644
index 000..d8fda73
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,999 @@
+/*
+ Copyright (C) 2006 Ivo van Doorn
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/workqueue.h
+#include linux/list.h
+#include linux/mutex.h
+#include linux/input.h
+#include linux/rfkill.h
+
+MODULE_AUTHOR(Ivo van Doorn [EMAIL PROTECTED]);
+MODULE_VERSION(1.0);
+MODULE_DESCRIPTION(RF key support);
+MODULE_LICENSE(GPL);
+
+/*
+ * rfkill key structure.
+ */
+struct rfkill_key {
+ /*
+* For sysfs representation.
+*/
+ struct class_device *cdev;
+
+ /*
+* Pointer to rfkill structure
+* that was filled in by key driver.
+*/
+ const struct rfkill *rfkill;
+
+ /*
+* Pointer to type structure
+* that this key belongs to.
+*/
+ struct rfkill_type *type;
+
+ /*
+* Current status of the key which controls the radio,
+* this value will change after the key state has changed
+* after polling, or the key driver has send the new state
+* manually.
+*/
+#define RFKILL_KEY_RADIO_STATUS1
+
+ unsigned long flags;
+
+ /*
+* Input device for this key.
+*/
+ struct input_dev *input;
+
+ /*
+* List head structure to be used
+* to add this structure to the list.
+*/
+ struct list_head entry;
+};
+
+/*
+ * rfkill type structure.
+ */
+struct rfkill_type {
+ /*
+* For sysfs representation.
+*/
+ struct class_device *cdev;
+
+ /*
+* All access to the type structure and its
+* children (the keys) are protected by this mutex.
+*/
+ struct mutex mutex;
+
+ /*
+* Name of this radio type.
+*/
+ char *name;
+
+ /*
+* Key type identification. Value must be any
+* in the key_type enum.
+*/
+ unsigned int key_type;
+
+ /*
+* List of rfkill_key structures.
+*/
+ struct list_head key_list;
+
+ /*
+* Number of registered keys of this type.
+*/
+ unsigned int key_count;
+
+ /*
+* The claim the user has
Re: [RFC] rfkill - Add support for input key to control wireless radio
Hope you will be resubmitting this.
> +/*
> + * 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;
Since rfkill is basically a function pointer table,
can it be made const?
> + /*
> + * 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;
Maybe turn these bits into a bit values (set_bit/clear_bit) in an unsigned long.
> + /*
> + * 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?
> + /*
> + * 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;
const?
> + /*
> + * Key type identification. Value must be any
> + * in the key_type enum.
> + */
> + unsigned int key_type;
> +
> + /*
> + * Number of registered keys of this type.
> + */
> + unsigned int key_count;
> +};
> +
> +/*
> + * rfkill master structure.
> + */
> +struct rfkill_master {
> + /*
> + * For sysfs representation.
> + */
> + struct class *class;
> +
> + /*
> + * 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
> + /*
> + * List of available key types.
> + */
> + struct rfkill_type type[KEY_TYPE_MAX];
> +
> + /*
> + * Total number of registered keys.
> + */
> + unsigned int key_count;
> +
> + /*
> + * Number of keys that require polling
> + */
> + unsigned int poll_required;
> +
> + /*
> + * List of rfkill_key structures.
> + */
> + struct list_head key_list;
> +
> + /*
> + * 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?
> +};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
Well it's been a while, but here is an updated version of rfkill.
The changes since the version that was originally send are:
Spelling fixes (Thanks to Randy Dunlap)
THIS_MODULE is now a field in the rkfill_master (Suggested by Christoph Hellwig)
Move to the new Workqueue API
The open_count has been completely removed, decision making on which action
should
be taken is now handled by the user_claim field, which can be set through sysfs.
The possible choice include
1 - let rfkill handle everything without bothering the user
2 - let rfkill handle everything but send a notification to the user
3 - let rfkill send a notification only
The toggling of the keys is now type based, this means that if 1 key is being
toggled
all keys of the same type will be toggled.
As optimization and clearly seperate the keys per type, the rfkill_type
structure
now holds the list of the keys that belong to him. This has greatly reduced
the size of the rfkill_master structure.
sysfs will hold the following entries:
- The main folder: "rfkill"
- The main folder contains the type folders "wlan", "bluetooth" and "irda".
- Each type folder contains the files
- "claim" where the user claim can be read/written
- "status" The radio status of this type
- The folders for each key belonging to this type
- Each key folder contains the files
- "status" The status of this key
- "idev" The symlink to the input device entry in sysfs
- "dev" The symlink to the drivers device entry in sysfs
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ba0e88c..6986d59 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,19 @@ config HP_SDC_RTC
Say Y here if you want to support the built-in real time clock
of the HP SDC controller.
+config RFKILL
+ tristate "RF button support"
+ help
+ If you say yes here, the rfkill driver will be build
+ which allowed network devices to register their hardware
+ RF button which controls the radio state. This driver
+ will then create an input device for it.
+
+ When the input device is not used, the rfkill driver
+ will make sure that when the RF button is pressed the radio
+ is enabled or disabled accordingly. When the input device
+ has been opened by the user this radio control will be left
+ to the user, and rfkill will only send the RF button status
+ change to userspace.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e788a1b 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o
+obj-$(CONFIG_RFKILL) += rfkill.o
diff --git a/drivers/input/misc/rfkill.c b/drivers/input/misc/rfkill.c
new file mode 100644
index 000..6719962
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,988 @@
+/*
+ Copyright (C) 2006 Ivo van Doorn
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include
+#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 polling, or the key driver has send the new state
+* manually.
+*/
+ int key_status;
+
+
Re: [RFC] rfkill - Add support for input key to control wireless radio
Well it's been a while, but here is an updated version of rfkill.
The changes since the version that was originally send are:
Spelling fixes (Thanks to Randy Dunlap)
THIS_MODULE is now a field in the rkfill_master (Suggested by Christoph Hellwig)
Move to the new Workqueue API
The open_count has been completely removed, decision making on which action
should
be taken is now handled by the user_claim field, which can be set through sysfs.
The possible choice include
1 - let rfkill handle everything without bothering the user
2 - let rfkill handle everything but send a notification to the user
3 - let rfkill send a notification only
The toggling of the keys is now type based, this means that if 1 key is being
toggled
all keys of the same type will be toggled.
As optimization and clearly seperate the keys per type, the rfkill_type
structure
now holds the list of the keys that belong to him. This has greatly reduced
the size of the rfkill_master structure.
sysfs will hold the following entries:
- The main folder: rfkill
- The main folder contains the type folders wlan, bluetooth and irda.
- Each type folder contains the files
- claim where the user claim can be read/written
- status The radio status of this type
- The folders for each key belonging to this type
- Each key folder contains the files
- status The status of this key
- idev The symlink to the input device entry in sysfs
- dev The symlink to the drivers device entry in sysfs
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ba0e88c..6986d59 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,19 @@ config HP_SDC_RTC
Say Y here if you want to support the built-in real time clock
of the HP SDC controller.
+config RFKILL
+ tristate RF button support
+ help
+ If you say yes here, the rfkill driver will be build
+ which allowed network devices to register their hardware
+ RF button which controls the radio state. This driver
+ will then create an input device for it.
+
+ When the input device is not used, the rfkill driver
+ will make sure that when the RF button is pressed the radio
+ is enabled or disabled accordingly. When the input device
+ has been opened by the user this radio control will be left
+ to the user, and rfkill will only send the RF button status
+ change to userspace.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e788a1b 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o
+obj-$(CONFIG_RFKILL) += rfkill.o
diff --git a/drivers/input/misc/rfkill.c b/drivers/input/misc/rfkill.c
new file mode 100644
index 000..6719962
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,988 @@
+/*
+ Copyright (C) 2006 Ivo van Doorn
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/workqueue.h
+#include linux/list.h
+#include linux/mutex.h
+#include linux/input.h
+#include linux/rfkill.h
+
+MODULE_AUTHOR(Ivo van Doorn [EMAIL PROTECTED]);
+MODULE_VERSION(1.0);
+MODULE_DESCRIPTION(RF key support);
+MODULE_LICENSE(GPL);
+
+/*
+ * rfkill key structure.
+ */
+struct rfkill_key {
+ /*
+* For sysfs representation.
+*/
+ struct class_device *cdev;
+
+ /*
+* Pointer to rfkill structure
+* that was filled in by key driver.
+*/
+ struct rfkill *rfkill;
+
+ /*
+* Pointer to type structure
+* that this key belongs to.
+*/
+ struct rfkill_type *type;
+
+ /*
+* Current status of the key which controls the radio,
+* this value will change after the key state has changed
+* after polling, or the key driver has send the
Re: [RFC] rfkill - Add support for input key to control wireless radio
Hope you will be resubmitting this.
+/*
+ * 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;
Since rfkill is basically a function pointer table,
can it be made const?
+ /*
+ * 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;
Maybe turn these bits into a bit values (set_bit/clear_bit) in an unsigned long.
+ /*
+ * 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?
+ /*
+ * 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;
const?
+ /*
+ * Key type identification. Value must be any
+ * in the key_type enum.
+ */
+ unsigned int key_type;
+
+ /*
+ * Number of registered keys of this type.
+ */
+ unsigned int key_count;
+};
+
+/*
+ * rfkill master structure.
+ */
+struct rfkill_master {
+ /*
+ * For sysfs representation.
+ */
+ struct class *class;
+
+ /*
+ * 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
+ /*
+ * List of available key types.
+ */
+ struct rfkill_type type[KEY_TYPE_MAX];
+
+ /*
+ * Total number of registered keys.
+ */
+ unsigned int key_count;
+
+ /*
+ * Number of keys that require polling
+ */
+ unsigned int poll_required;
+
+ /*
+ * List of rfkill_key structures.
+ */
+ struct list_head key_list;
+
+ /*
+ * 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?
+};
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 polling, or the key driver has send the new state
+* manually.
+*/
+ int key_status;
+
+ /*
+* Input device for this
Re: [RFC] rfkill - Add support for input key to control wireless radio
This is the latest version of rfkill.
The changes since the version that was originally send are:
Spelling fixes (Thanks to Randy Dunlap)
THIS_MODULE is now a field in the rkfill_master (Suggested by Christoph Hellwig)
The open_count has been completely removed, decision making on which action
should
be taken is now handled by the user_claim field, which can be set through sysfs.
The possible choice include
1 - let rfkill handle everything without bothering the user
2 - let rfkill handle everything but send a notification to the user
3 - let rfkill send a notification only
The toggling of the keys is now type based, this means that if 1 key is being
toggled
all keys of the same type will be toggled.
As optimization and clearly seperate the keys per type, the rfkill_type
structure
now holds the list of the keys that belong to him. This has greatly reduced
the size of the rfkill_master structure.
sysfs will hold the following entries:
- The main folder: rfkill
- The main folder contains the type folders wlan, bluetooth and irda.
- Each type folder contains the files
- claim where the user claim can be read/written
- status The radio status of this type
- The folders for each key belonging to this type
- Each key folder contains the files
- status The status of this key
- idev The symlink to the input device entry in sysfs
- dev The symlink to the drivers device entry in sysfs
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ba0e88c..e58c0bf 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,20 @@ config HP_SDC_RTC
Say Y here if you want to support the built-in real time clock
of the HP SDC controller.
+config RFKILL
+ tristate RF button support
+ depends on SYSFS
+ help
+ If you say yes here, the rfkill driver will be built
+ which allows network devices to register their hardware
+ RF button which controls the radio state. This driver
+ will then create an input device for it.
+
+ When the input device is not used, the rfkill driver
+ will make sure that when the RF button is pressed the radio
+ is enabled or disabled accordingly. When the input device
+ has been opened by the user this radio control will be left
+ to the user, and rfkill will only send the RF button status
+ change to userspace.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e788a1b 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o
+obj-$(CONFIG_RFKILL) += rfkill.o
diff --git a/drivers/input/misc/rfkill.c b/drivers/input/misc/rfkill.c
new file mode 100644
index 000..065ff56
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,986 @@
+/*
+ Copyright (C) 2006 Ivo van Doorn
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/workqueue.h
+#include linux/list.h
+#include linux/mutex.h
+#include linux/input.h
+#include linux/rfkill.h
+
+MODULE_AUTHOR(Ivo van Doorn [EMAIL PROTECTED]);
+MODULE_VERSION(1.0);
+MODULE_DESCRIPTION(RF key support);
+MODULE_LICENSE(GPL);
+
+/*
+ * rfkill key structure.
+ */
+struct rfkill_key {
+ /*
+* For sysfs representation.
+*/
+ struct class_device *cdev;
+
+ /*
+* Pointer to rfkill structure
+* that was filled in by key driver.
+*/
+ struct rfkill *rfkill;
+
+ /*
+* Pointer to type structure
+* that this key belongs to.
+*/
+ struct rfkill_type *type;
+
+ /*
+* Current status of the key which controls the radio,
+* this value will change after the key state has changed
+* after polling, or the key driver has send the new state
+* manually.
+
Re: [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 linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
Hi Ivo, On Thursday 07 December 2006 16:53, Ivo van Doorn wrote: > 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. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
Hi Ivo, On Thursday 07 December 2006 16:53, Ivo van Doorn wrote: 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. -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Wed, 2006-12-06 at 22:41 +0100, Ivo van Doorn wrote: > 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. 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. Again, I don't care how that happens, but I like the fact that there's renewed interest in getting this fixed. Dan > > > 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
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Wed, 2006-12-06 at 22:41 +0100, Ivo van Doorn wrote: 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. 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. Again, I don't care how that happens, but I like the fact that there's renewed interest in getting this fixed. Dan 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.
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 linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On 12/6/06, Jiri Benc <[EMAIL PROTECTED]> wrote: On Wed, 6 Dec 2006 15:18:12 -0500, Dmitry Torokhov wrote: > On 12/6/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote: > > Ok, so input device opening should not block the rfkill signal and the rfkill handler > > should still go through with its work unless a different config option indicates that > > userspace wants to handle the event. > > I don't think a config option is a good idea unless by config option > you mean a sysfs attribute. What about using EVIOCGRAB ioctl for this? Will not work when the button is on your USB keyboard ;) -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Wed, 6 Dec 2006 15:18:12 -0500, Dmitry Torokhov wrote: > On 12/6/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote: > > Ok, so input device opening should not block the rfkill signal and the > > rfkill handler > > should still go through with its work unless a different config option > > indicates that > > userspace wants to handle the event. > > I don't think a config option is a good idea unless by config option > you mean a sysfs attribute. What about using EVIOCGRAB ioctl for this? Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On 12/6/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote: > > 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... ... 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). ... > 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. ... > > 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 :) -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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
Re: [RFC] rfkill - Add support for input key to control wireless radio
On 12/6/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote: 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 Can't do anything here so just ignore it. 2 - Hardware key that does not control the hardware radio and does not report anything to userspace Kind of uninteresting button ;) 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. 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. 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. Does this make sense? > > > 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
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 linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On 12/6/06, Dan Williams <[EMAIL PROTECTED]> wrote: On Wed, 2006-12-06 at 09:37 -0500, Dmitry Torokhov wrote: > > Fans of the 3rd method, speak up ;) I think I brought up the 3rd method initially in this thread. I'm not necessarily advocating it, but I wanted to be sure people realized that this was a case, so that a clear decision would be made to support it or not to support it. (2) makes the most sense to me. I don't think we need to care about edge-cases like "But I only wanted to rfkill _one_ of my bluetooth dongles!!!", that's just insane. But using (2) also begs the question, can we _always_ identify what interface the rfkill belongs to? In Bastien's laptop, the rfkill switch _automatically_ disconnects the internal USB Bluetooth device from the USB bus, and uses the normal ipw2200 rfkill mechanism, whatever that is. In this case, you simply do not get an event that the bluetooth device is disabled from a button somewhere; it's just gone, and you'd have to do some magic to disable other bluetooth devices as well. Is this the same physical button? If so then for this particular box we'd just have to send 2 events - KEY_WIFI and KEY_BLUETOOTH at the same time. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Wed, 2006-12-06 at 09:37 -0500, 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. > > > 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. > > > > 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. > > Fans of the 3rd method, speak up ;) I think I brought up the 3rd method initially in this thread. I'm not necessarily advocating it, but I wanted to be sure people realized that this was a case, so that a clear decision would be made to support it or not to support it. (2) makes the most sense to me. I don't think we need to care about edge-cases like "But I only wanted to rfkill _one_ of my bluetooth dongles!!!", that's just insane. But using (2) also begs the question, can we _always_ identify what interface the rfkill belongs to? In Bastien's laptop, the rfkill switch _automatically_ disconnects the internal USB Bluetooth device from the USB bus, and uses the normal ipw2200 rfkill mechanism, whatever that is. In this case, you simply do not get an event that the bluetooth device is disabled from a button somewhere; it's just gone, and you'd have to do some magic to disable other bluetooth devices as well. Dan > > > > > 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. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo
Re: [RFC] rfkill - Add support for input key to control wireless radio
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. 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. > 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. Fans of the 3rd method, speak up ;) > 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. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
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. 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. 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. Fans of the 3rd method, speak up ;) 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. -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Wed, 2006-12-06 at 09:37 -0500, 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. 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. 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. Fans of the 3rd method, speak up ;) I think I brought up the 3rd method initially in this thread. I'm not necessarily advocating it, but I wanted to be sure people realized that this was a case, so that a clear decision would be made to support it or not to support it. (2) makes the most sense to me. I don't think we need to care about edge-cases like But I only wanted to rfkill _one_ of my bluetooth dongles!!!, that's just insane. But using (2) also begs the question, can we _always_ identify what interface the rfkill belongs to? In Bastien's laptop, the rfkill switch _automatically_ disconnects the internal USB Bluetooth device from the USB bus, and uses the normal ipw2200 rfkill mechanism, whatever that is. In this case, you simply do not get an event that the bluetooth device is disabled from a button somewhere; it's just gone, and you'd have to do some magic to disable other bluetooth devices as well. Dan 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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On 12/6/06, Dan Williams [EMAIL PROTECTED] wrote: On Wed, 2006-12-06 at 09:37 -0500, Dmitry Torokhov wrote: Fans of the 3rd method, speak up ;) I think I brought up the 3rd method initially in this thread. I'm not necessarily advocating it, but I wanted to be sure people realized that this was a case, so that a clear decision would be made to support it or not to support it. (2) makes the most sense to me. I don't think we need to care about edge-cases like But I only wanted to rfkill _one_ of my bluetooth dongles!!!, that's just insane. But using (2) also begs the question, can we _always_ identify what interface the rfkill belongs to? In Bastien's laptop, the rfkill switch _automatically_ disconnects the internal USB Bluetooth device from the USB bus, and uses the normal ipw2200 rfkill mechanism, whatever that is. In this case, you simply do not get an event that the bluetooth device is disabled from a button somewhere; it's just gone, and you'd have to do some magic to disable other bluetooth devices as well. Is this the same physical button? If so then for this particular box we'd just have to send 2 events - KEY_WIFI and KEY_BLUETOOTH at the same time. -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On 12/6/06, Ivo van Doorn [EMAIL PROTECTED] wrote: 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 Can't do anything here so just ignore it. 2 - Hardware key that does not control the hardware radio and does not report anything to userspace Kind of uninteresting button ;) 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. 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. 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. Does this make sense? 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
Re: [RFC] rfkill - Add support for input key to control wireless radio
Hi, That is my point. Given the fact that there are keys that are not directly connected with the radio switch userspace will have to handle them (wait for events then turn off radios somehow). You are advocating that userspace should also implement 2nd method for buttons that belong to rfkill interface. I do not understand the need for 2nd interface. If you separate radio switch from button code then userspace only need to implement 1st interface and be done with it. You will have set of cards that provide interface to enable/disable their transmitters and set of buttons that signal userspace desired state change. If both switch and button is implemented by the same driver then the driver can implement automatic button handling. Otherwise userspace help is necessary. Well there are 3 possible hardware key approaches: 1 - Hardware key that controls the hardware radio, and does not report anything to userspace Can't do anything here so just ignore it. Ok. 2 - Hardware key that does not control the hardware radio and does not report anything to userspace Kind of uninteresting button ;) And this is the button that rfkill was originally designed for. Laptops with integrated WiFi cards from Ralink have a hardware button that don't send anything to userspace (unless the ACPI event is read) and does not directly control the radio itself. 3 - Hardware key that does not control the hardware radio and reports the key to userspace So rfkill should not be used in the case of (1) and (3), but we still need something to support (2) or should the keys not be handled by userspace and always by the driver? This is making rfkill moving slowly away from the generic approach for all rfkill keys as the initial intention was. I my vision rfkill would represent userspace namageable radio switch. We have the followng possible configurations: 1. A device that does not allow controlling its transmitter from userspace. The driver should not use/register with rfkill subsystem as userspace can't do anyhting with it. If device has a button killing the transmitter the driver can still signal userspace appropriate event (KEY_WIFI, KEY_BLUETOOTH, etc) if it can detect that button was presssed so userspace can monitor state of the transmitter and probably shut down other transmitters to keep everything in sync. And this event should be reported by a generic approach right? So it should be similar as with your point 2 below. But this would mean that the driver should create the input device. Or can a driver send the KEY_WIFI event over a main layer without the need of a personal input device? I am not that familiar with the input device layer in the kernel, and this is my first attempt on creating something for it, so I might have missed something. ;) Because it could still register with rfkill, only not give the callback functions for changing the radio or polling. Then the driver can use the send_event function to inform rfkill of the event and process it further. The sysfs attributes could even be reduced to only add the change_status attribute when the radio_enable and radio_disable callback functions are implemented. 2. A device that does allow controlling its transmitter. The driver may (should) register with rfkill subsystem. Additionally, if there is a button, the driver should register it with input subsystem. Driver should manage transmitter state in response to button presses unless userspace takes over the process. This is indeed the main goal of rfkill. :) 3. A device without transmitter but with a button - just register with input core. Userspace will have to manage state of other devices with transmitters in response to button presses. This is clear too. Rfkill is only intended for drivers that control a device with a transmitter (WiFi, Bluetooth, IRDA) that have a button that is intended to do something with the radio/transmitter. Does this make sense? Yes, this was what I intended to do with rfkill, so at that point we have the same goal. attribute should be a tri-state on/off/auto, auto meaning the driver itself manages radio state. This would avoid another tacky IMHO point that in your implementation mere opening of an input device takes over RF driver. Explicit control allow applications snoop RF state without disturbing it. Currently userspace can always check the state of the button whenever they like by checking the sysfs entry. Unless the key is not directly connected to the driver (so there is no sysfs entry). Again you force 2 different interfaces. Ok, so input device opening should not block the rfkill signal and the rfkill handler should still go through with its work unless a different config option indicates that userspace wants to handle the event. I don't think a config option is a good idea unless by config option
Re: [RFC] rfkill - Add support for input key to control wireless radio
On 12/6/06, Ivo van Doorn [EMAIL PROTECTED] wrote: 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... ... 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). ... 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. ... 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 :) -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Wed, 6 Dec 2006 15:18:12 -0500, Dmitry Torokhov wrote: On 12/6/06, Ivo van Doorn [EMAIL PROTECTED] wrote: Ok, so input device opening should not block the rfkill signal and the rfkill handler should still go through with its work unless a different config option indicates that userspace wants to handle the event. I don't think a config option is a good idea unless by config option you mean a sysfs attribute. What about using EVIOCGRAB ioctl for this? Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On 12/6/06, Jiri Benc [EMAIL PROTECTED] wrote: On Wed, 6 Dec 2006 15:18:12 -0500, Dmitry Torokhov wrote: On 12/6/06, Ivo van Doorn [EMAIL PROTECTED] wrote: Ok, so input device opening should not block the rfkill signal and the rfkill handler should still go through with its work unless a different config option indicates that userspace wants to handle the event. I don't think a config option is a good idea unless by config option you mean a sysfs attribute. What about using EVIOCGRAB ioctl for this? Will not work when the button is on your USB keyboard ;) -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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(>mutex);
> > +
> > + if (rfkill_check_key(rfkill->key, new_status))
> > + schedule_work(>toggle_work);
> > +
> > + mutex_unlock(>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 linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 = >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 linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
> +/*
> + * 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 = >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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
+/*
+ * 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.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Sun, 3 Dec 2006 23:28:11 +0100 Ivo van Doorn wrote:
> 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.
>
> ---
>
> 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"
depends on SYSFS
> + help
> + If you say yes here, the rfkill driver will be build
s/build/built/
> + which allowed network devices to register their hardware
s/allowed/allows/
> + 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/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 @@
[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(>mutex);
> +
> + if (rfkill_check_key(rfkill->key, new_status))
> + schedule_work(>toggle_work);
> +
> + mutex_unlock(>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.
> +/*
> + * Function called by the key driver when the rfkill structure
> + * needs to be registered.
> + */
kernel-doc please.
> +int rfkill_register_key(struct rfkill *rfkill, int init_status)
> +{
> + struct rfkill_type *type = >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;
> +
> + mutex_lock(>mutex);
> +
> + /*
> + * Initialize key, and if required the type.
> + */
> + status = rfkill_add_type_key(type);
> + if (status)
> + goto exit;
> +
> + key = rfkill_key_init(rfkill, init_status);
> + if (!key) {
> + status = -ENOMEM;
> + goto exit_type;
> + }
> +
> + /*
> + * Add key to our list.
> + */
> + list_add(>entry, >key_list);
> +
> + /*
> + * Check if we need polling, and if we do
> + * increase the poll required counter and check
> + * if we weren't polling yet.
> + */
> + if (rfkill->poll && !master->poll_required++)
> + schedule_delayed_work(>poll_work, RFKILL_POLL_DELAY);
> +
> + mutex_unlock(>mutex);
> +
> + return 0;
> +
> +exit_type:
> + rfkill_del_type_key(type);
> +
> +exit:
> + mutex_unlock(>mutex);
> + module_put(THIS_MODULE);
> +
> + return status;
> +}
> +EXPORT_SYMBOL_GPL(rfkill_register_key);
> +
> +/*
> + * Function called by the key driver when the rfkill structure
> + * needs to be deregistered.
> + */
kernel-doc
> +int rfkill_deregister_key(struct rfkill *rfkill)
> +{
> + struct rfkill_type *type;
> +
> + if (!rfkill || !rfkill->key)
> + return -EINVAL;
> +
> + mutex_lock(>mutex);
> +
> + /*
> + * Cancel delayed work if this is the last key
> + * that requires polling. It is not bad if
> + * if the workqueue is still running,
> + * the workqueue won't rearm itself since the
> + * poll_required variable has been set.
> + * and we have protected the list with a semaphore.
> + */
> + if (rfkill->poll && !--master->poll_required)
> + cancel_delayed_work(>poll_work);
> +
> + /*
> + * Delete the rfkill structure to the list.
> + */
> + list_del(>key->entry);
> +
> + /*
> + * Deinitialize key.
> + */
> + type = rfkill->key->type;
> + rfkill_key_deinit(rfkill->key);
> + rfkill_del_type_key(type);
> +
> + mutex_unlock(>mutex);
> +
> + /*
> + * rfkill entry has been removed,
> + * decrease module use count.
> + */
> + module_put(THIS_MODULE);
> +
> + return 0;
> +}
>
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 linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at
Re: [RFC] rfkill - Add support for input key to control wireless radio
On 12/3/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote: 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. 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. 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 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. 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. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
Hi Dan, > 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 any case, any movement on rfkill interface/handling standardization > is quite welcome :) I want some handling for the Bluetooth rfkill in HAL, so our config application can physically turn on/off the Bluetooth chip with a simple method call to the HAL D-Bus interface. We also need to discover the existence of such a rfkill switch. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On 12/3/06, Ivo van Doorn [EMAIL PROTECTED] wrote: 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. 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. 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 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. 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. -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Sun, 3 Dec 2006 23:28:11 +0100 Ivo van Doorn wrote:
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.
---
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
depends on SYSFS
+ help
+ If you say yes here, the rfkill driver will be build
s/build/built/
+ which allowed network devices to register their hardware
s/allowed/allows/
+ 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/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 @@
[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.
+/*
+ * Function called by the key driver when the rfkill structure
+ * needs to be registered.
+ */
kernel-doc please.
+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;
+
+ mutex_lock(master-mutex);
+
+ /*
+ * Initialize key, and if required the type.
+ */
+ status = rfkill_add_type_key(type);
+ if (status)
+ goto exit;
+
+ key = rfkill_key_init(rfkill, init_status);
+ if (!key) {
+ status = -ENOMEM;
+ goto exit_type;
+ }
+
+ /*
+ * Add key to our list.
+ */
+ list_add(key-entry, master-key_list);
+
+ /*
+ * Check if we need polling, and if we do
+ * increase the poll required counter and check
+ * if we weren't polling yet.
+ */
+ if (rfkill-poll !master-poll_required++)
+ schedule_delayed_work(master-poll_work, RFKILL_POLL_DELAY);
+
+ mutex_unlock(master-mutex);
+
+ return 0;
+
+exit_type:
+ rfkill_del_type_key(type);
+
+exit:
+ mutex_unlock(master-mutex);
+ module_put(THIS_MODULE);
+
+ return status;
+}
+EXPORT_SYMBOL_GPL(rfkill_register_key);
+
+/*
+ * Function called by the key driver when the rfkill structure
+ * needs to be deregistered.
+ */
kernel-doc
+int rfkill_deregister_key(struct rfkill *rfkill)
+{
+ struct rfkill_type *type;
+
+ if (!rfkill || !rfkill-key)
+ return -EINVAL;
+
+ mutex_lock(master-mutex);
+
+ /*
+ * Cancel delayed work if this is the last key
+ * that requires polling. It is not bad if
+ * if the workqueue is still running,
+ * the workqueue won't rearm itself since the
+ * poll_required variable has been set.
+ * and we have protected the list with a semaphore.
+ */
+ if (rfkill-poll !--master-poll_required)
+ cancel_delayed_work(master-poll_work);
+
+ /*
+ * Delete the rfkill structure to the list.
+ */
+ list_del(rfkill-key-entry);
+
+ /*
+ * Deinitialize key.
+ */
+ type = rfkill-key-type;
+ rfkill_key_deinit(rfkill-key);
+ rfkill_del_type_key(type);
+
+ mutex_unlock(master-mutex);
+
+ /*
+ * rfkill entry has been removed,
+ * decrease module use count.
+ */
+ module_put(THIS_MODULE);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(rfkill_deregister_key);
diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
new file mode 100644
index
Re: [RFC] rfkill - Add support for input key to control wireless radio
Hi Dan, 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 any case, any movement on rfkill interface/handling standardization is quite welcome :) I want some handling for the Bluetooth rfkill in HAL, so our config application can physically turn on/off the Bluetooth chip with a simple method call to the HAL D-Bus interface. We also need to discover the existence of such a rfkill switch. Regards Marcel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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.
+*/
+ unsigned int key_type;
+
+ /*
+* Number of
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 linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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(>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 linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Sun, 2006-12-03 at 19:36 +0100, Ivo van Doorn wrote: > 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? 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. 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 any case, any movement on rfkill interface/handling standardization is quite welcome :) Cheers, Dan > 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
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Sun, 2006-12-03 at 19:36 +0100, Ivo van Doorn wrote:
> +static int rfkill_open(struct input_dev *dev)
> +{
> + ((struct rfkill_key*)(dev->private))->open_count++;
> + return 0;
> +}
Hi,
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 ?
Greetings,
Arjan van de Ven
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via
http://www.linuxfirmwarekit.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Sun, 2006-12-03 at 19:36 +0100, Ivo van Doorn wrote: > + > + down(>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 Greetings, Arjan van de Ven -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
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 Greetings, Arjan van de Ven -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Sun, 2006-12-03 at 19:36 +0100, Ivo van Doorn wrote:
+static int rfkill_open(struct input_dev *dev)
+{
+ ((struct rfkill_key*)(dev-private))-open_count++;
+ return 0;
+}
Hi,
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 ?
Greetings,
Arjan van de Ven
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via
http://www.linuxfirmwarekit.org
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] rfkill - Add support for input key to control wireless radio
On Sun, 2006-12-03 at 19:36 +0100, Ivo van Doorn wrote: 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? 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. 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 any case, any movement on rfkill interface/handling standardization is quite welcome :) Cheers, Dan 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
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 linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/workqueue.h
+#include linux/list.h
+#include linux/mutex.h
+#include linux/input.h
+#include linux/rfkill.h
+
+MODULE_AUTHOR(Ivo van Doorn [EMAIL PROTECTED]);
+MODULE_VERSION(1.0);
+MODULE_DESCRIPTION(RF key support);
+MODULE_LICENSE(GPL);
+
+/*
+ * rfkill key structure.
+ */
+struct rfkill_key {
+ /*
+* For sysfs representation.
+*/
+ struct class_device *cdev;
+
+ /*
+* Pointer to rfkill structure
+* that was filled in by key driver.
+*/
+ struct rfkill *rfkill;
+
+ /*
+* Pointer to type structure that this key belongs to.
+*/
+ struct rfkill_type *type;
+
+ /*
+* 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
