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

David Gibson <[email protected]> Tue, 9 Sep 2025 12:44:06 +1000

Newsgroups	org.kernel.vger.devicetree-compiler,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel
Message-ID	<aL-UdtUWAnyGOOzT@zatzit>

On Mon, Sep 08, 2025 at 11:01:42AM +0200, Geert Uytterhoeven wrote:
> Hi David,
> 
> On Mon, 8 Sept 2025 at 06:36, David Gibson <[email protected]> wrote:
> > On Thu, Sep 04, 2025 at 11:15:44AM +0530, Ayush Singh wrote:
> > > 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 don't expect chained connectors to be complicated.
> Boards using multiple-connectors may be more difficult, e.g.
> https://1bitsquared.de/products/pmod-hyperram

Ah.. from the link, I'm gathering you mean a peripheral which plugs
into multiple connectors on a parent board, rather than a board which
supplies multiple connectors.

That is a case I hadn't considered, which does complicate things
further.  I think the main thing that would need to be tackled here is
that the resources would need to be renamable / namespaced on the
plugin side as well as the parent board side.

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