> > The parameter isn't needed, or even usable, without the recursion
> > removed in the previous patch.
>
> These patches look great, and I intend to go through them carefully. At
> first glance, there appears to be a small problem in the pm-usbsusp patch:
Not with that patch ... it's actually in the CURRENT kernel unless it's
got CONFIG_USB_SUSPEND set!
Notice the FIXME added by pm-config.patch; it's part of the underlying
issue ... which by my reading isn't in this routine (yet). (And it's
unrelated to any usb_suspend_device parameter; $SUBJECT is irrelevant
other than "patch".)
This seems related to two OHCI regressions I noticed, by the way.
In one case, resume-via-reset seems broken without CONFIG_USB_SUSPEND;
the root hub timer doesn't restart correctly. (It tries to resubmit
the URB while the hub is suspended, fails, then dies.) In the other,
wakeup is broken since khubd never notices USB_PORT_STAT_C_SUSPEND;
as if the root hub timer stopped (new behavior?) and didn't restart.
> You skip calling usb_suspend_device for FREEZE events. That's good for
> external devices, but it's not good for root hubs. They really do need to
> be suspended even for FREEZE events, since FREEZE requires no interrupts
> or DMA.
Remember that HCDs consist of two hardware interfaces, which can normally
be managed somewhat separately:
- Root hub, which is the down-stream link. These are managed through
calls into the HCD: hub_suspend(), hub_resume(), the code handling
control requests, status polling, and so on.
- Controller, the upstream link. Sometimes controllers support
lower power modes than even "root hub suspended" (like "off", or
even just "clock off"), or they're like PCI (or PCMCIA) and have
additional control protocols to follow.
Now, the FIXME that I mentioned is basically that suspend/resume linkage
to the root hubs needs reworking. Today, it's completely unused unless
CONFIG_USB_SUSPEND is set ... so all the HCDs have code inside the
controller suspend/resume calls to cope with that.
That is: root hubs currently never see FREEZE except indirectly through
the upstream link ... except with the non-default CONFIG_USB_SUSPEND.
I suspect the right fix will involve adding to the code which you quoted,
by calling hcd->hub_suspend(); similarly on resume. That'll be a nice
step towards shrinking what CONFIG_USB_SUSPEND covers, and removing bugs
associated with the "other" setting of that option.
> This will be easy to fix, of course.
Just changing all the HCDs, the remote wakeup support, and the normal
suspend/resume paths ... and retesting them all both with and without
CONFIG_USB_SUSPEND, root hub timers, etc.
Not easy enough to be 2.6.14 material, I suspect!!
> Bringing up this next point may be a mistake, but bear with me... Now
> that we're switching to a model where the recursion for sleep transitions
> is handled entirely by the PM core (and recursion for runtime PM is
> handled by some as-yet unspecified means), there appears to be no longer
> any need for the "locktree" protocol. Do you agree?
Not at first glance. It's that "unspecified means" thing; we'll still
need to be able to resume devices, and hence possibly their parents and
up the tree to the root hub. Maybe it could be replaced later by
something similar though. :)
- Dave
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
