[lkml]   [2021]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RFC: oftree based setup of composite board devices
On Tue, Feb 9, 2021 at 12:25 AM Enrico Weigelt, metux IT consult
<> 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)

`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

 \ /
  Last update: 2021-02-10 11:38    [W:0.390 / U:1.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site