Re: [PATCH 5/5] rfkill: remove transmitter blocking on suspend

[Philip Langdale <philipl@overt.org>]

On Tue, 26 Aug 2008 11:58:01 -0300, Henrique de Moraes Holschuh
<hmh@hmh.eng.br> wrote:
> 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):

> 	toshiba-acpi w/rfkill support (not in mainline yet)

The toshiba bluetooth device is automatically disconnected and powered down
at suspend - and I'm glad to know that rfkill will still attempt to restore
the state - because the hardware definitely won't. :-)

So, no new work here.

--phil