Add a helper function to get the endpoint data structure
and put it into use.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

1024 bytes is way to small, one hd UVC webcam I have over here has so
many resolutions its descriptors take op close to 4k. Hopefully 8k will
be enough for all devices.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

If a user wants to redirect 2 identical usb sticks, in theory this is
possible by doing:
usb_add host:1234:5678
usb_add host:1234:5678

But this will lead to us trying to open the first stick twice, since we
don't break the loop after having found a match in our filter list, so the next'
filter list entry will result in us trying to open the same device again.

Fix this by adding the missing break.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

So that we don't index endp_table with a negative index.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Note that "op" also is not set, so before this change these error paths
would feed NULL to perror.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The connectinfo ioctl only differentiates between lo speed devices, and
all other speeds, where as we would like to know the real speed. The real
speed is available in sysfs so use that when available.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Factor out disconnect code (called when a device disappears) to a
separate function.  Add a check for ENODEV errno to a few more places
to make sure we notice disconnects.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This patch removes all references to signal.h when qemu-common.h is included
as they become redundant.
Signed-off-by: NAlexandre Raymond <cerbere@gmail.com>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>

Remove the cancel callback from the USBPacket struct, move it over
to USBDeviceInfo.  Zap usb_defer_packet() which is obsolete now.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Calculate the max packet size correctly.  Only bits 0..11 specify the size,
bits 11+12 specify the number of (highspeed) microframes the endpoint wants
to use.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Add support for splitting large transfers into multiple smaller ones.
This is needed for the upcoming EHCI emulation which allows guests
to submit requests up to 20k in size.  The linux kernel allows 16k
max size though.

Based on a patch from David Ahern, see
http://www.mail-archive.com/qemu-devel@nongnu.org/msg30337.html

Cc: David Ahern <daahern@cisco.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Lookup async urbs which are to be canceled using the linked list
instead of the direct opaque pointer.  There are two reasons we
are doing that:  First, to avoid the opaque poiner to the callback,
which is needed for upcoming cleanups.  Second, because we might
need multiple urbs per request for highspeed support, so a single
opaque pointer doesn't cut it any more anyway.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This patch adds code to track all async urbs in a linked list,
so we can find them without having to pass around a opaque
pointer to them.  Prerequisite for the cleanups.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This patch adds a hostport property which allows to specify the host usb
devices to pass through by bus number and physical port.  This means you
can basically hand over one (or more) of the usb plugs on your host to
the guest and whatever device is plugged in there will show up in the
guest.

Usage:

  -device usb-host,hostbus=1,hostport=1

You can figure the port numbers by plugging in some usb device, then
find it in "info usbhost" and pick bus and port specified there.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The device path isn't just a number.  It specifies the physical port
the device is connected to and in case the device is connected via
usb hub you'll have two numbers there, like this: "5.1".  The first
specifies the root port where the hub is plugged into, the second
specifies the port number of the hub where the device is plugged in.
With multiple hubs chained the string can become longer.

This patch renames devpath to port and makes it a string.   It also
adapts the sysfs parsing code accordingly.  The parser code is also more
strict now and skips the root hubs (which can't be assigned anyway).

The "info usbhost" monitor command now prints bus number, (os-assigned)
device address and physical port for each device.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Make the linux usb host passthrough code use the usb_generic_handle_packet()
function, rather then the curent DYI code. This removes 200 lines of almost
identical code.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

cppcheck report:
usb-linux.c:661: warning: Redundant assignment of "len" in switch

Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Extend the iso buffering code to also buffer iso out packets, this
fixes for example using usb speakers with usb redirection.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Currently we reserve room for endpoint data for 16 endpoints, but given
that we only use endpoint data for endpoints 1-15, and always index the
array with the endpoint-number - 1, 15 is enough.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Refuse iso usb packets when then max packet size for the endpoint is 0,
this avoids an abort in usb_host_alloc_iso() caused by trying to qemu_malloc
a 0 bytes large buffer.

If an endpoint is not in the usb descriptor we've no idea what kind of
endpoint it is and thus how to handle it, refuse packages in this case.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Currently we are submitting iso packets to the host one at a time, as we
receive them from the emulated host controller. This has 2 problems:
1) If we were fast enough to submit every packet in time for the next host host
controller usb frame, we would be generating 1000 hardware interrupts per
second on the host
2) We are not fast enough to submit every packet in time for the next host host
controller usb frame, causing us to not submit iso urbs in some usb frames
which causes devices with an endpoint with an interval of 1 ms (so every
frame) to loose data. This causes for example ubs-1.1 webcams to not work
properly (usb-2.0 is not supported at all atm).

