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
Or the usbcore component that did so.
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.
It only has to look at that value. Typically drivers should make sure it's a success code before doing anything that depends on success.
- Dave
------------------------------------------------------- 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
