With the ehci and xhci controllers a single packet can be larger then maxpacketsize, making it possible for the result of a single packet to be both having transferred some data as well as the transfer to have an error.
An example would be an input transfer from a bulk endpoint successfully receiving 1 or more maxpacketsize packets from the device, followed by a packet signalling halt. In practice this will almost never happen, still I believe it is worth to fix this, as this could happen under normal circumstances if for example a redirected usb mass storage device has shorter then requested scsi cmd or sense data, which is exactly a multiple of maxpacketsize. The former (shorter then requested data) is actually quite normal, but the exact a multiple of maxpacketsize is rather rare, which is why sofar we've not been bitten by this. Also as the patches which modify the hcd / redirect code show, having the length in a seperate field also leads to cleaner code (IMHO). Note: This patch series applies on top of the input pipelining patch series. Regards, Hans