Date:   Sun, 14 Feb 2021 19:18:55 -0600
From:   Frank Rowand <frowand.list@...il.com>
To:     "Enrico Weigelt, metux IT consult" <lkml@...ux.net>,
        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>,
        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 2/12/21 5:54 AM, Enrico Weigelt, metux IT consult wrote:
> 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

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

Powered by blists - more mailing lists