linux-kernel - Re: [RFC PATCH 11/12] platform/x86: skeleton for oftree based board device initialization

lists.openwall.net		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]

Message-ID: <CAHp75Vd9ui5bttkrG0KQLqecS_-5m_mPQHfdawpLhx7+YObrYQ@mail.gmail.com>
Date:   Wed, 10 Feb 2021 12:32:39 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     "Enrico Weigelt, metux IT consult" <info@...ux.net>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Linus Walleij <linus.walleij@...aro.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>,
        devicetree <devicetree@...r.kernel.org>
Subject: Re: [RFC PATCH 11/12] platform/x86: skeleton for oftree based board
 device initialization

On Tue, Feb 9, 2021 at 12:27 AM Enrico Weigelt, metux IT consult
<info@...ux.net> wrote:
>
> Lots of boards have extra devices that can't be fully probed via bus'es
> (like PCI) or generic firmware mechanisms like ACPI. Often those capabilities
> are just partial or even highly depend on firmware version.
>
> Instead of hand-writing board specific drivers merely for the correct
> initialization / parameterization of generic drivers, hereby introducing
> a generic mechanism, using the already well supported oftree.
>
> These oftrees are compiled into the driver, which first tries to match
> machine identifications (eg. DMI strings) against rules defined in the
> individual oftrees, and on success, probes the devices that are defined
> by them.
>
> For the time being, we just support matching on DMI_BOARD_NAME and
> DMI_SYS_VENDOR - other criteria, even bus- or ACPI-id's can be added later,
> when needed.

This is weird and seems it missed the fact of the DMI based modprobe
mechanism that the kernel has for ages.

-- 
With Best Regards,
Andy Shevchenko