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