Re: [PATCH net-next v4 5/8] mfd: zl3073x: Add functions to work with register mailboxes

[Lee Jones]

On Thu, 24 Apr 2025, Ivan Vecera wrote:

> 
> 
> On 24. 04. 25 9:29 odp., Andrew Lunn wrote:
> > > Yes, PHC (PTP) sub-driver is using mailboxes as well. Gpio as well for some
> > > initial configuration.
> > 
> > O.K, so the mailbox code needs sharing. The question is, where do you
> > put it.
> 
> This is crucial question... If I put the MB API into DPLL sub-driver
> then PTP sub-driver will depend on it. Potential GPIO sub-driver as
> well.
> 
> There could be some special library module to provide this for
> sub-drivers but is this what we want? And if so where to put it?

MFD is designed to take potentially large, monolithic devices and split
them up into smaller, more organised chunks, then Linusify them.  This
way, area experts (subsystem maintainers) get to concern themselves only
with the remit to which they are most specialised / knowledgable.  MFD
will handle how each of these areas are divided up and create all of the
shared resources for them.  On the odd occasion it will also provide a
_small_ API that the children can use to talk to the parent device.

However .... some devices, like yours, demand an API which is too
complex to reside in the MFD subsystem itself.  This is not the first
time this has happened and I doubt it will be the last.  My first
recommendation is usually to place all of the comms in drivers/platform,
since, at least in my own mind, if a complex API is required, then the
device has become almost platform-like.  There are lots of examples of
H/W comm APIs in there already for you to peruse.

-- 
Lee Jones [李琼斯]