On Wed, 4 Feb 2004, David Brownell wrote: > > 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.
Yes, using transfer_length=64 on Control IN might be helpful as well. IIRC we already know there are devices in the field which send descriptor with the correct length field but submitting exceeding data packets anyway... > >>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). 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 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. > > 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). I don't see why we would lose the detection of short packages. You mean with SPD condition in the middle of some queued urbs? Well, if the protocol requires to treat this SPD as error (i.e. stop processing the queued urbs) I agree this approach might make things difficult to recover. 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. 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
