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): Normally when you change a kernel-api to operate differently, you also fix up the relevant parts of the kernel as well. Have you looked into these drivers to see if they do have this problem or not? thanks, greg k-h -- 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
