Re: [RFC PATCH 11/77] Add support for FDT_REF_PHANDLE dtb tag

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

Hi David,

On Mon, 19 Jan 2026 16:40:12 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Fri, Jan 16, 2026 at 04:17:27PM +0100, Herve Codina wrote:
> > Hi David,
> > 
> > On Thu, 15 Jan 2026 12:24:49 +1100
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> >   
> > > On Mon, Jan 12, 2026 at 03:19:01PM +0100, Herve Codina wrote:  
> > > > The FDT_REF_PHANDLE dtb tag is similar to the FDT_REF_LOCAL tag except
> > > > that it identifies a reference to an external phandle. The node
> > > > referenced by the phandle is not present in the device-tree blob.    
> > > 
> > > The names FDT_REF_PHANDLE and FDT_REF_LOCAL are perhaps a little
> > > misleading - both are marking a phandle, the difference is in the form
> > > of reference.  That's quite difference from the distinction between
> > > the REF_PHANDLE and REF_PATH marker types, where the difference is in
> > > what the reference expands to in the property.  
> > 
> > I am agree.
> > 
> > FDT_PHANDLE: A local phandle with the value known.
> > FDT_PHANDLE_REF: An external phandle, its value need to be resolved ?  
> 
> Yeah, I think that works.
> 
> > This is aligned with FDT_EXPORT_SYM / FDT_EXPORT_SYM_REF.
> > 
> > Or maybe:
> > FDT_TYPE_PHANDLE
> > FDT_TYPE_PHANDLE_REF
> > 
> > "TYPE" has been mentioned by Rob in the "FDT_TYPE_U32" context.  
> 
> I don't especially like this.  phandles do have a bearing on types.
> But as I said to Rob, I think they're a sufficiently special case,
> that I'd prefer not to handle them as just an aspect of a more general
> "types" system.

Ok, I will not use 'TYPE' in the name of those tags.

> 
> Btw, since we're looking at dtb changes anyway, one possibility would
> be to no longer encode a node's phandle as a property, but include it
> as a new field in the FDT_BEGIN_NODE tag.  Putting it in a property
> was always a bit of a hack - in traditional OF, it was generally the
> node's address in memory, not something from a property.  Doing it
> that way might side step some messy edge cases like dealing with
> improperly encoded "linux,phandle" properties.
> 
> > Any other ideas are welcome.
> >   
> > > > The FDT_REF_PHANDLE dtb tag is a meta-data tag attached to a property.
> > > > 
> > > > It indicates that the property defined before this tag (FDT_PROP) uses a
> > > > phandle value and the node related to this phandle value is not local
> > > > node (i.e. the node is not present in the device-tree blob). This tag
> > > > can be available only in overlay or addon device-tree blobs. The phandle
> > > > value used in the property has to be resolved when the device-tree blob
> > > > is applied on top of a base device-tree.    
> > > 
> > > This is kind of looking ahead, but does that imply that this tag is
> > > only valid in addon dtbs?  
> > 
> > addon dtbs for sure but also overlay (plugin) dtbs.  
> 
> I don't really understand how they would be used for plugins - I
> thought the idea was that addons would more or less obsolete plugins.

They won't be used in plugins. Other mechanism are available in plugind.
My idea was to to keep things consistent.

I mean, pluggin dtb can have metadata. Having metadata doesn't mean that
they must be used.

FDT_REF_PHANDLE (or other name) makes sense in plugin dtb.

Is FDT_REF_PHANDLE valid for plugin dtb, the answer is yes.

Will FDT_REF_PHANDLE be used for symbol resolution in the plugin case, the
answer is no, other mechanisme are used (__fixups__ node).

> 
> > >   
> > > > It is followed by two values and a possible alignment padding:
> > > >  - offset (32bit):
> > > >      Offset in the property data where the phandle is available.
> > > >  - label (string including \0):
> > > >      The label to use to resolve the phandle value.    
> > > 
> > > I expect it will become apparent later in the series, but it would be
> > > helpful to clarify what the scope of that label is.  A single node?
> > > The whole tree?  Across a tree and all its possible addons?  
> > 
> > This label is the unresolved reference. Its scope is the dtb.  
> 
> "the dtb" being a single addon, yes?  That could have several meanings
> in the base tree depending on where the addon is attached, yes?

yes, the addon dtb is for a single addon.

yes, depending on where the addon is attached, the symbol resolution can reach
different nodes. Is that several "meanings", not sure.

From the addon: prop = <&i2c>;

Depending on node the addon is applied this could be resolved to the node
i2c@xxxx or i2c@yyyy but for sure it will be resolved to a node describing
an i2c controller.

> 
> > For instance, "prop = < 0 1 &foo>;" in a dts with the node referenced by
> > &foo not present in this dts (possible for addons and plugins) will lead
> > to 'FDT_REF_PHANDLE 8 "foo"'
> > 
> > The way "foo" is used when the dtb is applied is covered later in the
> > series.
> > 
> > It will be resolved with import/export mechanism (when the addon is
> > applied).
> > 
> > Also it can be a namespace label reference (see patch 66 for the definition
> > of namespace label reference) and here also it will be resolved thanks to
> > import/export mechanism. Namespace label references can only be present in
> > addons.
> > 

Best regards,
Hervé