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: <bda50568-a05d-4241-adbe-18efb2251d6e@rowland.harvard.edu>
Date: Fri, 17 Oct 2025 22:27:35 -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 Fri, Oct 17, 2025 at 07:15:11PM +0200, Michal Pecio wrote:
> On Fri, 17 Oct 2025 09:10:22 -0400, Alan Stern wrote:
> > On Fri, Oct 17, 2025 at 10:42:29AM +0800, yicongsrfy@....com wrote:
> > > Yes, there are many similar code instances in the USB subsystem.
> > > However, I'm primarily focused on the networking subsystem,
> > > so my abstraction work here might not be thorough enough.
> > > Hopefully, an experienced USB developer may can optimize this issue.  
> > 
> > Would it help to have a USB quirks flag that tells the core to prefer 
> > configurations with a USB_CLASS_VENDOR_SPEC interface class when we 
> > choose the device's configuration?  Or something similar to that (I'm 
> > not sure exactly what you are looking for)?
> 
> Either that or just patch usb_choose_configuration() to prefer vendor
> config *if* an interface driver is available. But not 100% sure if that
> couldn't backfire, so maybe only if the driver asked for it, indeed.
> 
> I was looking into making a PoC of that (I have r8152 with two configs)
> but there is a snag: r8152-cfgselector bails out if a vendor-specific
> check indicates the chip isn't a supported HW revision.
> 
> So to to fully replicate r8152-cfgselector, core would neet to get new
> "pre_probe" callback in the interface driver. It gets complicated.
> 
> A less complicated improvement could be moving the common part of all
> cfgselectors into usbnet. Not sure if it's worth it yet for only two?

Without a reasonable clear and quick criterion for deciding when to 
favor vendor-specific configs in the USB core, there's little I can do.  
Having a quirks flag should help remove some of the indecision, since 
such flags are set by hand rather than by an automated procedure.  But 
I'd still want to have a better idea of exactly what to do when the 
quirk flag is set.

Alan Stern