> > > Either way could work. I prefer to do it this way, though. > > > > It's certainly a good quick-fix for that issue. But it leaves an > > inconsistency (actually, two of them) I'd rather do away with. > > > > With this patch, the device suspend logic _only_ deals with a device's > > upstream USB link, when it has one (which root hubs don't). Which gives > > a clean definition of USB_SUSPEND to use as a good stabilization target: > > it enables (a) the USB suspend state, and (b) remote wakeup paths. > > I tend to think of the HC as the root hub's upstream connection,
Remember that root hubs, unlike "normal" hubs, expose _three_ faces (not two) through the driver model: the controller (e.g. a PCI or platform device); the root hub usb_device; and the root hub usb_interfacee. Plus, no upstream USB link exists; USB gets morphed to some other bus in silicon ... So if the HC (PCI/platform device) is the upstream link, then it'll be be power managed as a non-USB device. As one would expect. But for the downstream link ... I think the choice between the two is almost arbitrary. And it's less confusing to have hub->suspend call hcd->hub_suspend than to special-case hub support into device suspend. :) > which > implies that the bus->op->hub_suspend method call in __usb_suspend_device > should stay where it is. Moving the method call to the hub_suspend > function is wrong, because it would mean that suspending a hub's interface > has the unexpected side-effect of suspending the whole hub device (for > root hubs)! (And thereby suspending that entire bus!) That's not "wrong" ... it's 100% consistent with suspending any other hub interface! When it finishes suspending, the down-stream links are all suspended; not the upstream one. (True for both faces of the downstream link... though the usb_interface is always suspended first.) This is easier to fix than the hub/device parenting stuff... > Likewise, resuming > the root-hub device wouldn't work so long as the interface remained > suspended -- whereas it would work with external hubs. But we had previously discussed the need to change that behavior so that resuming a hub need **NOT** resume all the downstream links... again (testing is the only hard part of that patch). > However I like your clean definition of CONIFG_USB_SUSPEND, if you add the > proviso that (a) applies only to physical, non-root, devices. That is, we expect all HCDs to support "global(-to-this-bus) suspend"? Yes; usbcore will always use hcd->hub_suspend(). Today it doesn't. Another way to describe the difference would then be: (a) it's no longer just root hubs that will suspend downstream devices, all hubs will do that. - Dave ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
