From: Herve Codina <herve.codina@bootlin.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: David Gibson <david@gibson.dropbear.id.au>,
Ayush Singh <ayush@beagleboard.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
Rob Herring <robh@kernel.org>, Andrew Davis <afd@ti.com>,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
Luca Ceresoli <luca.ceresoli@bootlin.com>,
devicetree@vger.kernel.org, Jason Kridner <jkridner@gmail.com>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
devicetree-compiler@vger.kernel.org,
linux-kernel@vger.kernel.org,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: Device tree representation of (hotplug) connectors: discussion at ELCE
Date: Tue, 23 Sep 2025 15:36:46 +0200 [thread overview]
Message-ID: <20250923153646.754e86f8@bootlin.com> (raw)
In-Reply-To: <CAMuHMdWmDwedyPnBERs-tSYEG15nMUuh9u1Q+W_FdquHpUC0-A@mail.gmail.com>
On Tue, 23 Sep 2025 12:29:27 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Hervé,
>
> On Tue, 23 Sept 2025 at 11:49, Herve Codina <herve.codina@bootlin.com> wrote:
> > On Tue, 23 Sep 2025 18:09:13 +1000
> > David Gibson <david@gibson.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?
>
> 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.
I don't think that addon DT should support what is done in the dtso you pointed out.
Best regards,
Hervé
next prev parent reply other threads:[~2025-09-23 13:37 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-02 8:57 Device tree representation of (hotplug) connectors: discussion at ELCE Luca Ceresoli
2025-09-04 5:23 ` David Gibson
2025-09-04 5:45 ` Ayush Singh
2025-09-08 4:36 ` David Gibson
2025-09-08 9:01 ` Geert Uytterhoeven
2025-09-09 2:44 ` David Gibson
2025-09-08 12:51 ` Herve Codina
2025-09-09 5:09 ` David Gibson
2025-09-09 9:41 ` Herve Codina
2025-09-09 13:04 ` Geert Uytterhoeven
2025-09-10 4:36 ` David Gibson
2025-09-11 10:11 ` Herve Codina
2025-09-12 9:40 ` Luca Ceresoli
2025-09-10 4:33 ` David Gibson
2025-09-11 8:48 ` Herve Codina
2025-09-11 8:54 ` Geert Uytterhoeven
2025-09-11 10:23 ` Herve Codina
2025-09-11 12:15 ` Ayush Singh
2025-09-11 12:45 ` Herve Codina
2025-09-11 13:08 ` Geert Uytterhoeven
2025-09-11 13:58 ` Herve Codina
2025-09-15 4:51 ` David Gibson
2025-09-16 6:46 ` Herve Codina
2025-09-16 10:14 ` Geert Uytterhoeven
2025-09-16 12:22 ` Ayush Singh
2025-09-16 13:34 ` Geert Uytterhoeven
2025-09-16 14:25 ` Herve Codina
2025-09-16 15:35 ` Ayush Singh
2025-09-18 3:16 ` David Gibson
2025-09-18 7:44 ` Herve Codina
2025-09-18 8:06 ` Herve Codina
2025-09-19 4:52 ` David Gibson
2025-09-19 5:17 ` Ayush Singh
2025-09-19 15:20 ` Luca Ceresoli
2025-09-23 8:09 ` David Gibson
2025-09-23 9:48 ` Herve Codina
2025-09-23 10:29 ` Geert Uytterhoeven
2025-09-23 13:36 ` Herve Codina [this message]
2025-09-23 16:47 ` Andrew Davis
2025-09-24 4:17 ` David Gibson
2025-09-24 4:11 ` David Gibson
2025-09-24 17:03 ` Ayush Singh
2025-09-30 4:07 ` David Gibson
2025-09-30 7:52 ` Geert Uytterhoeven
2025-10-10 7:58 ` David Gibson
2025-10-10 16:31 ` Herve Codina
2025-09-24 3:54 ` David Gibson
2025-09-24 12:31 ` Herve Codina
2025-09-29 9:23 ` David Gibson
2025-09-30 7:09 ` Herve Codina
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250923153646.754e86f8@bootlin.com \
--to=herve.codina@bootlin.com \
--cc=afd@ti.com \
--cc=ayush@beagleboard.org \
--cc=conor+dt@kernel.org \
--cc=david@gibson.dropbear.id.au \
--cc=devicetree-compiler@vger.kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=geert@linux-m68k.org \
--cc=jkridner@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.ceresoli@bootlin.com \
--cc=robh@kernel.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=wsa+renesas@sang-engineering.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.