On Tue, Sep 6, 2022 at 3:28 PM Hector Martin <marcan@xxxxxxxxx> wrote: > On 06/09/2022 20.57, Linus Walleij wrote: > > On Tue, Sep 6, 2022 at 1:36 PM Hector Martin <marcan@xxxxxxxxx> wrote: > > 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. Good point. I don't know what ambition DT should have here. If there is a discrete component on I2C for example, we tend to describe it fully, this kind of stuff with misc "dark silicon" didn't exist when DT was first conceived. > 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. (...) That's OK, I think the patch series is good enough as it is and should be merged, so I have added my Reviewed-by. I think the world is a better place with support for Apple silicon being developed in-tree. > 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. I agree. Yours, Linus Walleij
