Re: subtle pm_runtime_put_sync race and sdio functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux