On Wednesday 27 April 2005 12:14 pm, Alan Stern wrote: > On Wed, 27 Apr 2005, David Brownell wrote: > > > The root hub autosuspend is different though; it turns off > > the flow of SOF packets, just like setting the suspend bit > > on the parent port of an external hub. > > Right again. And setting that suspend feature won't happen without > external intervention; there's nothing "auto" about it.
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. > > Thing is, there's no parent hub for the root, so there's no > > way the driver for such a hub could set that suspend bit... > > the parent is the HCD. Ergo, controlling root hub suspend > > is most naturally part of that HCD. ;) > > Let's carry this line of reasoning a little farther. You're saying that > the driver (i.e., the HCD) for the _parent_ of the root hub should be > responsible for autosuspending the root hub. 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. > By analogy, the driver of > the _parent_ of any USB device should be responsible for autosuspending > that device. Seems fishy to me. Yes, your analogy is indeed fishy -- we agree! 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. > 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(). 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. - 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 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
