Re: [PATCH 13/13] dtc: Merge the fragments of a dts file in main()

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

Hi David,

On Wed, 4 Nov 2026 20:47:45 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Wed, Nov 04, 2026 at 09:40:55AM +0100, Herve Codina wrote:
> > Hi David,
> > 
> > On Wed, 4 Nov 2026 17:51:41 +1100
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> >   
> > > On Tue, Nov 03, 2026 at 06:08:03PM +0100, Herve Codina wrote:  
> > > > On Sun,  1 Nov 2026 09:37:07 -0700
> > > > Simon Glass <sjg@chromium.org> wrote:
> > > >     
> > > > > We would like to run checks on each fragment of a dts file before it is
> > > > > merged, but that requires dt_from_source() to return the fragments
> > > > > unmerged, so that main() can decide what to do with them. At present
> > > > > they are merged at the end of the parse.    
> > > > 
> > > > Why running checks on each fragment instead of the dt where fragments are
> > > > merged ?    
> > > 
> > > This is part of the aim of the series.  Some checks make sense on an
> > > individual fragment, others don't.  Allowing both kinds lets us
> > > address several longstanding problems.
> > >   
> > 
> > To clarify this point, what kind of checks for individual fragment?  
> 
> As many as we can, eventually.  Anything that doesn't rely on whole
> tree context is a candidate.  This means
>   a) they'll be checked sensibly for dtbo output where we don't have
>      all the information to perform checks that rely on the broader
>      tree context
>   b) they'll catch logically incorrect things, even if they're later
>      overwritten by something
> 
> Initially the most important ones to run before merge are the
> structural ones like duplicate_*_names, node_name_not_empty,
> node_name_format.  The duplicate ones in particular means we enable
> consistent behaviour w.r.t. overwriting nodes between the first
> fragment and later fragments in the file.
> 
> 
> In fact, thinking about it, before the merge should eventually be the
> default place to run tests.  So the question is more, which checks
> should be deferred until after the merge (and therefore not be run at
> all for dtbo output).  Obviously anything that needs to look up an
> absolute path has to go after the merge.  Things that look up phanles
> are a tricky intermediate case.  Potentially those can work before
> merge, but only if they search for labels rather than actual phandles.
> 
> > What kind of longstanding problems?  
> 
> The biggest one, that I'm hoping this series will address is the fact
> that we don't have consistent behaviour if a node or property name is
> repeated between the first fragment (it generates a check failure) and
> later fragments (it silently overwrites).  But there have also been
> various reports about false positives from checks when they run on
> /plugin/ files, because the partial tree just doesn't have the
> information needed to properly complete the check.  Having different
> sets of checks before and after merge is the clearerst way I can see
> to properly handle those false positives, while still checking as much
> as we can for a dtbo.
>  
> > Can you give me details about them?
> > 
> > Maybe I've faced some of them in the support for addons implementation.  
> 
> That's possible, yes.  Or you might yet face them in addons.
> 

Hum, I see. I think the problem is not before / after merge for checks but
with / without orphans.

In a dts, we can have:
--- 8< ---
/ {
	node: node-a {
		prop1;
	};
};

&node {
	prop2;
	subnode: subnode {
		prop1;
	}
};

&node {
	prop3;
}

&subnode {
	prop2;
};
--- 8< --

In the end no orphans are present. Everything is merged in the root node.

In a dtso we can have:
--- 8< ---
&node {
	prop2;
	subnode: subnode {
		prop1;
	}
};

&node {
	prop3;
}

&subnode {
	prop2;
};
--- 8< ---

In this case, everything is merged to the orphan node &node.
This merged orphan node has to be checked.

I make a distinction between merge and format conversion performed for orphan
handling in dtso.

For dtso, the orphan node &node will be converted (format conversion) to
--- 8< ---
/ {
	fragment@0 {
		target = <&node>;
		__overlay__ {
			...
		};
	};

	__fixup__ {
		node = "/fragment@0:target:0";
	};
};
--- 8< ---

Best regards,
Hervé