On Thu, 27 Aug 2009, Daniel Drake wrote: > Alan Stern wrote: > > Daniel and David: > > > > This kernel patch implements the plan we discussed for handling short > > bulk transfers. It adds a new URB flag: USBDEVFS_URB_XFER_START. > > Here's how it works: > > Thanks, this is great!! > > > When libusb breaks a bulk-IN transfer up into multiple URBs, it should > > set > > > > USBDEVFS_URB_SHORT_NOT_OK | USBDEVFS_URB_XFER_START > > > > in the flags for the first URB, and > > > > USBDEVFS_URB_SHORT_NOT_OK > > > > for all the following ones. If any of these URBs completes with an > > error before libusb has finished submitting all of them, it should stop > > the submissions (they'll fail anyway with an EREMOTEIO error; perhaps > > a different code would be better). It probably already does this. > > Is EREMOTEIO used for any other condition here? It is the error code the kernel returns when there is a short packet and URB_SHORT_NOT_OK is set. But it currently is used that way only as a completion status, not as a submission error code. > I think the important thing is that it is unique so that we can detect > the condition easily. Is this sufficiently unique? A different code could be used if you would prefer; got any suggestions? > At the moment, if the submission of an URB fails, libusb cancels all the > URBs previously successfully submitted as part of that transfer, and > eventually reports a failure condition in the asynchronous callback, > once all of the cancelled URBs have been reaped. > In this specific case (submit failed because a previous URB in the same > transfer already completed and completed early), we'd want to report > success. That's right. You'd stop submitting any remaining URBs, but you wouldn't have to cancel the outstanding URBs since the kernel will cancel them for you. > Can we do something similar for BULK OUT too? If an URB fails before > transferring all data, cancel all URBs up until the start of the next > transfer. This seems less critical. Normally the only reasons for a bulk OUT URB to fail are because the device has been disconnected, the endpoint has been halted, or the URB was cancelled by userspace. In none of these cases does it matter whether further URBs are cancelled. (Well, the last case is a little questionable... but it's under your control in any event.) > I like David's suggestion of preserving the old meaning of > USBDEVFS_URB_SHORT_NOT_OK. I seriously doubt that any user programs employ it. Certainly nothing using libusb does. The old meaning is: If the transfer terminates early with a short packet, set urb->status to -EREMOTEIO instead of 0. That's not a terribly important distinction, especially since you can easily tell for yourself whether the transfer terminated early by comparing urb->actual_length with urb->buffer_length. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
