On Wed, 4 Feb 2004, 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. > > > 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.
Right, according to 11.12.4 this is how the hub _shall_ behave. I think for many hardware and firmware designers the problem is they don't get the requested length communicated from the host. So people make mistakes when just carelessly sending full packets instead, assuming the host (driver) will ignore the trailing stuff or whatever. No excuse for violating the specs of course, but that's what happens in the field. And of course there are devices which basically forward asynch input data to the host (like usbserial type, GPS or IrDA dongles). Then the driver has no choice but expecting up to maxpacket bytes - no way to tell the device "this time only 5 please". > > 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). Good point, bounce buffers might really hurt. But I'm not sure how serious this concern is, because it's only IN direction we have to think about. For network-like drivers the allocation of rx-skb is under control. Well, storage might be a problem - AFAIK the buffers come from the scsi layer. I might be wrong but my naive expectation would be thos buffers would be multiple of 512 bytes anyway so it would serve without bounce buffer even for highspeed? > 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. Well, it doesn't need to perfectly cover any possible case. Something like rounding up bulk/interrupt and control data IN buffers to the next multiple of 64 would help out in many cases I believe. > 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. Ok, exceeding the maxpacket value (both allowed and reported) is broken enough so we really want the HC to report BABBLE. If the device is that broken, there's nothing one could do I believe. And if this makes some HCs unuseable then - well no idea, but two pieces of broken hardware mutually killing each other. 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
