Am Sonntag, 26. September 2004 05:22 schrieb Alan Stern:
> 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?
They try what generically cannot be done. Thus they must die.
> > 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.
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
> > > 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?
I think resume should only be allowed for a device whose parent is awake.
> > 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.)
Emphatically yes. Ideally we could leave dpm_sem to system wide changes.
> 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.
Where's the problem if you don't generate them in the first place?
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
