Thread (35 messages) 35 messages, 6 authors, 2025-10-13

Re: [PATCH 2/2] net: usb: support quirks in usbnet

From: <hidden>
Date: 2025-09-29 09:30:38
Also in: linux-usb

On Mon, 29 Sep 2025 10:45:19 +0200, Oliver Neukum [off-list ref] wrote:
On 28.09.25 03:46, yicongsrfy@163.com wrote:
quoted
From: Yi Cong <redacted>

Some vendors' USB network interface controllers (NICs) may be compatible
with multiple drivers.
And here is the basic problem. This issue is not an issue specific to
usbnet. It arises everywhere we have a specific and a general
driver. Hence it ought to be solved in generic way in usbcore.

Nor can we do this with a simple list of devices, as we cannot
assume that the more specific driver is compiled in all systems.
An unconditional quirk is acceptable _only_ if usbnet would
not work.

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.)

This way, `usbnet_probe` can detect the blacklisted information.

usbnet_probe (...)
{
	...
	info = (const struct driver_info *) prod->driver_info;
	if (!info) {
		dev_dbg (&udev->dev, "blacklisted by %s\n", name);
		return -ENODEV;
	}
	...
}

From an implementation standpoint, this approach is indeed cleaner
and simpler than my current solution.
Is the method mentioned above an appropriate approach?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help