This patch fixes both problems by changing the iso packet pass through handling
to buffer packets. This version only does so for iso input packets (webcams,
audio in) I'm working on a second patch extending this to iso output packets
(audio out).

This patch makes use of the linux batching of iso packets in one urb.
When an iso in packet gets received from the emulated host controller,
it immediately submits 3 urbs with 32 iso in packets each. This causes
the host to only get an hw interrupt every 32 packets dropping the
interrupt rate to 32 interrupts per second and gives it a queue of urbs
to work from once the first 32 iso in packets have been received to make sure
no packets are dropped.

Besides submitting a whole bunch or urbs as soon as the first urb is
received, effectively creating a buffer inside the kernel, this patch also
gets rid of the asynchroneous completion for iso in urbs. Instead they are
only marked as complete in the fd write callback (which usbfs uses to signal
complete urbs). These complete packets then get consumed by returning them
synchroneously to the emulated host controller when it submits an iso in
packet for the ep in question. When no complete packets are ready (which
happens when the stream is starting) a 0 length packet gets returned to
the emulated host controller.

With this patch I've several usb-1.1 webcams working well with usb pass
through, where as without this patch none of them work.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

At least one device I have lies when receiving a USB_REQ_GET_INTERFACE,
always returning 0 even if the alternate setting is different. This is
likely caused because in practice this control message is never used as
the operating system's usb stack knows which alternate setting it has
told the device to get into, and thus this ctrl message does not get
tested by device manufacturers.

When usb_fs_type == USB_FS_SYS, the active alt. setting can be read directly
from sysfs, which allows using this device through qemu's usb redirection.
More in general it seems a good idea to not send needless control msg's to
devices, esp. as the code in question is called every time a set_interface
is done. Which happens multiple times during virtual machine startup, and
when device drivers are activating the usb device.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

The next patch in this series introduces multiple ways to get the
alt setting dependent upon usb_fs_type, it is cleaner to put this
into its own function.

Note that this patch also changes the assumed alt setting in case
of an error getting the alt setting to be 0 (a sane default) rather
then the interface numberwhich makes no sense.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Signed-off-by: NBrad Hards <bradh@frogmouth.net>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>

This isn't used, but leaving it empty causes valgrind noise.
Signed-off-by: NBrad Hards <bradh@frogmouth.net>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>

This was done with:

    sed -i '/get_clock\>.*rt_clock/s/get_clock\>/get_clock_ms/' \
        $(git grep -l 'get_clock\>.*rt_clock' )
    sed -i '/new_timer\>.*rt_clock/s/new_timer\>/new_timer_ms/' \
        $(git grep -l 'new_timer\>.*rt_clock' )

after checking that get_clock and new_timer never occur twice
on the same line.  There were no missed occurrences; however, even
if there had been, they would have been caught by the compiler.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Some devices seem to choke on receiving a USB_REQ_GET_CONFIGURATION ctrl msg
(witnessed with a digital picture frame usb id 1908:1320).
When usb_fs_type == USB_FS_SYS, the active configuration can be read directly
from sysfs, which allows using this device through qemu's usb redirection.
More in general it seems a good idea to not send needless control msg's to
devices, esp. as the code in question is called every time a set_interface
is done. Which happens multiple times during virtual machine startup, and
when device drivers are activating the usb device.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The next patch in this series introduces multiple ways to get the
configuration dependent upon usb_fs_type, it is cleaner to put this
into its own function.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This allows us to recreate the sysfspath used during scanning later
(which will be used in a later patch in this series).
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NShahar Havivi <shaharh@redhat.com>
Acked-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Signed-off-by: NShahar Havivi <shaharh@redhat.com>
Acked-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Signed-off-by: NDavid Ahern <daahern@cisco.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Value stored is never read.
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

This reverts commit 3c9c706c.

This breaks build (gcc 4.3.2):
    CC    usb-linux.o
 cc1: warnings being treated as errors
 /src/qemu/usb-linux.c: In function 'usb_linux_update_endp_table':
 /src/qemu/usb-linux.c:759: error: 'type' may be used uninitialized in
 this function
Reported-by: NBlue Swirl <blauwirbel@gmail.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The monitor_printf() reports failure.  Printing is wrong, because the
caller tries various arguments, and expects the function to fail for
some or all.

Disabled since commit 26a9e82a.  Remove it.