Hi,

 As per the previous discussions[1][2] this patch series brings the 3c509 
driver back.  Picking up net rather than net-next as I consider it a fix 
to accidental removal and so that any downstream users do not suffer from 
disruption when using released kernels.

 In the course of making the coding style changes requested I have come 
across an actual bug in transceiver type selection code, where the old 
setting is not masked out before ORing in the new one, causing no change 
to be actually made in a requested transition from BNC to AUI.  I guess 
this code must have been executed exceedingly rarely, as it's always been 
wrong ever since it was added in 2.5.42 back in 2002.

 Therefore I find it not worth backporting to stable branches, however for 
the sake of appropriateness, in case someone downstream does want to have 
the fix, I chose to apply it second in the series, right after the actual 
revert and before code clean-ups.

 The remaining patches of the series should be obvious; see the respective 
commit descriptions for details.

 Please apply.

References:

[1] "drivers: net: 3com: 3c509: Remove this driver", 
    <https://lore.kernel.org/r/alpine.DEB.2.21.2604240004280.28583@angie.orcam.me.uk/>.

[2] "MAINTAINERS: Add self for the 3c509 network driver", 
    <https://lore.kernel.org/r/alpine.DEB.2.21.2604271056460.28583@angie.orcam.me.uk/>.

  Maciej

On Wed, May 20, 2026 at 12:18:44PM +0100, Maciej W. Rozycki wrote:
> Hi,
> 
>  As per the previous discussions[1][2] this patch series brings the 3c509 
> driver back.  Picking up net rather than net-next as I consider it a fix 
> to accidental removal and so that any downstream users do not suffer from 
> disruption when using released kernels.
> 
>  In the course of making the coding style changes requested I have come 
> across an actual bug in transceiver type selection code, where the old 
> setting is not masked out before ORing in the new one, causing no change 
> to be actually made in a requested transition from BNC to AUI.  I guess 
> this code must have been executed exceedingly rarely, as it's always been 
> wrong ever since it was added in 2.5.42 back in 2002.
> 
>  Therefore I find it not worth backporting to stable branches, however for 
> the sake of appropriateness, in case someone downstream does want to have 
> the fix, I chose to apply it second in the series, right after the actual 
> revert and before code clean-ups.
> 
>  The remaining patches of the series should be obvious; see the respective 
> commit descriptions for details.

You need to split this up. Patches to net are likely to get back
ported, even if they don't have Fixes tags. So please add the driver
back in net, but fixup the issues you have found in net-next.

There is also an question of if we want the coding style patch or not.

https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html

  1.7.4. Clean-up patches

  Netdev discourages patches which perform simple clean-ups, which are
  not in the context of other work. For example:

  * Addressing checkpatch.pl, and other trivial coding style warnings

The problem with these sorts of patches is that they often break
stuff. This driver has been stable for a long time. Do we care about
coding style issues enough that we are happy to possibly break it? Do
we want to spend time on debugging it? Probably more time than it took
to fix the checkpatch issues?

       Andrew

On Thu, 21 May 2026 14:17:08 +0200 Andrew Lunn wrote:
> The problem with these sorts of patches is that they often break
> stuff. This driver has been stable for a long time. Do we care about
> coding style issues enough that we are happy to possibly break it? Do
> we want to spend time on debugging it? Probably more time than it took
> to fix the checkpatch issues?

The way I look at it, Maciej is the maintainer and has access to HW.
If we have to keep this driver it's better to modernize it a bit.
If nothing else it shows the maintainer is willing to put in the effort.

On Thu, 21 May 2026, Jakub Kicinski wrote:

> > The problem with these sorts of patches is that they often break
> > stuff. This driver has been stable for a long time. Do we care about
> > coding style issues enough that we are happy to possibly break it? Do
> > we want to spend time on debugging it? Probably more time than it took
> > to fix the checkpatch issues?
> 
> The way I look at it, Maciej is the maintainer and has access to HW.
> If we have to keep this driver it's better to modernize it a bit.
> If nothing else it shows the maintainer is willing to put in the effort.

 FWIW I've been around with Linux for 28 years now and have no immediate 
plans to disappear, although as we all know this may happen anytime and 
eventually will anyway.

  Maciej

On Thu, 21 May 2026, Andrew Lunn wrote:

> You need to split this up. Patches to net are likely to get back
> ported, even if they don't have Fixes tags. So please add the driver
> back in net, but fixup the issues you have found in net-next.

 Sure.

> There is also an question of if we want the coding style patch or not.
> 
> https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
> 
>   1.7.4. Clean-up patches
> 
>   Netdev discourages patches which perform simple clean-ups, which are
>   not in the context of other work. For example:
> 
>   * Addressing checkpatch.pl, and other trivial coding style warnings
> 
> The problem with these sorts of patches is that they often break
> stuff. This driver has been stable for a long time. Do we care about
> coding style issues enough that we are happy to possibly break it? Do
> we want to spend time on debugging it? Probably more time than it took
> to fix the checkpatch issues?

 The cleanup was requested by Jakub; since you're both maintainers for 
