On Saturday, December 18, 2010, Ohad Ben-Cohen wrote: > On Sat, Dec 18, 2010 at 6:40 PM, Johannes Berg > <johannes@xxxxxxxxxxxxxxxx> 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? > > Agree. > > If we can add a dev_pm_info bit, that would allow using runtime PM API > during suspend/resume transitions, the driver will not have to care. > > Rafael what do you think ? Is that totally unacceptable ? Already said. It is not acceptable at all. 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
