Re: [Qemu-devel] [PATCH] USB serial device support

[Jason Wessel]

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.