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

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

On Thu, Jun 18, 2026 at 10:24:38PM +0200, Herve Codina wrote:
> On Thu, 18 Jun 2026 18:16:05 +1000
> David Gibson <[email protected]> wrote:
>=20
> > 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@chr=
omium.org> wrote: =20
> > > >
> > > > Hi Rob,
> > > >
> > > > On Wed, Jun 17, 2026 at 05:54:42PM -0500, Rob Herring wrote: =20
> > > > > I would argue (and did the last time this came up IIRC) the overl=
ay =20
> > > >
> > > > 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@medi=
atek.com/
> > > >
> > > > I don't think it had a satisfying conclusion though.
> > > > =20
> > > > > should target the parent node instead and then you can put in
> > > > > #address-cells and #size-cells in the overlay to make it pass che=
cks
> > > > > (and make 'reg' parsable without applying the overlay). =20
> > > >
> > > > This implies we can't actually target the appropriate node via phan=
dle
> > > > 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 nam=
e 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
> > >=20
> > > Why can't we use the parent node phandle? =20
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > Targeting the parent node is not a good solution.
> >=20
> > > > 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 warnin=
gs
> > > > for the possibly-correct, and more ergnomic approach. =20
> > >=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. =20
> >=20
> > Yeah, the suggested patch is also not a good solution, comments on
> > that email.
>=20
> For #address-cells/#size-cells, you can also have the properties set in t=
he dtso
> file either in the __overlay__ node or if, some other DT properties are n=
eeded,
> in the fragment node.
>   https://elixir.bootlin.com/linux/v7.1/source/drivers/misc/lan966x_pci.d=
tso#L25

Setting #address-cells or #size-cells in __overlay__ or descendents
thereof is reasonable, but won't address the relevant case here: here
the problem is the check on 'reg' of the target node, which depends on
#*-cells of the *parent* node, which doesn't exist within the overlay
fragment.

You _could_ set #*-cells in the fragment@ node, and I think that will
fool the check.  It's a real hack, though, and I'd consider at best
dubiously conforming to the overlay spec.

> Worth noting that, in linux code, when an overlay is applied if #address-=
cells
> and/or #size-cells are identical to already existing ones, its fine. Othe=
rwise,
> an error is returned.
>   https://elixir.bootlin.com/linux/v7.1/source/drivers/of/overlay.c#L322
>=20
> We can have dtc checking reg values against #address-cells/#size-cells
> and when the overlay is applied, there is guarantees the
> #address-cells/#size-cells matches base DT existing ones.

But I'm guessing #*-cells in the fragment node *won't* be checked,
because that's not "applied" as such - it generally just has metadata
for the fragment.
>=20
> It is not yet perfect but it is better than nothing.
>=20
> Best regards,
> Herv=C3=A9
>=20

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

--Tn/ccXvv4d/cKgK6
Content-Type: application/pgp-signature; name=signature.asc

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

iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmo0wlkACgkQzQJF27ox
2GcoaBAAqVjNeXto5Brq2JpiSska1WO66STqzm9I62sbFvLgiQ6YDbZuUP6OZOWQ
6bF4dXV36nY6WGBzrjCeSs/++DuQEToedAssTlLX9EgYdcMJYN2Z78eqca9L6KcY
HZ93AKSFIoTF6ykzGXB2mOERf+XTNgJoQBZniBzGRG1iXnnzGhkwaqiVle4hzU6u
sT/9vRajt7xgfRnVxXk2XJ7JxPkCsVQrMjs2urBAWo3MtC73nI142q0zcBHjkzje
szcx7ThgngKsptAPXX9HV9WmPnpVwfuap1Zc2vBjgQpgLD5Tnhbcl5bXtflS7awZ
44Fm4KEmfj8CGdRC2IykPB3TVea693XVl+FFhn1nU1TNxEsntcXMEx91lSpGijAT
3zLFPKQR0gvqi1dmgG1JcAisY4FJhM0R/L8Bp2gW0Wy3g6+dvctlIYFl16CVKvxt
+mRE1aZVitkz/tUKC1ztL6GCzAwJTNKwbPEUSzmGinbJJJLkLqgrNDEFDpmvBVfY
98DPt8wC4CKVgR8nNSfK3zz9ud5MS99q3FBPr8rE6TK+3SboZe5mz8ohjfdFphR4
ARs3EyUTEljaumnnwwgNJiNvOXiO2o0k8X4eO/Z53/InxxSFhjSOs8Zt8NIJkZrQ
2vohCixV8Z7f731apdvmLvF44ZPf80iryl54HBr57DGdNojWQFg=
=3GP7
-----END PGP SIGNATURE-----

--Tn/ccXvv4d/cKgK6--