On Wed, 3 Mar 2004, David Brownell wrote:
You're saying that this code at the end of hcd_submit_urb() is wrong:
status = hcd->driver->urb_enqueue (hcd, urb, mem_flags); done:
Yes -- right here should be something like
if (status == -ENOMSG) { /* unlink-during-submit */ giveback(urb); status = 0; } else
... or something very similar. Assuming all the HCDs return ENOMSG (or whatever never-given-to-drivers code is chosen) for this case.
This should happen no matter what value status is, so long as it's non-zero. And by the same reasoning: The URB has already been linked, the HCD was unable to accept it, so it must be sent to giveback and submit_urb must return 0.
No ... only the "unlink-during-submit" (ENOMSG) case made a commitment to a complete() callback, the other returns didn't.
The unlink succeeded, which means the submit must too ... since complete() never fires unless submit() succeeds (returns zero), and unlink() can't succeed unless complete() fires.
And after all, wasn't it you (and Oliver) who badgered me into making sure those "normal" submit errors (no memory, no bandwidth, etc) were never reported through completions? Yet here you're arguing that they should be ... :)
It's important to keep the driver-visible semantics simple and testable ... avoidable complications just make for cases where USB drivers (and HCDs) _will_ get this wrong (and hence have bugs). The docs I quoted before define semantics that are simple, easily understood, and easily tested.
- Dave
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
