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 [李琼斯]