On Wed, 27 Apr 2005, David Brownell wrote: > > > 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.
I'm not familiar with the details of your drivers, so although it should be possible to make this work perhaps it's not very easy. At any rate, it should become easier with my updates to the root hub glue. > > > 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. It's part of the point. However, my main reason for asking that question was to eliminate system suspend from the discussion. From now on I will concentrate on how CONFIG_USB_SUSPEND interacts with runtime power management. > 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 ... Has that been fixed yet? Didn't Paulus submit something addressing this deadlock? > > 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. I'm not using git either. I just get Greg's cumulative patch files, apply them to a copy of the vanilla source tree, and use quilt. It's a little awkward, but it's hard to imagine it being any worse than git at this stage. > 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. Guess I'm used to UHCI, where things are simpler. Alan Stern ------------------------------------------------------- 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
