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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <806d82e6-6db6-4ec8-a49c-665a97ea36f8@suse.com>
Date: Tue, 21 Oct 2025 11:02:25 +0200
From: Oliver Neukum <oneukum@...e.com>
To: Michal Pecio <michal.pecio@...il.com>, Oliver Neukum <oneukum@...e.com>
Cc: Alan Stern <stern@...land.harvard.edu>, yicongsrfy@....com,
 andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com,
 kuba@...nel.org, linux-usb@...r.kernel.org, netdev@...r.kernel.org,
 pabeni@...hat.com
Subject: Re: [PATCH net v5 2/3] net: usb: ax88179_178a: add USB device driver
 for config selection

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