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] [day] [month] [year] [list]

Message-ID: <7fd2d38a-08c8-4043-8dfe-eb2171b4e4e8@rowland.harvard.edu>
Date: Wed, 22 Oct 2025 10:28:23 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Oliver Neukum <oneukum@...e.com>
Cc: Michal Pecio <michal.pecio@...il.com>, 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 Wed, Oct 22, 2025 at 09:58:57AM +0200, Oliver Neukum wrote:
> On 21.10.25 18:33, Alan Stern wrote:
> > On Tue, Oct 21, 2025 at 11:13:29AM +0200, Oliver Neukum wrote:
> > > On 20.10.25 18:59, Alan Stern wrote:
> > > 
> > > > 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.
> > > 
> > > That would make usb_modeswitch or yet a new udev component mandatory.
> > > That is the exact opposite of what we would like to achieve.
> > 
> > In the same way that usb_modeswitch or a udev script is already
> > mandatory for a bunch of other devices?
> 
> Arguably broken devices.

Perhaps so.  That doesn't affect my main point, however.  Besides, none 
of the possible approaches we have been discussing are truly 
_mandatory_, because the user can always force a configuration change 
simply by writing to a sysfs file.

> > I agree, it would be great if the kernel could handle all these things
> > for people.  But sometimes it's just a lot easier to do stuff in
> > userspace.
> 
> Well the kernel does handle them. It just handles them wrong.

:-)

> You are not proposing to leave devices in the unconfigured state,
> are you?

No, I wasn't.  But that might not be a bad idea in some cases.  If 
userspace can do a better job than the kernel at picking a device's 
initial configuration, we should stay out of its way.

The trick is to know for which devices -- there may be no general way of 
determining this.  Particularly if it depends on what out-of-tree 
drivers the user has installed.

> > > That is probably not wise in the long run. If the device whose driver
> > > we kick off is a CD-ROM, nobody cares. If it is a network interface,
> > > we'll have to deal with ugly cases like user space already having
> > > sent a DHCP query when we kick the old driver off the interface.
> > 
> > Doesn't the same concern apply every time a network interface goes down?
> 
> It does and that is why spontaneously shutting down network interfaces
> in the kernel is a bad idea.

If the action is carried out by usb_modeswitch, for example, the program 
can be responsible for shutting down the network interface cleanly 
before it does the config change.

Alan Stern