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

[Herve Codina <herve.codina@bootlin.com>]

Hi Ajush,

On Mon, 24 Feb 2025 15:39:41 +0530
Ayush Singh <ayush@beagleboard.org> wrote:

> On 2/24/25 14:07, Geert Uytterhoeven wrote:
> 
> > Hi Ayush,
> >
> > On Sat, 22 Feb 2025 at 21:14, Ayush Singh <ayush@beagleboard.org> wrote:  
> >> # 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?  
> > This is the most important issue: using DT overlays, you can change
> > about anything.  There is no protection yet to limit this to e.g. the
> > expansion connectors on your board.
> > This is what the various WIP "connector" abstractions are trying
> > to solve.  
> 
> Thanks for clarifying. However, as I mentioned above, there are usecases 
> for dynamic overlays outside of connectors. Specifically, for the 
> usecase of connecting random sensors to board pins. I do agree that any 
> fairly well specified connector should probably have it's own drivers 
> rather than using a generic userspace API.
> 
> Would it be enough to use `aliases` to specify the nodes where an 
> overlay can be applied as I have described here [0]. To further lock 
> down things, it might be possible to allow introducing indirection or 
> scoping nodes of sort. Here is an example:
> 
> \ {
> 
> aliases {
> 
> export_node0 = &spi0_scoped;
> 
> };
> 
> };
> 
> &spi0 {
> 
> spi0_scoped {};
> 
> // Stuff already connected internally
> 
> };
> 
> Any children of `spi0_scoped` should be treated as devices directly 
> connected to `spi0` but should provided isolation for any changes that 
> userspace overlays can make.

For i2c bus, I introduced i2c bus extension feature.
  https://lore.kernel.org/all/20250205173918.600037-1-herve.codina@bootlin.com/

The series didn't received any feedback from i2c maintainer yet but I hope
to have soon.

The approach proposed the series could be adapted on spi busses too.

Do you think the bus extension approach could be used in your use cases ?

Best regards,
Hervé