[PATCH 4/6] platform/apple: Add new Apple Mac SMC driver

[Lee Jones]

On Sat, 29 Oct 2022, Hector Martin wrote:

> On 09/09/2022 16.50, Lee Jones wrote:
> >> What's the point of just having effectively an array of mfd_cell and
> >> wrappers to call into the mfd core in the drivers/mfd/ tree and the
> >> rest of the driver elsewhere?
> > 
> > They should be separate drivers, with MFD registering the Platform.
> 
> Why? What purpose does this serve? I'm still confused. There's one
> parent device, which provides services to the child devices. There isn't
> one parent device which wraps a platform service which is used by
> children. This makes no sense. The platform device is the root, if it
> exposes MFD services, then it has to be in that direction, not the other
> way around.
> 
> Look at how this patch series is architected. There is smc_core.c, which
> implements SMC helpers and wrappers on top of a generic backend, and
> registers with the MFD subsystem. And then there is smc_rtkit.c which is
> the actual platform implementation on top of the RTKit framework, and is
> the actual platform device entry point.
> 
> A priori, the only thing that makes sense to me right now would be to
> move smc_core.c into drivers/mfd, and leave smc_rtkit.c in platform.
> That way the mfd registration would be in drivers/mfd (as would be the
> services offered to sub-drivers), but the actual backend implementation
> would be in platform/ (and there would eventually be others, e.g. at
> least two more for x86 systems). That does mean that the driver entry
> point will be in platform/, with mfd/smc_core.c serving as effectively
> library code to plumb in the mfd stuff into one of several possible
> platform devices. Would that work for you?

Yes, sounds sensible.  However, keep all of the abstraction craziness
somewhere else and fetch and share all of your shared resources from
the MFD (SMC) driver.

-- 
Lee Jones [李琼斯]