qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jason Wessel <jason.wessel@windriver.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] USB serial device support
Date: Thu, 09 Oct 2008 09:24:18 -0500	[thread overview]
Message-ID: <48EE1412.6030500@windriver.com> (raw)
In-Reply-To: <48ED247B.6070107@codemonkey.ws>


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.

      reply	other threads:[~2008-10-09 14:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-07 20:29 [Qemu-devel] [PATCH] USB serial device support Jason Wessel
2008-10-08 21:22 ` Anthony Liguori
2008-10-09 14:24   ` Jason Wessel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48EE1412.6030500@windriver.com \
    --to=jason.wessel@windriver.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).