On Fri, Feb 12, 2021 at 12:54 PM Enrico Weigelt, metux IT consult
[off-list ref] wrote:

On 12.02.21 10:58, Linus Walleij wrote:

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

I understand. I have had the same problem with trying to fix 96boards
mezzanines.

I also tried to sidestep the DT overlays, and it was generally disliked.
The DT people have made up their mind that overlays is what they
want to use for this type of stuff.

Yours,
Linus Walleij