> 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

Reply via email to