On Mon, Jan 23, 2017 at 12:47:31PM +0100, Petr Cvek wrote: > Dne 23.1.2017 v 12:32 Greg KH napsal(a): > >>>> 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 :) > >> > > So using 0106 "Composite gadget: ACM + Mass Storage" or 0104 > "Multifunction Composite Gadget" should be fine? (my actual setup is > not multifunction though). > > I'm actually trying to catch bug, when using configfs access webcam > does not work or kernel oopses (and webcam does not work) :-D. The product id should never be an issue for a bug, if so, then something a lot worse is going on. > >> 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... > > > > My lsusb shows separate strings (using usbutils from slackware64-current): > > Bus 004 Device 003: ID 1d6b:0102 Linux Foundation EEM Gadget > ... > idVendor 0x1d6b Linux Foundation > idProduct 0x0102 EEM Gadget > bcdDevice 4.07 > iManufacturer 1 Linux Foundation > iProduct 2 Webcam gadget > ... Ah, I guess it doesn't, but who knows how old that version of usbutils is, considering the last release I did was well over a year ago. I should do a new one one of these days... Anyway, I'd like to not assign a product id to a chunk of code that is going to be eventually deleted. Felipe, what's the plan for the "legacy" gadget code. Is it ever going away? thanks, greg k-h -- 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
