On Wed, 22 Sep 2004, David Brownell wrote:
> > If the power-off request was
> > for that single device alone we can simply return an error. If the
> > power-off request was system-wide then the error won't matter; when the
> > power to the parent hub is turned off, the power to the child will be too.
> >
> > So I'm not sure what the right approach is.
>
> One thing that's interesting about that example is that it shows
> that the current suspend() API is insufficient ... there's no way
> to express the distinction between "notify about system-wide power
> loss" and "request for per-device powerdown".
After more thought, I've decided that this isn't really a deficiency in
the suspend callback. There's no need to distinguish between a
notification and a request when calling a device driver; the callback
can always be interpreted as both. (When calling other subsystems -- such
as the block layer -- that want to know about suspends but don't control
any devices, the callbacks can be interpreted simply as notifications.)
What _is_ missing is a way for the driver to tell the PM core about its
special requirements. So here's another part to add to my proposal:
There are three new error codes defined, which drivers can use as return
values from their suspend callback:
-ERESUME_DEV: The device can't make the requested transition
to a higher suspend level without first being
resumed.
-ERESUME_PARENT: The device can't make the requested
transition to a higher suspend level unless its
parent is resumed first.
-ESUSPEND_PARENT: The device can't make the requested
transition to a higher suspend level unless its
parent is resumed first. However, if the parent
moves to the higher level then the child device
will follow along automatically.
The PM core can use these return codes in various obvious ways to cope
with device and bus peculiarities.
Another part of the proposal I forgot to mention earlier: The API should
include a way to ask for a device _and_ all the devices above it to be
resumed. Perhaps all resume requests should work like this, perhaps it
should be an option, or perhaps there should be a separate set of
resume_ancestors functions in the API -- I'm not sure which is best.
Note that implementing this correctly is very similar to doing locktree()!
There's an additional problem that should be mentioned. During a
system-wide suspend, the PM core remembers the old state of each device.
(If the device was not in state 0 before, nothing is done to it -- another
bug!) When the system wakes up, what should happen to devices whose old
state was not 0? The only reasonable alternatives are to leave them in
their deep sleep (possibly powered-off) even if they were only lightly
suspended before, or to turn them back on all the way. My feeling is that
resuming all the way is the better choice.
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
