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

[Marek Vasut]

On 5/6/20 4:26 PM, Alexandre Torgue wrote:
> 
> 
> 
>> 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 ?

But which ones do you want to drop? The pdk2 is a devkit , so you can
put in any SoM option, that's the problem.

>> 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.

Yes.

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

The number. Maintaining them is not that much of a problem.

> 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)

Maybe that's something we should consider for arm32, but that's a
different discussion altogether.

> 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.

I hope this patchset does the split right, it's the number.