lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 14 Feb 2021 19:18:55 -0600
From:   Frank Rowand <>
To:     "Enrico Weigelt, metux IT consult" <>,
        Linus Walleij <>,
        "Enrico Weigelt, metux IT consult" <>
Cc:     "" <>,
        "Rafael J. Wysocki" <>,
        Bartosz Golaszewski <>,
        Rob Herring <>,
        Pantelis Antoniou <>,
        "open list:GPIO SUBSYSTEM" <>,
        <>, Hans de Goede <>
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


> 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