this stuff would you please sort this out between you two?

 As I noted in the discussion referred I'm fine either way, and especially 
now that I've gone through the effort.  Overall I'm not a great enthusiast 
of such cleanups, as mentioned there in the context of the defxx driver, 
which IMO suffers from much worse coding style issues.  I'm even less an 
enthusiast of folding the cleanup into the revert, as it's a recipe asking 
for stuff to be missed.  Plus I do consider it important for 2/5 to apply 
cleanly on top of the original code.

 NB as I point out in the cover letter I made sure there's been no change 
to binary code produced, so I expect no fallout, and as we discussed with 
Jakub the removal of the driver broke `git blame' anyway, so there should 
be no cost associated with the cleanup.

 So as I say, may you both please weigh in pros and cons and let me know 
of the outcome?  I'll then proceed accordingly.

  Maciej

On Thu, 21 May 2026 13:45:26 +0100 (BST)
"Maciej W. Rozycki" <macro@orcam.me.uk> wrote:

> On Thu, 21 May 2026, Andrew Lunn wrote:
...
>  NB as I point out in the cover letter I made sure there's been no change 
> to binary code produced, so I expect no fallout, and as we discussed with 
> Jakub the removal of the driver broke `git blame' anyway, so there should 
> be no cost associated with the cleanup.

Can 'we' make sure that the commit that re-instates it has the git tag of the
old version in the commit message.
That lets people go back across the remove-add.

-- David

> 
>  So as I say, may you both please weigh in pros and cons and let me know 
> of the outcome?  I'll then proceed accordingly.
> 
>   Maciej
>

On Thu, 21 May 2026, David Laight wrote:

> >  NB as I point out in the cover letter I made sure there's been no change 
> > to binary code produced, so I expect no fallout, and as we discussed with 
> > Jakub the removal of the driver broke `git blame' anyway, so there should 
> > be no cost associated with the cleanup.
> 
> Can 'we' make sure that the commit that re-instates it has the git tag of the
> old version in the commit message.
> That lets people go back across the remove-add.

 It has all the usual `git revert' stuff.  Have you anything else in mind?

  Maciej

On Thu, 21 May 2026 18:49:52 +0100 (BST)
"Maciej W. Rozycki" <macro@orcam.me.uk> wrote:

> On Thu, 21 May 2026, David Laight wrote:
> 
> > >  NB as I point out in the cover letter I made sure there's been no change 
> > > to binary code produced, so I expect no fallout, and as we discussed with 
> > > Jakub the removal of the driver broke `git blame' anyway, so there should 
> > > be no cost associated with the cleanup.  
> > 
> > Can 'we' make sure that the commit that re-instates it has the git tag of the
> > old version in the commit message.
> > That lets people go back across the remove-add.  
> 
>  It has all the usual `git revert' stuff.  Have you anything else in mind?

Not sure :-)
But you were suggesting it would break 'blame'.
I know a 'delete' then 'add' gives serious grief.

-- David

> 
>   Maciej
>

On Wed, 20 May 2026 12:18:44 +0100 (BST) Maciej W. Rozycki wrote:
>  As per the previous discussions[1][2] this patch series brings the 3c509 
> driver back.  Picking up net rather than net-next as I consider it a fix 
> to accidental removal and so that any downstream users do not suffer from 
> disruption when using released kernels.
> 
>  In the course of making the coding style changes requested I have come 
> across an actual bug in transceiver type selection code, where the old 
> setting is not masked out before ORing in the new one, causing no change 
> to be actually made in a requested transition from BNC to AUI.  I guess 
> this code must have been executed exceedingly rarely, as it's always been 
> wrong ever since it was added in 2.5.42 back in 2002.
> 
>  Therefore I find it not worth backporting to stable branches, however for 
> the sake of appropriateness, in case someone downstream does want to have 
> the fix, I chose to apply it second in the series, right after the actual 
> revert and before code clean-ups.
> 
>  The remaining patches of the series should be obvious; see the respective 
> commit descriptions for details.

FWIW sashiko points out a number of potential issues:

https://sashiko.dev/#/patchset/alpine.DEB.2.21.2605201115010.1450%40angie.orcam.me.uk

On Thu, 21 May 2026, Jakub Kicinski wrote:

> >  The remaining patches of the series should be obvious; see the respective 
> > commit descriptions for details.
> 
> FWIW sashiko points out a number of potential issues:
> 
> https://sashiko.dev/#/patchset/alpine.DEB.2.21.2605201115010.1450%40angie.orcam.me.uk

 Thanks for the heads-up, I'll have a look, although it won't happen right 
away.  I may actually be able to verify SMP operation of this stuff even, 
as I've got an SMP box with free ISA slots at my remote lab and a spare 
3c509 board.  We shall see.

  Maciej