From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnwRF-0002hZ-4C for qemu-devel@nongnu.org; Thu, 09 Oct 2008 10:24:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KnwRD-0002gu-IR for qemu-devel@nongnu.org; Thu, 09 Oct 2008 10:24:24 -0400 Received: from [199.232.76.173] (port=40184 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnwRD-0002gl-8a for qemu-devel@nongnu.org; Thu, 09 Oct 2008 10:24:23 -0400 Received: from mail.windriver.com ([147.11.1.11]:64043 helo=mail.wrs.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KnwRC-0001y6-Iq for qemu-devel@nongnu.org; Thu, 09 Oct 2008 10:24:22 -0400 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m99EOHCL017862 for ; Thu, 9 Oct 2008 07:24:17 -0700 (PDT) Message-ID: <48EE1412.6030500@windriver.com> Date: Thu, 09 Oct 2008 09:24:18 -0500 From: Jason Wessel MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] USB serial device support References: <48EBC691.2010803@windriver.com> <48ED247B.6070107@codemonkey.ws> In-Reply-To: <48ED247B.6070107@codemonkey.ws> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Anthony Liguori wrote: > Jason Wessel wrote: >> Add in usb serial pass through support, based on the current usb-linux.c. >> > > Can you explain why this allows usb serial pass through support? It is > not at all obvious from the patch. > The patch header included the description of what causes it to work. The ioctl call qemu uses to the host linux kernel will always return less than 0 for the 3 different usb serial devices I tried. >>From QEMU's usb-linux.c, the ioctl is setup with: 833 ct.bRequestType = USB_DIR_IN | USB_RECIP_INTERFACE; 834 ct.bRequest = USB_REQ_GET_INTERFACE; ... 841 ret = ioctl(s->fd, USBDEVFS_CONTROL, &ct); On the host kernel this request translates into a call to the usb high level code in linux-2.6/drivers/usb/core/devio.c in the function usdev_ioctl(). The request for information is formed into a URB and sent to the device. The device itself is responding that the request is not supported. If you turn on the USB core debug printk's in the kernel you get the following message in response to the user space ioctl: usb 1-2: usbfs: USBDEVFS_CONTROL failed cmd qemu rqt 129 rq 10 len 1 ret -110 As an experiment, I even tried this ioctl against qemu's FTDI usb serial simulated device with the same result. The ioctl request can be made to succeed against qemu's simulated device by changing the request type from 833 ct.bRequestType = USB_DIR_IN | USB_RECIP_INTERFACE; To: 833 ct.bRequestType = USB_DIR_IN | USB_RECIP_DEVICE; It is important to note that even with the change above that this request still fails on the "real hardware", because the "real hardware" does not implement a response to either request type. The patch I provided was simply to implement a fall back to assign the alternate interface number to be the same as the primary interface obtained from the /sys information. The only other approach would be to find an other ioctl request that actually succeeds for these serial devices which could be implemented as a fall back. I don't have any kind of documentation that states what type of request you can make to these type of devices to get "alternate interface" information via a usb control request, which leads me to believe the devices simply do not support it. Perhaps someone else out there has low level documentation that states how you might send a USB control request for this? In the mean time, at least the usb serial devices work with the patch. Jason.