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

[Hector Martin <marcan@xxxxxxxxx>]

On 06/09/2022 20.57, Linus Walleij wrote:
> On Tue, Sep 6, 2022 at 1:36 PM Hector Martin <marcan@xxxxxxxxx> wrote:
>> On 06/09/2022 20.22, Linus Walleij wrote:
>>> On Tue, Sep 6, 2022 at 11:31 AM Mark Kettenis <mark.kettenis@xxxxxxxxx> 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.

Yes, but again, that only makes sense from the point of view of
describing hardware that exists, is useful, and could be used by the OS.

For any given platform X, if platform X does not use the secondary GPIO
controller for any service describable in the DT, then there is no point
in describing that GPIO controller. Same way ACPI tables do not describe
every single physical GPIO available on a platform, just whatever is
used by the AML.

This is the case for every existing Apple device to my knowledge.
Apple's device trees have zero references to the secondary controller's
GPIOs. It's possible they are only used internally by SMC, or they were
added to support future platforms that don't exist yet, or for debugging
purposes, or who knows.

If some day we find a use for those GPIOs, that would require a DT
change *anyway*, to describe that usage, and the controller could be
described then (we did something like that, using a GPIO that Apple
doesn't, for the interim display-backlight power control support, though
that is a temporary hack that will go away). Heck, we don't even know
what these GPIOs are connected to right now!

Ultimately, we're working with a reverse engineered platform here, and
DTs will inevitaby be incremental. But in this particular case, of
hardware that has no known useful purpose to an OS, I don't see the
point in gratuitously describing it. And besides, the way we set things
up, forward-compatible DT upgrades are trivial, and no actual user on
this platform is going to be stuck with an old DT and newer software (if
their software supports the platform properly, and that takes more than
the relatively trivial DT upgrade stuff anyway). I'm a lot more
interested in getting bindings upstreamed ASAP (so we can start
guaranteeing no backwards-compat breaks, which is important to avoid
outright breakage) than I am in trying to be exhaustive up front with
device instances. It's perfectly fine to say that users have to upgrade
both their DTs and kernels to get newer hardware support, on these
platforms.

- Hector