All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Rob Herring <robh@kernel.org>
Cc: "Uwe Kleine-König" <u.kleine-koenig@baylibre.com>,
	devicetree-compiler@vger.kernel.org,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Saravana Kannan" <saravanak@google.com>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH] libfdt: overlay: Fix phandle overwrite check for new subtrees
Date: Fri, 5 Jul 2024 21:49:17 +1000	[thread overview]
Message-ID: <ZofdvXLWunF4opJB@zatzit> (raw)
In-Reply-To: <CAL_JsqKj4w92Ym7KTmQo3D+iNszB5u6-kceMCrNCztM0LJaQkA@mail.gmail.com>

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

On Wed, Jul 03, 2024 at 11:06:32AM -0600, Rob Herring wrote:
> On Tue, Jul 2, 2024 at 7:44 AM Uwe Kleine-König
> <u.kleine-koenig@baylibre.com> wrote:
> >
> > Hello David,
> >
> > On Wed, Jun 26, 2024 at 09:55:52AM +0200, Uwe Kleine-König wrote:
> > > If the overlay's target is only created in a previous fragment, it
> > > doesn't exist in the unmodified base device tree. For the phandle
> > > overwrite check this can be ignored because in this case the base tree
> > > doesn't contain a phandle that could be overwritten.
> > >
> > > Adapt the corresponding check to not error out if that happens but just
> > > continue with the next fragment.
> > >
> > > This is currently triggered by
> > > arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso in the kernel
> > > repository which creates /panel in its first fragment and modifies it in
> > > its second.
> > >
> > > Reported-by: Rob Herring <robh@kernel.org>
> > > Link: https://lore.kernel.org/all/CAL_JsqL9MPycDjqQfPNAuGfC6EMrdzUivr+fuOS7YgU3biGd4A@mail.gmail.com/
> > > Fixes: 1fad065080e6 ("libfdt: overlay: ensure that existing phandles are not overwritten")
> > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> >
> > I wonder about this patch's state. Does David wait for feedback by Rob
> > as he reported the issue? Does Rob expect Geert to comment as
> > salvator-panel-aa104xd12.dtso is in his maintainer area? Are the
> > responsible people just busy; or is this fix already hidden in their
> > backlog?
> 
> I think it's just waiting on David.

Sorry, yes.  I'm always finding it hard to find time for dtc/libfdt
maintenance stuff, and I've been particularly busy lately.  I did
catch up on a bunch of trivial dtc/libfdt patches lately, but this
one's a bit more complex so I didn't get to it yet.

> The patch looks good to me, but I haven't tested it nor am I that
> familiar with this particular code.
> 
> Rob
> 

-- 
David Gibson (he or they)	| 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 --]

  reply	other threads:[~2024-07-05 12:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-26  7:55 [PATCH] libfdt: overlay: Fix phandle overwrite check for new subtrees Uwe Kleine-König
2024-07-02 13:44 ` Uwe Kleine-König
2024-07-03 17:06   ` Rob Herring
2024-07-05 11:49     ` David Gibson [this message]
2024-07-05 20:53       ` Uwe Kleine-König
2024-07-05 23:46 ` David Gibson

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=ZofdvXLWunF4opJB@zatzit \
    --to=david@gibson.dropbear.id.au \
    --cc=devicetree-compiler@vger.kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=robh@kernel.org \
    --cc=saravanak@google.com \
    --cc=u.kleine-koenig@baylibre.com \
    /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.