[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aL5dNtzwiinq_geg@zatzit>
Date: Mon, 8 Sep 2025 14:36:06 +1000
From: David Gibson <david@...son.dropbear.id.au>
To: Ayush Singh <ayush@...gleboard.org>
Cc: Luca Ceresoli <luca.ceresoli@...tlin.com>,
Krzysztof Kozlowski <krzk@...nel.org>, devicetree@...r.kernel.org,
Rob Herring <robh@...nel.org>, Jason Kridner <jkridner@...il.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
devicetree-compiler@...r.kernel.org, linux-kernel@...r.kernel.org,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
Herve Codina <herve.codina@...tlin.com>, Andrew Davis <afd@...com>
Subject: Re: Device tree representation of (hotplug) connectors: discussion
at ELCE
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@...X {
> > 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/20250618082313.549140-1-herve.codina@bootlin.com/
>
> [2]: https://lore.kernel.org/all/20250729-spi-bus-extension-v1-0-b20c73f2161a@beagleboard.org/
>
>
> > 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
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists