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