On Sat, 25 Sep 2004, David Brownell wrote:
> > int suspend_subtree (struct device *top_dev, u32 level, int remote_wakeup);
Is this supposed to be a replacement for or an addition to the existing
"suspend-one-device" routine?
> Well, "may_wakeup", versus "must_not_wakeup", and also
> probably "must_wakeup". Autosuspend idle mice only when
> they can take themselves out of suspend ... ;)
What about tree-related restrictions on remote wakeup, analogous to the
power-level restriction that a child must not be in a higher power-level
than its parent? As an example, consider that if a suspended USB hub has
remote wakeup disabled, its children won't be able to do remote wakeup no
matter what state they're in.
> > int resume_subtree (struct device *top_dev);
> >
> > Both would work by literally walking struct list_head children of struct
> > device. How about that?
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?
> 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
> algorithms. And maybe other related things ... it'd replace
> some current works-but-ugly recursive logic in USBcore.
I'm beginning to think that suspend/resume should _never_ add or remove
devices. At most they should mark devices as unusable somehow (like
USB_STATE_NOTATTACHED) and queue a request for some other thread to
remove them later. (I.e., just what the logical_disconnect() routine
does.)
Partly this has to do with insuring the device tree is handled properly.
If devices could be added during suspend, then they might not get
suspended properly. If devices could be removed during suspend/resume
then the tree traversal might fail. (Although removing devices during
suspend _after_ they have been visited might not be so bad -- but it's
still a tricky area.)
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.
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
