Re: Device tree representation of (hotplug) connectors: discussion at ELCE

David Gibson <[email protected]> Mon, 8 Sep 2025 14:36:06 +1000
Newsgroups	org.kernel.vger.devicetree-compiler,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel
Message-ID	<aL5dNtzwiinq_geg@zatzit>
On Thu, Sep 04, 2025 at 11:15:44AM +0530, Ayush Singh wrote:
> On 9/4/25 10:53, David Gibson wrote:
> > On Tue, Sep 02, 2025 at 10:57:10AM +0200, Luca Ceresoli wrote:
[snip]
> > 1) Connector local labels/symbols/aliases
> > 
> > This is not a new idea - both the export-symbols proposal and my
> > ancient connector proposal had this in one form or another.  I think
> > something along these lines is almost essential.  Things that plug
> > into connectors almost always require references to several host board
> > resources (interrupt controller, gpio, ...).  In order to be pluggable
> > on multiple host boards you want to refer to those symbolically.  In
> > order to support multiple instances of the same connector type, you
> > need those symbols to refer to different things fordifferent connector
> > instances.
> > 
> > Whhat I think is a mistake is trying to tie this too closely to the
> > existing __symbols__ structure.  Those have an ugly encoding that
> > requires tortured processing in a way that's not natural for dtb
> > handling.  Plus they already kinda-sorta duplicate old-school aliases
> > in an odd way.
> > 
> > You want some sort of string => node mapping on the connector side,
> > and a way to mark portions of properties on the plugin side as being
> > resolved to some string reference.  But we can take the opportunity to
> > design a better way of doing that than the ugly one we have now.
> 
> 
> Isn't export-symbols exactly this. We do take inspiration from __symbols__.
> However, in case of export-symbols, its string => phandle mapping (as
> opposed to string => string in __symbols__).

As far as the specific It kind of is, yes, and that aspect I like.
What I'm not convinced by is how export-symbols is proposed to fit in
with and be used by surrounding logic.  export-symbols has been
designed to fit in with the existing (ugly) overlay mechanism.  I
think that's putting the cart before the horse.  Instead work out how
to logically define connectors first - which will involve information
equivalent to export-symbols - then work out how to update or replace
the overlay mechanism to work with that.

> I suppose export-symbols could follow aliase conventions, but that still is
> a string => string mapping, which seems worse to me than a phandle (since
> phandle size is constant).
> 
> 
> > 
> > 2) Extend dtb itself
> > 
> > A maor thing that makes current symbols and fixups ugly is the fact
> > that they are encoded into properties in the device tree itself,
> > despite being logically at a different semantic level.  Obviously you
> > *can* do that, but it's not natural.  It would make more sense to add
> > fixup tags into the dtb format itself.
> 
> Having something akin to fixup in dtb format itself would be nice.

Yes, it would.

> > 3) bus-reg / bus-ranges
> > 
> > One thing that makes connector plugins a bit awkward is that they
> > often need to add things to multiple buses on the host system (MMIO &
> > i2c for a simple case).  This means that once resolved the plugin
> > isn't neatly a single subtree.  That's one factor making removal
> > really awkward.  Here's an idea I had a while ago to allow plugins to
> > be a single subtree, by extending what's allowed in the tree content:
> > 
> > Currently a node can only really have a presence on its immediate
> > parent bus, as encoded in the 'reg' and 'ranges' properties.
> > 'bus-reg' and 'bus-ranges' would extend that having a similar format
> > to 'reg' and 'ranges' but adding a phandle for each entry saying which
> > bus it lives on - somewhat similar to interrupt-map.
> > 
> > For example, here's an MMIO bus bridge of some sort, which has control
> > registers on I2C:
> > 
> > 	mmio-bus@... {
> > 		#address-cells = < 2 >;
> > 		#size-cells = < 2 >;
> > 		bridge@XXXX {
> > 			ranges = <...>;
> > 			bus-reg = <&i2c0 0x407>
> > 		}
> > 	}
> > 	i2c0: i2c@... {
> > 		#address-cells = < 1 >;
> > 		#size-cells = < 0 >;
> > 	}
> > 
> > In a sense this extends the device tree to a device DAG.
> > 
> > Obviously this does need changes at the OS device core level, but it
> > gives you a lot of flexibility having done so.
> 
> There is an i2c-bus-extension [1] and spi-bus-extension proposal to do the
> same. But, if we can figure out a common way for all buses, that would be
> great.

