Am Sonntag, 26. September 2004 01:48 schrieb David Brownell:
> On Saturday 25 September 2004 3:16 pm, Oliver Neukum wrote:
> > Hi,
> >
> > just looking through drivers/base/power/runtime.c it seems to me
> > that the approach is basically unworkable and cannot be made to
> > work. A sane API should probably be:
> >
> > int suspend_subtree (struct device *top_dev, u32 level, int remote_wakeup);
>
> 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?
> > int resume_subtree (struct device *top_dev);
> >
> > Both would work by literally walking struct list_head children of struct
> > device. How about that?
>
> 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?
> algorithms. And maybe other related things ... it'd replace
> some current works-but-ugly recursive logic in USBcore.
I would strongly feel that disconnect/plug event should be queued
while power states are being changed. Maybe partial tree power
changes can be restricted to one subsystem.
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
