netdev - Re: Fwd: 3 more broken Zaurii

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: <ZKbuoRBi50i8OZ9d@codemonkey.org.uk>
Date: Thu, 6 Jul 2023 12:41:05 -0400
From: Dave Jones <davej@...emonkey.org.uk>
To: Thorsten Leemhuis <regressions@...mhuis.info>
Cc: Bagas Sanjaya <bagasdotme@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Ross Maynard <bids.7405@...pond.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Regressions <regressions@...ts.linux.dev>,
	Linux Networking <netdev@...r.kernel.org>,
	Linux USB <linux-usb@...r.kernel.org>,
	Oliver Neukum <oneukum@...e.com>
Subject: Re: Fwd: 3 more broken Zaurii - SL-5600, A300, C700

On Thu, Jul 06, 2023 at 01:45:57PM +0200, Thorsten Leemhuis wrote:
 > On 06.07.23 05:08, Bagas Sanjaya wrote:
 > >>
 > >> I notice a regression report on Bugzilla [1]. Quoting from it:
 > >>
 > >>> The following patch broke support of 3 more Zaurus models: SL-5600, A300 and C700
 > >>>
 > >>> [16adf5d07987d93675945f3cecf0e33706566005] usbnet: Remove over-broad module alias from zaurus
 > 
 > ...
 > He sometimes shows up on Linux kernel lists, but I doubt he cares about
 > that change after all these years. And I would not blame him at all.

That's about the size of it.  This is pretty near the bottom of my ever-shrinking
list of kernel drivers I care about.

 > Yes, we have the "no regressions" rule, but contributing a change to the
 > kernel OTOH should not mean that you are responsible for all regressions
 > it causes for your whole life. :-)

That said, 12 years later, 16adf5d07987d93675945f3cecf0e33706566005
is still the right thing to do. Adding actual matches for the devices
rather than matching by class will prevent this getting loaded where it
doesn't need to be.

If someone actually cares to get this working, cargo-culting Oliver's
change to add the extra id is likely the way forward.

	Dave