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: <3c2a20ef-5388-49bd-ab09-27921ef1a729@rowland.harvard.edu>
Date: Mon, 20 Oct 2025 12:59:04 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Michal Pecio <michal.pecio@...il.com>
Cc: yicongsrfy@....com, andrew+netdev@...n.ch, davem@...emloft.net,
	edumazet@...gle.com, kuba@...nel.org, linux-usb@...r.kernel.org,
	netdev@...r.kernel.org, oliver@...kum.org, pabeni@...hat.com
Subject: Re: [PATCH net v5 2/3] net: usb: ax88179_178a: add USB device driver
 for config selection

On Mon, Oct 20, 2025 at 06:23:27PM +0200, Michal Pecio wrote:
> On Mon, 20 Oct 2025 11:56:50 -0400, Alan Stern wrote:
> > Instead of all this preferred() stuff, why not have the ax88179 driver's 
> > probe routine check for a different configuration with a vendor-specific 
> > interface?  If that other config is present and the chip is the right 
> > type then you can call usb_driver_set_configuration() -- this is exactly 
> > what it's meant for.
> 
> That could be doable and some code could be shared I guess, but how to
> get the probe() routine to run in the first place?
> 
> The chip may be in other configuration, without this vendor interface.
> If we remove _AND_INTERFACE_INFO, it's still a problem that cdc_ether
> may already be bound to the CDC interface in CDC config.
> 
> Registering a *device* driver plows through such obstacles, because
> core allows device drivers to immediately displace existing drivers.
> 
> 
> It seems that this could work, if cdc_ether blacklisting and revert
> of _AND_INTERFACE_INFO are applied as suggested in this series.
> (But as part of the main commit, to avoid transient regressions).
> 
> I wonder if blacklisting is considered necessary evil? Without it, it's
> possible that cdc_ether binds for a moment before it's kicked out by
> the vendor driver. Looks weird in dmesg, at the very least.
> 
> FWIW, my RTL8153 is blacklisted in cdc_ether too. So much for the
> promise that cfgselectors will allow users to choose drivers ;)

Another possibility is simply to give up on handling all of this 
automatically in the kernel.  The usb_modeswitch program certainly 
should be capable of determining when a USB network device ought to 
switch to a different configuration; that's very similar to the things 
it does already.  Maybe userspace is the best place to implement this 
stuff.

Furthermore, with usb_modeswitch it's not at all uncommon to have some 
drivers bind momentarily before being kicked off.  People don't care 
about it very much, as long it all happens reliably and automatically.

Alan Stern