On Thu, 20 May 2010, David Brownell wrote: > > This patch (as1362) adjusts the way the USB autosuspend > > routines > > handle remote-wakeup settings. They aren't supposed > > to use > > device_may_wakeup(); that test is intended only for system > > sleep, not > > runtime power management. > > For what it's worth, I never thought that ... but it's likely > a defensible policy, in conjunction with other policies. > > Thing is, wakeup is also a runtime PM mechanism, not just a way > to kick a system out of a sleep mode. In fact, a "sleep mode" is > just a point on the spectrum of runtime power saving modes, so to > reserve one exit mechanism for sleep modes seems like a strange > concept: drawing arbitrary (and not that useful) lines in the sand, > which make it hard to package a coherent/unified approach. That's true... But on many Linux systems (such as PCs) there is a clear distinction between runtime power management and system PM. This distinction is embedded in the PM core's programming interfaces and also in peoples' expectations. For example, if your root hub is suspended at runtime and you unplug an external hub, you want the root hub to wake up and notice the unplug event. But if you just closed the lid of your notebook PC, putting it into system suspend, then you don't want the computer to wake up when you unplug that external hub. In part, this is related to the fact that deeper power savings can be achieved with system PM than with runtime PM (on PC's at least) combined with the fact that runtime PM is handled automatically whereas system PM must be initiated by the user. Obviously this is all platform-dependent; certainly I would expect an Android system to behave differently. The policy regarding use of device_may_wakeup() is documented; see Documentation/power/runtime_pm.txt. (That file also describes a device_run_wake() test, but as far as I'm aware it isn't implemented yet.) Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
