On 2/23/25 02:01, Heinrich Schuchardt wrote:
Am 22. Februar 2025 21:13:56 MEZ schrieb Ayush Singh <ayush@xxxxxxxxxxxxxxx>:
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@xxxxxxxxxxxx/#t
[1]: https://lore.kernel.org/all/20161220190455.25115-1-xypron.glpk@xxxxxx/
[2]: https://www.beagleboard.org/boards/pocketbeagle-2
[3]: https://www.raspberrypi.com/
Best Regards,
Ayush Singh
Hello Ayush,
On [1] I gave up when I got the impression that the maintainers only wanted to further their own companies interest and did not show openness for a globally usable functionality.
Best regards
Heinrich
I am thinking about an implementation more in line with your sysfs
proposal [0]. Maybe I should send an RFC to get more replies but here is
what I was thinking of:
Having a property in `aliases` such as `export_node{num}` to explicitly
export nodes which support overlay application. The `of_sysfs` module
will create sysfs entries for each of exported nodes.
The same files as [0] will be provided for each node:
load: This is a write only file. Data written to it is interpreted as
devicetree blob, and applied using `of_overlay_fdt_apply()` to the
target node.
loaded: This is a read only file.
It provides the count of loaded overlays as a decimal
number.
unload: This is a write only file.
If a positive number n is wrtten to this file the n
most recent overlays are destroyed.
If a negative number is written to this file all
overlays are destroyed.
Since any nodes that can have dynamic overlays applied need to be
explicitly enabled in base devicetree, I think this should help with
some security concerns.
I am a bit unsure if I would need to create a new device for each of the
exported node or just create kobject for each node directly (since the
sysfs entries should probably be under
`/sys/firmware/overlays/export_node{num}` rather than `/sys/devices`).
[0]: https://lore.kernel.org/all/20161220190455.25115-1-xypron.glpk@xxxxxx/
Best Regards,
Ayush Singh
