> Yes, I confused a point and it is a big difference. I restated, and my > current question w.r.t ehci-hcd still stands. The resubmission code > is in ehci-hcd, and I pasted the code block.
It's not "resubmission". One or more URBs were queued by the driver, and haven't even been seen by the controller yet! The only legal thing to do with them is to start processing ... for the very first time. In fact, at that point it's quite common for that URB not to have been queued before the previous urb->complete() call was issued. And we know one was issued, because that's a fault path (which may include the "unlink" software-induced fault). So there will often be nothing "re" about the URB, and certainly the submit/urb_enqueue path was very distinct from the qh_completions() path. They do however interact in a couple significant ways, like that common one: driver submits an URB in previous->complete(). One more thing to notice about that particular schedule re-activation path ... the HCD lock was dropped, so other drivers may have entered the driver (SMP etc). Reentrancy on that path is not restricted to the specific module accessed through previous->complete(). - Dave 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
