Re: [PATCH net-next v6 1/9] net: dsa: microchip: Add support for KSZ8463 global irq

[Vladimir Oltean <olteanv@gmail.com>]

On Mon, Mar 09, 2026 at 01:54:28PM +0100, Bastien Curutchet wrote:
> I have a new iteration ready. It uses only the high byte of the interrupt
> registers for the KSZ8463, which keeps unchanged the current 8-bit accesses
> logic.
> 
> Shall I send it ? Or would you like more time to think/discuss about whether
> we should split ksz_common into several drivers ?

"Send it", you mean on Thursday after the weekly 'net' -> 'net-next'
merge so it doesn't conflict with your "net: dsa: microchip: Fix error
path in PTP IRQ setup" change, right?

I don't know. I have to say that I may be partly responsible for guiding
Arun Ramadoss a few years ago towards unifying all ksz_switch drivers
under a single dsa_switch_ops, and that doesn't seem to have been a
great move, given their amount of differences.

Prior to Arun Ramadoss' refactoring such that lan937x could come in and
make use of ksz9477 code, we had two distinct core drivers: ksz8795.c
and ksz9477.c.  Having checked out an old kernel before his changes,
I'm not sure why I was so blinded by all the false code sharing hidden
behind dev_ops that was already there.  If you factor out the MIB worker
thread and other inconsequential small driver things like that, they're
perfectly separate hardware architectures which could use perfectly
isolated drivers with only minimal duplication, and we possibly wouldn't
even need the 8/16/32 regmap tables.

"Resources global in one family and per-port in another" is a recurring
theme, and the inability to have clearly distinct code paths that handle
these clearly distinct hardware architectures is a problem. I'm not sure
of the extent to which I was aware of it when making those suggestions
to Arun. I can recall this thread that indicates a still unsolved, to
this day, problem which was caused by the desire to have a unified driver:
https://patchwork.kernel.org/project/netdevbpf/patch/20230316161250.3286055-3-vladimir.oltean@nxp.com/

I don't have a good plan, but the current state of affairs is not your
fault, and I don't want it to stop you from making progress with the
KSZ8463 PTP support. Maybe we can continue discussing a clean line for a
KSZ8 (and maybe even KSZ8463) split where the code duplication would be
minimal, with further input from Tristram.