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

Lee Jones lee at kernel.org
Thu Sep 8 06:36:26 PDT 2022


On Thu, 08 Sep 2022, Hector Martin wrote:

> 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).

Understood.  Fair point.

> > 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.

-- 
Lee Jones [李琼斯]



More information about the linux-arm-kernel mailing list