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

[Bastien Curutchet]

On 3/9/26 9:54 PM, Vladimir Oltean wrote:
> 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@xxxxxxx/
> > 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.

I, more or less, managed to fit this PTP support in the current 
framework, but the next series I prepared to add periodic output support 
is full of is_ksz8463() branches. So I think that I'll go with what you 
suggested and try to move the KSZ8463 support in the ksz8995.c driver. 
It will probably be cleaner this way.

TBH I'm a bit lost with all these KSZ variants but IIUC KSZ8463 and 
KSZ8995 both belong to the 'old generation' of the hardware. Maybe a 
good split would be to have these old switches in the ksz8995.c driver 
and keep the rest under ksz_common infra.


Best regards,
BAstein