Re: [PATCH v2 0/6] dtc: Fix deletes within a section and before a redefinition

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

Hi David,

On Wed, 4 Nov 2026 17:01:55 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Tue, Nov 03, 2026 at 02:00:30PM +0100, Herve Codina wrote:
> > Hi Simon, David,
> > 
> > On Mon, 2 Nov 2026 12:41:24 +1100
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> > 
> > ...
> >   
> > > 
> > > Yes, that was my intention, though we can revisit it if that breakgs
> > > things for people in practice.  This was the way it was before
> > > source-level overlays were implemented, and still is for the "base"
> > > tree fragment in a file.
> > >   
> > > > In an overlay, a top-level /delete-node/ &label can remove a node from
> > > > another fragment of the same overlay, as Hervé pointed out. I assume
> > > > that should keep working, with only deletes of something in the base
> > > > tree being an error. Is that right?    
> > > 
> > > Uh.. yes.  In a sense this is a question of whether we try to
> > > partially resolve the overlays in a /plugin/ dts or not.  i.e. Do we
> > > attempt to merge those fragments we can, or do we translate every
> > > fragment directly into the dtbo to be resolved at runtime.  I'm not
> > > sure there's a clear correct answer here, so I'd err on the side of
> > > maintaining existing behaviour.
> > >   
> > 
> > David, I don't see you point here.
> > 
> > IMHO, /delete-node/ and /delete-property/ keywords present in a dts
> > apply to the generated dtb.
> > 
> > A dts with /delete-*/ will generate a dtb with related node/property
> > deleted.
> > 
> > A dtso with /delete-*/ will generate a dtbo with related node/property
> > deleted.
> > 
> > David, I don't see why resolution is (or should be) involved here.  
> 
> So the restructure I'm now suggesting here means that processing those
> deletes doesn't happen during the parse, but as an explicit later
> step.  For dtb output, that must result in a single tree.  For dtbo
> output although we may be able to merge some parts, we don't expect to
> be able to fully resolve them.

Yes.

> 
> Given that, and ignoring deletes for now, the merge step could be
> entirely skipped for dtbo output: just emit each dts fragment as a
> dtbo fragment and let them be resolved at runtime, regardless of
> whether they modify things from a base tree or from earlier fragment.

IHMO, having possible merges done is better but well, we can have
unmerged fragments.

> 
> However, once we consider deletes we need an intermediate
> representation of "a delete" within a fragment.  But that can't be
> encoded into dbto format.  So, deletes in a /plugin/ dts require that
> we attempt to resolve the fragment merge (as much as we can), rather
> than leaving it all to runtime.
> 

Ok.

Best regards,
Hervé