Commit bed7aac9 authored by Henrique de Moraes Holschuh's avatar Henrique de Moraes Holschuh Committed by John W. Linville

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: default avatarHenrique 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: default avatarJohn W. Linville <linville@tuxdriver.com>
parent e35cc4dd
...@@ -341,6 +341,8 @@ key that does nothing by itself, as well as any hot key that is type-specific ...@@ -341,6 +341,8 @@ key that does nothing by itself, as well as any hot key that is type-specific
3.1 Guidelines for wireless device drivers 3.1 Guidelines for wireless device drivers
------------------------------------------ ------------------------------------------
(in this text, rfkill->foo means the foo field of struct rfkill).
1. Each independent transmitter in a wireless device (usually there is only one 1. Each independent transmitter in a wireless device (usually there is only one
transmitter per device) should have a SINGLE rfkill class attached to it. transmitter per device) should have a SINGLE rfkill class attached to it.
...@@ -363,10 +365,32 @@ This rule exists because users of the rfkill subsystem expect to get (and set, ...@@ -363,10 +365,32 @@ This rule exists because users of the rfkill subsystem expect to get (and set,
when possible) the overall transmitter rfkill state, not of a particular rfkill when possible) the overall transmitter rfkill state, not of a particular rfkill
line. line.
5. During suspend, the rfkill class will attempt to soft-block the radio 5. The wireless device driver MUST NOT leave the transmitter enabled during
through a call to rfkill->toggle_radio, and will try to restore its previous suspend and hibernation unless:
state during resume. After a rfkill class is suspended, it will *not* call
rfkill->toggle_radio until it is resumed. 5.1. The transmitter has to be enabled for some sort of functionality
like wake-on-wireless-packet or autonomous packed forwarding in a mesh
network, and that functionality is enabled for this suspend/hibernation
cycle.
AND
5.2. The device was not on a user-requested BLOCKED state before
the suspend (i.e. the driver must NOT unblock a device, not even
to support wake-on-wireless-packet or remain in the mesh).
In other words, there is absolutely no allowed scenario where a driver can
automatically take action to unblock a rfkill controller (obviously, this deals
with scenarios where soft-blocking or both soft and hard blocking is happening.
Scenarios where hardware rfkill lines are the only ones blocking the
transmitter are outside of this rule, since the wireless device driver does not
control its input hardware rfkill lines in the first place).
6. During resume, rfkill will try to restore its previous state.
7. After a rfkill class is suspended, it will *not* call rfkill->toggle_radio
until it is resumed.
Example of a WLAN wireless driver connected to the rfkill subsystem: Example of a WLAN wireless driver connected to the rfkill subsystem:
-------------------------------------------------------------------- --------------------------------------------------------------------
......
...@@ -512,21 +512,9 @@ static void rfkill_release(struct device *dev) ...@@ -512,21 +512,9 @@ static void rfkill_release(struct device *dev)
#ifdef CONFIG_PM #ifdef CONFIG_PM
static int rfkill_suspend(struct device *dev, pm_message_t state) static int rfkill_suspend(struct device *dev, pm_message_t state)
{ {
struct rfkill *rfkill = to_rfkill(dev); /* mark class device as suspended */
if (dev->power.power_state.event != state.event)
if (dev->power.power_state.event != state.event) {
if (state.event & PM_EVENT_SLEEP) {
/* Stop transmitter, keep state, no notifies */
update_rfkill_state(rfkill);
mutex_lock(&rfkill->mutex);
rfkill->toggle_radio(rfkill->data,
RFKILL_STATE_SOFT_BLOCKED);
mutex_unlock(&rfkill->mutex);
}
dev->power.power_state = state; dev->power.power_state = state;
}
return 0; return 0;
} }
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment