On Tue, Aug 26, 2008 at 11:58:01AM -0300, Henrique de Moraes Holschuh 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): > 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) Are we now satisfied that the in-kernel drivers above are all prepared for this patch? John -- John W. Linville linville@xxxxxxxxxxxxx -- 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
