Re: [PATCH 1/6] dt-bindings: mfd: add binding for Apple Mac System Management Controller

[Linus Walleij <linus.walleij@linaro.org>]

On Tue, Sep 6, 2022 at 1:36 PM Hector Martin <marcan@marcan.st> wrote:
> On 06/09/2022 20.22, Linus Walleij wrote:
> > On Tue, Sep 6, 2022 at 11:31 AM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >
> >> Another argument for having sub-nodes is that the firmware actually
> >> exposes *two* GPIO controllers.  For now we only support the "master"
> >> PMU GPIOs, but there also is a "slave" PMU GPIO controller that uses a
> >> separate set of SMC "keys".  We currently don't need any of the pins
> >> on the "slave", so we don't expose it in the DT yet.
> >
> > That sounds backward, like we don't expose device X as DT node
> > because $OS doesn't use it yet. DT should just expose (by nodes or
> > other ways) all hardware that exist or at least all hardware we know
> > about no matter what $OS is using.
>
> How so? The are piles and piles of unused hardware not exposed in the
> DT, and piles and piles of hardware that will be used but we haven't
> figured out how to do it yet, so it's not exposed. For example, we know
> there are like 8 or so UARTs, but we don't define them in the DT because
> they are not connected to anything on any existing device and we don't
> need them. Apple does the same thing in their DTs (only used hardware is
> defined).
>
> I don't really see the point of exposing a GPIO controller when we don't
> actually do anything with the pins yet, and might never do so. Having
> drivers bind and stay unused just increases the amount of code running
> without any ultimate purpose, so why do it? It's not like any other OS
> would use the hardware either - GPIOs are only useful if they are
> referenced in the DT for something, and we don't have anything that
> would reference these.

This comes from the FDT background in OpenFirmware, and there is
definitely a timeline perspective (also called "waterfall model") in that
line of thinking: a DT is written that describes the hardware and flashed
into the BIOS and never changed, then the operating system is
implemented at a later point. This is how e.g. the PC ACPI BIOS tables
are also thinking about themselves.

Of course the world does not work like that, but as a standard process
DT and ACPI works with the same ambition as any such process: slowly and
impersonal, like the planets, or the plants.

The ambition that a DT should always remain backward compatible
comes from the same historical root and reasoning.

Any agile development or (heh) hardware discovers through reverse
engineering will of course drive a truck through that line of thinking.

Realistically, use the same approach as with everything else, I like the
IETF motto "rough consensus and running code", any ambition taken too
far will just stifle development. So I'd say make an honest effort to
resonably describe the nodes we see will be useful in the foreseeable
future.

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel