From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42691) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tt47D-00055L-8H for qemu-devel@nongnu.org; Wed, 09 Jan 2013 17:27:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tt47B-00029R-Ry for qemu-devel@nongnu.org; Wed, 09 Jan 2013 17:27:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:63019) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tt47B-00029K-K0 for qemu-devel@nongnu.org; Wed, 09 Jan 2013 17:27:17 -0500 Message-ID: <50EDE976.1000309@redhat.com> Date: Wed, 09 Jan 2013 23:04:38 +0100 From: Hans de Goede MIME-Version: 1.0 References: <1357650894-16982-1-git-send-email-kraxel@redhat.com> <1357650894-16982-32-git-send-email-kraxel@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 31/32] usbredir: Add support for buffered bulk input (v2) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Gerd Hoffmann , qemu-devel@nongnu.org Hi, On 01/09/2013 09:52 PM, Blue Swirl wrote: >> diff --git a/hw/usb/quirks-ftdi-ids.h b/hw/usb/quirks-ftdi-ids.h >> new file mode 100644 >> index 0000000..57c12ef >> --- /dev/null >> +++ b/hw/usb/quirks-ftdi-ids.h >> @@ -0,0 +1,1255 @@ >> +/* >> + * vendor/product IDs (VID/PID) of devices using FTDI USB serial conv= erters. >> + * Please keep numerically sorted within individual areas, thanks! >> + * >> + * Philipp G=C3=BChring - pg@futureware.at - added the Device ID of t= he USB relais >> + * from Rudolf Gugler > > License information is missing. > > Where is this file coming from, Linux? Yes, it is a one on one copy of linux/drivers/usb/serial/ftdi_sio_ids.h, so I did not think it would be a good idea to simply slap a copyright hea= der on top ... One could argue it is an integral part of linux/drivers/usb/serial/ftdi_s= io.c and use the copy right headers from there. > Should we use linux-headers instead? Since this is a copy of an internal kernel header, rather then of one fro= m the linux/include/linux or linux/include/asm "public" hierarchies it seemed w= rong to me to use linux-headers for this. Regards, Hans