On Wed, 4 Feb 2004, David Brownell 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.)
Interesting, with the Cypress mcu OUT ep are always prepared to accept maxpacket data. I'm wondering why anybody would ever design an OUT ep on the device side with buffers smaller than the maximum possible size... > 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. Right, but then you are lost anyway. For such transfer the receiving end must always expect len=maxpacket. No chance if the other end wanted to send less but submits maxlen without framing - been there (stir4200 ;-) > 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. I think the point is if the receiving end knows the length of the real data (from spec, protocol or framing), the extra read would prevent the babble and allow the device to discard the trailing stuff and just work. If the amount of trailing data is unknown all we can do is report the error and hope something above the driver might eventually recover. > 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. Agreed Martin ------------------------------------------------------- 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
