[EMAIL PROTECTED] wrote:
The different controllers have different ways of reporting the disconnect faults. In the case of EHCI, EPROTO is indeed one of the faults that will sometimes indicate "device disconnected but khubd hasn't reported it yet". In other cases it will indicate a temporary hardware glitch.
So at least my hunch about treating -EPROTO as a fatal error being the wrong thing to do had a rational basis.
See drivers/usb/net/usbnet.c in rx_complete() for one way to cope with those problems. EPROTO is used there as a hint to throttle down resubmits. When it's a recoverable error (cabling/hardware glitch) things recover. Otherwise (disconnect) the driver gets shut down sooner, because it's not spinning forever and livelocking khubd. FWIW I think "usbnet" is one of the few USB drivers to really pay much attention to fault handling/recovery issues ... at the time the audio drivers were written, there were no good models to follow. So that rx_complete() callback might be worth some study.
I can see in a hand-waving sort of way what usbnet does, yes. Sadly, implementing a similar thing in usbmidi is certainly beyond my paltry kernel knowledge. (I've already learned a lot more than I ever thought I'd need to, and there's only so much my brain can take in... :-). I'll be very glad to test any clever patches, though...
Colin Fletcher. -- ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
