On Wed, 4 Feb 2004, Martin Diehl wrote:
BTW, I think it would be a good idea for all IN urb to round the requested
transfer_length up to the next multiple of maxpacket size. Always, for all drivers - except if the protocol explicitly requires treating SPD as error.
I tend to agree, with some reservations.
I tend to agree with a generalization: make that all READs. On the host side that's IN transfers. Within a gadget, it's OUT transfers. (Net2280, in particular, has a rude hardware failure mode you can avoid by not issuing short reads.)
Also with an exception: sometimes it can be just too much of a PITA to handle the faults that may expose. For example, when the other end is supposed to send N bytes (with N % maxpacket != 0) it may not be realistic to recover traffic synchronization. For example, maybe the data stream doesn't have internal framing. It's typical for USB protocols to rely on USB packet framing.
That said, it's probably reasonable to accept a bit of extra data, maybe up to one byte shy of maxpacket, to handle cases where the peer is sending the wrong amount of data but there's no risk of that kind of synchronization problems.
When the peer is deeply broken, it can often be better to fail gracefully rather than try to limp along, coping with pathological recovery logic.
The second difficulty is that the maxpacket size can be fairly large, up to 1024 bytes for high-speed interrupt and isochronous endpoints. The additional overhead won't be extreme but it might be worth considering.
Make that 3 KBytes for those cases, not 1024 bytes ... :)
- Dave
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
