netdev - Re: [PATCH net-next v2] net: ethernet: neterion: s2io: remove unused driver

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: <alpine.DEB.2.21.2601290525150.40317@angie.orcam.me.uk>
Date: Thu, 29 Jan 2026 13:42:53 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Jakub Kicinski <kuba@...nel.org>
cc: Ethan Nelson-Moore <enelsonmoore@...il.com>, netdev@...r.kernel.org, 
    linux-doc@...r.kernel.org, linux-pci@...r.kernel.org, 
    linux-mips@...r.kernel.org, linux-s390@...r.kernel.org, 
    Jonathan Corbet <corbet@....net>, Linas Vepstas <linasvepstas@...il.com>, 
    Mahesh J Salgaonkar <mahesh@...ux.ibm.com>, 
    Oliver O'Halloran <oohall@...il.com>, Bjorn Helgaas <bhelgaas@...gle.com>, 
    "David S. Miller" <davem@...emloft.net>, 
    Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, 
    Simon Horman <horms@...nel.org>, 
    Thomas Bogendoerfer <tsbogend@...ha.franken.de>, 
    Madhavan Srinivasan <maddy@...ux.ibm.com>, 
    Michael Ellerman <mpe@...erman.id.au>, Nicholas Piggin <npiggin@...il.com>, 
    "Christophe Leroy (CS GROUP)" <chleroy@...nel.org>, 
    Heiko Carstens <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>, 
    Alexander Gordeev <agordeev@...ux.ibm.com>, 
    Christian Borntraeger <borntraeger@...ux.ibm.com>, 
    Sven Schnelle <svens@...ux.ibm.com>, Andrew Lunn <andrew+netdev@...n.ch>, 
    Andrew Morton <akpm@...ux-foundation.org>, 
    Martin Kepplinger-Novaković <martink@...teo.de>, 
    Pavel Machek <pavel@....cz>, MD Danish Anwar <danishanwar@...com>, 
    Mengyuan Lou <mengyuanlou@...-swift.com>, 
    Pablo Neira Ayuso <pablo@...filter.org>, Takashi Iwai <tiwai@...e.de>, 
    Huacai Chen <chenhuacai@...nel.org>, Theodore Ts'o <tytso@....edu>, 
    Eric Biggers <ebiggers@...gle.com>, 
    Madadi Vineeth Reddy <vineethr@...ux.ibm.com>, 
    Shrikanth Hegde <sshegde@...ux.ibm.com>, 
    Geert Uytterhoeven <geert@...ux-m68k.org>, 
    Ard Biesheuvel <ardb@...nel.org>, 
    "Martin K. Petersen" <martin.petersen@...cle.com>, 
    Frederic Barrat <fbarrat@...ux.ibm.com>, 
    Andrew Donnellan <ajd@...ux.ibm.com>, 
    Herbert Xu <herbert@...dor.apana.org.au>, 
    Konstantin Shkolnyy <kshk@...ux.ibm.com>, 
    Vadim Fedorenko <vadim.fedorenko@...ux.dev>, 
    Lorenzo Bianconi <lorenzo@...nel.org>, 
    Lukas Bulwahn <lukas.bulwahn@...hat.com>, Dong Yibo <dong100@...se.com>, 
    Heiner Kallweit <hkallweit1@...il.com>, Thomas Gleixner <tglx@...nel.org>, 
    Ingo Molnar <mingo@...nel.org>, Lukas Wunner <lukas@...ner.de>, 
    Giovanni Cabiddu <giovanni.cabiddu@...el.com>
Subject: Re: [PATCH net-next v2] net: ethernet: neterion: s2io: remove unused
 driver

On Tue, 27 Jan 2026, Jakub Kicinski wrote:

> > > highly unlikely that this driver is still being used. Remove the
> > > driver, and move the former maintainer to the CREDITS file (restoring
> > > credit for the vxge driver, which was removed in commit f05643a0f60b
> > > ("eth: remove neterion/vxge").  
> > 
> >  How do you know it's not used? 
> 
> Hard to prove a negative and whatnot.
> 
> We deleted the vxge which I think(?) was for a newer version of this HW
> 3+ years ago and nobody complained. 

 It may or may not mean anything.  Overall I think it would be fair to 
have a deprecation period of say a year with the affected code guarded 
with CONFIG_DEPRECATED, giving a chance for people downstream to notice 
and act.  That seems to work for the other projects I've been involved 
with (GNU toolchain components and the policy for target removal).

> > What's the gain from removing a driver unless say it's broken and
> > does not build?
> 
> People keep sending cleanups and fixes for these old drivers.
> It takes time to review that stuff.

 Fair point, however the driver has a maintainer listed who should be 
taking care of that.  I can see he was cc'd on v1 but not this revision, 
so does that mean the address bounces?  If so, it should be stated in an
updated change description, and that would certainly be a good reason to 
first deprecate a driver and if no one steps up, then discard it.

  Maciej