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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