> > > ... Suspending an external hub's interface won't > > > have any effect on the downstream ports; they will be affected only when > > > you call usb_suspend_device for the children. > > > > True, but that must always have happened before the interface can suspend > > in any case... > > Not so. There's no reason why we can't suspend a hub's interface without > suspending its downstream ports. If the child devices actually were > children of the hub interface, instead of being children of the hub > device, then I would agree with you. We're victims of poor initial > design.
We may be such victims, but in this we're not powerless either... Another way to look at it: "hub" is the only driver in the whole tree that's so confused about the difference between "device" and "interface". It's not IMO worth the pile of special cases needed to maintain that confusion, scattering hub class code through device and hcd infrastructure. > All right, let's cut through the rest of the arguments. I'm willing to > accept that we should do our best to manage the downstream ports through > the hub interface, even though the driver-model design doesn't mirror this > logically. Good! :) > We do at least have one thing in our favor: Since the hub > interface is registered before any child devices, the > reverse-order-of-registration used for system suspend callbacks will not > try to suspend the interface before the children. > > (BTW, is there any possibility of changing things so that downstream > devices really _are_ children of the hub interface instead of children of > the hub device? This would have repercussions for userspace, since the > sysfs pathnames would change -- which makes me suspect it's not feasible > politically.) This is what I was alluding to when I pointed out that the pm_parent mechanism "should" eventually be able to solve problems for us. One logical structure would have devices' pm_parents be some facet of the hub interface, with PM suspend/resume operations using that information through some TBS calls ... without making such sysfs name changes. On the other hand, don't you just want to _try_ changing that parentage without solving that pm_parent issue, and hearing the screams? ;) > The hub.c:hub_suspend routine should be changed so that for PM_FREEZE and > PM_SUSPEND events it skips checking the state of the child devices. We > can trust the PM core to have already put them in the correct state. No we can't. There are two counter-examples today. One is sysfs, which should arguably be changed to do some of that checking (and stop clobbering the device power state recorded by device drivers) to the extent it can be abstracted. Another is root hub autosuspend. > None of the above answers the original question about where the call to > hcd->hub_suspend belongs. I still say it should go in usb_generic_suspend > intead of hub.c:hub_suspend. Here's a reason which I think is conclusive: > > When you suspend an external hub's interface but not the hub itself (i.e., > not its upstream port), the hub won't generate remote wakeup requests. The key point is that usbcore won't be watching the notifications; they stop inside the hub's port status bits unless the upstream link is suspended. They're actually still being issued... > Port status changes would show up only in the status URB, and the hub > driver will have unlinked that URB. But with a root hub, calling > hcd->hub_suspend _does_ enable remote wakeup. Strictly speaking, it wouldn't _need_ to enable it. Then it'd act the same as with an external hub in that state: a semi-responsive lump. In practice we _do_ want to enable wakeup, if the root hub supports it. The way to disable a USB bus is to unbind its HCD, not to play games with awkward PM states. > So hcd->hub_suspend should > be called as part of the hub device suspend, not part of the hub interface > suspend. Or wakeups could be enabled in root_hub_dev->suspend rather than as part of the downstream link suspension. That'd give a closer match for external hubs ... but how closely should the two mimic each other? > Having said that, I should also point out that in the long run, the > difference will be minimal. As part of the runtime PM design I'm working > on, USB devices will automatically be suspended as soon as all their > interfaces are -- that's the upward propagation of PM state changes. So > suspending a hub's interface will _cause_ the hub device to be suspended. Right, I'm looking forward to seeing that. My next patchset will smooth out most of the differences appearing with USB_SUSPEND, and make various remote wakeup scenarios work again. So it'll go well with that mechanism. - 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
