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
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel