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

[Bastien Curutchet]

Hi all,

On 3/13/26 6:29 PM, Tristram.Ha@xxxxxxxxxxxxx wrote:
> > On Thu, Mar 12, 2026 at 03:45:26PM +0200, Vladimir Oltean wrote:
> > > Thanks for the comment. I took a deeper look at the ksz_switch common
> > > driver and I've started working on some patches. I'll return when
> > > they're more or less ready.
> >
> > So if the common ksz_switch were to remain preferable, we still have the
> > problem that it's very cluttered/abstract and impossible to follow and
> > ensure correctness/lack of regressions for other hardware.
> >
> > Bastien, Tristram, I've tried to address that very particular issue by
> > giving KSZ8463 its very own dsa_switch_ops structure, which it doesn't
> > have to share with anyone else.
> >
> > I have no hardware to test, but some patches are here:
> > https://github.com/vladimiroltean/linux/tree/ksz_separate_dsa_switch_ops
> >
> > Do you think this would be useful? For now I've created a common ksz8_setup(),
> > but it can be further split into whatever granularity is required for
> > ksz8463 to have its own IRQ domain operations.
> > > > One could conceivable walk this alternative route of having independent
> > per-family dsa_switch_ops and only call ksz_common.c when something is
> > truly common ad infinitum. We could use it to get rid of dev->info->regs[],
> > dev->info->xmii_ctrl1, etc. We could further give ksz8463 a separate
> > ksz_ptp_clock_register() implementation with different PTP operations,
> > to address Bastien's concern. I stopped at only 19 patches though :-/
> >
> > What do you think, is this direction something worth exploring? Does it
> > help with the PTP IRQ differences here?
>
> What I did was to simulate the port interrupt mechanism used by KSZ9477
> and LAN937X switch families.  I think that does minimum disruption to the
> original code.  That new interrupt code also allows interrupt use for
> KSZ8863, KSZ8895, and KSZ8795.  I provided that code to Bastien to test.

I took a look at Tristram's patches, they should work but I'm not a big 
fan of emulating other hardware behavior to fit the existing driver. I'd 
rather go with Vladimir's approach.

Thanks for these patches Vladimir, they provide a clear path forward for 
the remaining work. I'll rebase my work on top of them. I'll implement a 
ksz8463_setup() function to match the KSZ interrupt scheme before adding 
PTP support.

And, indeed, implementing a ksz8463_ptp_clock_register() should then 
make it easier to add the periodic output support I plan to implement 
afterwards.


Best regards,
Bastien