On 7/5/06, Alan Stern <[EMAIL PROTECTED]> wrote: > Actually it is. Look in drivers/usb/core/hub.c at the > usb_set_device_state() routine.
will do. > Potentially tight doesn't have to mean tight. Higher-level drivers should > strive to avoid immediate resubmissions of URBs that fail because of > device disconnection. Some drivers do behave this way and some don't. I went back and looked to make sure my understanding was straight... and as it turns out, I was misremembering where this was happening. The resubmission is in ehci-q.c:qh_completions(); it is not checking to see if the device is disconnected (is this possible?) before deciding the endpoint EPROTO fault calls for tearing it down and setting it back up. Active/submitted URBs potentially have nothing to do with it; it is happening even when my devices are idle. Is this part of what you're referring to as a high level driver? Monty Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
