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>
bed7aac941