What I meant if that the other configurations are not checked for UAC1 or UAC2 capabilities, you only check that there is more than one configurationThe current detection logic is that UAC3 configuration is chosen only when a device has a configuration with audio interface supporting UAC3 protocol.[ Adding linux-usb ML to Cc, as it's a core USB issue ]IIRC an UAC3-capable device is required to expose a backwards-compatible
So the device seems incorrectly advertising as if it were supporting
UAC3 -- assuming the device is still not UAC3-capable.
IOW, it's a buggy firmware. We need some blacklisting, or revert the
commit for now, unless any real UAC3 device comes up to the market.
configuration (either UAC1 or UAC2). Maybe an additional test can be
done to harden the detection so that UAC3 is only chosen if indeed a
second audio configuration is present as well.
I also vaguely recall there was talk about adding information in the BOS
descriptor, but I don't know if this was ever published.
Additionally, it already makes sure that UAC3 is selected only when there is more than one configuration.