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