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
