This routine cancels an in-progress request. URBs complete only once per submission, and may be canceled only once per submission. Successful cancelation means the requests's completion handler will be called with a status code indicating that the request has been canceled (rather than any other code) and will quickly be removed from host controller data structures.
In the past, clearing the URB_ASYNC_UNLINK transfer flag for the
URB indicated that the request was synchronous. This usage is now
deprecated; if the flag is clear the call will be forwarded to
usb_kill_urb
and the return value will be 0. In the future, drivers
should call usb_kill_urb
directly for synchronous unlinking.
When the URB_ASYNC_UNLINK transfer flag for the URB is set, this request is asynchronous. Success is indicated by returning -EINPROGRESS, at which time the URB will normally have been unlinked but not yet given back to the device driver. When it is called, the completion function will see urb->status == -ECONNRESET. Failure is indicated by any other return value. Unlinking will fail when the URB is not currently "linked" (i.e., it was never submitted, or it was unlinked before, or the hardware is already finished with it), even if the completion handler has not yet run.
Host Controller Drivers (HCDs) place all the URBs for a particular endpoint in a queue. Normally the queue advances as the controller hardware processes each request. But when an URB terminates with any fault (such as an error, or being unlinked) its queue stops, at least until that URB's completion routine returns. It is guaranteed that the queue will not restart until all its unlinked URBs have been fully retired, with their completion routines run, even if that's not until some time after the original completion handler returns.
This means that USB device drivers can safely build deep queues for large or complex transfers, and clean them up reliably after any sort of aborted transfer by unlinking all pending URBs at the first fault.
Note that an URB terminating early because a short packet was received will count as an error if and only if the URB_SHORT_NOT_OK flag is set. Also, that all unlinks performed in any URB completion handler must be asynchronous.
Queues for isochronous endpoints are treated differently, because they advance at fixed rates. Such queues do not stop when an URB is unlinked. An unlinked URB may leave a gap in the stream of packets. It is undefined whether such gaps can be filled in.
When a control URB terminates with an error, it is likely that the status stage of the transfer will not take place, even if it is merely a soft error resulting from a short-packet with URB_SHORT_NOT_OK set.