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

[Jakub Kicinski <kuba@kernel.org>]

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.