[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250930081415.3410752-1-yicongsrfy@163.com>
Date: Tue, 30 Sep 2025 16:14:15 +0800
From: yicongsrfy@....com
To: oneukum@...e.com
Cc: andrew+netdev@...n.ch,
davem@...emloft.net,
edumazet@...gle.com,
kuba@...nel.org,
linux-usb@...r.kernel.org,
marcan@...can.st,
netdev@...r.kernel.org,
pabeni@...hat.com,
yicong@...inos.cn
Subject: Re: [PATCH 2/2] net: usb: support quirks in usbnet
On Mon, 29 Sep 2025 12:21:30 +0200, Oliver Neukum <oneukum@...e.com> wrote:
>
> On 29.09.25 11:29, yicongsrfy@....com wrote:
> > On Mon, 29 Sep 2025 10:45:19 +0200, Oliver Neukum <oneukum@...e.com> wrote:
>
> >> Please get in contact with the core USB developers. The problem
> >> needs to be solved, but this is not a solution.
> >
> > Thank you for your reply!
> >
> > Should I add the AX88179 chip information into the `usb_quirk_list`
> > in `drivers/usb/core/quirks.c`? (Of course, it will also include a
> > check for whether `CONFIG_USB_NET_AX88179_178A` is enabled.)
>
> That would need to be discussed.
> Ideally the probe() method of cdc_ncm would never be called.
> But there is the possibility that cdc_ncm is already loaded
> and the other driver is not.
> > From an implementation standpoint, this approach is indeed cleaner
> > and simpler than my current solution.
> > Is the method mentioned above an appropriate approach?
> Well, no. Declining devices is not usbnet's job. If the logic
> needs to go into a device driver, it needs to go into cdc-ncm,
> which would need to check quirks.
Thank you for your suggestions!
I've placed the quirk in cdc_ncm and modified its probe
method accordingly. Could you please review whether the
v4 version of the patch is appropriate?
Powered by blists - more mailing lists