linux-kernel - Re: RFC: oftree based setup of composite board devices

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]

Date:   Wed, 10 Feb 2021 12:30:40 +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: oftree based setup of composite board devices

On Tue, Feb 9, 2021 at 12:25 AM Enrico Weigelt, metux IT consult
<info@...ux.net> wrote:
>
> Hello folks,
>
> here's an RFC for using compiled-in dtb's for initializing board devices
> that can't be probed via bus'es or firmware.
>
> Use cases are boards with non-oftree firmware (ACPI, etc) where certain
> platform devices can't be directly enumerated via firmware. Traditionally
> we had to write board specific drivers that check for board identification
> (DMI strings, etc), then initialize the actual devices and their links
> (eg. gpio<->leds/buttons, ...). Often this can be expressed just by DT.

In ACPI we support DT compatible strings, and we support overlays for
a long time. Would it work for you?

> This patch queue does a bunch of preparations in oftree code, so we can
> support multiple fully independent DT's (not using DT overlays). And then
> adds a generic driver parses compiled-in fdt blobs, checks for mathing
> DMI strings and initializes the devices. As an example, the last patch
> adds an alternative implementation for the PC engines APU2/3/4 board
> family based on device tree.

Sounds weird, but let's see...

> The approach can be easily be extended to other kinds of composite devices,
> eg. PCI cards or USB dongles.

What do you mean? PCI and USB are self-enumerated. What's wrong with them?

> Yet some drawbacks of the current implementation:
>
>  * individual FDT's can't be modularized yet (IMHO, we don't have DMI-based
>    modprobing anyways)

What?! https://lwn.net/Articles/233385/
`git grep -n 'MODULE_DEVICE_TABLE(dmi'`

>  * can't reconfigure or attach to devices outside the individual DT's
>    (eg. probed by PCI, etc)


-- 
With Best Regards,
Andy Shevchenko