[Qemu-devel] [PATCH 0/4] RFC: usb: split packet result into actual_length + status

[Hans de Goede <hdegoede@redhat.com>]

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