On Tuesday 26 April 2005 10:08 am, Alan Stern wrote: > On Mon, 25 Apr 2005, David Brownell wrote: > > > On Sunday 24 April 2005 9:21 am, Alan Stern wrote: > > > > > > There's no recursion. When the PCI device is suspended or > > > resumed, the code does _not_ suspend or resume the root hub > > > device. > > > > If it can be guaranteed that the root hub is already suspended, > > including all the root hub timer wierdness, that's OK. But last > > I checked, that wasn't particularly straightforward. It may well > > be getting easier to do now with your updates to the hub code and > > to the root hub glue; but not in the 2.6.12-rc3 code. > > I don't see any problem.
I did when I tried. Theory != practice, and there's been no clean way to make the root hub timers stop from HCD-only operations. > > > This is in keeping with my attitude that the USB subsystem shouldn't do > > > much (or any!) recursion for suspend/resume. > > > > It's hard to say; the PM device tree framework is pretty goofy, > > and that's the root cause of why it works the way it does now. > > > > As you know, I've been leaning towards making the CONFIG_USB_SUSPEND > > code get rid of recursion. And in fact I've had patches doing > > just that... > > > > The big blotch on that nice picture is ... > > I agree with everything you say, and you seem to be agreeing (perhaps with > reservations!) with what I wrote. My reservations are pragmatic. And aggravated by the recent changes to the PM code which make device-level PM act *WORSE* than before. > > > Note that they don't call usb_suspend_device or usb_resume_device, since > > > those routines don't do anything when CONFIG_USB_SUSPEND isn't set. > > > > And again, we want CONFIG_USB_SUSPEND to eventually be the default. > > We need more drivers to support suspend() and resume() methods though, > > and other cleanups (including in the driver model pm core stuff) > > before that's fully safe. > > Actually I'm not clear on what would be unsafe about leaving it always on. > For system sleep it wouldn't make much difference, would it? We'd need a decent answer to handle drivers without suspend() and resume() methods in "selective" suspend. Remember that system suspend is NOT the point. Calling remove() and probe() ought to work just fine, and after all those methods will always be well debugged. There was just a little bitty self-deadlock problem in the PM core to fix ... > > > When the hub driver gets auto-suspend capability added, the HCD won't > > > need > > > it. Until then, an HCD-initiated auto-suspend is completely internal to > > > the driver -- usbcore is unaware that anything has happened. > > > > That sounds fair, but also dependent on some cleanups with respect > > to usbcore and root hub timers that haven't been merged yet... > > Everything necessary should already be present in Greg's > usb-2.6.12-rc3.patch. But I suspect you don't really need anything > special. If a root-hub timer fires at a bad moment, the hub_status > routine need only return 0. That patch is too new for me to be working with, unfortunately; and my time for converting to GIT is not yet. Note that both EHCI and OHCI already _have_ such logic in the hub_status code ... but it wasn't sufficient before. There are a LOT of paths through usbcore and HCDs on which things will trip up. - Dave ------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
