On Wed, 14 Jun 2006, David Brownell wrote:
> On Wednesday 14 June 2006 12:05 pm, Alan Stern wrote:
> >
> > > Did you test this with remote wakeup on all three HCDs? And with plain
> > > old external hubs? With and without CONFIG_USB_SUSPEND? I suppose I
> > > was just a bit surprised to see how much resume-side recursion could
> > > be removed and have things still work. So I'm curious about just how
> > > much is known to work. ;)
> >
> > I've done some testing, there hasn't been enough time to be really
> > thorough about it. (This was an example of "Post early, post often"
> > philosophy.) It works with EHCI and UHCI and external hubs, when
> > CONFIG_USB_SUSPEND is set. I haven't tried it yet with CONFIG_USB_SUSPEND
> > unset -- in fact, I haven't yet tried any of this stuff with a system
> > suspend.
>
> Unit tested, not /sys/power/state integration tested. As I'd
> expect; there are a _lot_ of configurations that need testing.
I've now done some more testing. The patches work with swsusp and STR.
OHCI is okay. I haven't yet tried turning off CONFIG_USB_SUSPEND.
Neither EHCI nor OHCI root-hub remote wakeup worked on either of the
computers I tried. This is understandable given that they didn't work in
the original kernel without the patches applied either (2.6.17-rc6 +
gregkh-all).
It turned out that one thing needed to be changed. The code should not
return an error when trying to resume a device in USB_STATE_NOTATTACHED.
This confuses the PM core when awakening from a system sleep, because it
will then try to resume the child interfaces and devices and warn that the
parent device is still suspended.
Presumably the same problem will occur when autosuspend is working. Say
you have a single USB device plugged in. As part of a system sleep, the
PM core suspends the device. Then the root hub, having no unsuspended
children, will immediately autosuspend. The PM core will keep a record of
the fact that the root hub is suspended. Then when the system wakes up,
the core won't try to resume the root hub (since it was suspended at the
time of the sleep) but will try to resume the child device. The resume
will work, because the root hub will autoresume, but the PM core will
still log a warning message.
> I'm thinking that I won't have time to test any of this soon, so the
> notion comes up that getting many "safe" bits into the next set of
> pages that get merged (in a few weeks?) would be good.
I'll go through and update the patches to try and make the "safe" parts as
safe as possible. That should include:
the connect-test change in devio.c;
adding the private mutex to usb-skeleton.c;
moving code from usb.c to driver.c;
implementing usb_device_driver and making usb_generic
the first one;
renaming usb_suspend_device to usb_port_suspend;
splitting apart the suspend/resume routines for devices
and interfaces.
It should be possible to apply those changes quickly. That leaves these
other changes for later:
General code cleanup (perhaps split into several pieces);
Remove resume recursion for child devices;
Move the resume recursion code for a device's interfaces;
Suspend interfaces along with their device.
BTW, I checked the usb.tmpl documentation file. It already includes the
kerneldoc from driver.c as well as from usb.c. So no immediate changes
are necessary.
Alan Stern
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
