On 2/12/21 5:54 AM, Enrico Weigelt, metux IT consult wrote:

On 12.02.21 10:58, Linus Walleij wrote:

Hi,

quoted

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)

quoted

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

The RCAR use of overlays that are built into the driver are a known
pattern that is explicitly not to be repeated.  The driver has been
granted a grandfathered in status, thus an exception as long as
needed.

-Frank

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).

quoted

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