Re: [Question] Status of user-space dynamic overlays API

[Luca Ceresoli <luca.ceresoli@bootlin.com>]

Hello Ayush,

On Wed, 30 Apr 2025 15:48:27 +0530
Ayush Singh <ayush@beagleboard.org> wrote:

> On 2/23/25 01:43, Ayush Singh wrote:
> 
> > Hello everyone.
> >
> > I have been looking at ways to do runtime devicetree overlay 
> > application, and was just wondering what the current status of the 
> > different proposals [0], [1] were. They seem to be quite old and I 
> > think they were already rejected, but due to all the broken links, I 
> > am not really sure about the exact reasons. Also, maybe we now have 
> > the solutions to some the blockers at the time.
> >
> >
> > Let me fist go over some of the use cases where I think dynamic 
> > devicetree overlays can be useful. I am mostly interested in their use 
> > in single board computers like PocketBeagle 2 [2], Raspberry Pi [3], etc.
> >
> >
> > # Uses
> >
> > ## Dynamic Pin muxing
> >
> > A lot of SBC's aimed for creating hardware projects expose headers, 
> > where each pin can be used for multiple things like GPIO, I2C, PWM, 
> > etc, depending on the pinmux. I think Raspberry Pi has it's own 
> > solution to do userspace pinmux, but if userspace devicetree 
> > application was a thing, it could probably be used for this. 
> > Additionally, being able to use dynamic devicetree overlays for pin 
> > muxing would allow much easier transition to use proper device trees 
> > during production.
> >
> >
> > ## Dynamic Sensors/Devices
> >
> > Using devices such as sensors, external ADCs, EEPROMs, etc are also a 
> > common usecase in SBC's. A lot of current solutions seem to be 
> > designed around using user-space drivers in such cases. This is a bit 
> > of a shame since Linux kernel already has drivers for a lot of these 
> > drivers, and they are probably going to be of higher quality than most 
> > user space drivers.
> >
> >
> > # Challenges
> >
> > ## Security
> >
> > The concerns regarding security seemed to show up in the other 
> > proposals. There was a proposal to have a devicetree property to 
> > allow/deny the application of overlays in some nodes, with default 
> > being deny. Was it insufficient?
> >
> >
> > ## Memory Leaks
> >
> > Currently, updating/removing properties leaks memory. Was it one of 
> > the reasons for the rejection of previous proposals?
> >
> >
> > Maybe kernel already has some solutions more suited to my usecase that 
> > I am unware of?
> >
> >
> > [0]: 
> > https://lore.kernel.org/all/1417605808-23327-1-git-send-email-pantelis.antoniou@konsulko.com/#t
> >
> > [1]: 
> > https://lore.kernel.org/all/20161220190455.25115-1-xypron.glpk@gmx.de/
> >
> > [2]: https://www.beagleboard.org/boards/pocketbeagle-2
> >
> > [3]: https://www.raspberrypi.com/
> >
> >
> > Best Regards,
> >
> > Ayush Singh
> >  
> 
> Just trying to consolidate the discussion. Feel free to correct anything 
> wrong.
> 
> 
> - Rather a generic global overlay solution, a driver per connector 
> should be used.
> 
> - The board headers (e.g. PocketBeagle 2) should be treated as a single 
> connector and any peripherals on it can be treated as an addon-board.

I agree with both points.

To the best of my knowledge this is also the position that everybody
agrees on, except Andrew Davis.

That said, I think this topic desperately needs some official feedback
from device tree and dt-schema maintainers: about export-symbols in the
very first place, and about i2c-bus-extension immediately after.
Otherwise we're keeping on circling around the same ideas after having
discussed and refined them so many times.

Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com