rfkill: Remove IRDA
Subsystems (5)
PATCH 1/3 rfkill: Remove IRDA
As Dmitry pointed out earlier, rfkill-input.c doesn't support irda because there are no users and we shouldn't add unrequired KEY_ defines.
However, RFKILL_TYPE_IRDA was defined in the rfkill.h header file and would confuse people about whether it is implemented or not.
This patch removes IRDA support completely, so it can be added whenever a driver wants the feature.
Signed-off-by Ivo van Doorn <[email protected]>
Acked-by Dmitry Torokhov <[email protected]>
--- include/linux/rfkill.h | 8 +++----- net/rfkill/Kconfig | 2 +- net/rfkill/rfkill.c | 5 +---- 3 files changed, 5 insertions(+), 10 deletions(-)
include/linux/rfkill.h +3 -5
@@ -31,13 +31,11 @@* enum rfkill_type - type of rfkill switch. * RFKILL_TYPE_WLAN: switch is no a Wireless network devices. * RFKILL_TYPE_BlUETOOTH: switch is on a bluetooth device. -* RFKILL_TYPE_IRDA: switch is on an infrared devices. */ enum rfkill_type { -RFKILL_TYPE_WLAN =0 , -RFKILL_TYPE_BLUETOOTH =1 , -RFKILL_TYPE_IRDA =2 , -RFKILL_TYPE_MAX =3 , +RFKILL_TYPE_WLAN , +RFKILL_TYPE_BLUETOOTH , +RFKILL_TYPE_MAX , };enum rfkill_state {
net/rfkill/Kconfig +1 -1
@@ -5,7 +5,7 @@ menuconfig RFKILL tristate "RF switch subsystem support" help Say Y here if you want to have control over RF switches - found on many WiFi, Bluetooth and IRDA cards. + found on many WiFi and Bluetooth cards. To compile this driver as a module, choose M here: the module will be called rfkill.
net/rfkill/rfkill.c +1 -4
@@ -106,9 +106,6 @@ static ssize_t rfkill_type_show(struct device *dev,case RFKILL_TYPE_BLUETOOTH : type ="bluetooth" ;break ; -case RFKILL_TYPE_IRDA : - type ="irda" ; -break ;default :BUG (); }
@@ -281,7 +278,7 @@ static void rfkill_remove_switch(struct rfkill *rfkill)/** * rfkill_allocate - allocate memory for rfkill structure. * @parent: device that has rf switch on it -* @type: type of the switch (wlan, bluetooth, irda) +* @type: type of the switch (RFKILL_TYPE_*) * * This function should be called by the network driver when it needs * rfkill structure. Once the structure is allocated the driver shoud
Signature · 1 line
1.5.3
PATCH 2/3 rfkill: Add support for ultrawideband
This patch will add support for UWB keys to rfkill, support for this has been requested by Inaky.
Signed-off-by Ivo van Doorn <[email protected]>
Acked-by Dmitry Torokhov <[email protected]>
--- include/linux/input.h | 1 + include/linux/rfkill.h | 2 ++ net/rfkill/rfkill-input.c | 9 +++++++++ net/rfkill/rfkill.c | 3 +++ 4 files changed, 15 insertions(+), 0 deletions(-)
include/linux/input.h +1 -0
@@ -360,6 +360,7 @@ struct input_absinfo {#define KEY_BLUETOOTH 237#define KEY_WLAN 238 +#define KEY_UWB 239#define KEY_UNKNOWN 240
include/linux/rfkill.h +2 -0
@@ -31,10 +31,12 @@* enum rfkill_type - type of rfkill switch. * RFKILL_TYPE_WLAN: switch is no a Wireless network devices. * RFKILL_TYPE_BlUETOOTH: switch is on a bluetooth device. +* RFKILL_TYPE_UWB: switch is on a Ultra wideband device. */ enum rfkill_type {RFKILL_TYPE_WLAN ,RFKILL_TYPE_BLUETOOTH , +RFKILL_TYPE_UWB ,RFKILL_TYPE_MAX , };
net/rfkill/rfkill-input.c +9 -0
@@ -81,6 +81,7 @@ static void rfkill_schedule_toggle(struct rfkill_task *task) static DEFINE_RFKILL_TASK(rfkill_wlan, RFKILL_TYPE_WLAN); static DEFINE_RFKILL_TASK(rfkill_bt, RFKILL_TYPE_BLUETOOTH); +static DEFINE_RFKILL_TASK(rfkill_uwb, RFKILL_TYPE_UWB);static void rfkill_event (struct input_handle *handle,unsigned int type,unsigned int code,int down)
@@ -93,6 +94,9 @@ static void rfkill_event(struct input_handle *handle, unsigned int type,case KEY_BLUETOOTH :rfkill_schedule_toggle (&rfkill_bt);break ; +case KEY_UWB : +rfkill_schedule_toggle (&rfkill_uwb); +break ;default :break ; }
@@ -148,6 +152,11 @@ static const struct input_device_id rfkill_ids[] = { .evbit = { BIT(EV_KEY) }, .keybit = { [LONG(KEY_BLUETOOTH)] = BIT(KEY_BLUETOOTH) }, }, + { + .flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_KEYBIT, + .evbit = { BIT(EV_KEY) }, + .keybit = { [LONG(KEY_UWB)] = BIT(KEY_UWB) }, + }, { } };
net/rfkill/rfkill.c +3 -0
@@ -106,6 +106,9 @@ static ssize_t rfkill_type_show(struct device *dev,case RFKILL_TYPE_BLUETOOTH : type ="bluetooth" ;break ; +case RFKILL_TYPE_UWB : + type ="ultrawideband" ; +break ;default :BUG (); }
Signature · 1 line
1.5.3
PATCH 3/3 rfkill: Add rfkill documentation
In reply to Ivo van DoornAdd a documentation file which contains
a short description about rfkill with some
notes about drivers and the userspace interface.
Signed-off-by Ivo van Doorn <[email protected]>
Acked-by Dmitry Torokhov <[email protected]>
--- Documentation/rfkill.txt | 88 ++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 88 insertions(+), 0 deletions(-) create mode 100644 Documentation/rfkill.txt
Documentation/rfkill.txt new file +88 -0
@@ -0,0 +1,88 @@ +rfkill - RF switch subsystem support +==================================== + +1 Implementation details +2 Driver support +3 Userspace support + +=============================================================================== +1: Implementation details + +The rfkill switch subsystem offers support for keys often found on laptops +to enable wireless devices like WiFi and Bluetooth. + +This is done by providing the user 3 possibilities: + - The rfkill system handles all events, userspace is not aware of events. + - The rfkill system handles all events, userspace is informed about the event. + - The rfkill system does not handle events, userspace handles all events. + +The buttons to enable and disable the wireless radios are important in +situations where the user is for example using his laptop on a location where +wireless radios _must_ be disabled (e.g airplanes). +Because of this requirement, userspace support for the keys should not be +made mandatory. Because userspace might want to perform some additional smarter +tasks when the key is pressed, rfkill still provides userspace the possibility +to take over the task to handle the key events. + +The system inside the kernel has been split into 2 seperate sections: + 1 - RFKILL + 2 - RFKILL_INPUT + +The first option enables rfkill support and will make sure userspace will +be notified of any events through the input device. It also creates several +sysfs entries which can be used by userspace. See section "Userspace support". + +The second option provides a rfkill input handler. This handler will +listen to all rfkill key events and will toggle the radio accordingly, +with this option enabled userspace could either do nothing or simply +perform monitoring tasks. + +==================================== +2: Driver support + +Drivers who wish to build in rfkill subsystem support should +make sure their driver depends of the Kconfig option RFKILL, it should +_not_ depend on RFKILL_INPUT. + +Unless key events trigger a interrupt to which the driver listens, polling +will be required to determine the key state changes. For this the input +layer providers the input-polldev handler. + +A driver should implement a few steps to correctly make use of the +rfkill subsystem. First for non-polling drivers: + + - rfkill_allocate() + - input_allocate_device() + - rfkill_register() + - input_register_device() + +For polling drivers: + + - rfkill_allocate() + - input_allocate_polled_device() + - rfkill_register() + - input_register_polled_device() + +When a key event has been detected, the correct event should be +send over the input device which has been registered by the driver. + +==================================== +3: Userspace support + +For each key a input device will be created which will send out the correct +key event when the rfkill key has been pressed. + +The following sysfs entries will be created: + + name: Name assigned by driver to this key (interface or driver name). + type: Name of the key type ("wlan", "bluetooth", etc). + state: Current state of the key. 1: On, 0: Off. + claim: 1: Userspace handles events, 0: Kernel handles events + +Both the "state" and "claim" entries are also writable. For the "state" entry +this means that when 1 or 0 is written all radios will be toggled accordingly. +For the "claim" entry writing 1 to it will mean that the kernel will no longer +handle key events even though RFKILL_INPUT input was enabled. When "claim" has +been set to 0, userspace should make sure it will listen for the input events +or check the sysfs "state" entry regularly to correctly perform the required +tasks when the rkfill key is pressed.
Signature · 1 line
1.5.3
Re: [PATCH 3/3] rfkill: Add rfkill documentation
Quoted 3 lines · On Mon, 10 Sep 2007 19:56:03 +0200 Ivo van Doorn wrote:
Add a documentation file which contains
a short description about rfkill with some
notes about drivers and the userspace interface.
Thanks. I have noted a few typo/editorial changes below.
Quoted 20 lines
Signed-off-by Ivo van Doorn <[email protected]>Acked-by Dmitry Torokhov <[email protected]>--- Documentation/rfkill.txt | 88 ++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 88 insertions(+), 0 deletions(-) create mode 100644 Documentation/rfkill.txtDocumentation/rfkill.txt new file +7
-0@@ -0,0 +1,88 @@ +rfkill - RF switch subsystem support +==================================== + +1 Implementation details +2 Driver support +3 Userspace support +
Documentation/rfkill.txt line 17
Quoted 10 lines
Documentation/rfkill.txt new file +10
-0+=============================================================================== +1: Implementation details + +The rfkill switch subsystem offers support for keys often found on laptops +to enable wireless devices like WiFi and Bluetooth. + +This is done by providing the user 3 possibilities: + - The rfkill system handles all events, userspace is not aware of events. + - The rfkill system handles all events, userspace is informed about the event. + - The rfkill system does not handle events, userspace handles all events.
I would s/,/;/ in the 3 lines above.
Documentation/rfkill.txt line 27
Quoted 9 lines
Documentation/rfkill.txt new file +9
-0+The buttons to enable and disable the wireless radios are important in +situations where the user is for example using his laptop on a location where +wireless radios _must_ be disabled (e.g airplanes). +Because of this requirement, userspace support for the keys should not be +made mandatory. Because userspace might want to perform some additional smarter +tasks when the key is pressed, rfkill still provides userspace the possibility +to take over the task to handle the key events. + +The system inside the kernel has been split into 2 seperate sections:
separate
Documentation/rfkill.txt line 35
Quoted 8 lines
Documentation/rfkill.txt new file +8
-0+ 1 - RFKILL + 2 - RFKILL_INPUT + +The first option enables rfkill support and will make sure userspace will +be notified of any events through the input device. It also creates several +sysfs entries which can be used by userspace. See section "Userspace support". + +The second option provides a rfkill input handler. This handler will
an
Documentation/rfkill.txt line 36
Quoted 1 line
Documentation/rfkill.txt new file +1
-0+listen to all rfkill key events and will toggle the radio accordingly,
end above with ; or . If '.', s/with/With/ on next line.
Documentation/rfkill.txt line 43
Quoted 7 lines
Documentation/rfkill.txt new file +7
-0+with this option enabled userspace could either do nothing or simply +perform monitoring tasks. + +==================================== +2: Driver support + +Drivers who wish to build in rfkill subsystem support should
Drivers that
But, drivers can't/don't wish, so it would be better to say something like:
To build a driver with rfkill subsystem support, the driver should depend on the Kconfig symbol RFKILL; it should _not_ depend on RKFILL_INPUT.
Documentation/rfkill.txt line 47
Quoted 4 lines
Documentation/rfkill.txt new file +4
-0+make sure their driver depends of the Kconfig option RFKILL, it should +_not_ depend on RFKILL_INPUT. + +Unless key events trigger a interrupt to which the driver listens, polling
an interrupt
Quoted 10 lines
Documentation/rfkill.txt new file +10
-0+will be required to determine the key state changes. For this the input +layer providers the input-polldev handler. + +A driver should implement a few steps to correctly make use of the +rfkill subsystem. First for non-polling drivers: + + - rfkill_allocate() + - input_allocate_device() + - rfkill_register() + - input_register_device()
Documentation/rfkill.txt line 67
Quoted 10 lines
Documentation/rfkill.txt new file +10
-0+ +For polling drivers: + + - rfkill_allocate() + - input_allocate_polled_device() + - rfkill_register() + - input_register_polled_device() + +When a key event has been detected, the correct event should be +send over the input device which has been registered by the driver.
sent
Documentation/rfkill.txt line 72
Quoted 5 lines
Documentation/rfkill.txt new file +5
-0+ +==================================== +3: Userspace support + +For each key a input device will be created which will send out the correct
an
Documentation/rfkill.txt line 83
Quoted 11 lines
Documentation/rfkill.txt new file +11
-0+key event when the rfkill key has been pressed. + +The following sysfs entries will be created: + + name: Name assigned by driver to this key (interface or driver name). + type: Name of the key type ("wlan", "bluetooth", etc). + state: Current state of the key. 1: On, 0: Off. + claim: 1: Userspace handles events, 0: Kernel handles events + +Both the "state" and "claim" entries are also writable. For the "state" entry +this means that when 1 or 0 is written all radios will be toggled accordingly.
will be written even if they are already in that state?
Documentation/rfkill.txt line 84
Quoted 1 line
Documentation/rfkill.txt new file +1
-0+For the "claim" entry writing 1 to it will mean that the kernel will no longer
s/will mean/means/
s/will no longer handle/no longer handles/
Documentation/rfkill.txt line 86
Quoted 2 lines
Documentation/rfkill.txt new file +2
-0+handle key events even though RFKILL_INPUT input was enabled. When "claim" has +been set to 0, userspace should make sure it will listen for the input events
s/it will listen/that it listens/
Documentation/rfkill.txt line 88
Quoted 3 lines
Documentation/rfkill.txt new file +2
-0+or check the sysfs "state" entry regularly to correctly perform the required +tasks when the rkfill key is pressed.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
Re: [PATCH 3/3] rfkill: Add rfkill documentation
Quoted 7 lines · Randy Dunlap
Quoted 3 lines · On Mon, 10 Sep 2007 19:56:03 +0200 Ivo van Doorn wrote:
Add a documentation file which contains
a short description about rfkill with some
notes about drivers and the userspace interface.Thanks. I have noted a few typo/editorial changes below.
Thanks!
I'll resend this patch within a few minutes. :)
Ivo
Quoted 148 lines
Quoted 20 lines
Signed-off-by Ivo van Doorn <[email protected]>Acked-by Dmitry Torokhov <[email protected]>--- Documentation/rfkill.txt | 88 ++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 88 insertions(+), 0 deletions(-) create mode 100644 Documentation/rfkill.txtDocumentation/rfkill.txt new file +7
-0@@ -0,0 +1,88 @@ +rfkill - RF switch subsystem support +==================================== + +1 Implementation details +2 Driver support +3 Userspace support +Documentation/rfkill.txt line 17
Quoted 10 lines
Documentation/rfkill.txt new file +10
-0+=============================================================================== +1: Implementation details + +The rfkill switch subsystem offers support for keys often found on laptops +to enable wireless devices like WiFi and Bluetooth. + +This is done by providing the user 3 possibilities: + - The rfkill system handles all events, userspace is not aware of events. + - The rfkill system handles all events, userspace is informed about the event. + - The rfkill system does not handle events, userspace handles all events.I would s/,/;/ in the 3 lines above.
Documentation/rfkill.txt line 27
Quoted 9 lines
Documentation/rfkill.txt new file +9
-0+The buttons to enable and disable the wireless radios are important in +situations where the user is for example using his laptop on a location where +wireless radios _must_ be disabled (e.g airplanes). +Because of this requirement, userspace support for the keys should not be +made mandatory. Because userspace might want to perform some additional smarter +tasks when the key is pressed, rfkill still provides userspace the possibility +to take over the task to handle the key events. + +The system inside the kernel has been split into 2 seperate sections:separate
Documentation/rfkill.txt line 35
Quoted 8 lines
Documentation/rfkill.txt new file +8
-0+ 1 - RFKILL + 2 - RFKILL_INPUT + +The first option enables rfkill support and will make sure userspace will +be notified of any events through the input device. It also creates several +sysfs entries which can be used by userspace. See section "Userspace support". + +The second option provides a rfkill input handler. This handler willan
Documentation/rfkill.txt line 36
Quoted 1 line
Documentation/rfkill.txt new file +1
-0+listen to all rfkill key events and will toggle the radio accordingly,end above with ; or . If '.', s/with/With/ on next line.
Documentation/rfkill.txt line 43
Quoted 7 lines
Documentation/rfkill.txt new file +7
-0+with this option enabled userspace could either do nothing or simply +perform monitoring tasks. + +==================================== +2: Driver support + +Drivers who wish to build in rfkill subsystem support shouldDrivers that
But, drivers can't/don't wish, so it would be better to say something like:
To build a driver with rfkill subsystem support, the driver should depend on the
Kconfigsymbol RFKILL; it should _not_ depend onRKFILL_INPUT.Documentation/rfkill.txt line 47
Quoted 4 lines
Documentation/rfkill.txt new file +4
-0+make sure their driver depends of the Kconfig option RFKILL, it should +_not_ depend on RFKILL_INPUT. + +Unless key events trigger a interrupt to which the driver listens, pollingan interrupt
Quoted 10 lines
Documentation/rfkill.txt new file +10
-0+will be required to determine the key state changes. For this the input +layer providers the input-polldev handler. + +A driver should implement a few steps to correctly make use of the +rfkill subsystem. First for non-polling drivers: + + - rfkill_allocate() + - input_allocate_device() + - rfkill_register() + - input_register_device()Documentation/rfkill.txt line 67
Quoted 10 lines
Documentation/rfkill.txt new file +10
-0+ +For polling drivers: + + - rfkill_allocate() + - input_allocate_polled_device() + - rfkill_register() + - input_register_polled_device() + +When a key event has been detected, the correct event should be +send over the input device which has been registered by the driver.sent
Documentation/rfkill.txt line 72
Quoted 5 lines
Documentation/rfkill.txt new file +5
-0+ +==================================== +3: Userspace support + +For each key a input device will be created which will send out the correctan
Documentation/rfkill.txt line 83
Quoted 11 lines
Documentation/rfkill.txt new file +11
-0+key event when the rfkill key has been pressed. + +The following sysfs entries will be created: + + name: Name assigned by driver to this key (interface or driver name). + type: Name of the key type ("wlan", "bluetooth", etc). + state: Current state of the key. 1: On, 0: Off. + claim: 1: Userspace handles events, 0: Kernel handles events + +Both the "state" and "claim" entries are also writable. For the "state" entry +this means that when 1 or 0 is written all radios will be toggled accordingly.will be written even if they are already in that state?
Documentation/rfkill.txt line 84
Quoted 1 line
Documentation/rfkill.txt new file +1
-0+For the "claim" entry writing 1 to it will mean that the kernel will no longers/will mean/means/
s/will no longer handle/no longer handles/Documentation/rfkill.txt line 86
Quoted 2 lines
Documentation/rfkill.txt new file +2
-0+handle key events even though RFKILL_INPUT input was enabled. When "claim" has +been set to 0, userspace should make sure it will listen for the input eventss/it will listen/that it listens/
Documentation/rfkill.txt line 88
Quoted 3 lines
Documentation/rfkill.txt new file +2
-0+or check the sysfs "state" entry regularly to correctly perform the required +tasks when the rkfill key is pressed.---
~Randy
*** Remember to useDocumentation/SubmitChecklistwhen testing your code ***
PATCH v2 3/3 rfkill: Add rfkill documentation
In reply to Ivo van DoornAdd a documentation file which contains
a short description about rfkill with some
notes about drivers and the userspace interface.
Changes since v1:
- Spellchecking
Signed-off-by Ivo van Doorn <[email protected]>
Acked-by Dmitry Torokhov <[email protected]>
---
Only patch 3 was updated, patches 1 and 2 remain the same.
Documentation/rfkill.txt | 89 ++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 89 insertions(+), 0 deletions(-) create mode 100644 Documentation/rfkill.txt
Documentation/rfkill.txt new file +89 -0
@@ -0,0 +1,89 @@ +rfkill - RF switch subsystem support +==================================== + +1 Implementation details +2 Driver support +3 Userspace support + +=============================================================================== +1: Implementation details + +The rfkill switch subsystem offers support for keys often found on laptops +to enable wireless devices like WiFi and Bluetooth. + +This is done by providing the user 3 possibilities: + 1 - The rfkill system handles all events, userspace is not aware of events; + 2 - The rfkill system handles all events, userspace is informed about the event; + 3 - The rfkill system does not handle events, userspace handles all events; + +The buttons to enable and disable the wireless radios are important in +situations where the user is for example using his laptop on a location where +wireless radios _must_ be disabled (e.g. airplanes). +Because of this requirement, userspace support for the keys should not be +made mandatory. Because userspace might want to perform some additional smarter +tasks when the key is pressed, rfkill still provides userspace the possibility +to take over the task to handle the key events. + +The system inside the kernel has been split into 2 separate sections: + 1 - RFKILL + 2 - RFKILL_INPUT + +The first option enables rfkill support and will make sure userspace will +be notified of any events through the input device. It also creates several +sysfs entries which can be used by userspace. See section "Userspace support". + +The second option provides an rfkill input handler. This handler will +listen to all rfkill key events and will toggle the radio accordingly. +With this option enabled userspace could either do nothing or simply +perform monitoring tasks. + +==================================== +2: Driver support + +To build a driver with rfkill subsystem support, the driver should +depend on the Kconfig symbol RFKILL; it should _not_ depend on +RKFILL_INPUT. + +Unless key events trigger an interrupt to which the driver listens, polling +will be required to determine the key state changes. For this the input +layer providers the input-polldev handler. + +A driver should implement a few steps to correctly make use of the +rfkill subsystem. First for non-polling drivers: + + - rfkill_allocate() + - input_allocate_device() + - rfkill_register() + - input_register_device() + +For polling drivers: + + - rfkill_allocate() + - input_allocate_polled_device() + - rfkill_register() + - input_register_polled_device() + +When a key event has been detected, the correct event should be +sent over the input device which has been registered by the driver. + +==================================== +3: Userspace support + +For each key an input device will be created which will send out the correct +key event when the rfkill key has been pressed. + +The following sysfs entries will be created: + + name: Name assigned by driver to this key (interface or driver name). + type: Name of the key type ("wlan", "bluetooth", etc). + state: Current state of the key. 1: On, 0: Off. + claim: 1: Userspace handles events, 0: Kernel handles events + +Both the "state" and "claim" entries are also writable. For the "state" entry +this means that when 1 or 0 is written all radios, not yet in the requested +state, will be will be toggled accordingly. +For the "claim" entry writing 1 to it means that the kernel no longer handles +handle key events even though RFKILL_INPUT input was enabled. When "claim" has +been set to 0, userspace should make sure that it listens for the input events +or check the sysfs "state" entry regularly to correctly perform the required +tasks when the rkfill key is pressed.
Signature · 1 line
1.5.3
Re: [PATCH 3/3 v2] rfkill: Add rfkill documentation
On Tue, 11 Sep 2007 19:01:01 +0200 Ivo van Doorn wrote:
Almost done. See below.
Documentation/rfkill.txt
Quoted 10 lines
Documentation/rfkill.txt | 89 ++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 89 insertions(+), 0 deletions(-) create mode 100644 Documentation/rfkill.txtDocumentation/rfkill.txt new file +0
-0@@ -0,0 +1,89 @@
+===============================================================================
Documentation/rfkill.txt line 17
Quoted 9 lines
Documentation/rfkill.txt new file +9
-0+1: Implementation details + +The rfkill switch subsystem offers support for keys often found on laptops +to enable wireless devices like WiFi and Bluetooth. + +This is done by providing the user 3 possibilities: + 1 - The rfkill system handles all events, userspace is not aware of events; + 2 - The rfkill system handles all events, userspace is informed about the event; + 3 - The rfkill system does not handle events, userspace handles all events;
In the above 3 lines,
change "events," to "events;"
and then end each line with a period (".").
Quoted 23 lines
Documentation/rfkill.txt new file +23
-0+The buttons to enable and disable the wireless radios are important in +situations where the user is for example using his laptop on a location where +wireless radios _must_ be disabled (e.g. airplanes). +Because of this requirement, userspace support for the keys should not be +made mandatory. Because userspace might want to perform some additional smarter +tasks when the key is pressed, rfkill still provides userspace the possibility +to take over the task to handle the key events. + +The system inside the kernel has been split into 2 separate sections: + 1 - RFKILL + 2 - RFKILL_INPUT + +The first option enables rfkill support and will make sure userspace will +be notified of any events through the input device. It also creates several +sysfs entries which can be used by userspace. See section "Userspace support". + +The second option provides an rfkill input handler. This handler will +listen to all rfkill key events and will toggle the radio accordingly. +With this option enabled userspace could either do nothing or simply +perform monitoring tasks. + +==================================== +2: Driver support
...
Quoted 8 lines
+====================================
+3: Userspace supportDocumentation/rfkill.txt new file +6
-0+ +For each key an input device will be created which will send out the correct +key event when the rfkill key has been pressed. + +The following sysfs entries will be created: +
Documentation/rfkill.txt line 86
Quoted 10 lines
Documentation/rfkill.txt new file +10
-0+ name: Name assigned by driver to this key (interface or driver name). + type: Name of the key type ("wlan", "bluetooth", etc). + state: Current state of the key. 1: On, 0: Off. + claim: 1: Userspace handles events, 0: Kernel handles events + +Both the "state" and "claim" entries are also writable. For the "state" entry +this means that when 1 or 0 is written all radios, not yet in the requested +state, will be will be toggled accordingly. +For the "claim" entry writing 1 to it means that the kernel no longer handles +handle key events even though RFKILL_INPUT input was enabled. When "claim" has
Drop "handle" above.
Documentation/rfkill.txt line 89
Quoted 3 lines
Documentation/rfkill.txt new file +3
-0+been set to 0, userspace should make sure that it listens for the input events +or check the sysfs "state" entry regularly to correctly perform the required +tasks when the rkfill key is pressed.
Thanks.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
PATCH v3 3/3 rfkill: Add rfkill documentation
In reply to Ivo van DoornAdd a documentation file which contains
a short description about rfkill with some
notes about drivers and the userspace interface.
Changes since v1 and v2:
- Spellchecking
Signed-off-by Ivo van Doorn <[email protected]>
Acked-by Dmitry Torokhov <[email protected]>
---
Only patch 3 was updated, patches 1 and 2 remain the same.
Documentation/rfkill.txt | 89 ++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 89 insertions(+), 0 deletions(-) create mode 100644 Documentation/rfkill.txt
Documentation/rfkill.txt new file +89 -0
@@ -0,0 +1,89 @@ +rfkill - RF switch subsystem support +==================================== + +1 Implementation details +2 Driver support +3 Userspace support + +=============================================================================== +1: Implementation details + +The rfkill switch subsystem offers support for keys often found on laptops +to enable wireless devices like WiFi and Bluetooth. + +This is done by providing the user 3 possibilities: + 1 - The rfkill system handles all events; userspace is not aware of events. + 2 - The rfkill system handles all events; userspace is informed about the events. + 3 - The rfkill system does not handle events; userspace handles all events. + +The buttons to enable and disable the wireless radios are important in +situations where the user is for example using his laptop on a location where +wireless radios _must_ be disabled (e.g. airplanes). +Because of this requirement, userspace support for the keys should not be +made mandatory. Because userspace might want to perform some additional smarter +tasks when the key is pressed, rfkill still provides userspace the possibility +to take over the task to handle the key events. + +The system inside the kernel has been split into 2 separate sections: + 1 - RFKILL + 2 - RFKILL_INPUT + +The first option enables rfkill support and will make sure userspace will +be notified of any events through the input device. It also creates several +sysfs entries which can be used by userspace. See section "Userspace support". + +The second option provides an rfkill input handler. This handler will +listen to all rfkill key events and will toggle the radio accordingly. +With this option enabled userspace could either do nothing or simply +perform monitoring tasks. + +==================================== +2: Driver support + +To build a driver with rfkill subsystem support, the driver should +depend on the Kconfig symbol RFKILL; it should _not_ depend on +RKFILL_INPUT. + +Unless key events trigger an interrupt to which the driver listens, polling +will be required to determine the key state changes. For this the input +layer providers the input-polldev handler. + +A driver should implement a few steps to correctly make use of the +rfkill subsystem. First for non-polling drivers: + + - rfkill_allocate() + - input_allocate_device() + - rfkill_register() + - input_register_device() + +For polling drivers: + + - rfkill_allocate() + - input_allocate_polled_device() + - rfkill_register() + - input_register_polled_device() + +When a key event has been detected, the correct event should be +sent over the input device which has been registered by the driver. + +==================================== +3: Userspace support + +For each key an input device will be created which will send out the correct +key event when the rfkill key has been pressed. + +The following sysfs entries will be created: + + name: Name assigned by driver to this key (interface or driver name). + type: Name of the key type ("wlan", "bluetooth", etc). + state: Current state of the key. 1: On, 0: Off. + claim: 1: Userspace handles events, 0: Kernel handles events + +Both the "state" and "claim" entries are also writable. For the "state" entry +this means that when 1 or 0 is written all radios, not yet in the requested +state, will be will be toggled accordingly. +For the "claim" entry writing 1 to it means that the kernel no longer handles +key events even though RFKILL_INPUT input was enabled. When "claim" has been +set to 0, userspace should make sure that it listens for the input events or +check the sysfs "state" entry regularly to correctly perform the required +tasks when the rkfill key is pressed.
Signature · 1 line
1.5.3
Re: [PATCH 3/3 v3] rfkill: Add rfkill documentation
Quoted 9 lines · On Tue, 11 Sep 2007 22:20:45 +0200 Ivo van Doorn wrote:
Add a documentation file which contains
a short description about rfkill with some
notes about drivers and the userspace interface.Changes since v1 and v2:
- SpellcheckingSigned-off-by Ivo van Doorn <[email protected]>Acked-by Dmitry Torokhov <[email protected]>
Thanks.
Acked-by Randy Dunlap <[email protected]>
Quoted 111 lines
---
Only patch 3 was updated, patches 1 and 2 remain the same.
Documentation/rfkill.txt | 89 ++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 89 insertions(+), 0 deletions(-) create mode 100644 Documentation/rfkill.txtDocumentation/rfkill.txt new file +89
-0@@ -0,0 +1,89 @@ +rfkill - RF switch subsystem support +==================================== + +1 Implementation details +2 Driver support +3 Userspace support + +=============================================================================== +1: Implementation details + +The rfkill switch subsystem offers support for keys often found on laptops +to enable wireless devices like WiFi and Bluetooth. + +This is done by providing the user 3 possibilities: + 1 - The rfkill system handles all events; userspace is not aware of events. + 2 - The rfkill system handles all events; userspace is informed about the events. + 3 - The rfkill system does not handle events; userspace handles all events. + +The buttons to enable and disable the wireless radios are important in +situations where the user is for example using his laptop on a location where +wireless radios _must_ be disabled (e.g. airplanes). +Because of this requirement, userspace support for the keys should not be +made mandatory. Because userspace might want to perform some additional smarter +tasks when the key is pressed, rfkill still provides userspace the possibility +to take over the task to handle the key events. + +The system inside the kernel has been split into 2 separate sections: + 1 - RFKILL + 2 - RFKILL_INPUT + +The first option enables rfkill support and will make sure userspace will +be notified of any events through the input device. It also creates several +sysfs entries which can be used by userspace. See section "Userspace support". + +The second option provides an rfkill input handler. This handler will +listen to all rfkill key events and will toggle the radio accordingly. +With this option enabled userspace could either do nothing or simply +perform monitoring tasks. + +==================================== +2: Driver support + +To build a driver with rfkill subsystem support, the driver should +depend on the Kconfig symbol RFKILL; it should _not_ depend on +RKFILL_INPUT. + +Unless key events trigger an interrupt to which the driver listens, polling +will be required to determine the key state changes. For this the input +layer providers the input-polldev handler. + +A driver should implement a few steps to correctly make use of the +rfkill subsystem. First for non-polling drivers: + + - rfkill_allocate() + - input_allocate_device() + - rfkill_register() + - input_register_device() + +For polling drivers: + + - rfkill_allocate() + - input_allocate_polled_device() + - rfkill_register() + - input_register_polled_device() + +When a key event has been detected, the correct event should be +sent over the input device which has been registered by the driver. + +==================================== +3: Userspace support + +For each key an input device will be created which will send out the correct +key event when the rfkill key has been pressed. + +The following sysfs entries will be created: + + name: Name assigned by driver to this key (interface or driver name). + type: Name of the key type ("wlan", "bluetooth", etc). + state: Current state of the key. 1: On, 0: Off. + claim: 1: Userspace handles events, 0: Kernel handles events + +Both the "state" and "claim" entries are also writable. For the "state" entry +this means that when 1 or 0 is written all radios, not yet in the requested +state, will be will be toggled accordingly. +For the "claim" entry writing 1 to it means that the kernel no longer handles +key events even though RFKILL_INPUT input was enabled. When "claim" has been +set to 0, userspace should make sure that it listens for the input events or +check the sysfs "state" entry regularly to correctly perform the required +tasks when the rkfill key is pressed.Signature · 6 lines
1.5.3 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
PATCH v4 1/3 rfkill: Remove IRDA
In reply to Ivo van DoornAs Dmitry pointed out earlier, rfkill-input.c doesn't support irda because there are no users and we shouldn't add unrequired KEY_ defines.
However, RFKILL_TYPE_IRDA was defined in the rfkill.h header file and would confuse people about whether it is implemented or not.
This patch removes IRDA support completely, so it can be added whenever a driver wants the feature.
Signed-off-by Ivo van Doorn <[email protected]>
CC Dmitry Torokhov <[email protected]>
CC Inaky Perez-Gonzalez <[email protected]>
--- include/linux/rfkill.h | 8 +++----- net/rfkill/Kconfig | 2 +- net/rfkill/rfkill.c | 5 +---- 3 files changed, 5 insertions(+), 10 deletions(-)
include/linux/rfkill.h +3 -5
@@ -31,13 +31,11 @@* enum rfkill_type - type of rfkill switch. * RFKILL_TYPE_WLAN: switch is no a Wireless network devices. * RFKILL_TYPE_BlUETOOTH: switch is on a bluetooth device. -* RFKILL_TYPE_IRDA: switch is on an infrared devices. */ enum rfkill_type { -RFKILL_TYPE_WLAN =0 , -RFKILL_TYPE_BLUETOOTH =1 , -RFKILL_TYPE_IRDA =2 , -RFKILL_TYPE_MAX =3 , +RFKILL_TYPE_WLAN , +RFKILL_TYPE_BLUETOOTH , +RFKILL_TYPE_MAX , };enum rfkill_state {
net/rfkill/Kconfig +1 -1
@@ -5,7 +5,7 @@ menuconfig RFKILL tristate "RF switch subsystem support" help Say Y here if you want to have control over RF switches - found on many WiFi, Bluetooth and IRDA cards. + found on many WiFi and Bluetooth cards. To compile this driver as a module, choose M here: the module will be called rfkill.
net/rfkill/rfkill.c +1 -4
@@ -106,9 +106,6 @@ static ssize_t rfkill_type_show(struct device *dev,case RFKILL_TYPE_BLUETOOTH : type ="bluetooth" ;break ; -case RFKILL_TYPE_IRDA : - type ="irda" ; -break ;default :BUG (); }
@@ -281,7 +278,7 @@ static void rfkill_remove_switch(struct rfkill *rfkill)/** * rfkill_allocate - allocate memory for rfkill structure. * @parent: device that has rf switch on it -* @type: type of the switch (wlan, bluetooth, irda) +* @type: type of the switch (RFKILL_TYPE_*) * * This function should be called by the network driver when it needs * rfkill structure. Once the structure is allocated the driver shoud
Signature · 1 line
1.5.3
PATCH v4 2/3 rfkill: Add support for ultrawideband
In reply to Ivo van DoornThis patch will add support for UWB keys to rfkill, support for this has been requested by Inaky.
Signed-off-by Ivo van Doorn <[email protected]>
CC Dmitry Torokhov <[email protected]>
CC Inaky Perez-Gonzalez <[email protected]>
--- include/linux/input.h | 1 + include/linux/rfkill.h | 2 ++ net/rfkill/rfkill-input.c | 9 +++++++++ net/rfkill/rfkill.c | 3 +++ 4 files changed, 15 insertions(+), 0 deletions(-)
include/linux/input.h +1 -0
@@ -360,6 +360,7 @@ struct input_absinfo {#define KEY_BLUETOOTH 237#define KEY_WLAN 238 +#define KEY_UWB 239#define KEY_UNKNOWN 240
include/linux/rfkill.h +2 -0
@@ -31,10 +31,12 @@* enum rfkill_type - type of rfkill switch. * RFKILL_TYPE_WLAN: switch is no a Wireless network devices. * RFKILL_TYPE_BlUETOOTH: switch is on a bluetooth device. +* RFKILL_TYPE_UWB: switch is on a Ultra wideband device. */ enum rfkill_type {RFKILL_TYPE_WLAN ,RFKILL_TYPE_BLUETOOTH , +RFKILL_TYPE_UWB ,RFKILL_TYPE_MAX , };
net/rfkill/rfkill-input.c +9 -0
@@ -81,6 +81,7 @@ static void rfkill_schedule_toggle(struct rfkill_task *task) static DEFINE_RFKILL_TASK(rfkill_wlan, RFKILL_TYPE_WLAN); static DEFINE_RFKILL_TASK(rfkill_bt, RFKILL_TYPE_BLUETOOTH); +static DEFINE_RFKILL_TASK(rfkill_uwb, RFKILL_TYPE_UWB);static void rfkill_event (struct input_handle *handle,unsigned int type,unsigned int code,int down)
@@ -93,6 +94,9 @@ static void rfkill_event(struct input_handle *handle, unsigned int type,case KEY_BLUETOOTH :rfkill_schedule_toggle (&rfkill_bt);break ; +case KEY_UWB : +rfkill_schedule_toggle (&rfkill_uwb); +break ;default :break ; }
@@ -148,6 +152,11 @@ static const struct input_device_id rfkill_ids[] = { .evbit = { BIT(EV_KEY) }, .keybit = { [LONG(KEY_BLUETOOTH)] = BIT(KEY_BLUETOOTH) }, }, + { + .flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_KEYBIT, + .evbit = { BIT(EV_KEY) }, + .keybit = { [LONG(KEY_UWB)] = BIT(KEY_UWB) }, + }, { } };
net/rfkill/rfkill.c +3 -0
@@ -106,6 +106,9 @@ static ssize_t rfkill_type_show(struct device *dev,case RFKILL_TYPE_BLUETOOTH : type ="bluetooth" ;break ; +case RFKILL_TYPE_UWB : + type ="ultrawideband" ; +break ;default :BUG (); }
Signature · 1 line
1.5.3
PATCH v4 3/3 rfkill: Add rfkill documentation
In reply to Ivo van DoornAdd a documentation file which contains
a short description about rfkill with some
notes about drivers and the userspace interface.
Changes since v1 and v2:
- Spellchecking
Signed-off-by Ivo van Doorn <[email protected]>
Acked-by Dmitry Torokhov <[email protected]>
Acked-by Randy Dunlap <[email protected]>
--- Documentation/rfkill.txt | 89 ++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 89 insertions(+), 0 deletions(-) create mode 100644 Documentation/rfkill.txt
Documentation/rfkill.txt new file +89 -0
@@ -0,0 +1,89 @@ +rfkill - RF switch subsystem support +==================================== + +1 Implementation details +2 Driver support +3 Userspace support + +=============================================================================== +1: Implementation details + +The rfkill switch subsystem offers support for keys often found on laptops +to enable wireless devices like WiFi and Bluetooth. + +This is done by providing the user 3 possibilities: + 1 - The rfkill system handles all events; userspace is not aware of events. + 2 - The rfkill system handles all events; userspace is informed about the events. + 3 - The rfkill system does not handle events; userspace handles all events. + +The buttons to enable and disable the wireless radios are important in +situations where the user is for example using his laptop on a location where +wireless radios _must_ be disabled (e.g. airplanes). +Because of this requirement, userspace support for the keys should not be +made mandatory. Because userspace might want to perform some additional smarter +tasks when the key is pressed, rfkill still provides userspace the possibility +to take over the task to handle the key events. + +The system inside the kernel has been split into 2 separate sections: + 1 - RFKILL + 2 - RFKILL_INPUT + +The first option enables rfkill support and will make sure userspace will +be notified of any events through the input device. It also creates several +sysfs entries which can be used by userspace. See section "Userspace support". + +The second option provides an rfkill input handler. This handler will +listen to all rfkill key events and will toggle the radio accordingly. +With this option enabled userspace could either do nothing or simply +perform monitoring tasks. + +==================================== +2: Driver support + +To build a driver with rfkill subsystem support, the driver should +depend on the Kconfig symbol RFKILL; it should _not_ depend on +RKFILL_INPUT. + +Unless key events trigger an interrupt to which the driver listens, polling +will be required to determine the key state changes. For this the input +layer providers the input-polldev handler. + +A driver should implement a few steps to correctly make use of the +rfkill subsystem. First for non-polling drivers: + + - rfkill_allocate() + - input_allocate_device() + - rfkill_register() + - input_register_device() + +For polling drivers: + + - rfkill_allocate() + - input_allocate_polled_device() + - rfkill_register() + - input_register_polled_device() + +When a key event has been detected, the correct event should be +sent over the input device which has been registered by the driver. + +==================================== +3: Userspace support + +For each key an input device will be created which will send out the correct +key event when the rfkill key has been pressed. + +The following sysfs entries will be created: + + name: Name assigned by driver to this key (interface or driver name). + type: Name of the key type ("wlan", "bluetooth", etc). + state: Current state of the key. 1: On, 0: Off. + claim: 1: Userspace handles events, 0: Kernel handles events + +Both the "state" and "claim" entries are also writable. For the "state" entry +this means that when 1 or 0 is written all radios, not yet in the requested +state, will be will be toggled accordingly. +For the "claim" entry writing 1 to it means that the kernel no longer handles +key events even though RFKILL_INPUT input was enabled. When "claim" has been +set to 0, userspace should make sure that it listens for the input events or +check the sysfs "state" entry regularly to correctly perform the required +tasks when the rkfill key is pressed.
Signature · 1 line
1.5.3
From: Ivo van Doorn <[email protected]>
Date: Wed, 12 Sep 2007 20:14:26 +0200
Quoted 8 lines
As Dmitry pointed out earlier,
rfkill-input.cdoesn't support irda because there are no users and we shouldn't add unrequiredKEY_defines.However,
RFKILL_TYPE_IRDAwas defined in therfkill.hheader file and would confuse people about whether it is implemented or not.
Quoted 7 lines
This patch removes IRDA support completely, so it can be added whenever a driver wants the feature.
Signed-off-by Ivo van Doorn <[email protected]>CC Dmitry Torokhov <[email protected]>CC Inaky Perez-Gonzalez <[email protected]>
Applied to net-2.6.24
Re: [PATCH 2/3 v4] rfkill: Add support for ultrawideband
In reply to Ivo van DoornFrom: Ivo van Doorn <[email protected]>
Date: Wed, 12 Sep 2007 20:14:29 +0200
Quoted 6 lines
This patch will add support for UWB keys to rfkill, support for this has been requested by Inaky.
Signed-off-by Ivo van Doorn <[email protected]>CC Dmitry Torokhov <[email protected]>CC Inaky Perez-Gonzalez <[email protected]>
Applied to net-2.6.24
Re: [PATCH 3/3 v4] rfkill: Add rfkill documentation
In reply to Ivo van DoornFrom: Ivo van Doorn <[email protected]>
Date: Wed, 12 Sep 2007 20:14:39 +0200
Quoted 10 lines
Add a documentation file which contains a short description about rfkill with some notes about drivers and the userspace interface.
Changes since v1 and v2:
- SpellcheckingSigned-off-by Ivo van Doorn <[email protected]>Acked-by Dmitry Torokhov <[email protected]>Acked-by Randy Dunlap <[email protected]>
Applied to net-2.6.24, thanks.