devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: frowand.list@gmail.com
Cc: robh@kernel.org, grant.likely@secretlab.ca,
	pantelis.antoniou@konsulko.com, dimitrysh@google.com,
	john.stultz@linaro.org, nicolas.dechesne@linaro.org,
	devicetree@vger.kernel.org, daniel.thompson@linaro.org,
	loic.poulain@linaro.org
Subject: Re: Revisiting Devicetree Overlay Manager
Date: Wed, 25 Apr 2018 13:04:42 +0530	[thread overview]
Message-ID: <20180425073442.e4pikxonhqr5r7cw@linaro.org> (raw)
In-Reply-To: <20180419143804.brdgezjaxqalarum@linaro.org>

Hi Frank,

Did you had time to look into this? Especially I'd like to hear your
opinion on the first pain point I have mentioned. I can understand
that the whole point on introducing the of_overlay_fdt_apply() API
is to remove the duplication of overlay FDT unflattening, but do you have
any idea of how we can make this API work with overlay nodes appended
to the base DTB?

Thanks,
Mani

On Thu, Apr 19, 2018 at 08:08:04PM +0530, Manivannan Sadhasivam wrote:
> Hello Everyone,
> 
> I have just started working on the Devicetree Overlay Manager support in
> kernel. The idea is to merge overlays at boot time specified via some
> interface like kernel command line. The motivation for this work comes from
> Overlay Manager [1] submitted by John last year. The mechanism which I have
> been working on is an extension to John's work. It focusses on addressing
> Rob's comments on the Overlay Manager which involves having multiple ways
> to load overlays.
> 
> Proposal:
> =========
> 
> 1. Pass all devicetree overlays via following methods:
>    - Overlays appended to base DTB
>    - Individual overlays built into kernel as firmware blobs
>    - Any other ways?
> 
> 2. Specify overlays to load via kernel command line as below:
>    - overlay_mgr.overlays=<overlay1,overlay2,...>
> 
> 3. Merge only the specified overlays during boot time. First look for the
> overlay in the base DTB. If it is found, just apply it, else defer to firmware
> load approach.
> 
> The Overlay Manager code is expected to be very simple and will just do the
> above mentioned work. Later on, it will be extended to support dynamic
> modification of overlays from userspace with some additional security
> features like having a property listed in the base devicetree for only
> allowing changes to the current node and its child nodes, etc...
> 
> Pain Points:
> ============
> 
> 1. Starting from 4.17 we don't have any API exposed from DT core to merge
> individual devicetree nodes. We only have of_overlay_fdt_apply() function
> which takes the whole FDT. This will work very well for the firmware approach
> since we will pass the overlays blobs but not for overlays appended to base DTB,
> where we will pass individual overlay nodes.
> 
> 2. Using firmware load method will force us to have this Overlay Manager code
> at late_initcall level since firmware class exists only in fs_inticall level,
> which might be too late for some devices.
> 
> 3. This whole approach is not expected to work very well (still not yet tested)
> on DSI based devices since it needs to be present at very early during boot
> process.
> 
> The Overlay Manager propsed here will be board agnostic and it should work on
> all platforms supporting DT. This will be a _very_ useful feature for the
> development boards such as 96Boards, Raspberry Pi, BBB etc... and also for
> production ready devices.
> 
> So, I'd like to hear suggestions/feedbacks for the above mentioned proposal &
> pain points and hope to land the most awaited feature in kernel.
> 
> Regards,
> Mani
> 
> [1] https://lkml.org/lkml/2017/10/10/20

  reply	other threads:[~2018-04-25  7:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-19 14:38 Revisiting Devicetree Overlay Manager Manivannan Sadhasivam
2018-04-25  7:34 ` Manivannan Sadhasivam [this message]
2018-04-25 17:26   ` Frank Rowand
2018-05-18  3:53     ` Frank Rowand
2018-05-22 19:32       ` Alan Tull
2018-05-22 21:13         ` Frank Rowand
2018-04-25 17:30 ` John Stultz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180425073442.e4pikxonhqr5r7cw@linaro.org \
    --to=manivannan.sadhasivam@linaro.org \
    --cc=daniel.thompson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dimitrysh@google.com \
    --cc=frowand.list@gmail.com \
    --cc=grant.likely@secretlab.ca \
    --cc=john.stultz@linaro.org \
    --cc=loic.poulain@linaro.org \
    --cc=nicolas.dechesne@linaro.org \
    --cc=pantelis.antoniou@konsulko.com \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).