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

Ivan Vecera
2025-04-10T09:18:37Z

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