One of those cases is in hub_reset(), which I mentioned above. The others
are rather analogous although different in detail; they occur when a host
controller fails -- everything below the root hub is disconnected but the
root hub remains. In a way, failure of an HC can be treated as failure of the virtual root hub.
It shouldn't be just "in a way"! And in fact, if we had a clean way to fail root hubs, we could handle some power management scenarios a lot better ... and also do bus resets in the generic layer, rather than UHCI and OHCI having private schemes, and EHCI (and surely other out-of-tree hcds) having none at all.
Right now the only way hubs can fail is by not responding properly (or at all!) to the periodic status request. Almost by definition, that doesn't happen with root hubs. We could emulate it in the same way we virtualize the other functions of a root hub. Is that what you are suggesting?
I suppose having a reset() method somewhere would be right ... the virtual root hub code (in the hcd glue) would implement it one way, and the current hub_reset() logic would handle for non-root hubs.
That could get used in three cases: (i) panic, hardware error; (ii) rmmod foo-hcd; (iii) in pm-resume paths, when the root hub lost power and devices went away.
In ohci-hcd.c, see hc_restart() and when it gets used. There's a significant driver model bug in that area ... it deadlocks when the root hub gets reset during PM resume, since that resume processing needs to disconnect all the devices that used to be present.
Logically, usb_disconnect() is part of the hub driver. This is one of those "left hand and right hand must cooperate" deals.
Sort of. That's undoubtedly true when usb_disconnect() is called as a result of a hub reporting a connect-change event on a port. It's not so clear when usb_disconnect() is called as a result of deregistering an entire bus because the HC driver is being unloaded.
That is, whether khubd is calling it or whether some other context is calling it.
Seems to me there should really be two usb_disconnect() calls, both of which feed disconect events to khubd. One of the calls would come internally, from hub status transfer processing. It's currently using the same API as the other entry point...
The other entry point would be for the HCD layer, during the two bus shutdown paths: during "rmmod", and after panic when the hardware frogged. Also ideally during the PM resume cases which need it. This is the one which needs to be synchronous; the other one wouldn't really need that.
The only way around this would be for usb_disconnect(), in addition to holding serialize, to remove the hub from the event list and prevent it from ever being added back on. But that's exactly what unbinding the hub driver would do!
When a device is marked NOTATTACHED, the hub driver already knows that only disconnect processing is meaningful. I suspect that today it completely ignores that knowledge.
- Dave
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
