Message-ID: <b1990c97-8751-4964-a3e8-9598f4cfac2a@beagleboard.org>
Date: Wed, 30 Apr 2025 17:37:33 +0530
From: Ayush Singh <ayush@...gleboard.org>
To: xypron.glpk@....de, Jason Kridner <jkridner@...gleboard.org>,
 Deepak Khatri <lorforlinux@...gleboard.org>, Dhruva Gole <d-gole@...com>,
 Robert Nelson <robertcnelson@...gleboard.org>, Andrew Davis <afd@...com>,
 Geert Uytterhoeven <geert@...ux-m68k.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 David Gibson <david@...son.dropbear.id.au>,
 Luca Ceresoli <luca.ceresoli@...tlin.com>,
 Pantelis Antoniou <pantelis.antoniou@...il.com>,
 Herve Codina <herve.codina@...tlin.com>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
 <devicetree@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>
Subject: [Discussion] Global vs Local devicetree overlays for addon board +
 connector setups

Hello everyone,


This mailing thread is dedicated to discussing what approach should be 
taken regarding overlays for addon board + connector setups. It is 
loosely a continuation of [0], so feel free to go through it.


Introduction
*************

To provide a background, the goal is to have a common way to support 
setups involving addon board + connector. Some examples are as follows:

- MikroBUS [1]

- PocketBeagle 2 [2]: After discussion in [0], it seems that even board 
headers should be treated as a addon board + connector problem.


There are 2 main approaches currently floating around. They serve as 
examples of Global and Local approaches. However, the main discussion 
topic is global vs local rather than the specific approaches.


1. __symbols__ based approach [3]


This was originally proposed by Andre Davis [3]. It defines an overlay 
with just special names in `__symbols__`, which is used along with an 
overlay for the addon-board, which makes use of the node names defined 
in the connector `__symbols__` overlay. Please take a look at the 
original patch series since it provides a working example of how it can 
be used [3].


It has a few nice benefits such as it works pretty well with existing 
infrastructure, and does not need much in the way of new functionality. 
However, for this discussion thread, I want to consolidate the 
discussion regarding how this approach directly adds the devices to the 
appropriate nodes, Eg. An SPI device in addon board will be added to the 
appropriate SPI controller, etc. This means the changes are made to the 
global tree.


2. export-symbols based approach [4]


This approach was originally proposed by Herve Codina [5]. It defines a 
special node (local to the connector) say `export-symbols`. This node 
takes precedence over global `__symbols__`, and thus is used to define 
standard names for nodes used in addon board overlay. Please look at [4] 
to get a more in-depth explanation.


The main difference here is that all the addon board overlay changes are 
isolated to the connector node in the devicetree. Eg: an I2C device in 
addon board will be added to the connector node (as defined in i2c bus 
extension patch series [6]). This means the changes are made to the 
connector node and not the global tree.


This approach needs extra plumbing (like i2c bus extension [6], 
something similar for SPI, etc) to make the whole approach work. Only 
GPIO and PWM with Nexus node can use this approach right now.


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


A lot of connectors + addon board setups do not have any dynamic 
discovery addition. This is compounded when talking about treating the 
whole header in SBCs like PocketBeagle 2 as a connector, since people 
would want to wire LEDs and stuff to individual pins. So a mechanism 
using sysfs or configfs is required


2. Dynamic device addition/removal by driver using EEPROM or something else


Some setups (MikroBUS boards with 1-wire EEPROM, Beagle capes) have 
EEPROMs that contain board information which can be used to detect which 
overlay should be applied.


Main Discussion

*****************

The main topic I wish to discuss if global devicetree overlays are okay 
for addon-board setups. Let me outline some reasons for I prefer the 
local devicetree overlays approach:


1. Addon board removal on multiple connector setups


Say connector A added an I2C device to the controller, then connector B 
added an I2C device to the same controller. I am not sure how well 
removing overlays out-of-order works.


2. Who owns the device


Say there are 2 connectors A and B. Both connectors share an I2C 
controller. Let both connectors have the same device attached. In case 
of `__symbols__` based approach, both connectors would technically be 
successful in applying the overlays, rather than one of the overlays 
failing.


3. How to register the newly added devices


I am a bit unsure about this one since I will have to check if the 
kernel tries to register new devices automatically after applying the 
overlay. For local setups, I was using `devm_of_platform_populate` on 
the connector device.


4. Security


I think local modification is more secure than global tree modification. 
A completely local solution should be as secure from devicetree 
perspective as USB. But I am not an expert.


Drawbacks of local setups

***************************


1. Needs a lot of surrounding work.


I2C bus extension is needed for I2C devices to work, something similar 
for SPI. At least ADC, PWM and GPIO should be covered with just nexus nodes.


Closing Thoughts

******************


I would really like to reach consensus regarding weather the addon-board 
overlays should be global or local. This will help to give a direction 
regarding what should be improved, and hopefully make future development 
move faster. Once a bit of consensus has been reached, we can discuss 
specific implementations.


[0]: 
https://lore.kernel.org/linux-devicetree/d42100cb-eaa0-487f-aaaa-6d8f87bc0705@beagleboard.org/T/#m09b2ebe28b6202b2a926970150caf718eff6d9ac

[1]: https://www.mikroe.com/mikrobus

[2]: https://www.beagleboard.org/boards/pocketbeagle-2

[3]: https://lore.kernel.org/lkml/20240702164403.29067-1-afd@ti.com/

[4]: 
https://lore.kernel.org/devicetree-spec/dbe566ea-447f-4f91-a0b2-f464374955f4@beagleboard.org/T/#m591e737b48ebe96aafa39d87652e07eef99dff90

[5]: 
https://lore.kernel.org/all/20241209151830.95723-1-herve.codina@bootlin.com/

[6]: 
https://lore.kernel.org/devicetree-spec/20250401081041.114333-1-herve.codina@bootlin.com/T/#t



Best Regards,

Ayush Singh

Powered by blists - more mailing lists