On Mon, 5 Jan 2004, David Brownell wrote: > 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.
I'll have to look at that... > 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. That seems reasonable, although I'm not convinced that the two paths need to be treated differently (apart from issues of synchrony). Why would a PM resume require disconnecting a root hub, and by extension, everything beneath it -- unless the HC hardware had actually gone away while the system was asleep? > > 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. It does. To take it into account properly would require some additional assumptions. For instance, the driver might have to assume that if a hub on the event list is already locked, it's because the hub is in the process of being disconnected. There's a race: usb_disconnect() can't set the state to NOTATTACHED until it has locked the hub, and if khubd isn't able to acquire the lock then it can't be sure the state won't change to NOTATTACHED in the near future. The best way to prevent that from becoming a problem is for usb_disconnect() to insure the hub isn't on the event list to begin with. And the best way to insure _that_ is to unbind the hub driver. Alan Stern ------------------------------------------------------- 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
