All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Frank Rowand <frowand.list@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Masahiro Yamada <masahiroy@kernel.org>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Bill Mills <bill.mills@linaro.org>,
	anmar.oueja@linaro.org
Subject: Re: [PATCH V5 5/5] of: unittest: Statically apply overlays using fdtoverlay
Date: Thu, 21 Jan 2021 17:34:38 +1100	[thread overview]
Message-ID: <20210121063438.GJ5174@yekko.fritz.box> (raw)
In-Reply-To: <20210121053426.4dw5oqz7qb4y7hvm@vireshk-i7>

[-- Attachment #1: Type: text/plain, Size: 1862 bytes --]

On Thu, Jan 21, 2021 at 11:04:26AM +0530, Viresh Kumar wrote:
> On 20-01-21, 23:14, Frank Rowand wrote:
> > It is a convenient FDT to use because it provides the frame that the overlays
> > require to be applied.  It is fortunate that fdtoverlay does not reject the use
> > of an FDT with overlay metadata as the base blob.
> 
> > This is probably a good idea instead of depending on the leniency of fdtoverlay.
> 
> I believe fdtoverlay allows that intentionally, that would be required
> for the cases where we have a hierarchy of extension boards or
> overlays.

Um.. no.

> A platform can have a base dtb (with /plugin/;), then we can have an
> overlay (1) for an extension board (with /plugin/;) and then an
> overlay (2) for an extension board for the previous extension board.
> 
> In such a case overlay-(2) can't be applied directly to the base dtb
> as it may not find all the nodes it is trying to update. And so
> overlay-(2) needs to be applied to overlay-(1) and then the output of
> this can be applied to the base dtb.

No, this is the wrong way around.  The expected operation here is that
you apply overlay (1) to the base tree, giving you, say, output1.dtb.
output1.dtb is (effectively) a base tree itself, to which you can then
apply overlay-(2).

What you're talking about is "merging" overlays: combingin overlay (1)
and (2) into overlay-(X) which would have the same effect applied to
base.dtb as (1) and (2) applied in sequence.  Merging overlays is
something that could make sense, but fdtoverlay will not do it at
present.

> This is very similar to what I tried with the intermediate.dtb
> earlier.
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2021-01-21  6:45 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-20  7:06 [PATCH V5 0/5] dt: build overlays Viresh Kumar
2021-01-20  7:06 ` [PATCH V5 1/5] scripts: dtc: Fetch fdtoverlay.c from external DTC project Viresh Kumar
2021-01-20  7:06 ` [PATCH V5 2/5] scripts: dtc: Build fdtoverlay tool Viresh Kumar
2021-01-20  7:06 ` [PATCH V5 3/5] scripts: dtc: Remove the unused fdtdump.c file Viresh Kumar
2021-01-21  0:44   ` David Gibson
2021-01-21  4:17     ` Viresh Kumar
2021-01-21  6:26       ` David Gibson
2021-01-21 14:18         ` Rob Herring
2021-01-20  7:06 ` [PATCH V5 4/5] kbuild: Add support to build overlays (%.dtbo) Viresh Kumar
2021-01-20  8:58   ` Masahiro Yamada
2021-01-20  9:55     ` Viresh Kumar
2021-01-20 11:04       ` Masahiro Yamada
2021-01-20 11:27         ` Viresh Kumar
2021-01-21  0:49   ` David Gibson
2021-01-21  4:13     ` Viresh Kumar
2021-01-21  5:40       ` Frank Rowand
2021-01-21  6:25       ` David Gibson
2021-01-20  7:06 ` [PATCH V5 5/5] of: unittest: Statically apply overlays using fdtoverlay Viresh Kumar
2021-01-21  0:51   ` David Gibson
2021-01-21  5:14     ` Frank Rowand
2021-01-21  5:34       ` Viresh Kumar
2021-01-21  5:45         ` Frank Rowand
2021-01-21  5:50           ` Viresh Kumar
2021-01-21  6:36             ` David Gibson
2021-01-21  6:34         ` David Gibson [this message]
2021-01-21  6:57           ` Viresh Kumar
2021-01-21 23:39             ` David Gibson
2021-01-22  3:10               ` Viresh Kumar
2021-01-22  4:27                 ` David Gibson
2021-01-21  5:34       ` Frank Rowand
2021-01-21  5:43         ` Viresh Kumar
2021-01-21  5:55           ` Frank Rowand
2021-01-21  5:58             ` Viresh Kumar
2021-01-21  7:04               ` Frank Rowand
2021-01-21 23:41                 ` David Gibson
2021-01-21  6:37             ` David Gibson
2021-01-20 15:43 ` [PATCH V5 0/5] dt: build overlays Rob Herring
2021-01-21  4:14   ` Viresh Kumar

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=20210121063438.GJ5174@yekko.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=anmar.oueja@linaro.org \
    --cc=bill.mills@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=pantelis.antoniou@konsulko.com \
    --cc=robh+dt@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.