Re: [PATCH v2 00/14] Add Microchip ZL3073x support (part 1)

[Ivan Vecera]

On 10. 04. 25 2:17 dop., Jakub Kicinski wrote:
> On Wed,  9 Apr 2025 16:42:36 +0200 Ivan Vecera wrote:
> > Add support for Microchip Azurite DPLL/PTP/SyncE chip family that
> > provides DPLL and PTP functionality. This series bring first part
> > that adds the common MFD driver that provides an access to the bus
> > that can be either I2C or SPI.
> >
> > The next series will bring the DPLL driver that will covers DPLL
> > functionality. And another ones will bring PTP driver and flashing
> > capability via devlink.
> >
> > Testing was done by myself and by Prathosh Satish on Microchip EDS2
> > development board with ZL30732 DPLL chip connected over I2C bus.
>
> The DPLL here is for timing, right? Not digital logic?
> After a brief glance I'm wondering why mfd, PHC + DPLL
> is a pretty common combo. Am I missing something?

Well, you are right, this is not pretty common combo right now. But how 
many DPLL implementations we have now in kernel?

There are 3 mlx5, ice and ptp_ocp. The first two are ethernet NIC 
drivers that re-expose (translate) DPLL API provided by their firmwares 
and the 3rd timecard that acts primarily as PTP clock.

Azurite is primarly the DPLL chip with multiple DPLL channels and one of 
its use-case is time synchronization or signal synchronization. Other 
one can be PTP clock and even GPIO controller where some of input or 
output pins can be configured not to receive or send periodic signal but 
can act is GPIO inputs or outputs (depends on wiring and usage).

So I have taken an approach to have common MFD driver that provides a 
synchronized access to device registers and to have another drivers for 
particular functionality in well bounded manner (DPLL sub-device (MFD 
cell) for each DPLL channel, PTP cell for channel that is configured to 
provide PTP clock and potentially GPIO controller cell but this is 
out-of-scope now).

Btw. I would be interesting to see a NIC that just exposes an access to 
I2C bus (implements I2C read/write by NIC firmware) instead of exposing 
complete DPLL API from the firmware. Just an idea.

Thanks,
Ivan