From: Luca Ceresoli <luca.ceresoli@bootlin.com>
To: Ayush Singh <ayush@beagleboard.org>
Cc: Andrew Davis <afd@ti.com>,
xypron.glpk@gmx.de, Jason Kridner <jkridner@beagleboard.org>,
Deepak Khatri <lorforlinux@beagleboard.org>,
Dhruva Gole <d-gole@ti.com>,
Robert Nelson <robertcnelson@beagleboard.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
David Gibson <david@gibson.dropbear.id.au>,
Pantelis Antoniou <pantelis.antoniou@gmail.com>,
Herve Codina <herve.codina@bootlin.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [Discussion] Global vs Local devicetree overlays for addon board + connector setups
Date: Mon, 9 Jun 2025 16:13:53 +0200 [thread overview]
Message-ID: <20250609161353.49214dee@booty> (raw)
In-Reply-To: <46bb7e4f-1e65-4510-a27f-19ae87c4c272@beagleboard.org>
Hello Andrew,
adding a bit more to the discussion.
On Thu, 5 Jun 2025 12:52:19 +0530
Ayush Singh <ayush@beagleboard.org> wrote:
[...]
> >> Basic Requirements
> >>
> >> *********************
> >>
> >>
> >> Here are some basic functionality that the chosen approach can do for
> >> it to be viable for the connector + addon board setups:
> >>
> >>
> >> 1. Dynamic device addition/removal from userspace
> >>
> >
> > I'm going to suggest we ignore the removal part. Not because it is too
> > difficult to solve, but because it is impossible to solve.
> >
> > A huge amount of drivers and devices do not actually allow for removal.
> >
> > The reason is because there is no need, hot-pluggable busses are the
> > exception, not the rule. The rare cases like USB are built to handle
> > this both in hardware and software. None of the connectors we have
> > talked about are actually hot-pluggable! I2C, SPI, etc.. none of
> > these are hot-pluggable. Even if you get away with yanking the cape
> > off a BeagleBone while it is running once or twice, it is violating
> > the electrical specifications and you will eventually break something.
> >
> > If we don't focus on the (non-valid) removal part, so many other parts
> > solutions become viable again. Right now we have no good way to even
> > *add* an add-on board, even statically, so let's not let "perfect" be
> > the enemy of good..
>
>
> Not quite, removal is a very important part of the equation, specially
> for mikroBUS. mikroBUS iteself is not exactly hot-pluggable, but Beagle
> has a usecase of mikroBUS over greybus (over 6lowpan). Since the node
> can be removed, you now have a setup where mikroBUS becomes removable.
Removal is indeed valid.
There are use cases for removal, as discussed at LPC2024 [1][2]. And
for the use case Hervé and I am working on, mentioned at LPC, addition
without removal is totally useless.
Busses that are non-natively hotplug are surely tricky to handle but
they work if 1) the hardware is designed to be electrically safe against
removal (HDMI DDC is a simple example based on I²C) and 2) the drivers
and related subsystems are resilient to removal. We are working on 2,
and I'm working particularly on DRM (some series I sent recently: [3],
[4]).
[1] https://lpc.events/event/18/contributions/1696/attachments/1404/3464/ceresoli-codina-hotplug-overlays.pdf
[2] https://www.youtube.com/watch?v=ACDCiC1r8Xw
[3] https://lore.kernel.org/lkml/20250528-drm-bridge-convert-to-alloc-api-v4-1-f04e698c9a77@bootlin.com/
[4] https://lore.kernel.org/lkml/20250606-drm-bridge-alloc-doc-test-v9-0-b5bf7b43ed92@bootlin.com/
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
prev parent reply other threads:[~2025-06-09 14:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-30 12:07 [Discussion] Global vs Local devicetree overlays for addon board + connector setups Ayush Singh
2025-04-30 14:09 ` Herve Codina
2025-04-30 14:31 ` Geert Uytterhoeven
2025-04-30 14:58 ` Herve Codina
2025-05-01 6:05 ` Ayush Singh
2025-05-04 12:33 ` Ayush Singh
2025-05-04 12:50 ` Greg Kroah-Hartman
2025-05-04 13:00 ` Ayush Singh
2025-05-04 13:13 ` Greg Kroah-Hartman
2025-05-05 6:43 ` Geert Uytterhoeven
2025-05-05 20:56 ` Rob Herring
2025-06-04 19:03 ` Andrew Davis
2025-06-05 7:22 ` Ayush Singh
2025-06-09 14:13 ` Luca Ceresoli [this message]
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=20250609161353.49214dee@booty \
--to=luca.ceresoli@bootlin.com \
--cc=afd@ti.com \
--cc=ayush@beagleboard.org \
--cc=d-gole@ti.com \
--cc=david@gibson.dropbear.id.au \
--cc=devicetree@vger.kernel.org \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=herve.codina@bootlin.com \
--cc=jkridner@beagleboard.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorforlinux@beagleboard.org \
--cc=pantelis.antoniou@gmail.com \
--cc=robertcnelson@beagleboard.org \
--cc=xypron.glpk@gmx.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox