On Mon, Nov 02, 2020 at 11:47:18AM -0800, Jakub Kicinski wrote: > On Mon, 2 Nov 2020 07:20:15 +0000 Hayes Wang wrote: > > Jakub Kicinski <k...@kernel.org> > > > Can you describe the use case in more detail? > > > > > > AFAICT r8152 defines a match for the exact same device. > > > Does it not mean that which driver is used will be somewhat random > > > if both are built? > > > > I export rtl_get_version() from r8152. It would return none zero > > value if r8152 could support this device. Both r8152 and r8153_ecm > > would check the return value of rtl_get_version() in porbe(). > > Therefore, if rtl_get_version() return none zero value, the r8152 > > is used for the device with vendor mode. Otherwise, the r8153_ecm > > is used for the device with ECM mode. > > Oh, I see, I missed that the rtl_get_version() checking is the inverse > of r8152. > > > > > +/* Define these values to match your device */ > > > > +#define VENDOR_ID_REALTEK 0x0bda > > > > +#define VENDOR_ID_MICROSOFT 0x045e > > > > +#define VENDOR_ID_SAMSUNG 0x04e8 > > > > +#define VENDOR_ID_LENOVO 0x17ef > > > > +#define VENDOR_ID_LINKSYS 0x13b1 > > > > +#define VENDOR_ID_NVIDIA 0x0955 > > > > +#define VENDOR_ID_TPLINK 0x2357 > > > > > > $ git grep 0x2357 | grep -i tplink > > > drivers/net/usb/cdc_ether.c:#define TPLINK_VENDOR_ID 0x2357 > > > drivers/net/usb/r8152.c:#define VENDOR_ID_TPLINK 0x2357 > > > drivers/usb/serial/option.c:#define TPLINK_VENDOR_ID > > > 0x2357 > > > > > > $ git grep 0x17ef | grep -i lenovo > > > drivers/hid/hid-ids.h:#define USB_VENDOR_ID_LENOVO 0x17ef > > > drivers/hid/wacom.h:#define USB_VENDOR_ID_LENOVO 0x17ef > > > drivers/net/usb/cdc_ether.c:#define LENOVO_VENDOR_ID 0x17ef > > > drivers/net/usb/r8152.c:#define VENDOR_ID_LENOVO 0x17ef > > > > > > Time to consolidate those vendor id defines perhaps? > > > > It seems that there is no such header file which I could include > > or add the new vendor IDs. > > Please create one. (Adding Greg KH to the recipients, in case there is > a reason that USB subsystem doesn't have a common vendor id header.)
There is a reason, it's a nightmare to maintain and handle merges for, just don't do it. Read the comments at the top of the pci_ids.h file if you are curious why we don't even do this for PCI device ids anymore for the past 10+ years. So no, please do not create such a common file, it is not needed or a good idea. thanks, greg k-h
