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

[Bastien Curutchet <bastien.curutchet@bootlin.com>]

Hi all,

On 3/13/26 6:29 PM, Tristram.Ha@microchip.com 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