Re: [PATCH net v5 2/3] net: usb: ax88179_178a: add USB device driver for config selection

[Oliver Neukum <oneukum@suse.com>]

On 20.10.25 17:59, Michal Pecio wrote:
> On Mon, 20 Oct 2025 11:59:06 +0200, Oliver Neukum wrote:
>> On 18.10.25 17:21, Michal Pecio wrote:

>>> @@ -1255,6 +1257,8 @@ struct usb_driver {
>>>    
>>>    	void (*shutdown)(struct usb_interface *intf);
>>>    
>>> +	bool (*preferred)(struct usb_device *udev);
>>
>> I am sorry, but this is a bit clunky. If you really want to
>> introduce such a method, why not just return the preferred
>> configuration?
> 
> Because I wanted to introduce exactly such a method, rather than one
> which returns the configuration ;)

Well, then I have to state that your patch perfectly implements
your wish. >:->
Would you allow me a follow up question, though? Why have you
developed that wish?

> The point was to pull configuration selection *out* of those drivers.

While I appreciate the goal, it is not clear to me how adding
a method to the generic interface driver template achieves that goal.
In fact this approach seems counterproductive.

In particular a bool will not work for the generic case.
If you really want to make this generic, you'll have to face
the unfortunate possibility that a configuration have
multiple interfaces whose drivers disagree in that regard.
At a minimum you'd have to be able to return a "don't care"
value to compute a reasonable pick.
  > They already do it, and it makes them copy-paste the same trivial loop
> which iterates through configs until it finds the vendor interface.

If the concern is simply getting the code centralized (which
is not wrong), then Alan's original proposal of having a flag
(let's not call it a quirk) in usbcore for devices that need
the logic in the heuristic for picking a configuration to be
inverted would seem to be the simplest approach.

> The idea is to have a maximally simple check for a known-good vendor
> interface driver before making unfounded assumptions like:
> 
> /* 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. */
> 
> Unfortunately, that's only half the battle. The other half is forcing
> configuration reevaluation when such a driver is loaded. I hoped it

Exactly. Hence don't put the information that the assumption
must not be made into a driver but into usbcore. Problem avoided.

It looks like this is an issue we are not going to find a perfect
solution for. Hence our priority should be finding the simplest
change. IMHO that's a new quirk just inverting existing logic.
Sure, it is a bit ugly because it depends on the kernel configuration,
but that is what we have a preprocessor for.

	Regards
		Oliver