On Wed, Jun 17, 2026 at 09:58:03PM -0500, Rob Herring wrote:
> On Wed, Jun 17, 2026 at 6:35 PM Brian Norris <briannorris@chromium.org> wrote:
> >
> > 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.
> 
> Why can't we use the parent node phandle?

That assumes it has one, and that the name of the target node within
its parent is fixed, not variable between boards that can take the
same overlay.

This approach also normalises overwriting (presumably with the same
values, but nothing verifies that) properties outside the device we're
actually trying to update, exacerbating the write-anywhere problem
that overlays already suffer from.

Targeting the parent node is not a good solution.

> > 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.
> 
> It just feels to me like we're disabling checks one by one on
> overlays. And it's not just dtc checks we have to skip, but schema
> checks too. We somewhat mitigate that by requiring (requesting really,
> because it gets skipped) overlays to be applied to *something* at
> build time, but that's the kernel tree which isn't everything.

Yeah, the suggested patch is also not a good solution, comments on
that email.

-- 
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