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

[Hector Martin <marcan@marcan.st>]

On 08/09/2022 21.31, Lee Jones wrote:
> On Thu, 08 Sep 2022, Hector Martin wrote:
>> But it's not exactly your
>> typical MFD device (it's not even a separate chip, it's part of the main
>> SoC), so I'm not sure if it really belongs in mfd/ from an
>> organizational standpoint?
> 
> There is a strong argument for all SoCs to be classed as (massive)
> MFDs.  However seeing as they represent more of a whole platform,
> rather than an add-on chip, we have had the sense to represent them
> differently.  Some such submissions I have made explicit requests to be
> moved form drivers/mfd *into* drivers/platform in the past.
> 
> Most SoCs are solely represented in DT, omitting the requirement for
> subsequent device registration.  Have you considered this?  If so, why
> does this not suit your use-case?

This driver and a subset of its sub-drivers are intended to generalize
(via different backends, but no changes to sub-drivers) to legacy and T2
Mac platforms, eventually superseding applesmc (which is in hwmon/
because it started out as that, but has now grown random features and is
quite a mess). Those are are Intel/UEFI machines and not DT platforms,
and on those the SMC is actually a separate chip in some form (much like
an EC).

> The long and the short of it is; if you wish to treat this device, or
> at least a section of it, as a type of MFD, then please draft that
> part of it as an MFD driver, residing in drivers/mfd.  If it's "not
> really an MFD", then find another way to represent the conglomeration
> please.
> 
> If the MFD route is the best, then you can register each of the
> devices, including the *-core from drivers/mfd.  Grep for "cross-ec"
> as a relatively recently good example.

I think cros-ec is similar enough, yeah. As long as you don't mind
having the core codebase in mfd/ (4 files: core, rtkit backend, and
future T2 and legacy backends) we can do that.

- Hector