Date:   Thu, 11 Mar 2021 15:41:12 +0100
From:   Ahmad Fatoum <a.fatoum@...gutronix.de>
To:     Alexandre TORGUE <alexandre.torgue@...s.st.com>,
        Marek Vasut <marex@...x.de>,
        Alexandre TORGUE <alexandre.torgue@...com>,
        "Alex G." <mr.nuke.me@...il.com>,
        Gabriel FERNANDEZ - foss <gabriel.fernandez@...s.st.com>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Etienne CARRIERE <etienne.carriere@...com>
Cc:     "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-stm32@...md-mailman.stormreply.com" 
        <linux-stm32@...md-mailman.stormreply.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>
Subject: Re: [Linux-stm32] [PATCH v2 00/14] Introduce STM32MP1 RCC in secured
 mode

Hello,

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.

Cheers,
Ahmad

> 
> 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-stm32 mailing list
> Linux-stm32@...md-mailman.stormreply.com
> https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Powered by blists - more mailing lists