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

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 4639 bytes --]

On Thu, Jun 18, 2026 at 10:24:38PM +0200, Herve Codina wrote:
> 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

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

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.
> 
> It is not yet perfect but it is better than nothing.
> 
> Best regards,
> Hervé
> 

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]