linux-kernel - 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-next>] [day] [month] [year] [list]

Date:   Mon,  8 Feb 2021 23:21:51 +0100
From:   "Enrico Weigelt, metux IT consult" <info@...ux.net>
To:     linux-kernel@...r.kernel.org
Cc:     rafael@...nel.org, info@...ux.net, linus.walleij@...aro.org,
        bgolaszewski@...libre.com, robh+dt@...nel.org,
        frowand.list@...il.com, pantelis.antoniou@...sulko.com,
        linux-gpio@...r.kernel.org, devicetree@...r.kernel.org
Subject: RFC: oftree based setup of composite board devices

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.

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.

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

Yet some drawbacks of the current implementation:

 * individual FDT's can't be modularized yet (IMHO, we don't have DMI-based
   modprobing anyways)
 * can't reconfigure or attach to devices outside the individual DT's
   (eg. probed by PCI, etc)

have fun,

--mtx