On 12.02.21 10:58, Linus Walleij wrote: Hi,
I think Intel people often take the stance that the ACPI DSDT (or whatever) needs to be fixed.
It should, actually board/firmware vendors should think more carefully and do it right in the first place. But reality is different. And firmware upgrade often is anything but easy (as soon as we leave the field of average Joh Doe's home PC)
If the usecase is to explicitly work around deployed firmware that cannot and will not be upgraded/fixed by describing the hardware using DT instead, based on just the DMI ID then we should spell that out explicitly.
Okay, maybe I should have stated this more clearly. OTOH, the scope is also a little bit greater: certain external cards that don't need much special handling for the card itself, just enumerate devices (and connections between them) using existing drivers. That's a pretty common scenario in industrial backplane systems, where we have lots of different (even application specific) cards, usually composed of standard chips, that can be identified by some ID, but cannot describe themselves. We have to write lots of specific drivers for them, usually just for instantiating existing drivers. (we rarely see such code going towards mainline). A similar case (mainlined) seems to be the RCAR display unit - they're using dt overlays that are built into the driver and applied by it based on the detected DU at runtime. RCAR seems to be a pure DT platform, so that's an obvious move. APU2/3/4 is ACPI based, so I went in a different direction - but I'm now investigating how to make DT overlays work on an ACPI platform (eg. needs some initial nodes, ...) In case that's successful, I'll rework my RFC to use overlays, and it will become much smaller (my oftree core changes then won't be necessary anymore).
It feels a bit like fixing a problem using a different hardware description just because we can. Look in drivers/gpio/gpiolib-acpi.c table gpiolib_acpi_quirks[]. It's just an example how this is fixed using fine granular ACPI-specific mechanisms at several places in the kernel instead of just tossing out the whole description and redoing it in device tree.
I'm quite reluctant to put everything in there. Theoretically, for apu case, I could prevent enumerating the incomplete gpios there, but the actual driver setup still remains (certainly don't wanna put that into such a global place). But the original problem of having to write so much code for just instantiating generic drivers remains. And distributing knowledge of certain devices over several places doesn't feel like a good idea to me. --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@xxxxxxxxx -- +49-151-27565287
