On Tue, 26 Aug 2008 11:58:01 -0300, Henrique de Moraes Holschuh <hmh@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
