lkml.org 
[lkml]   [2021]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC PATCH 11/12] platform/x86: skeleton for oftree based board device initialization
    From
    Date
    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
    >

    \
     
     \ /
      Last update: 2021-02-15 02:20    [W:2.368 / U:0.272 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site