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

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

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

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.

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