On Wed, 27 Apr 2005, David Brownell wrote: > I see your point, but do you see mine? Namely, that any hub > will _only_ autosuspend. It's in reaction to something else > happening, to be sure, but any notion that software directly > tells any hub to suspend itself is purely an illusion that must > be provided by software. > > This particular discussion is about how that illusion should > be provided for host controller root hubs.
I think we're agreeing violently. :-) > I'm pointing out how the hardware works, and saying that for **EVERY** USB > device, the parent is the final arbiter of whether it suspends. You can't > change how the hardware works. Arguing it isn't going to help. That's not in question. The issue is: Out of all the drivers floating around, which one should decide when a particular device can be suspended for lack of activity? > The parent must clearly participate in the suspend. In the usual sense, > it's "responsible" for suspending. The fishiness comes maybe from not > distinguishing the "auto" part of autosuspend ... which I think we've both > been using to indicate a policy a driver applies internally. Yes. But which driver...? > > Instead, the driver of the device itself should be responsible. It > > carries out the autosuspend by sending a request to the parent hub. In > > the same way, the hub driver should be responsible for autosuspending the > > root hub. It should carry out the autosuspend by sending a command to the > > HCD. Which is exactly what it would do, if khubd included an autosuspend > > routine that called usb_suspend_device for the hub being suspended. > > And in general, every USB device could autosuspend like that: once all its > children/interfaces are suspended, call usb_suspend_device(). That scheme (or one like it) can work for lots more devices than just USB! > And curiously enough, usb_suspend_device() does exactly what I described. > It asks either the HCD (for root hubs) or the parent hub (otherwise) to > suspend. > > Maybe the real issue is lack of generic USB autosuspend code, which would > necessarily have to work something like that. That's one reason I started > to work on removing the recursion from the CONFIG_USB_SUSPEND code. You're probably right. Generic USB autosuspend code would have to go in the hub driver, as hubs are the only USB devices with generic (i.e., USB) children. I do have an old patch somewhere for adding hub autosuspend. It never went very far, partly because of the ongoing changes in the PM core and partly because OHCI didn't like it. And UHCI's root hub support wasn't in good enough shape at the time to allow autosuspend, although now it should be okay. The patch did work when suspending external hubs attached to a UHCI controller. 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 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
