linux-kernel - Re: [RFC PATCH 11/77] Add support for FDT_REF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aW3DvDooCXxw83Av@zatzit>
Date: Mon, 19 Jan 2026 16:40:12 +1100
From: David Gibson <david@...son.dropbear.id.au>
To: Herve Codina <herve.codina@...tlin.com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Ayush Singh <ayush@...gleboard.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	devicetree-compiler@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, devicetree-spec@...r.kernel.org,
	Hui Pu <hui.pu@...ealthcare.com>,
	Ian Ray <ian.ray@...ealthcare.com>,
	Luca Ceresoli <luca.ceresoli@...tlin.com>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [RFC PATCH 11/77] Add support for FDT_REF_PHANDLE dtb tag

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@...son.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.

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

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)