blob: 5316cea95ce0af0eeabbb62c0d5ff3eb1f8d31d8 [file] [log] [blame]
Ivo van Doorndac24ab2007-09-13 09:22:55 +02001rfkill - RF switch subsystem support
2====================================
3
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -030041 Introduction
52 Implementation details
63 Kernel driver guidelines
74 Kernel API
85 Userspace support
Ivo van Doorndac24ab2007-09-13 09:22:55 +02009
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -030010
111. Introduction:
Ivo van Doorndac24ab2007-09-13 09:22:55 +020012
Henrique de Moraes Holschuhf3146af2008-06-23 17:22:56 -030013The rfkill switch subsystem exists to add a generic interface to circuitry that
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -030014can enable or disable the signal output of a wireless *transmitter* of any
15type. By far, the most common use is to disable radio-frequency transmitters.
Henrique de Moraes Holschuhf3146af2008-06-23 17:22:56 -030016
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -030017The rfkill switch subsystem offers support for keys and switches often found on
18laptops to enable wireless devices like WiFi and Bluetooth to actually perform
19an action.
Henrique de Moraes Holschuhf3146af2008-06-23 17:22:56 -030020
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -030021The buttons to enable and disable the wireless transmitters are important in
Ivo van Doorndac24ab2007-09-13 09:22:55 +020022situations where the user is for example using his laptop on a location where
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -030023radio-frequency transmitters _must_ be disabled (e.g. airplanes).
24
25Because of this requirement, userspace support for the keys should not be made
26mandatory. Because userspace might want to perform some additional smarter
27tasks when the key is pressed, rfkill provides userspace the possibility to
28take over the task to handle the key events.
29
30===============================================================================
312: Implementation details
32
33The rfkill class provides kernel drivers with an interface that allows them to
34know when they should enable or disable a wireless network device transmitter.
35
36The rfkill-input module provides the kernel with the ability to implement a
37basic response when the user presses a key or button (or toggles a switch)
38related to rfkill functionality. It is an in-kernel implementation of default
39policy of reacting to rfkill-related input events and neither mandatory nor
40required for wireless drivers to operate.
41
42The rfkill-input module also provides EPO (emergency power-off) functionality
43for all wireless transmitters. This function cannot be overriden, and it is
44always active. rfkill EPO is related to *_RFKILL_ALL input events.
45
46All state changes on rfkill devices are propagated by the rfkill class to a
47notification chain and also to userspace through uevents.
Ivo van Doorndac24ab2007-09-13 09:22:55 +020048
49The system inside the kernel has been split into 2 separate sections:
50 1 - RFKILL
51 2 - RFKILL_INPUT
52
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -030053The first option enables rfkill support and will make sure userspace will be
54notified of any events through uevents. It provides a notification chain for
55interested parties in the kernel to also get notified of rfkill state changes
56in other drivers. It creates several sysfs entries which can be used by
57userspace. See section "Userspace support".
Ivo van Doorndac24ab2007-09-13 09:22:55 +020058
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -030059The second option provides an rfkill input handler. This handler will listen to
60all rfkill key events and will toggle the radio accordingly. With this option
61enabled userspace could either do nothing or simply perform monitoring tasks.
Ivo van Doorndac24ab2007-09-13 09:22:55 +020062
Henrique de Moraes Holschuh50056572008-06-23 17:46:42 -030063When a rfkill switch is in the RFKILL_STATE_UNBLOCKED, the wireless transmitter
64(radio TX circuit for example) is *enabled*. When the rfkill switch is in the
65RFKILL_STATE_SOFT_BLOCKED or RFKILL_STATE_HARD_BLOCKED, the wireless
66transmitter is to be *blocked* from operating.
67
68RFKILL_STATE_SOFT_BLOCKED indicates that a call to toggle_radio() can change
69that state. RFKILL_STATE_HARD_BLOCKED indicates that a call to toggle_radio()
70will not be able to change the state and will return with a suitable error if
71attempts are made to set the state to RFKILL_STATE_UNBLOCKED.
72
73RFKILL_STATE_HARD_BLOCKED is used by drivers to signal that the device is
74locked in the BLOCKED state by a hardwire rfkill line (typically an input pin
75that, when active, forces the transmitter to be disabled) which the driver
76CANNOT override.
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -030077
78Full rfkill functionality requires two different subsystems to cooperate: the
79input layer and the rfkill class. The input layer issues *commands* to the
80entire system requesting that devices registered to the rfkill class change
81state. The way this interaction happens is not complex, but it is not obvious
82either:
83
84Kernel Input layer:
85
86 * Generates KEY_WWAN, KEY_WLAN, KEY_BLUETOOTH, SW_RFKILL_ALL, and
87 other such events when the user presses certain keys, buttons, or
88 toggles certain physical switches.
89
90 THE INPUT LAYER IS NEVER USED TO PROPAGATE STATUS, NOTIFICATIONS OR THE
91 KIND OF STUFF AN ON-SCREEN-DISPLAY APPLICATION WOULD REPORT. It is
92 used to issue *commands* for the system to change behaviour, and these
93 commands may or may not be carried out by some kernel driver or
94 userspace application. It follows that doing user feedback based only
95 on input events is broken, there is no guarantee that an input event
96 will be acted upon.
97
98 Most wireless communication device drivers implementing rfkill
99 functionality MUST NOT generate these events, and have no reason to
100 register themselves with the input layer. This is a common
101 misconception. There is an API to propagate rfkill status change
102 information, and it is NOT the input layer.
103
104rfkill class:
105
106 * Calls a hook in a driver to effectively change the wireless
107 transmitter state;
108 * Keeps track of the wireless transmitter state (with help from
109 the driver);
110 * Generates userspace notifications (uevents) and a call to a
111 notification chain (kernel) when there is a wireless transmitter
112 state change;
113 * Connects a wireless communications driver with the common rfkill
114 control system, which, for example, allows actions such as
115 "switch all bluetooth devices offline" to be carried out by
116 userspace or by rfkill-input.
117
118 THE RFKILL CLASS NEVER ISSUES INPUT EVENTS. THE RFKILL CLASS DOES
119 NOT LISTEN TO INPUT EVENTS. NO DRIVER USING THE RFKILL CLASS SHALL
120 EVER LISTEN TO, OR ACT ON RFKILL INPUT EVENTS.
121
122 Most wireless data communication drivers in the kernel have just to
123 implement the rfkill class API to work properly. Interfacing to the
124 input layer is not often required (and is very often a *bug*).
125
126Userspace input handlers (uevents) or kernel input handlers (rfkill-input):
127
128 * Implements the policy of what should happen when one of the input
129 layer events related to rfkill operation is received.
130 * Uses the sysfs interface (userspace) or private rfkill API calls
131 to tell the devices registered with the rfkill class to change
132 their state (i.e. translates the input layer event into real
133 action).
134 * rfkill-input implements EPO by handling EV_SW SW_RFKILL_ALL 0
135 (power off all transmitters) in a special way: it ignores any
Henrique de Moraes Holschuh50056572008-06-23 17:46:42 -0300136 overrides and local state cache and forces all transmitters to the
137 RFKILL_STATE_SOFT_BLOCKED state (including those which are already
138 supposed to be BLOCKED). Note that the opposite event (power on all
139 transmitters) is handled normally.
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -0300140
141Userspace uevent handler or kernel platform-specific drivers hooked to the
142rfkill notifier chain:
143
144 * Taps into the rfkill notifier chain or to KOBJ_CHANGE uevents,
145 in order to know when a device that is registered with the rfkill
146 class changes state;
147 * Issues feedback notifications to the user;
148 * In the rare platforms where this is required, synthesizes an input
149 event to command all *OTHER* rfkill devices to also change their
150 statues when a specific rfkill device changes state.
151
152
153===============================================================================
1543: Kernel driver guidelines
155
156The first thing one needs to know is whether his driver should be talking to
157the rfkill class or to the input layer.
158
159Do not mistake input devices for rfkill devices. The only type of "rfkill
160switch" device that is to be registered with the rfkill class are those
161directly controlling the circuits that cause a wireless transmitter to stop
162working (or the software equivalent of them). Every other kind of "rfkill
163switch" is just an input device and MUST NOT be registered with the rfkill
164class.
165
166A driver should register a device with the rfkill class when ALL of the
167following conditions are met:
168
1691. The device is/controls a data communications wireless transmitter;
170
1712. The kernel can interact with the hardware/firmware to CHANGE the wireless
172 transmitter state (block/unblock TX operation);
173
174A driver should register a device with the input subsystem to issue
175rfkill-related events (KEY_WLAN, KEY_BLUETOOTH, KEY_WWAN, KEY_WIMAX,
176SW_RFKILL_ALL, etc) when ALL of the folowing conditions are met:
177
1781. It is directly related to some physical device the user interacts with, to
179 command the O.S./firmware/hardware to enable/disable a data communications
180 wireless transmitter.
181
182 Examples of the physical device are: buttons, keys and switches the user
183 will press/touch/slide/switch to enable or disable the wireless
184 communication device.
185
1862. It is NOT slaved to another device, i.e. there is no other device that
187 issues rfkill-related input events in preference to this one.
188
189 Typically, the ACPI "radio kill" switch of a laptop is the master input
190 device to issue rfkill events, and, e.g., the WLAN card is just a slave
191 device that gets disabled by its hardware radio-kill input pin.
192
193When in doubt, do not issue input events. For drivers that should generate
194input events in some platforms, but not in others (e.g. b43), the best solution
195is to NEVER generate input events in the first place. That work should be
196deferred to a platform-specific kernel module (which will know when to generate
197events through the rfkill notifier chain) or to userspace. This avoids the
198usual maintenance problems with DMI whitelisting.
199
200
201Corner cases and examples:
Ivo van Doorndac24ab2007-09-13 09:22:55 +0200202====================================
Ivo van Doorndac24ab2007-09-13 09:22:55 +0200203
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -03002041. If the device is an input device that, because of hardware or firmware,
205causes wireless transmitters to be blocked regardless of the kernel's will, it
206is still just an input device, and NOT to be registered with the rfkill class.
Ivo van Doorndac24ab2007-09-13 09:22:55 +0200207
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -03002082. If the wireless transmitter switch control is read-only, it is an input
209device and not to be registered with the rfkill class (and maybe not to be made
210an input layer event source either, see below).
Ivo van Doorndac24ab2007-09-13 09:22:55 +0200211
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -03002123. If there is some other device driver *closer* to the actual hardware the
213user interacted with (the button/switch/key) to issue an input event, THAT is
214the device driver that should be issuing input events.
Ivo van Doorndac24ab2007-09-13 09:22:55 +0200215
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -0300216E.g:
217 [RFKILL slider switch] -- [GPIO hardware] -- [WLAN card rf-kill input]
218 (platform driver) (wireless card driver)
Ivo van Doorndac24ab2007-09-13 09:22:55 +0200219
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -0300220The user is closer to the RFKILL slide switch plaform driver, so the driver
221which must issue input events is the platform driver looking at the GPIO
222hardware, and NEVER the wireless card driver (which is just a slave). It is
223very likely that there are other leaves than just the WLAN card rf-kill input
224(e.g. a bluetooth card, etc)...
Ivo van Doorndac24ab2007-09-13 09:22:55 +0200225
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -0300226On the other hand, some embedded devices do this:
Ivo van Doorndac24ab2007-09-13 09:22:55 +0200227
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -0300228 [RFKILL slider switch] -- [WLAN card rf-kill input]
229 (wireless card driver)
Ivo van Doorndac24ab2007-09-13 09:22:55 +0200230
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -0300231In this situation, the wireless card driver *could* register itself as an input
232device and issue rf-kill related input events... but in order to AVOID the need
233for DMI whitelisting, the wireless card driver does NOT do it. Userspace (HAL)
234or a platform driver (that exists only on these embedded devices) will do the
235dirty job of issuing the input events.
236
237
238COMMON MISTAKES in kernel drivers, related to rfkill:
Ivo van Doorndac24ab2007-09-13 09:22:55 +0200239====================================
Ivo van Doorndac24ab2007-09-13 09:22:55 +0200240
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -03002411. NEVER confuse input device keys and buttons with input device switches.
242
243 1a. Switches are always set or reset. They report the current state
244 (on position or off position).
245
246 1b. Keys and buttons are either in the pressed or not-pressed state, and
247 that's it. A "button" that latches down when you press it, and
248 unlatches when you press it again is in fact a switch as far as input
249 devices go.
250
251Add the SW_* events you need for switches, do NOT try to emulate a button using
252KEY_* events just because there is no such SW_* event yet. Do NOT try to use,
253for example, KEY_BLUETOOTH when you should be using SW_BLUETOOTH instead.
254
2552. Input device switches (sources of EV_SW events) DO store their current
256state, and that state CAN be queried from userspace through IOCTLs. There is
257no sysfs interface for this, but that doesn't mean you should break things
258trying to hook it to the rfkill class to get a sysfs interface :-)
259
2603. Do not issue *_RFKILL_ALL events, unless you are sure it is the correct
261event for your switch/button. These events are emergency power-off events when
262they are trying to turn the transmitters off. An example of an input device
263which SHOULD generate *_RFKILL_ALL events is the wireless-kill switch in a
264laptop which is NOT a hotkey, but a real switch that kills radios in hardware,
265even if the O.S. has gone to lunch. An example of an input device which SHOULD
266NOT generate *_RFKILL_ALL events is any sort of hot key that does nothing by
267itself, as well as any hot key that is type-specific (e.g. the one for WLAN).
268
269
270===============================================================================
2714: Kernel API
272
273To build a driver with rfkill subsystem support, the driver should depend on
274the Kconfig symbol RFKILL; it should _not_ depend on RKFILL_INPUT.
275
276The hardware the driver talks to may be write-only (where the current state
277of the hardware is unknown), or read-write (where the hardware can be queried
278about its current state).
279
280The rfkill class will call the get_state hook of a device every time it needs
281to know the *real* current state of the hardware. This can happen often.
282
283Some hardware provides events when its status changes. In these cases, it is
284best for the driver to not provide a get_state hook, and instead register the
285rfkill class *already* with the correct status, and keep it updated using
286rfkill_force_state() when it gets an event from the hardware.
287
288There is no provision for a statically-allocated rfkill struct. You must
289use rfkill_allocate() to allocate one.
290
291You should:
292 - rfkill_allocate()
293 - modify rfkill fields (flags, name)
294 - modify state to the current hardware state (THIS IS THE ONLY TIME
295 YOU CAN ACCESS state DIRECTLY)
296 - rfkill_register()
297
Henrique de Moraes Holschuh50056572008-06-23 17:46:42 -0300298The only way to set a device to the RFKILL_STATE_HARD_BLOCKED state is through
299a suitable return of get_state() or through rfkill_force_state().
300
301When a device is in the RFKILL_STATE_HARD_BLOCKED state, the only way to switch
302it to a different state is through a suitable return of get_state() or through
303rfkill_force_state().
304
305If toggle_radio() is called to set a device to state RFKILL_STATE_SOFT_BLOCKED
306when that device is already at the RFKILL_STATE_HARD_BLOCKED state, it should
307not return an error. Instead, it should try to double-block the transmitter,
308so that its state will change from RFKILL_STATE_HARD_BLOCKED to
309RFKILL_STATE_SOFT_BLOCKED should the hardware blocking cease.
310
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -0300311Please refer to the source for more documentation.
312
313===============================================================================
3145: Userspace support
315
316rfkill devices issue uevents (with an action of "change"), with the following
317environment variables set:
318
319RFKILL_NAME
320RFKILL_STATE
321RFKILL_TYPE
322
323The ABI for these variables is defined by the sysfs attributes. It is best
324to take a quick look at the source to make sure of the possible values.
325
326It is expected that HAL will trap those, and bridge them to DBUS, etc. These
327events CAN and SHOULD be used to give feedback to the user about the rfkill
328status of the system.
329
330Input devices may issue events that are related to rfkill. These are the
331various KEY_* events and SW_* events supported by rfkill-input.c.
332
333******IMPORTANT******
334When rfkill-input is ACTIVE, userspace is NOT TO CHANGE THE STATE OF AN RFKILL
335SWITCH IN RESPONSE TO AN INPUT EVENT also handled by rfkill-input, unless it
336has set to true the user_claim attribute for that particular switch. This rule
337is *absolute*; do NOT violate it.
338******IMPORTANT******
339
340Userspace must not assume it is the only source of control for rfkill switches.
341Their state CAN and WILL change on its own, due to firmware actions, direct
342user actions, and the rfkill-input EPO override for *_RFKILL_ALL.
343
344When rfkill-input is not active, userspace must initiate an rfkill status
345change by writing to the "state" attribute in order for anything to happen.
346
347Take particular care to implement EV_SW SW_RFKILL_ALL properly. When that
348switch is set to OFF, *every* rfkill device *MUST* be immediately put into the
Henrique de Moraes Holschuh50056572008-06-23 17:46:42 -0300349RFKILL_STATE_SOFT_BLOCKED state, no questions asked.
Ivo van Doorndac24ab2007-09-13 09:22:55 +0200350
351The following sysfs entries will be created:
352
353 name: Name assigned by driver to this key (interface or driver name).
354 type: Name of the key type ("wlan", "bluetooth", etc).
Henrique de Moraes Holschuh50056572008-06-23 17:46:42 -0300355 state: Current state of the transmitter
356 0: RFKILL_STATE_SOFT_BLOCKED
357 transmitter is forced off, but you can override it
358 by a write to the state attribute, or through input
359 events (if rfkill-input is loaded).
360 1: RFKILL_STATE_UNBLOCKED
361 transmiter is NOT forced off, and may operate if
362 all other conditions for such operation are met
363 (such as interface is up and configured, etc).
364 2: RFKILL_STATE_HARD_BLOCKED
365 transmitter is forced off by something outside of
366 the driver's control.
367
368 You cannot set a device to this state through
369 writes to the state attribute.
Ivo van Doorndac24ab2007-09-13 09:22:55 +0200370 claim: 1: Userspace handles events, 0: Kernel handles events
371
372Both the "state" and "claim" entries are also writable. For the "state" entry
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -0300373this means that when 1 or 0 is written, the device rfkill state (if not yet in
374the requested state), will be will be toggled accordingly.
375
Ivo van Doorndac24ab2007-09-13 09:22:55 +0200376For the "claim" entry writing 1 to it means that the kernel no longer handles
377key events even though RFKILL_INPUT input was enabled. When "claim" has been
378set to 0, userspace should make sure that it listens for the input events or
Henrique de Moraes Holschuhdc288522008-06-23 17:23:08 -0300379check the sysfs "state" entry regularly to correctly perform the required tasks
380when the rkfill key is pressed.
381
382A note about input devices and EV_SW events:
383
384In order to know the current state of an input device switch (like
385SW_RFKILL_ALL), you will need to use an IOCTL. That information is not
386available through sysfs in a generic way at this time, and it is not available
387through the rfkill class AT ALL.