Am Montag, 26. Februar 2007 18:37 schrieb Alan Stern: > > - don't do an immediate suspend independent of autosuspend > > Why not? In extreme cases the user can force an immediate suspend by > doing suspend-to-RAM anyway. This merely preserves the capability we are > about to lose when the power/state attribute disappears completely.
Arent we removing that attribute among other things precisely because this capability violates the power tree requirements? > > > Add a new power/suspended attribute. Writing 1 will always try to suspend > > > immediately (_not_ an autosuspend!) and writing 0 will always resume > > > immediately (but will start the autosuspend timer). > > > > This is problematic, as it is a totally new code path. > > No it isn't. It's the code path used for traditional > suspend-to-{RAM,disk} and also used by power/state. STR/D freeeze user space, thus making additional guarantees we wouldn't meet. power/state is being obsoleted. > > > BTW, note that an autosuspend request is different from a plain old > > > suspend request. Autosuspend will fail if an interface requires > > > remote-wakeup capability but remote wakeup is disabled, whereas a regular > > > suspend won't fail. > > > > Yes, that too. It makes that even more asymmetric. We wake up on demand > > in only one direction. > > I don't know what you mean. We _always_ wake up on demand. What's > asymmetrical about that? We wake up for output. We suspend even if we can't wake up for input. > > If you want such an interface I'd suggest that it mean > > that a device stay suspended until the user says so. > > No. One more time: > > WE ALWAYS WAKE UP ON DEMAND! Why? Repeating the assertion doesn't make it any more logical. > If the user really wants a device to suspend and not wake up, he can take > more drastic action. Just don't send it any more demands. Unbind it from > its driver. Unplug it -- and that would save even more power! (Apart from the interesting question of how to unplug a touchpad built into a laptop) If we want that, than again I don't see why you want to suspend "in between" autosuspend and full system suspend. It should be enough to suspend immediately if the driver has agreed to autosuspension. Regards Oliver ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel