lkml.org 
[lkml]   [2020]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Q] devicetree overlays
From
Date
On 4/16/20 9:46 AM, Sven Van Asbroeck wrote:
> Pantelis, Frank,
>
> A quick question about the state of devicetree overlays. There don't seem to
> be many in-kernel overlay users (rcar and fpga only?). Does it make sense for
> new projects to use them?

Run time overlay apply and run time overlay remove from user space are not
supported in the mainline kernel.

rcar is grandfathered in. fpga use is very careful and done in a somewhat
restricted manner.

There is a desire for run time overlay apply and run time overlay remove
to become more complete and more robust. Improvements are slowly moving
forward.

The best way to use overlays at the moment is to apply them before booting
the Linux kernel, such as having u-boot apply them.

My opinion is that run time overlay apply and run time overlay remove will
always be more fragile and less well supported than pre-boot overlay apply,
and thus run time usage should be avoided if possible.

You can read more details about the status and direction of overlays at:

https://elinux.org/Frank%27s_Evolving_Overlay_Thoughts


>
> My situation is this: I have hardware which consists of several modules.
> Knowledge about the type and location of these modules is located in an
> on-board eeprom.

Does the eeprom provide an ID, from which an overlay blob can be inferred?
Or is "the type and location of these modules" more explicit, such as
path of the blob in a filesystem?

>
> So now I need to assemble a devicetree, by puzzling various 'blobs' together.
> This could be done in the bootloader,

Do this, if at all reasonably possible.

> but also by a rcar-like driver, which
> queries the eeprom and inserts devicetree fragments/overlays into a live kernel.

Don't do this.

>
> A couple of questions:
> - are devicetree overlays here to stay? (given that there are 2 in-kernel users)

I expect devicetree overlay run time support to remain for fpga. I am optimistic
that we will add support for other use cases in an incremental roll out of
functionality. But this is not happening quickly.


> - does it make sense to solve the modular devicetree problem in a rcar-like
> fashion?

No.

> - is there perhaps a more canonical / idiomatic way to solve this?

Yes, apply the overlays before booting.

>
> Sven
>

\
 
 \ /
  Last update: 2020-04-27 22:26    [W:0.092 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site