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

[Marek Vasut]

On 5/6/20 5:15 PM, Alexandre Torgue wrote:
> 
> 
> On 5/6/20 4:58 PM, Marek Vasut wrote:
>> On 5/6/20 4:55 PM, Alexandre Torgue wrote:
>>>
>>>
>>> On 5/6/20 4:39 PM, Marek Vasut wrote:
>>>> 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.
>>>
>>> Ok but we could choice to build only one (or few) possibilities. I mean
>>> maybe only mp157 ?
>>
>> But that one isn't gonna work for e.g. 153 then, would it?
> 
> No but we could let user of 153 do his own dts by hand. With a good
> split is not difficult to do.
> 
> For e.g I don't plan to upstream stm32mp153c-dk2 (I don't know if it
> really exist), but user could easily create his own stm32mp153c-dk2.dts
> by assembling well dtsi files and taking stm32mp157c-dk2 (or dk1) as
> example.

I would still want to make it easy for the users of this SoM to just use
it though. And I am quite sure there will be all combinations of it
eventually.

[...]