From: Brian Norris <briannorris@chromium.org>
To: Rob Herring <robh@kernel.org>
Cc: devicetree-compiler@vger.kernel.org
Subject: Re: [PATCH] checks: Avoid warnings for reg override in __overlay__
Date: Wed, 17 Jun 2026 16:35:47 -0700 [thread overview]
Message-ID: <ajMvU-U-cdnlXykM@google.com> (raw)
In-Reply-To: <CAL_Jsq++ERWJ19BcVXHKTzq1PN7tpJm=rm6e08UCH_gcp6ncHg@mail.gmail.com>
Hi Rob,
On Wed, Jun 17, 2026 at 05:54:42PM -0500, Rob Herring wrote:
> I would argue (and did the last time this came up IIRC) the overlay
I gave a quick look for prior art, but didn't go far enough. I see this
was a similar conversation:
[PATCH v2] checks: Suppress warnings on overlay fragments
https://lore.kernel.org/all/20230308091539.11178-1-qun-wei.lin@mediatek.com/
I don't think it had a satisfying conclusion though.
> should target the parent node instead and then you can put in
> #address-cells and #size-cells in the overlay to make it pass checks
> (and make 'reg' parsable without applying the overlay).
This implies we can't actually target the appropriate node via phandle
any more, and so we lose the ergonomics that phandles provide. Where
previouly an overlay could be resilient to node renaming and other sorts
of incompatibilities between a dtb and a dtbo (the overlay wouldn't
apply if &foo isn't found), now we'd have to open-code the node name and
maybe even its parent node name in the overlay. If either of those were
wrong ... we wouldn't notice at all, unless there's an obvious
functional breakage as a result.
I acknowledge that it's difficult to parse and validate dtbos when they
are low on context. But I don't see why we should emit false warnings
for the possibly-correct, and more ergnomic approach.
Brian
next prev parent reply other threads:[~2026-06-17 23:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-17 20:44 [PATCH] checks: Avoid warnings for reg override in __overlay__ Brian Norris
2026-06-17 22:54 ` Rob Herring
2026-06-17 23:35 ` Brian Norris [this message]
2026-06-18 2:58 ` Rob Herring
2026-06-18 8:16 ` David Gibson
2026-06-18 8:25 ` 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=ajMvU-U-cdnlXykM@google.com \
--to=briannorris@chromium.org \
--cc=devicetree-compiler@vger.kernel.org \
--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