Message-ID: <c5ed2b27-21a2-5a07-8dd9-e080f9a6cd98@metux.net>
Date:   Fri, 12 Feb 2021 12:54:50 +0100
From:   "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To:     Linus Walleij <linus.walleij@...aro.org>,
        "Enrico Weigelt, metux IT consult" <info@...ux.net>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, Hans de Goede <hdegoede@...hat.com>
Subject: Re: [RFC PATCH 11/12] platform/x86: skeleton for oftree based board
 device initialization

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@...ux.net -- +49-151-27565287

Powered by blists - more mailing lists