From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48383) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TL86T-0001b0-Qj for qemu-devel@nongnu.org; Mon, 08 Oct 2012 03:50:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TL86P-00069R-CC for qemu-devel@nongnu.org; Mon, 08 Oct 2012 03:50:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40399) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TL86O-00066X-Pv for qemu-devel@nongnu.org; Mon, 08 Oct 2012 03:50:13 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q987oC9U001522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 8 Oct 2012 03:50:12 -0400 From: Hans de Goede Date: Mon, 8 Oct 2012 09:51:27 +0200 Message-Id: <1349682696-3046-4-git-send-email-hdegoede@redhat.com> In-Reply-To: <1349682696-3046-1-git-send-email-hdegoede@redhat.com> References: <1349682696-3046-1-git-send-email-hdegoede@redhat.com> Subject: [Qemu-devel] [PATCH 03/12] usb-host-linux: Only enabling pipeling for output endpoints List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Hans de Goede , qemu-devel@nongnu.org With the upcoming input pipelining support, large input packets may get submitted to the device, which require special handling when the packets ends up being split again by usb-host-linux due to usbfs limitations. The exact demands for properly handling larger split input transfers is explained in detail in this libusb commit: https://github.com/libusbx/libusbx/commit/ede02ba91920f9be787a7f3cd006c5a4b92b5eab Specifically in the large comment block the commit adds. Note that IMHO it would be better to just port usb-host-linux to libusb and let libusb worry about such usbfs details, rather then reproducing all this code inside host-linux.c Note that the not proper handling of this currently already can be a problem when used in combination with an emulated xhci controller, as that can already submit large enough transfers to trigger this. Signed-off-by: Hans de Goede --- hw/usb/host-linux.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/hw/usb/host-linux.c b/hw/usb/host-linux.c index 44f1a64..3a258b4 100644 --- a/hw/usb/host-linux.c +++ b/hw/usb/host-linux.c @@ -1224,7 +1224,8 @@ static int usb_linux_update_endp_table(USBHostDevice *s) usb_ep_set_type(&s->dev, pid, ep, type); usb_ep_set_ifnum(&s->dev, pid, ep, interface); if ((s->options & (1 << USB_HOST_OPT_PIPELINE)) && - (type == USB_ENDPOINT_XFER_BULK)) { + (type == USB_ENDPOINT_XFER_BULK) && + (pid == USB_TOKEN_OUT)) { usb_ep_set_pipeline(&s->dev, pid, ep, true); } -- 1.7.12.1