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

On Wed, Jun 17, 2026 at 6:35=E2=80=AFPM 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/[email protected]=
om/
>
> 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?

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

I don't care too much other than we validate everything in overlays somehow=
.

Rob