On Saturday, December 18, 2010, Johannes Berg wrote: > On Sat, 2010-12-18 at 18:00 +0200, Ohad Ben-Cohen wrote: > > > > That's where the problem is. If there's a difference, from the driver's > > > point of view, between suspend and some other operation, there should be a > > > way to tell the driver what case it actually is dealing with. > > > > Yes, the problem will be solved if the driver would bypass the runtime > > PM framework on system suspend. mac80211 obviously has this > > information, and technically it's very easy to let the driver know > > about it. > > > > But the difference between suspend and normal operation is really > > artificial: in both cases mac80211 just asks the driver to power its > > device down, and the end result is exactly the same (a GPIO line of > > the device is de-asserted in our case). The difference between these > > two scenarios > > exist only because runtime PM is effectively disabled during system > > suspend, and therefore the driver has to look for an alternative way > > to power down the device. > > Sounds to me like the difference isn't really in the driver, but the > core PM subsystem. Why does it care when powering off a device whether > it's during suspend, or during runtime? The problem is that the driver is using something it shouldn't use for the particular purpose. Plain and simple. Namely, it uses the runtime PM _framework_ (which has specific and _documented_ limitations) for general power management of the device it handles. It is wrong and it has nothing to do with the PM subsystem. Thanks, Rafael -- 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
