usb: quirks: Add quirk to prefer vendor-specific configuration

Some USB devices with multiple configurations expose a vendor-specific
interface class that should be preferred by default. However, the generic
usb_choose_configuration() logic selects the first configuration whose
first interface uses a non-vendor-specific class, which can lead to
incomplete or limited functionality.

Introduce a new quirk, USB_QUIRK_CHOOSE_VENDOR_SPEC_CFG, which
instructs the USB core to prefer a configuration that contains a
vendor-specific interface class when multiple configurations are present.

Apply this quirk to the ASIX AX88179 USB Ethernet adapter
(0x0b95:0x1790), which requires selecting its vendor-specific
configuration for full functionality, instead of falling back to
cdc_ncm.

Signed-off-by: Ivan Hu <ivan.hu@canonical.com>
---
 drivers/usb/core/generic.c | 15 +++++++++++++++
 drivers/usb/core/quirks.c  |  3 +++
 include/linux/usb/quirks.h |  3 +++
 3 files changed, 21 insertions(+)

On Thu, Apr 10, 2025 at 10:46:26AM +0800, Ivan Hu wrote:
> Some USB devices with multiple configurations expose a vendor-specific
> interface class that should be preferred by default. However, the generic
> usb_choose_configuration() logic selects the first configuration whose
> first interface uses a non-vendor-specific class, which can lead to
> incomplete or limited functionality.
> 
> Introduce a new quirk, USB_QUIRK_CHOOSE_VENDOR_SPEC_CFG, which
> instructs the USB core to prefer a configuration that contains a
> vendor-specific interface class when multiple configurations are present.
> 
> Apply this quirk to the ASIX AX88179 USB Ethernet adapter
> (0x0b95:0x1790), which requires selecting its vendor-specific
> configuration for full functionality, instead of falling back to
> cdc_ncm.

Shouldn't this be done in userspace instead?  And how does other
operating systems handle this, the "first" configuration is usually the
default for them as well, do they have some built-in quirk to handle
this or do they rely on a vendor-provided driver?

thanks,

greg k-h

On 2025/4/10 14:58, Greg KH wrote:
> On Thu, Apr 10, 2025 at 10:46:26AM +0800, Ivan Hu wrote:
>> Some USB devices with multiple configurations expose a vendor-specific
>> interface class that should be preferred by default. However, the generic
>> usb_choose_configuration() logic selects the first configuration whose
>> first interface uses a non-vendor-specific class, which can lead to
>> incomplete or limited functionality.
>>
>> Introduce a new quirk, USB_QUIRK_CHOOSE_VENDOR_SPEC_CFG, which
>> instructs the USB core to prefer a configuration that contains a
>> vendor-specific interface class when multiple configurations are present.
>>
>> Apply this quirk to the ASIX AX88179 USB Ethernet adapter
>> (0x0b95:0x1790), which requires selecting its vendor-specific
>> configuration for full functionality, instead of falling back to
>> cdc_ncm.
> 
> Shouldn't this be done in userspace instead?  And how does other
> operating systems handle this, the "first" configuration is usually the
> default for them as well, do they have some built-in quirk to handle
> this or do they rely on a vendor-provided driver?
> 
> thanks,
> 
> greg k-h
> 

Hi Greg,

Thanks for the feedback.

In this case, the device advertises three configuration descriptors. The first is vendor-specific, the second is CDC-NCM, and the third is CDC-Ether:

Device Descriptor:
   idVendor           0x0b95 ASIX Electronics Corp.
   idProduct          0x1790 AX88179 Gigabit Ethernet
   bNumConfigurations      3

Configuration 1:
   Interface 0:
     bInterfaceClass       255 Vendor Specific Class

Configuration 2:
   Interface 0:
     bInterfaceClass         2 Communications
     bInterfaceSubClass     13 (CDC-NCM)

Configuration 3:
   Interface 0:
     bInterfaceClass         2 Communications
     bInterfaceSubClass      6 (CDC-Ether)

In drivers/usb/core/generic.c, the logic currently prefers the first configuration whose first interface is non-vendor-specific,
based on the assumption that Linux is more likely to have a generic class driver than a vendor-specific one:
		/* From the remaining configs, choose the first one whose
		 * first interface is for a non-vendor-specific class.
		 * Reason: Linux is more likely to have a class driver
		 * than a vendor-specific driver. */
This results in the CDC-NCM configuration being selected by default, even though the kernel already supports the vendor-specific driver ax88179_178a,
which provides the correct and full functionality.

Of course, this could be handled in userspace, but due to security restrictions on certain systems, such as Ubuntu Core, modifying configuration selection in userspace becomes significantly more complex and less straightforward.
And although I don’t have insight into the exact design in Windows, but during testing on a standard Windows install, the device is correctly initialized with the vendor driver without any additional configuration or modification.
Given that this quirk is device-specific and not a general change in policy, the proposed quirk simply allows the kernel to prefer the correct vendor-specific configuration when it's known to be required.

Cheers,
Ivan