From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZXmr-0002FE-VM for qemu-devel@nongnu.org; Mon, 25 Jan 2010 17:52:02 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZXmn-0002CA-2s for qemu-devel@nongnu.org; Mon, 25 Jan 2010 17:52:01 -0500 Received: from [199.232.76.173] (port=60930 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZXmn-0002C2-0p for qemu-devel@nongnu.org; Mon, 25 Jan 2010 17:51:57 -0500 Received: from jessica.hrz.tu-chemnitz.de ([134.109.132.47]:41760) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NZXml-0000a4-DQ for qemu-devel@nongnu.org; Mon, 25 Jan 2010 17:51:56 -0500 Message-ID: <4B5E2080.5010701@plauener.de> Date: Mon, 25 Jan 2010 23:51:44 +0100 From: Christian Krause MIME-Version: 1.0 References: <20100124163452.GB8270@gondor.middle-earth.priv> <20100124212034.GA6415@redhat.com> In-Reply-To: <20100124212034.GA6415@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH, RESEND] usb: increase buffer for USB control requests List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org Hello Michael, On 01/24/2010 10:20 PM, Michael S. Tsirkin wrote: > On Sun, Jan 24, 2010 at 05:34:52PM +0100, Christian Krause wrote: >> Resend. The patch was already sent to the list on 2009-12-11. It would >> be great if it could be reviewed and applied. Thank you very much >> in advance. >> >> The WLAN USB stick ZyXEL NWD271N (0586:3417) uses very large >> usb control transfers of more than 2048 bytes which won't fit >> into the buffer of the ctrl_struct. This results in an error message >> "husb: ctrl buffer too small" and a non-working device. >> Increasing the buffer size to 8192 seems to be a safe choice. >> >> Signed-off-by: Christian Krause > > Are there any drawbacks to make\ing the buffer larger? I've roughly looked into the source code of usb-linux.c and I don't see an issue if the buffer would be larger: - if the buffer is used to get data via USBDEVFS_SUBMITURB from the kernel then the check: if (buffer_len > sizeof(s->ctrl.buffer)) { fprintf(stderr, "husb: ctrl buffer too small (%u > %zu)\n", buffer_len, sizeof(s->ctrl.buffer)); return USB_RET_STALL; } already ensures that the we only supply a buffer_len which matches the buffer - on the other hand, when we copy data out of the buffer into the data structures from the HC, then there is also a check that we only copy as much data as the HC requests: if (len > p->len) len = p->len; memcpy(p->data, s->ctrl.buffer + s->ctrl.offset, len); > If no, let's just make it 64K? IIUC that's a maximum > length for control transfers as length is a 16 bit field. I think that's OK since it looks like that the increase of memory would only be 64k per usb host device. Best regards, Christian >> --- >> usb-linux.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/usb-linux.c b/usb-linux.c >> index 285ac22..d205bd3 100644 >> --- a/usb-linux.c >> +++ b/usb-linux.c >> @@ -113,7 +113,7 @@ struct ctrl_struct { >> uint16_t offset; >> uint8_t state; >> struct usb_ctrlrequest req; >> - uint8_t buffer[2048]; >> + uint8_t buffer[8192]; >> }; >> >> struct USBAutoFilter { >> -- >> 1.6.2.5 >> >> >