Commit dac24ab396fc92985060d5cb3c467d2d0ffc0c20
Committed by
David S. Miller
1 parent
e0665486b7
Exists in
master
and in
20 other branches
[RFKILL]: Add rfkill documentation
Add a documentation file which contains a short description about rfkill with some notes about drivers and the userspace interface. Changes since v1 and v2: - Spellchecking Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Acked-by: Dmitry Torokhov <dtor@mail.ru> Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Showing 1 changed file with 89 additions and 0 deletions Side-by-side Diff
Documentation/rfkill.txt
1 | +rfkill - RF switch subsystem support | |
2 | +==================================== | |
3 | + | |
4 | +1 Implementation details | |
5 | +2 Driver support | |
6 | +3 Userspace support | |
7 | + | |
8 | +=============================================================================== | |
9 | +1: Implementation details | |
10 | + | |
11 | +The rfkill switch subsystem offers support for keys often found on laptops | |
12 | +to enable wireless devices like WiFi and Bluetooth. | |
13 | + | |
14 | +This is done by providing the user 3 possibilities: | |
15 | + 1 - The rfkill system handles all events; userspace is not aware of events. | |
16 | + 2 - The rfkill system handles all events; userspace is informed about the events. | |
17 | + 3 - The rfkill system does not handle events; userspace handles all events. | |
18 | + | |
19 | +The buttons to enable and disable the wireless radios are important in | |
20 | +situations where the user is for example using his laptop on a location where | |
21 | +wireless radios _must_ be disabled (e.g. airplanes). | |
22 | +Because of this requirement, userspace support for the keys should not be | |
23 | +made mandatory. Because userspace might want to perform some additional smarter | |
24 | +tasks when the key is pressed, rfkill still provides userspace the possibility | |
25 | +to take over the task to handle the key events. | |
26 | + | |
27 | +The system inside the kernel has been split into 2 separate sections: | |
28 | + 1 - RFKILL | |
29 | + 2 - RFKILL_INPUT | |
30 | + | |
31 | +The first option enables rfkill support and will make sure userspace will | |
32 | +be notified of any events through the input device. It also creates several | |
33 | +sysfs entries which can be used by userspace. See section "Userspace support". | |
34 | + | |
35 | +The second option provides an rfkill input handler. This handler will | |
36 | +listen to all rfkill key events and will toggle the radio accordingly. | |
37 | +With this option enabled userspace could either do nothing or simply | |
38 | +perform monitoring tasks. | |
39 | + | |
40 | +==================================== | |
41 | +2: Driver support | |
42 | + | |
43 | +To build a driver with rfkill subsystem support, the driver should | |
44 | +depend on the Kconfig symbol RFKILL; it should _not_ depend on | |
45 | +RKFILL_INPUT. | |
46 | + | |
47 | +Unless key events trigger an interrupt to which the driver listens, polling | |
48 | +will be required to determine the key state changes. For this the input | |
49 | +layer providers the input-polldev handler. | |
50 | + | |
51 | +A driver should implement a few steps to correctly make use of the | |
52 | +rfkill subsystem. First for non-polling drivers: | |
53 | + | |
54 | + - rfkill_allocate() | |
55 | + - input_allocate_device() | |
56 | + - rfkill_register() | |
57 | + - input_register_device() | |
58 | + | |
59 | +For polling drivers: | |
60 | + | |
61 | + - rfkill_allocate() | |
62 | + - input_allocate_polled_device() | |
63 | + - rfkill_register() | |
64 | + - input_register_polled_device() | |
65 | + | |
66 | +When a key event has been detected, the correct event should be | |
67 | +sent over the input device which has been registered by the driver. | |
68 | + | |
69 | +==================================== | |
70 | +3: Userspace support | |
71 | + | |
72 | +For each key an input device will be created which will send out the correct | |
73 | +key event when the rfkill key has been pressed. | |
74 | + | |
75 | +The following sysfs entries will be created: | |
76 | + | |
77 | + name: Name assigned by driver to this key (interface or driver name). | |
78 | + type: Name of the key type ("wlan", "bluetooth", etc). | |
79 | + state: Current state of the key. 1: On, 0: Off. | |
80 | + claim: 1: Userspace handles events, 0: Kernel handles events | |
81 | + | |
82 | +Both the "state" and "claim" entries are also writable. For the "state" entry | |
83 | +this means that when 1 or 0 is written all radios, not yet in the requested | |
84 | +state, will be will be toggled accordingly. | |
85 | +For the "claim" entry writing 1 to it means that the kernel no longer handles | |
86 | +key events even though RFKILL_INPUT input was enabled. When "claim" has been | |
87 | +set to 0, userspace should make sure that it listens for the input events or | |
88 | +check the sysfs "state" entry regularly to correctly perform the required | |
89 | +tasks when the rkfill key is pressed. |