From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Hayes Wang <hayeswang@realtek.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
nic_swsd <nic_swsd@realtek.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
Oliver Neukum <oliver@neukum.org>
Subject: Re: [PATCH net-next v2] net/usb/r8153_ecm: support ECM mode for RTL8153
Date: Tue, 3 Nov 2020 10:32:41 +0100 [thread overview]
Message-ID: <20201103093241.GA79239@kroah.com> (raw)
In-Reply-To: <20201102114718.0118cc12@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
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@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
next prev parent reply other threads:[~2020-11-03 9:32 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-29 12:33 [PATCH] net/usb/r8153_ecm: support ECM mode for RTL8153 Hayes Wang
2020-10-29 15:04 ` kernel test robot
2020-10-29 15:04 ` kernel test robot
2020-10-30 3:23 ` [PATCH net-next v2] " Hayes Wang
2020-10-31 23:08 ` Jakub Kicinski
2020-11-02 7:20 ` Hayes Wang
2020-11-02 19:47 ` Jakub Kicinski
2020-11-03 9:32 ` Greg Kroah-Hartman [this message]
2020-11-03 9:51 ` Hayes Wang
2020-11-03 16:15 ` Jakub Kicinski
2020-11-04 1:39 ` Hayes Wang
2020-11-04 1:44 ` Jakub Kicinski
2020-11-03 9:46 ` [PATCH net-next v3 0/2] drivers/net/usb: " Hayes Wang
2020-11-03 9:46 ` [PATCH net-next v3 1/2] include/linux/usb: new header file for the vendor ID of USB devices Hayes Wang
2020-11-03 9:55 ` Greg KH
2020-11-03 9:46 ` [PATCH net-next v3 2/2] net/usb/r8153_ecm: support ECM mode for RTL8153 Hayes Wang
2020-11-04 2:19 ` [PATCH net-next v2 RESEND] " Hayes Wang
2020-11-06 1:00 ` Jakub Kicinski
2020-11-13 15:29 ` Marek Szyprowski
2020-11-16 6:52 ` [PATCH net-next] r8153_ecm: avoid to be prior to r8152 driver Hayes Wang
2020-11-16 9:18 ` Marek Szyprowski
2020-11-16 17:02 ` Jakub Kicinski
2020-11-17 1:50 ` Hayes Wang
2020-11-17 16:11 ` Jakub Kicinski
2020-11-18 1:21 ` Hayes Wang
2020-11-18 6:43 ` [PATCH net-next v2] " Hayes Wang
2020-11-18 8:18 ` Marek Szyprowski
2020-11-19 16:50 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201103093241.GA79239@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=hayeswang@realtek.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nic_swsd@realtek.com \
--cc=oliver@neukum.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.