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?
> > Looks good to me; it's a good place to fix the current deadlock
> > issues (so suspending/resuming can safely "remove" objects,
> > or add them) and to stick any of those constant-stack-space
>
> Do you have a pointer to those?
David and I both gave examples earlier in this thread. (Finding them
might not be too easy though; the thread has gotten pretty long...)
> > Is this supposed to be a replacement for or an addition to the existing
> > "suspend-one-device" routine?
>
> They try what generically cannot be done. Thus they must die.
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.
> 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.
> > 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.
> > Other issues: during suspend-to-{RAM,disk} no other processes are
> > running. So what happens to the hotplug events generated by device
> > addition/removal? Maybe that's not a problem; I just don't know.
>
> Where's the problem if you don't generate them in the first place?
There is no problem. That was my point; this is yet another reason for
avoiding adding/removing devices during suspend/resume.
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
