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

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] [day] [month] [year] [list]

Message-ID: <aNNvaN4xJtKBFmWT@zatzit>
Date: Wed, 24 Sep 2025 14:11:20 +1000
From: David Gibson <david@...son.dropbear.id.au>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Herve Codina <herve.codina@...tlin.com>,
	Ayush Singh <ayush@...gleboard.org>,
	Krzysztof Kozlowski <krzk@...nel.org>,
	Rob Herring <robh@...nel.org>, Andrew Davis <afd@...com>,
	Wolfram Sang <wsa+renesas@...g-engineering.com>,
	Luca Ceresoli <luca.ceresoli@...tlin.com>,
	devicetree@...r.kernel.org, Jason Kridner <jkridner@...il.com>,
	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>
Subject: Re: Device tree representation of (hotplug) connectors: discussion
 at ELCE

On Tue, Sep 23, 2025 at 12:29:27PM +0200, Geert Uytterhoeven wrote:
> Hi Hervé,
> 
> On Tue, 23 Sept 2025 at 11:49, Herve Codina <herve.codina@...tlin.com> wrote:
> > On Tue, 23 Sep 2025 18:09:13 +1000
> > David Gibson <david@...son.dropbear.id.au> 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?

Hmm.  My first inclination would be that this case is not in scope for
the protocol we're trying to design now.  If the widget provides
things to the base board as well as the other way around, it's no
longer an "addon" for the purposes of this spec.

But it's possible I've underestimated how common / useful such a case
is.

Note that I'd expect the existing overlay mechanism to still be
around.  It may be ugly and not very well thought out, but its
drawbacks are much less severe if you're not dealing with hot unplug.

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