Suppose usb_submit_urb() fails in the HCD for some legitimate reason, such
as lack of memory. Then giveback certainly should not be called.
Right. Logically there are two phases inside an HCD: grab any remaining resources needed (like memory or bandwidth) ... then update the hardware schedule (additional faults to be treated as catastrophes, like a hardware malfunction).
What you seem to be on to is that when there's a fault before that "lock down and go" stage commits, the same cancel-must-giveback logic must exist ... it's not just on the success path. (And that patch only handled the success path, which predominates.)
So maybe some of that logic should exist in hcd_submit_urb(); if the (internal) failure were -ENOMSG or somesuch, that could could be responsible for the giveback(). I'd support such a patch; better than having that particular logic in all the HCDs.
Generalizing, if usb_submit_urb() fails because of an unlink request before the URB could be queued, again giveback shouldn't be called. The prime guarantee provided by the API is that it will return the URB in one of two ways; either submit fails with an error code or else the completion routine is eventually called. Not both.
The real question is: If usb_unlink_urb() is called while usb_submit_urb() is still running, and if usb_submit_urb() ultimately returns an error, does it then make sense for usb_unlink_urb() to return success? There
Kerneldoc has for some time said:
- usb_submit_urb() success means the completion() will be called; or sometimes, that it was already called.
- usb_unlink_urb() success means the same thing, except that the status code in that callback is ECONNRESET (or ENOENT); and the urb was "previously submitted".
- URBs complete only once per submission, and may be canceled only once per submission.
Given those rules, the unlink may not succeed unless the submit does.
are good arguments for both answers. Yes it should return success, because it succeeded in getting the URB away from the HCD. No it
But it didn't succeed, since there was no completion(). No different from any other case where submit fails. That unlink() call did affected anything, and the completion handler didn't notice a submit.
shouldn't, because you can't succeed in unlinking an URB that wasn't linked to begin with. (Of course, it really was linked for a brief period
Exactly: it was linked, and that fact was advertised to the rest of the kernel. All parts of this story need to agree!
- Dave
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
