Am Sonntag, 26. September 2004 17:44 schrieb Alan Stern:
> On Sun, 26 Sep 2004, Oliver Neukum wrote:
>
> > > Well, "may_wakeup", versus "must_not_wakeup", and also
> > > probably "must_wakeup". Autosuspend idle mice only when
> > > they can take themselves out of suspend ... ;)
> >
> > Question. Do you think that such interpretation should be left to
> > drivers or should the core have a way to query devices about
> > capabilities?
>
> It's not clear how a query capability could be used. Wouldn't it be good
> enough if the driver returns an error code when asked to turn on a setting
> the device doesn't support?
A difference in taste, I guess. I would prefer devices to report what they
can do and never asked to do the impossible. Returning errors certainly
works, but may have a problem accurately describing the cause of the error.
> What about the corresponding resume call? There certainly are reasons for
> wanting to resume a device without resuming all its children. Testing, if
> nothing else.
Simplicity. If walking in a minefield I prefer to tread as few paths
as possible. It can be added later.
> > True. That's a strong argument for enforcing strict hierarchy and always
> > going through the fully awake state. You must suspend only if
> > a) the parent is awake
> > b) all children are awake or in a lower or equal state
>
> This is now a little out of context, but I think the situation isn't quite
> so bad. If a device is unable to make a state transition because its
> parent isn't awake, it should simply return an error code. The PM core
> would then know to resume the parent and retry the request. Or to fail
> the request, as the case may be.
Again simplicity. Do what is sure to work.
> > > There needs to be a function to resume a subtree (or a device) plus all
> > > the ancestors. I'm not sure if this needs to be a separate function or if
> > > resume should always do this; what do you think?
> >
> > I think resume should only be allowed for a device whose parent is awake.
>
> That's like saying that suspend should only be allowed for a device whose
> children are already suspended. So why do you want to add the new
> suspend_subtree() routine? If you do one, you should do the other.
I think we should only operate on subtrees whose fathers are awake,
both for suspend and resume.
Regards
Oliver
-------------------------------------------------------
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
