On Wed, Sep 24, 2025 at 10:33:50PM +0530, Ayush Singh wrote:

On 9/24/25 09:41, David Gibson wrote:

quoted

On Tue, Sep 23, 2025 at 12:29:27PM +0200, Geert Uytterhoeven wrote:

quoted

Hi Hervé,

On Tue, 23 Sept 2025 at 11:49, Herve Codina [off-list ref] wrote:

quoted

On Tue, 23 Sep 2025 18:09:13 +1000
David Gibson [off-list ref] wrote:

quoted

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.

Well, while that was not an initial use-case in my mind, external clock
inputs are a valid use-case when talking about connectors for board headers
specifically (e.g. pocketbeagle connector).

I guess I'm not familiar enough with modern embedded hardware.  I'm
having a hard time wrapping my head around what's going on here.  If
the external clock input is optional (hence under a connector), how is
anything on the base board dependent on it?  If nothing on the base
board is dependent, why do we need to modify its properties to
represent it?

Is this a design flaw in the clocks binding?

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