On 18/12/2010 13:29, Ohad Ben-Cohen wrote: > > During system suspend, our driver is asked (by mac80211's suspend > handler) to power off its device. When this happens, the driver has no > idea that the system is suspending - regular driver code (responsible > to remove the wlan interface and stop the device) is being called. > Obviously pm_runtime_put_sync() won't power off the device at this > point, but later during suspend, when the SDIO core will suspend, the > device will be powered off and things would work as expected. > > That breaks when the suspend transition is cancelled (e.g. due to an > error) before SDIO core gets the chance to power off the device: the > driver will be asked (by mac80211's resume handler) to power up the > device and reinitialize it, but since the device was never powered > off, the driver will fail doing so because the device is quiescent (a > power cycle should have put him into a communicable state, but that > never happened in this scenario). > > At that resume point the device is always on - whether the system > suspended successfully or not - and the driver can't tell whether the > device was indeed powered off beforehand or not. In addition, the > driver code that is going to fail is not a resume handler - it's just > regular driver code responsible for powering on the device and > reinitializing it (which is being called by mac80211's resume > handler). It's not clear where the problem is exactly. It may be useful if you describe the wi-fi chip's operational or power states and the valid transitions between them. Is the problem: 1. The suspend handler puts the wi-fi chip into a state that cannot be recovered from without a power cycle? The obvious solution would be to not put the chip into such a state. or 2. The resume handler fails because it cannot distinguish between a wi-fi chip that needs reinitializing from power-on and one that is already operational? There is probably a chip register you can query to determine if the chip was powered down or reset. In the absense of any suitable chip-specific register a CCCR register such as I/O Enable might be usable. David _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
