public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
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

      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