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

[Hector Martin <marcan@xxxxxxxxx>]

On 08/09/2022 22.36, Lee Jones wrote:
> On Thu, 08 Sep 2022, Hector Martin wrote:
> 
>> On 08/09/2022 21.31, Lee Jones wrote:
>>> 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.
> 
> That's actually not what I'm suggesting.
> 
> You *only* need to move the subsequent-device-registration handling
> into drivers/mfd.  The remainder really should be treated as Platform
> (not to be confused with Arch Platform) code and should reside in
> drivers/platform.  Just as we do with cros-ec.

That's... an interesting approach. Is the code in drivers/mfd supposed
to be a subdevice itself? That seems to be what's going on with
cros_ec_dev.c, but do we really need that layer of indirection? 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?

- Hector