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. > Why? Because there is no way for the device to know how many bytes the > HC expects to receive - except if known in advance due to some higher > level protocol. In practice that's almost always the case. It was here, for instance: A hub with two ports is required by the standard to send status reports containing 3 bits stored in a single byte. > But we know real world devices have some tendency to send > more than they should in some occasion, which leads to babble condition > with serious consequences on VIA UHCI. Exactly. > OTOH, preparing the host to accept full packets doesn't hurt. If the > device correctly sends less bytes we get a short read, that's all. IMHO > whenever SPD is an acceptable thing from the perspective of driver, it > might use sufficiently long transfer buffer to fetch a whole packet in > case of trailing data. Exactly what you are doing with this patch. I can see two possible difficulties. One is that the driver may have been handed a transfer buffer that is not guaranteed to be long enough to hold an entire maximum-size packet; the driver would have to allocate a bounce buffer and that might amount to a serious overhead (particularly since the bad consequences are restricted to a relatively small set of devices). 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. Even worse, one of the notorious failure cases I've seen involved a high-speed device attached to a UHCI controller. Somehow it got confused and tried to send a bulk packet _larger_ than 64 bytes -- the endpoint's maxpacket value and the full-speed limit for bulk. That was our conclusion at the time, anyway; it wasn't easy to tell exactly what had happened. 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
