Messages in this thread - First message in thread
- "Enrico Weigelt, metux IT consult"
- "Enrico Weigelt, metux IT consult"
- "Enrico Weigelt, metux IT consult"
- "Enrico Weigelt, metux IT consult"
- "Enrico Weigelt, metux IT consult"
- "Enrico Weigelt, metux IT consult"
- "Enrico Weigelt, metux IT consult"
- "Enrico Weigelt, metux IT consult"
- "Enrico Weigelt, metux IT consult"
- "Enrico Weigelt, metux IT consult"
- "Enrico Weigelt, metux IT consult"
- "Enrico Weigelt, metux IT consult"
- "Enrico Weigelt, metux IT consult"
- Rob Herring
- Andy Shevchenko
|  | | From | Andy Shevchenko <> | Date | Wed, 10 Feb 2021 12:30:40 +0200 | 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@metux.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
|  |