Re: [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode

[Alexandre TORGUE <alexandre.torgue@foss.st.com>]

Hi

On 3/11/21 12:43 PM, Marek Vasut wrote:
> On 3/11/21 9:08 AM, Alexandre TORGUE wrote:
>> Hi ALex
> 
> Hello everyone,
> 
> [...]
> 
>>> Subject: Re: [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode
>>>
>>> On 1/26/21 3:01 AM, gabriel.fernandez@foss.st.com wrote:
>>>> From: Gabriel Fernandez <gabriel.fernandez@foss.st.com>
>>>>
>>>> Platform STM32MP1 can be used in configuration where some clocks and
>>>> IP resets can relate as secure resources.
>>>> These resources are moved from a RCC clock/reset handle to a SCMI
>>>> clock/reset_domain handle.
>>>>
>>>> The RCC clock driver is now dependent of the SCMI driver, then we have
>>>> to manage now the probe defering.
>>>>
>>>> v1 -> v2:
>>>>     - fix yamllint warnings.
>>>
>>> Hi Gabriel,
>>>
>>> I don't have much clout with the maintainers, but I have to NAK this 
>>> series
>>> after finding major breakage.
>>>
>>> The problem with series is that it breaks pretty much every board it 
>>> touches.
>>> I have a DK2 here that I'm using for development, which no longer 
>>> boots with
>>> this series applied.
>>>
>>> The crux of the matter is that this series assumes all boards will 
>>> boot with an
>>> FSBL that implements a very specific SCMI clock tree. This is major ABI
>>> breakage for anyone not using TF-A as the first stage bootloader. Anyone
>>> using u-boot SPL is screwed.
>>>
>>> This series imposes a SOC-wide change via the dtsi files. So even 
>>> boards that
>>> you don't intend to convert to SCMI will get broken this way.
>>> Adding a -no-scmi file that isn't used anywhere doesn't help things.
>>
>> You are right. We mainly take care about NO ST (DH/...) boards, but  
>> not really about current usage
>> Of our stm32 boards. Several options exist:
> 
> Since a lot of people benefit from the good upstream support for the MP1 
> _and_ keep updating their machines to get the latest fixes, it is very 
> important to keep the current usage working.
> 
>> 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).

Gabriel, can you wait a bit before sending something about SCMI in dtsi, 
I would like to align this strategy internally.

Marek, Alex: thanks for your inputs.

Regards
Alex

>> The third could be the less costly.
> 
> [...]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel