Re: [PATCH] checks: Avoid warnings for reg override in __overlay__

--Q5l3d6hEx18FTHRr
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 17, 2026 at 09:58:03PM -0500, Rob Herring wrote:
> On Wed, Jun 17, 2026 at 6:35=E2=80=AFPM Brian Norris <briannorris@chromiu=
m.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=
=2Ecom/
> >
> > 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.
>=20
> 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.
>=20
> 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.

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

--Q5l3d6hEx18FTHRr
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmozqTwACgkQzQJF27ox
2GcyuBAAharTpQtB/o1gRhRbPevG2UEaicA++BlnJRaor7P+GQ0vUqLs4zA/wxKv
46lEfYoEDFEdRTTCLfn0aqnrpvPiDB+hFHkNdQBbrim87B/QEykRxIltY4MEf+1P
DOyAOr3Vz7yUcuiHfQwFvWSlbsxprrRRk1mSk5NZ+sW5Uy9/jZi62XeXFMrTjBVz
hvVnk3Enxx4UCiTzG7dbGs/92ONUekvAWQpHfyVvbmidM8kNpPfrLE4VMzug12rN
I9hFGbyPCy0UJu86YVsuKs1XKONLwMaX56MShEzyqRAAx2YmDTwoEIdPg5Ou1vFR
wSmTY/XaSEfHMoC7V6WXLQwMJm52C7qZrGxeji7D2yeNFd5N8HKupDI9Wth9G5Vc
s/h1P2CDxOpksGRPda9p3f+VFGYppd/lIEiWny7WluikuZ7ht31FNDzuONCLLtBr
dxb7Qo91klsAycFeLcTKiMnxbniU8KkvT8ze1AYQAcRSgyW9115E+qHS80IAaKIf
4YH4RROm7wZPWWgEJ8j9t8TglmDM7Kv4iu6AXifZapUNY/YuE6QfC2heIZMzyIKB
kDhELEqbiZWABU6v7iTp8TM4rWpa0WfWZt4bfXneJVBoeI+gFeoaPnrNEcBWUUJS
cXv4x1pvOFbcqvsshRD/neDBnH+dUyvxvAYFGMa0hK7Vv8r5JSo=
=bFSH
-----END PGP SIGNATURE-----

--Q5l3d6hEx18FTHRr--