From: Andrew Lunn <andrew@lunn.ch>
To: Byron Stanoszek <gandalf@winds.org>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-doc@vger.kernel.org
Subject: Re: [PATCH net 00/18] Remove a number of ISA and PCMCIA Ethernet drivers
Date: Wed, 22 Apr 2026 00:30:36 +0200 [thread overview]
Message-ID: <e056d348-4560-4df3-85c4-e29393b004e9@lunn.ch> (raw)
In-Reply-To: <71d319ef-cd49-e8a8-70dd-cf0763ac6305@winds.org>
On Tue, Apr 21, 2026 at 04:44:11PM -0400, Byron Stanoszek wrote:
> On Tue, 21 Apr 2026, Andrew Lunn wrote:
>
> > These old drivers have not been much of a Maintenance burden until
> > recently. Now there are more newbies using AI and fuzzers finding
> > issues, resulting in more work for Maintainers. Fixing these old
> > drivers make little sense, if it is not clear they have users.
> >
> > drivers: net: 3com: 3c59x: Remove this driver
>
> Hi Andrew,
>
> I happen to still use this driver on several hundred industrial PC
> installations that were outfitted with 3com 3C905-B & CX cards 15+ years ago.
> The old hardware still runs, therefore those cards haven't needed to be
> replaced. I keep these systems up to date with the latest Linux kernel roughly
> once per year.
So 6.18? 6.12?
> I understand the maintenance burden, but I would be delighted to continue
> receiving bug fixes for this driver via the mainline Linux kernel if you are
> still willing to continue to support it.
Looking at the history of 3c59x.c i see:
Date: Tue Jan 6 10:47:21 2026 +0100
net: 3com: 3c59x: fix possible null dereference in vortex_probe1()
Date: Wed Jan 3 13:09:23 2018 -0500
3c59x: fix missing dma_mapping_error check and bad ring refill logic
Date: Thu Feb 25 13:02:50 2016 -0500
3c59x: mask LAST_FRAG bit from length field in ring
Date: Sun Feb 28 16:49:29 2016 +0900
3c59x: Ensure to apply the expires time
Date: Wed Jan 13 12:43:54 2016 -0500
3c59x: fix another page map/single unmap imbalance
Date: Wed Jan 13 12:43:53 2016 -0500
3c59x: balance page maps and unmaps
Date: Tue Jul 7 20:48:55 2015 +0200
3c59x: Fix shared IRQ handling
So it looks like it was been pretty stable since 2016.
Could you live with v6.18, which has an expected EOL of December 2028?
If you are only updating once per year, security is not an issue, you
just want stability.
In fact, you might actually find stability starts going down in the
next couple of years, maybe sooner. What we expect to happen soon is a
lot more AI generated 'bug fixes', probably from newbies who are
unable to evaluate if the AI is generated good fixes or bad fixes, or
fixes which are theoretical rather than actual bugs etc. We netdev
Maintainers are already seeing the number of patches going up, and are
expecting to get overloaded. Which means quality will go down. We have
also seen the AI generated fixes are indiscriminate, neither the AI,
nor the human, care, or even look, to see if the driver is from the
last century. We Maintainers however would prefer spending our time on
drivers from the last ten years, maybe newer. So patches for these
older drivers is going to get less review, and bad patches will slip
through.
By dropping them for the current HEAD, we are reducing our surface
area. It will be interesting to see if the AI patches are only for
HEAD, or they start going back to older kernels to find 'bugs'.
However, just because a driver has gone from HEAD, it does not really
prevent us from taking patches for stable. But we Maintainers want to
avoid doing the triage work, figuring out good from bad.
We have not discussed it as a Maintainer team, but one thing which
might work is we add a entry for 3c59x.c in MAINTAINERS, in stable,
pointing to you. You can then validate patches, and tell us if they
are O.K. to queue for stable.
Andrew
next prev parent reply other threads:[~2026-04-21 22:30 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-21 19:31 [PATCH net 00/18] Remove a number of ISA and PCMCIA Ethernet drivers Andrew Lunn
2026-04-21 19:31 ` [PATCH net 01/18] drivers: net: 3com: 3c509: Remove this driver Andrew Lunn
2026-04-21 19:31 ` [PATCH net 02/18] drivers: net: 3com: 3c515: " Andrew Lunn
2026-04-21 19:31 ` [PATCH net 03/18] drivers: net: 3com: 3c574: " Andrew Lunn
2026-04-21 19:31 ` [PATCH net 04/18] drivers: net: 3com: 3c589: " Andrew Lunn
2026-04-21 19:31 ` [PATCH net 05/18] drivers: net: 3com: 3c59x: " Andrew Lunn
2026-04-21 19:31 ` [PATCH net 06/18] drivers: net: amd: Remove hplance and mvme147 Andrew Lunn
2026-04-21 21:38 ` Daniel Palmer
2026-04-22 12:50 ` Andrew Lunn
2026-04-22 7:37 ` Geert Uytterhoeven
2026-04-21 19:31 ` [PATCH net 07/18] drivers: net: amd: lance: Remove this driver Andrew Lunn
2026-04-21 19:31 ` [PATCH net 08/18] drivers: net: amd: nmclan: " Andrew Lunn
2026-04-21 19:31 ` [PATCH net 09/18] drivers: net: smsc: smc9194: " Andrew Lunn
2026-04-21 19:31 ` [PATCH net 10/18] drivers: net: smsc: smc91c92: " Andrew Lunn
2026-04-21 19:31 ` [PATCH net 11/18] drivers: net: cirrus: cs89x0: " Andrew Lunn
2026-04-22 7:31 ` Geert Uytterhoeven
2026-04-22 12:13 ` Andrew Lunn
2026-04-22 12:17 ` Geert Uytterhoeven
2026-04-21 19:31 ` [PATCH net 12/18] drivers: net: cirrus: mac89x0: " Andrew Lunn
2026-04-21 21:34 ` Daniel Palmer
2026-04-22 7:36 ` Geert Uytterhoeven
2026-04-21 19:31 ` [PATCH net 13/18] drivers: net: fujitsu: fmvj18x: " Andrew Lunn
2026-04-21 19:31 ` [PATCH net 14/18] drivers: net: xircom: xirc2ps: " Andrew Lunn
2026-04-21 19:31 ` [PATCH net 15/18] drivers: net: 8390: AX88190: " Andrew Lunn
2026-04-21 19:31 ` [PATCH net 16/18] drivers: net: 8390: pcnet: " Andrew Lunn
2026-04-21 19:31 ` [PATCH net 17/18] drivers: net: 8390: ultra: " Andrew Lunn
2026-04-21 19:31 ` [PATCH net 18/18] drivers: net: 8390: wd80x3: " Andrew Lunn
2026-04-21 19:53 ` [PATCH net 00/18] Remove a number of ISA and PCMCIA Ethernet drivers Andrew Lunn
2026-04-22 1:39 ` Jakub Kicinski
2026-04-21 20:44 ` Byron Stanoszek
2026-04-21 22:30 ` Andrew Lunn [this message]
2026-04-22 3:03 ` Byron Stanoszek
2026-04-22 12:11 ` Andrew Lunn
2026-04-22 15:19 ` Byron Stanoszek
2026-04-21 22:03 ` Daniel Palmer
2026-04-22 9:13 ` David Laight
2026-04-22 9:33 ` Daniel Palmer
2026-04-22 5:42 ` John Paul Adrian Glaubitz
2026-04-22 7:42 ` Geert Uytterhoeven
2026-04-22 10:45 ` Finn Thain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e056d348-4560-4df3-85c4-e29393b004e9@lunn.ch \
--to=andrew@lunn.ch \
--cc=andrew+netdev@lunn.ch \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gandalf@winds.org \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=skhan@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox