[Linux-stm32] [PATCH 01/12] ARM: dts: stm32: Add alternate pinmux for I2C2 pins

[Alexandre Torgue]

> All right, thanks.
> 
> btw I had this internal discussion now about handling the combinatorial
> explosion of board DTs here. If we support them all, by the end of the
> lifespan of these devices, we end up with:
> 
> STM32MP15{1,3,7}{a,c,d,f} SoM rev. {0..7}00 on baseboard rev. {0..7}00.
> 
> There won't be every SoM and baseboard revision combination all right.
> But even the amount of SoM options gives me 12 DTs. That is not a low
> number. Does ST have some plan to handle such situation ?

Yes I have the same point in mind. How to maintain all boards ? Should 
we refuse some boards and only keep one as example ?


> I can imagine that U-Boot can patch the DT and enable/disable
> functionality , which could handle the {a,c,d,f} options and reduce the
> amount of DTs. It could possibly also handle the {1,3,7} options.
> 

It is something I discussed with Kevin Hilman at ELCE and sometime with 
Rob on IIRc. We could use u-boot to handle differences between SoC, and 
boards. Technically it's possible but the main issue doing that is,  you 
will hide some updates in your bootloader and then your dtb used by 
kernel will not reflect your dts file. It could be confused for 
customers and users.

> Any other ideas ?

What is for you the main issue ? the number of files to add or how to 
maintain all those files ?

If it is the number of files to add, we can think about several ways:

1-As mentioned above, to only keep kind of reference platforms

2-Have vendor directories in arch/arm/boot/dts (but it's another story 
to make it accepted)

3-Or maybe use DTBO to overwrite some configuration.

If the concern is about how to maintain, maybe I'm wrong but I think 
that with a good split and factorization we could minimize support.

Currently I only those things in mind but nothing really mature.

regards
alex