On Mon, Jan 23, 2017 at 01:27:59PM +0200, Felipe Balbi wrote: > > Hi, > > Greg KH <greg@xxxxxxxxx> writes: > > On Mon, Jan 23, 2017 at 11:30:01AM +0100, Petr Cvek wrote: > >> Hello, > >> > >> It seems the USB product ID for g_webcam usb device gadget is incorrectly used from EEM gadget "Ethernet Emulation Model". So "webcam" device has a confusing description in lsusb: > >> > >> 1d6b:0102 Linux Foundation EEM Gadget > >> > >> I would change it to 0x0106, which is a next unassigned value > >> (according to http://www.linux-usb.org/usb.ids). Does this step > >> require some official communication with the holder of VID (Linux > >> Foundation)? Or all it takes is just to send patch to the kernel and > >> to the usb.ids database? > > > > Note, usb.ids doesn't seem to have picked up the last few changes I > > asked to reserve there, here's the latest reserved id list from the LF > > that I am in charge of: > > > > # Linux Foundation USB id list. > > 1d6b Linux Foundation > > 0001 1.1 root hub > > 0002 2.0 root hub > > 0003 3.0 root hub > > 0100 PTP Gadget > > 0101 Audio Gadget > > 0102 EEM Gadget > > 0103 NCM (Ethernet) Gadget > > 0104 Multifunction Composite Gadget > > 0105 FunctionFS Gadget > > 0106 Composite Gadget: ACM + Mass Storage > > 0200 Qemu Audio Device > > 0246 BlueZ Host Stack > > 0247 BlueZ for Android > > > >> I know it is only a cosmetic change on a legacy driver, but I assume > >> it would be better to have some default value for configfs API than to > >> borrow a PID from a whole different gadget. > > > > For class devices, they really don't need a new id, we should just use > > only one of them as it doesn't matter :) > > fine by me. Just lsusb will look funky ;-) Heh, true, but I thought lsusb would use a string if the device provided it. Haven't looked at that portion of the code in a very long time... -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
