linux-kernel - Re: [Q] devicetree overlays

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 27 Apr 2020 15:26:01 -0500
From:   Frank Rowand <frowand.list@...il.com>
To:     Sven Van Asbroeck <thesven73@...il.com>,
        Pantelis Antoniou <pantelis.antoniou@...sulko.com>
Cc:     David Airlie <airlied@...ux.ie>, Daniel Vetter <daniel@...ll.ch>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [Q] devicetree overlays

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
>