aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorHenrique de Moraes Holschuh <hmh@hmh.eng.br>2008-08-26 10:58:01 -0400
committerJohn W. Linville <linville@tuxdriver.com>2008-09-15 16:48:25 -0400
commitbed7aac9416f50425d2200df32bcc9bf248ff8cb (patch)
tree4471647eb3e15d3afb7eba8642537b96561dff7b /Documentation
parente35cc4ddcc4c3b11006bcabe8ce28aa7e18da318 (diff)
rfkill: remove transmitter blocking on suspend
Currently, rfkill would stand in the way of properly supporting wireless devices that are capable of waking the system up from sleep or hibernation when they receive a special wireless message. It would also get in the way of mesh devices that need to remain operational even during platform suspend. To avoid that, stop trying to block the transmitters on the rfkill class suspend handler. Drivers that need rfkill's older behaviour will have to implement it by themselves in their own suspend handling. Do note that rfkill *will* attempt to restore the transmitter state on resume in any situation. This happens after the driver's resume method is called by the suspend core (class devices resume after the devices they are attached to have been resumed). The following drivers need to check if they need to explicitly block their transmitters in their own suspend handlers (maintainers Cc'd): arch/arm/mach-pxa/tosa-bt.c drivers/net/usb/hso.c drivers/net/wireless/rt2x00/* (USB might need it?) drivers/net/wireless/b43/ (SSB over USB might need it?) drivers/misc/hp-wmi.c eeepc-laptop w/rfkill support (not in mainline yet) Compal laptop w/rfkill support (not in mainline yet) toshiba-acpi w/rfkill support (not in mainline yet) Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: Matthew Garrett <mjg@redhat.com> Cc: Andrew Bird <ajb@spheresystems.co.uk> Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: Cezary Jackiewicz <cezary.jackiewicz@gmail.com> Cc: Philip Langdale <philipl@overt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/rfkill.txt32
1 files changed, 28 insertions, 4 deletions
diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
index 6fcb3060dec5..b65f0799df48 100644
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt
@@ -341,6 +341,8 @@ key that does nothing by itself, as well as any hot key that is type-specific
3413.1 Guidelines for wireless device drivers 3413.1 Guidelines for wireless device drivers
342------------------------------------------ 342------------------------------------------
343 343
344(in this text, rfkill->foo means the foo field of struct rfkill).
345
3441. Each independent transmitter in a wireless device (usually there is only one 3461. Each independent transmitter in a wireless device (usually there is only one
345transmitter per device) should have a SINGLE rfkill class attached to it. 347transmitter per device) should have a SINGLE rfkill class attached to it.
346 348
@@ -363,10 +365,32 @@ This rule exists because users of the rfkill subsystem expect to get (and set,
363when possible) the overall transmitter rfkill state, not of a particular rfkill 365when possible) the overall transmitter rfkill state, not of a particular rfkill
364line. 366line.
365 367
3665. During suspend, the rfkill class will attempt to soft-block the radio 3685. The wireless device driver MUST NOT leave the transmitter enabled during
367through a call to rfkill->toggle_radio, and will try to restore its previous 369suspend and hibernation unless:
368state during resume. After a rfkill class is suspended, it will *not* call 370
369rfkill->toggle_radio until it is resumed. 371 5.1. The transmitter has to be enabled for some sort of functionality
372 like wake-on-wireless-packet or autonomous packed forwarding in a mesh
373 network, and that functionality is enabled for this suspend/hibernation
374 cycle.
375
376AND
377
378 5.2. The device was not on a user-requested BLOCKED state before
379 the suspend (i.e. the driver must NOT unblock a device, not even
380 to support wake-on-wireless-packet or remain in the mesh).
381
382In other words, there is absolutely no allowed scenario where a driver can
383automatically take action to unblock a rfkill controller (obviously, this deals
384with scenarios where soft-blocking or both soft and hard blocking is happening.
385Scenarios where hardware rfkill lines are the only ones blocking the
386transmitter are outside of this rule, since the wireless device driver does not
387control its input hardware rfkill lines in the first place).
388
3896. During resume, rfkill will try to restore its previous state.
390
3917. After a rfkill class is suspended, it will *not* call rfkill->toggle_radio
392until it is resumed.
393
370 394
371Example of a WLAN wireless driver connected to the rfkill subsystem: 395Example of a WLAN wireless driver connected to the rfkill subsystem:
372-------------------------------------------------------------------- 396--------------------------------------------------------------------