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. ...
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.
The device controllers I've seen use the same mechanism. Control OUT transfers aren't very common, for what it's worth ... we should probably add some regression test code to make sure that error is handled cleanly in all the (host and device) USB controller drivers.
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.
Not necessarily. Off-by-one style bugs happen all the time, and if that didn't pad out the whole packet, it's always possible to recover gracefully by issuing the "biggest possible short read". But if you lost the transfer boundary -- you may never be able to recover it without resetting the endpoint (or altsetting).
At least by requesting M bytes you don't also have a "controller dead because of babble" problem as well.
So you might not want to apply the exception in that case. That's a rude failure, certainly.
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?
It's a question of how bad the error is. There's a big difference between failures where there is no longer a short packet (so multiple transfers can run together) and ones where it's just not quite as short as expected (maybe this transfer is broken, but the next one probably isn't).
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?
Because that's the model. "High Bandwidth" transfers are treated just like big packets of up to 3KB in size; not like up to 3 individual 1KB transfers.
- Dave
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
