On Tue, 3 Nov 2020 10:32:41 +0100 Greg Kroah-Hartman wrote: > 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 <kuba@xxxxxxxxxx> > > > > 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. Ah! Good that we asked :) > 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. I wouldn't go that far, PCI subsystem just doesn't want everyone to add IDs to the shared file unless there is a reason. * Do not add new entries to this file unless the definitions * are shared between multiple drivers. Which seems quite reasonable. But it is most certainly your call :)