> > Workaround; > > If the size of the data transfers are known, set the buffer > > length to the exact number of bytes to be received." > > That is, "drivers should do what they already do". > > And it won't work for the common case of drivers > accepting short reads. For example, a network > link uses a buffer big enough for a full frame of > Ethernet data, but most packets are shorter.
Suppose we like to use a network link (hint)...
Then short frames that ends with ones will become corrupted at USB HW level.
Will these be delivered to the driver or thrown away by the HW?
That's actually a bad example in one sense: the network stack will ignore such noise at the end of a frame. That's atypical.
Other driver stacks might not be able to tell the difference, unless they also use internal framing.
Does USB use HW resending on checksum errors? I guess not it is LOW level. I guess testing is the only way to really know.
Or reading the USB spec. Data toggle won't advance if there was known corruption. But in this case the extra bytes were added "late", and they're not part of the USB packet whose checksum presumably passed.
BTW this could be a problem for other USB OHCI hosts, since I guess that ST has licensed it from someone.
Sure, but they seem to have mangled it during their integration.
- Dave
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
