On Sat, Dec 18, 2010 at 4:16 PM, David Vrabel <david.vrabel@xxxxxxx> wrote: ... > It may be useful if you > describe the wi-fi chip's operational or power states and the valid > transitions between them. Sure. When powered up initially, the device is a standard SDIO device that responds to bus transactions. Soon after being initialized (firmware download, configuration, etc..), the device is put at a quiescent state by the driver, and therefore the driver has to be explicitly wake it up before any SDIO communication takes place. Toggling the device's power down and up again brings it back to the fully active state. > 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? Yes. But please note that it's not the driver's resume handler, it's just regular driver code that powers up the device and reinitializes it (that happens to be called by mac80211's resume handler here, but otherwise is the regular code that powers up the device and initializes when the user brings up the wlan interface). > 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. That's a problem: without knowing if the device was powered off or not, the driver will have to do some guess work, where an SDIO error would indicate that the device was powered on all along (and therefore just needs to be waken up). That's not pretty: even if that didn't involve bus errors, it means adding a bus transaction just to tell between two different legitimate software paths (we would also need to add code that would reset the device state in case it wasn't powered off. Usually the driver assumed it can just power off the device, but if that's not the case anymore, the driver will have to do that differently. We never tried that so I can't tell if it'd be trivial or not, but I'm concerned because usually untested device scenarios tend to be quirky...). Thanks, Ohad. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
