[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [PATCH 0/4] RFC: usb: split packet result into actual_lengt
From: |
Hans de Goede |
Subject: |
[Qemu-devel] [PATCH 0/4] RFC: usb: split packet result into actual_length + status |
Date: |
Thu, 18 Oct 2012 16:05:52 +0200 |
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
- [Qemu-devel] [PATCH 0/4] RFC: usb: split packet result into actual_length + status,
Hans de Goede <=