I'll make this short, since most of the issues in this thread involve questions originally asked by Oliver that by now have been answered.
I'm not aware of any drivers that check to see whether a call to usb_unlink_urb() failed because the URB had already completed. That makes all this pretty theoretical, at best. On Fri, 18 Jul 2003, David Brownell wrote: > Are you asking to get multiple fault reports -- both for the > software-induced faults (ECONNRESET, ESHUTDOWN, ENOENT), and > for any preceding hardware fault (normal completion, ETIMEDOUT, > and so on)? No. I just thought it would be a good idea to set urb->status according to what actually happened on the bus. If the transaction was never started, or started but didn't finish because it was dequeued, the status code should be ECONNRESET (or ENOENT). If the transaction finished, the status should be 0, ETIMEDOUT, or whatever. If an unlink and dequeue were requested but the transaction finished before the dequeue took effect, this ought to fall under the second case, implying that the unlink failed. (Notice that the return code from hcd_unlink_urb() is the value returned by the HCD's dequeue routine, if that routine was called.) > > Is there any reason why the status couldn't be changed if the low-level HC > > driver detects that the hardware did manage to complete the transfer > > before it could be dequeued? When that happens, why not report that the > > URB succeeded and the unlink failed -- which is what really did occur -- > > rather than the other way around as we do now? > > You're forgetting the asynchrony involved. Whatever component > decided to initiate the unlink has already gone and done things > relying on knowledge that the urb will get an "unlinked" callback. > And it wasn't speculative execution... What component? The high-level driver that called usb_unlink_urb()? The driver can't have done anything that relied on the URB getting unlinked because it doesn't know what the return code from usb_unlink_urb() will be. Or maybe you were referring to hcd_unlink_urb(). The only thing it does based on knowledge that the URB will be unlinked is to set urb->status. > Plus, the HCD _does_ report the actual bytes transferred, which > already gives enough status for the device driver if it wants > to implement almost any "second-guess that unlink" logic. True. And I don't think any driver uses that information for an unlinked URB in any event. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