Heh, right.  That reinforces my thought that this could be a good
idea.

[Btw, the theoretically correct IEEE1275 way to do this is change
 addressing across the whole tree.  e.g. set #address-cells = <3>,
 with the first cell being, say, 0 for mmio, 1 for i2c, 2 for SPI,
 then the remaining cells are the address within that bus.  So, this
 sort of thing is technically possible in old-school OF trees.  That
 would become pretty unmanageable though.  The idea of bus-reg is to
 encode the same information in a less awkward way]

> [1]:
> https://lore.kernel.org/all/[email protected]/
> 
> [2]: https://lore.kernel.org/all/[email protected]/
> 
> 
> > 4) You don't necessarily need to build a "full" device tree
> > 
> > Flattened device trees (as opposed to original IEEE1275 device trees)
> > - by design - allow certain information to be omitted.  The most
> > common example is that for introspectable buses, like PCI, it's normal
> > to have the DT only include a node for the host bridge, with devices
> > under it being discovered by their own bus specific methods.  That's
> > discovery is handled by the bus/bridge driver.
> > 
> > Connectors usually aren't introspectable, but it's still possible to
> > use an approach like this where the connector driver's discovery
> > method is "look at a different device tree".  So, for example,
> > 
> > Board device tree:
> > 
> > / {
> > 	compatible = "board-with-foo-connector";
> > 	. . .
> > 	mmio@... {
> > 		foo-connector@... {
> > 			compatible = "foo-connector";
> > 			ranges = < ... >;
> > 		}
> > 	}
> > }
> > 
> > Foo device tree:
> > 
> > / {
> > 	compatible = "foo-device";
> > 	foo-port-id = < 0x1234 >;
> > 	component@... {
> > 		reg = < ... >;
> > 	}
> > }
> > 
> > Obviously a "foo device tree" would have different conventions than a
> > board device tree.  It wouldn't have /cpus, /memory, /chosen - but it
> > could have its own "magic" nodes that make sense for the properties of
> > the specific connector type.
> > 
> > Again, that would require work in the device core part of the OS.  The
> > bonus is that runtime addition and removal is now trivial.  No hacking
> > of the base device tree is needed, and so doesn't need to be reverted.
> > The connector driver just adds/removes the reference to its own
> > private tree.
> > 
> > This would, of course, need some way to refer to board resources
> > (interrupt controller, gpio controller) etc.  I think that can be
> > assembled using some of the previous ideas, though.
> 
> I would need to wrap my head around this a bit, specially in context of
> chaining connectors. It does seem like it will still require the points you
> mentioned above to be present in one form or another, i.e. some way to
> extend busses to different nodes/trees and connector (even a chained one)
> local symbols/aliases.

Yes, it would still require those mappings.  I don't think chained
connectors introduce a lot of extra complication.  An intermediate
connector would need to be able to "re-export" things it got from its
parent connector to its child connector(s) - renaming them if
necessary.

I think those two elements would be enough to make something that's
useful in at least a few cases.  However, the pretty common case of a
connector with pins from multiple different parent buses would need
bus-reg or something similar.  Or else the nasty multiplexed encoding
described above.

I say, "nasty" and in many cases it would be, but I think there may be
some cases where that approach does make sense: e.g. a connector that
has several logically separate address spaces but which always travel
together and are typically handled by a common bridge device.  PCI is
a case of this, if you squint - a host bridge provides a config space
bus, and an MMIO bus and a PIO bus.  Also sometimes some sort of
interrupt controller / interrupt routing, complicated by the fact that
there are several different models for that across PCI and PCI-E.

-- 
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
signature.asc (application/pgp-signature, 833 B)