On Fri, 23 Sep 2005, David Brownell wrote: > I sent by a proposal sketch a while ago that repurposed it as the > manager for a set of devices. To suspend or resume a device X, the > pmcore calls would replace x->bus->suspend(x) calls with something > accessing a facet of some other object that knows about X and the > other related devices in that set: > > x->pm_parent->suspend(x) > x->pm_parent->resume(x) > > That would allow the notion of "parenting" to be whatever it needs > to be, and would directly support managers for the sort of "cluster > of interrelated devices" that generally make up the problem cases.
In fact, once you do this there's no need for the suspend and resume methods in struct device. They can be replaced by these methods in the embedded pm_info. > > ... skipping to a different topic ... > > > To put it more explicitly: I would consider a host controller to comprise > > a part (A) that manages the connection to the PCI (or other system-level) > > bus, plus a part that manages the connection to the USB bus and which acts > > like a hub. This second part includes both the upstream (B) and > > downstream (C) halves of the root hub, as laid out in Chapter 11. That's > > in contrast to what you have written; you essentially said that you viewed > > the (A) part as the upstream half of the root hub. > > Because there **IS** no (B) ... there is no upstream USB link. If you > look at the external signals, all you'll see is (A) and (C). Anything > else is an implementation detail of the hardware ... something that a > given HCD could know about, but usbcore shouldn't care about. > > That is: HCs are black boxes with two interfaces: (A) is upstream, covered > by a spec like PCI bus or the SOC power/interconnect/clocking/...; while > (C) is a set of downstream links, covered by the USB spec. They may be black boxes, but we treat them as though they contain a hub. We communicate with them via usb_submit_urb and friends, we expect to get back 16-bit port status and port change values, we expect them to respond to Set-Feature and Clear-Feature, and so on. So why shouldn't we have them to respond to usb_suspend_device and hub.c:hub_suspend the same way as other hubs? (Apart from the issues involving USB_SUSPEND, of course.) After all, for an external hub, suspending the interface doesn't affect the hardware. It doesn't communicate with the device at all. Why should it do so for a root hub? With your new patches, calling usb_suspend_device(rhdev) does practically nothing besides maybe setting a power_state value. It doesn't even affect remote wakeup settings! What happens with an external hub if I first suspend the interface, then turn off the wakeup_enable flag, and then call usb_suspend_device for the hub? Compare that to what happens with a root hub. I would be a lot happier if you renamed hcd->hub_suspend to hcd->bus_suspend and explicitly defined it as leaving remote wakeup turned off. Then there would have to be a new callback, hcd->rh_suspend, which would do nothing but enable remote wakeup, and would be called from usb_suspend_device. But this seems silly when you could just as easily do both from usb_suspend_device. (Come to think of it, we should change the callback's name to hcd->rh_suspend in any case -- the current name is too easily confused with hub:hub_suspend.) Alan Stern ------------------------------------------------------- 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
