Re: RFC: oftree based setup of composite board devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10.02.21 11:30, Andy Shevchenko wrote:

Hi,

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?

please tell me more, how ACPI and DT can already work together ?

You already know my apu board driver - that's my first example usecase.

There're few things I don't know how to solve w/ overlays:

* match rules shall be inside the DTS
* future match rules shall also check for bios versions etc
* adding new boards shall be possible by just adding another DTS to
  the tree (not a whole module)
* supporting several board variants (w/ small differences) by one DTS
* sometimes existing devices (eg. enumerated by acpi) need to be kicked
  out (buggy firmware, ...)
* can't rely on any special userland tweaks

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?

In general yes, but of course you need drivers for them. Sometimes those
devices are composites of other devices, wired up in some special way.
Traditionally, we'd need to write a special driver that just don't do
much more than instantiating other drivers.

Those things could be expressed via DTS, so we don't need to write
individual drivers anymore.

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'`

Shame on me, I really must have missed that all the time, thanks for the
hint.

But that has some drawbacks in my case:

* need to split the information into several places (instead of having
  all in one DTS)
* need to have one separate module board, or merge the dmi tables.

My goal is having everything that describes a board into one DTS (source) file.


--mtx

--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@xxxxxxxxx -- +49-151-27565287



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux