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 for Android: free password hash cracker in your pocket

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

Message-ID: <b3eb1a6f-696b-4ece-b906-4ecd14252321@suse.com>
Date: Wed, 22 Oct 2025 09:58:57 +0200
From: Oliver Neukum <oneukum@...e.com>
To: Alan Stern <stern@...land.harvard.edu>
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 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. 
> 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?
>> 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.

	Regards
		Oliver