[Linux-stm32] [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode

[Alexandre TORGUE]

Hi Marek

On 3/11/21 9:09 PM, Marek Vasut wrote:
> On 3/11/21 7:10 PM, Alexandre TORGUE wrote:
>> Hi Guys
>>
>> On 3/11/21 5:11 PM, Marek Vasut wrote:
>>> On 3/11/21 3:41 PM, Ahmad Fatoum wrote:
>>>> Hello,
>>>
>>> Hi,
>>>
>>>> On 11.03.21 15:02, Alexandre TORGUE wrote:
>>>>> On 3/11/21 12:43 PM, Marek Vasut wrote:
>>>>>> On 3/11/21 9:08 AM, Alexandre TORGUE wrote:
>>>>>>> 1- Break the current ABI: as soon as those patches are merged, 
>>>>>>> stm32mp157c-dk2.dtb will impose to use
>>>>>>> A tf-a for scmi clocks. For people using u-boot spl, the will 
>>>>>>> have to create their own "no-secure" devicetree.
>>>>>>
>>>>>> NAK, this breaks existing boards and existing setups, e.g. DK2 
>>>>>> that does not use ATF.
>>>>>>
>>>>>>> 2-As you suggest, create a new "secure" dtb per boards (Not my 
>>>>>>> wish for maintenance perspectives).
>>>>>>
>>>>>> I agree with Alex (G) that the "secure" option should be opt-in.
>>>>>> That way existing setups remain working and no extra requirements 
>>>>>> are imposed on MP1 users. Esp. since as far as I understand this, 
>>>>>> the "secure" part isn't really about security, but rather about 
>>>>>> moving clock configuration from Linux to some firmware blob.
>>>>>>
>>>>>>> 3- Keep kernel device tree as they are and applied this secure 
>>>>>>> layer (scmi clocks phandle) thanks to dtbo in
>>>>>>> U-boot.
>>>>>>
>>>>>> Is this really better than
>>>>>> #include "stm32mp15xx-enable-secure-stuff.dtsi"
>>>>>> in a board DT ? Because that is how I imagine the opt-in "secure" 
>>>>>> option could work.
>>>>>>
>>>>>
>>>>> Discussing with Patrick about u-boot, we could use dtbo application 
>>>>> thanks to extlinux.conf. BUT it it will not prevent other case 
>>>>> (i.e. TF-A which jump directly in kernel@). So the "least worst" 
>>>>> solution is to create a new "stm32mp1257c-scmi-dk2 board which will 
>>>>> overload clock entries with a scmi phandle (as proposed by Alex).
>>>>
>>>> I raised this issue before with your colleagues. I still believe the 
>>>> correct way
>>>> would be for the TF-A to pass down either a device tree or an 
>>>> overlay with the
>>>> actual settings in use, e.g.:
>>>>
>>>>    - Clocks/Resets done via SCMI
>>>>    - Reserved memory regions
>>>>
>>>> If TF-A directly boots Linux, it can apply the overlay itself, 
>>>> otherwise it's
>>>> passed down to SSBL that applies it before booting Linux.
>>>
>>> That sounds good and it is something e.g. R-Car already does, it 
>>> merges DT fragment from prior stages at U-Boot level and then passes 
>>> the result to Linux.
>>>
>>> So on ST hardware, the same could very well happen and it would work 
>>> for both non-ATF / ATF / ATF+TEE options.
>>
>> Even this solution sounds good but we are currently not able to do it 
>> in our TF-A/u-boot so not feasible for the moment.
> 
> Why not ? U-Boot is perfectly capable of merging prior stage DT and DT 
> loaded from elsewhere. See R-Car3 for example.

Ok, We will check what it is possible to do by this way before taking a 
decision.

Thanks
Alex

> 
>> So we have to find a solution for now. Create a new dtb can be this 
>> solution. Our internal strategy is to use scmi on our official ST 
>> board. It will be a really drawback to include a "no-scmi.dtsi" in DH 
>> boards (for example) and to create a stm32mp157c-noscmi-dk2.dts ?
> 
> I would highly prefer the SCMI to be opt-in, not opt-out.
> 
> But still, isn't it possible to auto-detect the board configuration in 
> Linux and pick the clock enumeration based on that automatically ?