On Sunday 24 April 2005 9:21 am, Alan Stern wrote: > > There's no recursion. When the PCI device is suspended or > resumed, the code does _not_ suspend or resume the root hub > device.
If it can be guaranteed that the root hub is already suspended, including all the root hub timer wierdness, that's OK. But last I checked, that wasn't particularly straightforward. It may well be getting easier to do now with your updates to the hub code and to the root hub glue; but not in the 2.6.12-rc3 code. > This is in keeping with my attitude that the USB subsystem shouldn't do > much (or any!) recursion for suspend/resume. It's hard to say; the PM device tree framework is pretty goofy, and that's the root cause of why it works the way it does now. As you know, I've been leaning towards making the CONFIG_USB_SUSPEND code get rid of recursion. And in fact I've had patches doing just that, for a few months now (waiting for 2.6.12 to ship before I clean them up and submit). The big blotch on that nice picture is that sysfs power/states are (a) the only standard way to test suspend/resume outside of system suspend transitions that affect every device, (b) wholly ignorant of the basic rules that children suspend first, and parents resume first, (c) interacting curiously with suspend states one would think should be driver-internal, notably for root hub timers. > During a system sleep/wakeup > transition it's not necessary, as the PM core will do it for us. For > runtime power management the recursion can be left up to userspace tools. As I've said to you in off-list email ... although I've also said that relying on userspace tools for that is only a debugging hack, and the need for them is only more proof of the (increasing!) weakness of the driver model support for anything other than system suspend states. ;) > (This leaves unanswered the question of how to handle a situation where > one user program is trying to suspend a parent device while at the same > time another program is trying to resume a child device. Let's not worry > about that for now.) That's a case where clearly the kernel PM support has to provide enough synchronization to do this "right". > There's an exception made if CONFIG_USB_SUSPEND isn't set. > In that case the PCI device's suspend/resume routines do > automatically call the internal subroutines for suspending/ > resuming the root hub -- otherwise the root hub would never > change state! OHCI and EHCI do that too. > Note that they don't call usb_suspend_device or usb_resume_device, since > those routines don't do anything when CONFIG_USB_SUSPEND isn't set. And again, we want CONFIG_USB_SUSPEND to eventually be the default. We need more drivers to support suspend() and resume() methods though, and other cleanups (including in the driver model pm core stuff) before that's fully safe. > On the other hand, the code does do a minimal amount of > checking. The PCI device's suspend routine checks that the > root hub is already suspended, and the root hub's resume > routine checks that the PCI device is already resumed. If > the checks fail an error is returned. > > Note that these checks don't actually involve dereferencing > hcd->self.root_hub. The driver keeps track internally of the state of > the root hub. Thus there's no danger should the code run at a time > when the root hub hasn't been registered (although in fact that can't > happen). You know, those constraints actually belong in the driver core code, not in USB at all... > Auto-suspend (called AUTO_STOP in uhci-hcd) is handled > separately from the normal suspend pathway. In particular, > it doesn't involve calling usb_suspend_device for the root > hub. Likewise, resuming from AUTO_STOP doesn't involve > calling usb_resume_device. Only internal routines are > involved. > > This is partly so that auto-suspend can work even when CONFIG_USB_SUSPEND > is off. But more importantly, it reflects a separation of > responsibilities between the hub driver and the HCD. As far as usbcore is > concerned, the root hub is (like every other hub) totally under the > control of the hub driver. It shouldn't be suspended or resumed on the > whim of the HCD, which is only supposed to manage the hardware. > > When the hub driver gets auto-suspend capability added, the HCD won't need > it. Until then, an HCD-initiated auto-suspend is completely internal to > the driver -- usbcore is unaware that anything has happened. That sounds fair, but also dependent on some cleanups with respect to usbcore and root hub timers that haven't been merged yet... > An HCD should be largely unaware of the existence of > hcd->self.root_hub. When the HCD needs to do something > that affects the root hub, a facility should be provided > by usbcore. In short, the HCD should never need to > dereference hcd->self.root_hub. > > The facilities currently available for use by HCDs include usb_hc_died, > usb_hcd_resume_root_hub, and usb_hcd_poll_rh_status. Normally usbcore > will call usb_hc_died on behalf of the HCD, so the driver doesn't need to > do so by hand. The usb_hcd_poll_rh_status routine is quite new, and > drivers should convert to use IRQs rather than polling for port changes. > > From looking through the code, I see that we need another facility added: > usb_hcd_root_hub_lost_power. This would take over the duty of marking all > the children devices as NOTATTACHED and simulating connect-change events > on their ports, something which clearly belongs in usbcore and not in > HCDs. OHCI relies on that "lost power" capability. It's always been a fairly nasty interaction with usbcore and the hub driver. I seem to recall making that work may have been the first substantial OHCI patch that I ever submitted (2.3.x I think). I'd be glad to finally see usbcore stop getting in the way of HCDs there. :) - Dave ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
