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

Reply via email to