Re: [Qemu-devel] [PATCH 26/26] usbredir: Add support for buffered bulk input

[Hans de Goede]

Hi,

On 12/18/2012 02:36 PM, Gerd Hoffmann wrote:
>    Hi,
>
> Added patches 1-25 to the usb queue (using v2 of patch 10).
>
> >   hw/usb/redirect-ftdi-ids.h   | 1255 ++++++++++++++++++++++++++++++++++++++++++
> >   hw/usb/redirect-pl2303-ids.h |  150 +++++
> >   hw/usb/redirect-usb-ids.h    |  910 ++++++++++++++++++++++++++++++
>
> Where does this come from?  Linux kernel I guess?

These 2 are 1 on 1 copies from the kernel:

hw/usb/redirect-ftdi-ids.h   | 1255 ++++++++++++++++++++++++++++++++++++++++++
hw/usb/redirect-pl2303-ids.h |  150 +++++

They contain "boring" stuff like:

#define FTDI_8U232AM_PID 0x6001 /* Similar device to SIO above */
#define FTDI_8U232AM_ALT_PID 0x6006 /* FTDI's alternate PID for above */

Which allows me to easily copy the id tables from the kernel
drivers (.c files).

This one:
hw/usb/redirect-usb-ids.h

Contains the usb-id tables copied from the kernel, as stated
in the comments:

    /*
     * Silicon Laboratories CP210x USB to RS232 serial adapter ids
     * copied from linux/drivers/usb/serial/cp210x.c
     *
     * Copyright (C) 2005 Craig Shelley (address@hidden)
     */
    { USB_DEVICE(0x045B, 0x0053) }, /* Renesas RX610 RX-Stick */

> What is the procedure to update them?

I've defined my own version of the USB_DEVICE macro, after that
the tables are just 1 on 1 copies from the kernel tree, with
s/<tab>/    /

So updating them can be done by emptying the list and then copying in
the new list from the latest kernel, this is an (easy) manual procedure
for now.

> I also think this shouldn't be tied to redir, I think it is better to
> have a hw/usb/quirks.c file where the device id database and helper
> functions to match devices against the list are living.

Makes sense, one problem I see though is that right now I've
2 id tables, named usbredir_raw_serial_ids and usbredir_ftdi_serial_ids
since ftdi based adapters need some extra special handling (a quirk
to the quirk).

Once we start working with quirk tables it makes sense to have 1 large
table with an extra uint32_t field which contains the actual quirks as
bitmask. All perfectly sensible, but this breaks the easy copy and
paste syncing of the tables from the Linux kernel ...

So any good ideas for this from you ?

Regards,

Hans