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

David Gibson <[email protected]> Wed, 24 Sep 2025 14:17:02 +1000
Newsgroups	org.kernel.vger.devicetree-compiler,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel
Message-ID	<aNNwvhgdDidsWfRD@zatzit>
On Tue, Sep 23, 2025 at 11:47:38AM -0500, Andrew Davis wrote:
> On 9/23/25 8:36 AM, Herve Codina wrote:
> > On Tue, 23 Sep 2025 12:29:27 +0200
> > Geert Uytterhoeven <[email protected]> wrote:
> > 
> > > Hi Hervé,
> > > 
> > > On Tue, 23 Sept 2025 at 11:49, Herve Codina <[email protected]> wrote:
> > > > On Tue, 23 Sep 2025 18:09:13 +1000
> > > > David Gibson <[email protected]> wrote:
> > > > > Ah, right.  To be clear: we absolutely don't want multiple addons
> > > > > altering the same nodes.  But I think we could do that in ways other
> > > > > than putting everything under a connector.  This is exactly why I
> > > > > think we should think this through as an end-to-end problem, rather
> > > > > trying to do it as a tweak to the existing (crap) overlay system.
> > > > > 
> > > > > So, if we're thinking of this as an entirely new way of updating the
> > > > > base dt - not "an overlay" - we can decide on the rules to ensure that
> > > > > addition and removal is sane.  Two obvious ones I think we should
> > > > > definitely have are:
> > > > > 
> > > > > a) Addons can only add completely new nodes, never modify existing
> > > > >     ones.  This means that whatever addons are present at runtime,
> > > > >     every node has a single well defined owner (either base board or
> > > > >     addon).
> > > > 
> > > > In this rule I suppose that "never modify existing ones" should be understood
> > > > as "never modify, add or remove properties in existing ones". Because, of course
> > > > adding a full node in a existing one is allowed (rule b).
> > > 
> > > What if the add-on board contains a provider for the base board.
> > > E.g. the connector has a clock input, fed by an optional clock generator
> > > on the add-on board.  Hooking that into the system requires modifying
> > > a clocks property in the base board, cfr. [1].
> > > Or is there some other solution?
> > > 
> > > I was also wondering about endpoints, as they have two sides: one on
> > > the base board, and one on the add-on board. But it seems that typically
> > > both ends are added by the extension, so these fall under rule b.
> > > 
> > > Thanks!
> > > 
> > > [1] https://elixir.bootlin.com/linux/v6.16/source/arch/arm64/boot/dts/renesas/white-hawk-ard-audio-da7212.dtso#L165
> > > 
> > 
> > Hi Geert,
> > 
> > Addon DT we talk about is not a way to fine tune base board devices.
> > 
> > For the clock, you need a clock driver which is able to support clock hot-plugging.
> > Same for endpoint, the remote endpoint part should support hot-plugging.
> 
> Why should these drivers need hot-plug support, they are attached and then
> the board is booted. Nothing is hot-plugged here.

That's a reasonable case, but not AIUI, the case that Hervé (and
others) are trying to deal with.  The existing overlay mechanics are
not as problematic when you don't have to deal with hot unplug.

Here we're trying to design a protocol that's suitable for things that
can (at least in principle) be hot plugged and unplugged.


As a little background here the existing overlay mechanism was never
designed for hotplugging let alone hot unplugging.  It was built for
boot time, or pre-boot use, "tweaking" a mostly correct device tree.

In fact... it wasn't even really designed for that.  Its semantics
were basically just copied from dtc's *compile time* overlay support.
That wasn't designed for any kind of plugging, hot, cold, whatever.
It was designed for building DTs for a bunch of similar but not
identical boards from a common base (such as a SoC tree).

Moved to runtime with dtbo, that was already pretty clunky.
Attempting to use it for hotplug is just awful.

-- 
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)