On Wed, 4 Feb 2004, David Brownell wrote: > Alan Stern wrote: > > 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.)
It's not clear whether this should include control transfers. Presumably they use different mechanisms within device controllers, and anyway they do contain a length field. > 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. I don't quite understand. Suppose the other end is supposed to send N bytes, so you submit a request for M (= N rounded up to a multiple of maxpacket) bytes. If the other end does what it's supposed to, using M instead of N won't make any difference. If the other end doesn't do what it's supposed to then you've got a synchronization problem in any case. At least by requesting M bytes you don't also have a "controller dead because of babble" problem as well. > 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. This may be the same question over again -- why one byte shy? Are you concerned about being able to detect whether or not the other end has done something wrong? > 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. A driver can tell whether actual length > expected length and treat it like babble. On the other hand, a VIA controller shutting itself off is _not_ "failing gracefully". > > 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 ... :) I don't get it, sorry... Why 3 KB? Alan Stern ------------------------------------------------------- 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
