On Tuesday 24 March 2009, Ben Dooks wrote: > I've noticed that the 'struct usb_request' has a .short_not_ok > field in it, which the documentation says is to specify short > transfers are not allowed. More like: * @short_not_ok: When reading data, makes short packets be * treated as errors (queue stops advancing till cleanup). It's specific to reads (OUT transfers) and should only affect queue processing. Compare this to the host side URB_SHORT_NOT_OK flag. That also applies to reads (IN transfers there) ... key difference being that the host side hardware generally is better at supporting DMA queues. The main behavioral difference is that on the host side, for historical reasons (and annoyance), the URB will completes with a fault code if it gets a short read. > Searching through all the current gadget drivers (circa -rc5), > there's not one of them that does anything with this field > before notifying the completion. Seems to not really be used right now. Candidate for simplification/removal someday, maybe... > Is there any reason to check this, and if so, what error should > the request return? Typical processing for RX transfers is to call the request completion logic, and when it returns then start the next transfer in the queue. If that's what your driver does, the flag has no effect: the hardware will never be working through the queue while completions are processed. Alternative #1 would be to start the next transfer (if any) right before issuing the completion callback ... then if there was no such transfer in the queue, do like "typical" above. If you did that, you'd need to check the flag (on short RX only!) and skip that "start next" until after the completion callback finished. Were there a transfer in the queue, the completion callback might want to unlink it. (Simpler to just use "typical" case logic, even if it gives up a bit of potential I/O overlap.) Alternative #2 would apply only for hardware that supported the kind of DMA queue that's routine on host side, where you could actually have the hardware streaming transfers continuously and just pick off completions periodically. In that case you'd have to arrange for a short RX packet to stop the DMA queue processing. (I've never seen peripheral side hardware with DMA that works well enough to support this type of implementation strategy.) -- 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
