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).
Maybe I got you wrong but I don't understand what one might gain when extending the readlen to maxpacket-1 compared to maxpacket. Either we can resync due to some heuristics (either framing or assuming what we received was the expected amount plus some trailing garbage) or synchronisation is lost anyway.
The "maxpacket - 1" enables heuristics that may not be possible otherwise. It depends on the protocol being used (on top of "raw USB").
The whole point when extending the read to the next mutliple of maxpacket is to avoid the babble. I assume a pretty likely cause for babbling devices is they submit maxlen data when we expect less. In this situation, requesting transfer_length multiple of maxpacket is the only way to avoid the babbly and thus the risk to kill some HC. Trying to re-establish data integrity is a different issue then which might be impossible without resetting the ep.
If your top priority is to avoid issuing reads that might in some cases lock up a VIA UHCI, you have no flexibility -- true. If that's just one of the factors you're weighing, you may need other options.
But anyway, I'm not claiming this being the ultimate solution in all cases, but it might help avoid the babble related issues in some cases. In fact my general impression is there are driver authors not being aware the urb->transfer_length isn't communicated to the device at all.
That could be. Particularly with 2.4-based systems, the API doc wasn't coupled to the source code, so it was particularly easy to overlook all kinds of important points. Even for issues that are documented; and I'm not sure this one got documented.
- Dave
------------------------------------------------------- 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
