On Thu, 1 May 2014, Dave Mielke wrote: > A further question: > > I'm quite sure that the read is supposed to deliver more than 64 bytes, and I > know for sure that the endpoint descriptor specifies a pacaket size of 64 > bytes. My understanding is that this is still okay, but that the endpoint is > supposed to split the larger packet up into a sequence of smaller ones which > are 64 bytes long (except for the last one). Is this correct?
Yes, that's right. To be precise, the device is responsible for breaking up a large transfer into a series of packets, each of which is 64 bytes except possibly the last one. > If it matters, this is a USB 1.1 device. The same principle applies to USB-2 and USB-3. Just replace 64 with the endpoint's max-packet size. > Assuming I'm correct, what does Linux do if the device attempts to transfer > the > whole larger packet in a single operation? Is it possible that this might > result in ETIME because, perhaps, a lower layer fails the transfer, and then, > maybe, a higher layer sees it as a response failure? No, it would result in EOVERFLOW. The various error codes used by Linux's USB stack are described in the kernel source file Documentation/usb/error-codes.txt. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
