Those three are part of the root hub life-cycle. Note that we still haven't moved all "restart controller" logic into usbcore; the UHCI code still has its own mechanism (which seems to fire during routine operation), as does OHCI (during certain PM resume scenarios, only).
I don't know what UHCI code you're referring to. When the controller stops by itself, the driver doesn't attempt to restart it.
Sorry, my bad. I thought I'd seen reports of UHCI continuing to operate after such "fatal" errors. Maybe I mis-read them, or the controller itself wasn't halting in all cases I'd expect (from reading the docs).
Are you talking about the way the driver suspends the controller when it sees that no devices are attached and then resumes when a device is plugged in? I've been assuming that should be kept private within the driver; is there any reason to let the glue layer know when that happens?
No reason at all. Per-port suspensions should be managed by the hub driver though, I think. The UHCI notion of a suspended controller seems to be more like the notion of an "empty schedule", where only the root hub status polling is active.
6. Passing PM suspend/resume messages down to the HCD
Needs more work, once PM behaves well outside of USB. So does the hub driver, to enable remote wakeup.
Remote wakeup aside, and ignoring problems with the higher layers' handling of PM, what more needs to be done in the glue layer?
I can't answer that until PM works reliably enough (for me) to analyse the problem! Resume from D3Cold (where devices go away) was a trouble spot.
Why not simply decide that the hcd glue layer owns the state? Drivers needn't change it at all; they can let the glue layer know whether transitions succeed by way of return codes. And there could be callbacks, like usb_hc_died(), for drivers to notify the glue layer about spontaneous transitions. (Maybe that's the only one needed.)
That might work. Now that we have reset(), it might actually make sense to change hcd->state to RUNNING before start() ... requiring the HCD to call usb_hc_died() as soon as it fails. At least, so long as no other task could be expecting all RUNNING hosts to be operational ... it's the fault handling that make me hesitate to change such stuff. And the way that the "dead HC" cleanup isn't yet integrated much with khubd.
You could add a STARTING state, sort of the obverse of the QUIESCING state. It would behave just like RUNNING except that URB submissions would not be accepted.
... except that one of the first things that happens when you register the root hub is submitting the hub status interrupt transfer. Still seems simpler to me to have the HCD flag when the hardware is really up. Of course that could be a usb_hc_running() call too.
- Dave
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
