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

[Herve Codina <herve.codina@bootlin.com>]

On Thu, 18 Jun 2026 18:16:05 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

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

For #address-cells/#size-cells, you can also have the properties set in the dtso
file either in the __overlay__ node or if, some other DT properties are needed,
in the fragment node.
  https://elixir.bootlin.com/linux/v7.1/source/drivers/misc/lan966x_pci.dtso#L25

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. Otherwise,
an error is returned.
  https://elixir.bootlin.com/linux/v7.1/source/drivers/of/overlay.c#L322

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.

It is not yet perfect but it is better than nothing.

Best regards,
Hervé