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

[Ivan Vecera]

On 11. 04. 25 12:57 dop., Jakub Kicinski wrote:
> On Thu, 10 Apr 2025 11:18:24 +0200 Ivan Vecera wrote:
> > 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).
>
> Okay, my understanding was that if you need to reuse the component
> drivers across multiple different SoCs or devices, and there is no
> "natural" bus then MFD is the go to. OTOH using MFD as a software
> abstraction/to organize your code is a pointless complication.
> (We're going to merge the MFD parts via Lee's tree and the all actual
> drivers via netdev?) Admittedly that's just my feeling and not based
> on any real info or experience. I defer to Lee and others to pass
> judgment.

I followed an example of rsmu mfd driver that provides an access to the 
bus (i2c/spi) via regmap and ptp_clockmatrix platform driver for the PTP 
functionality of the RSMU chip. The ptp_clockmatrix device is also 
instantiated only from rsmu mfd and it is not shared by multiple mfd 
drivers.

I.