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

[Alexandre TORGUE]

Hi ALex

> -----Original Message-----
> From: Alex G. <mr.nuke.me at gmail.com>
> Sent: mardi 9 mars 2021 22:50
> To: Gabriel FERNANDEZ - foss <gabriel.fernandez at foss.st.com>; Michael
> Turquette <mturquette at baylibre.com>; Stephen Boyd
> <sboyd at kernel.org>; Rob Herring <robh+dt at kernel.org>; Maxime Coquelin
> <mcoquelin.stm32 at gmail.com>; Alexandre TORGUE
> <alexandre.torgue at st.com>; Philipp Zabel <p.zabel at pengutronix.de>;
> Etienne CARRIERE <etienne.carriere at st.com>; marex at denx.de; Marek
> Vasut <marex at denx.de>
> Cc: devicetree at vger.kernel.org; linux-kernel at vger.kernel.org; linux-
> clk at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-stm32 at st-
> md-mailman.stormreply.com
> Subject: Re: [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode
> 
> On 1/26/21 3:01 AM, gabriel.fernandez at foss.st.com wrote:
> > From: Gabriel Fernandez <gabriel.fernandez at 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:

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.

2-As you suggest, create a new "secure" dtb per boards (Not my wish for maintenance perspectives).

3- Keep kernel device tree as they are and applied this secure layer (scmi clocks phandle) thanks to dtbo in
U-boot.

The third could be the less costly.

Thanks 
Alex

> Here's what I suggest:
> 
> Generate new dtb files for those boards that you want to convert. So you
> would get:
>    - stm32mp157c-dk2.dtb # Good old hardware clocks
>    - stm32mp157c-dk2-secure-rcc.dtb # Clocks accessible by scmi.
> 
> A lot of users use a larger build system where they extract the relevant files.
> With the scheme I'm proposing you don't break their builds, and you allow
> SCMI users to have upstream support.
> 
> This means that you'll have to rethink the DTS and DTSI changes to
> accomodate both use cases.
> 
> Thanks,
> Alex
> 
> 
> 
> 
> >
> > Gabriel Fernandez (14):
> >    clk: stm32mp1: merge 'clk-hsi-div' and 'ck_hsi' into one clock
> >    clk: stm32mp1: merge 'ck_hse_rtc' and 'ck_rtc' into one clock
> >    clk: stm32mp1: remove intermediate pll clocks
> >    clk: stm32mp1: convert to module driver
> >    clk: stm32mp1: move RCC reset controller into RCC clock driver
> >    reset: stm32mp1: remove stm32mp1 reset
> >    dt-bindings: clock: add IDs for SCMI clocks on stm32mp15
> >    dt-bindings: reset: add IDs for SCMI reset domains on stm32mp15
> >    dt-bindings: reset: add MCU HOLD BOOT ID for SCMI reset domains on
> >      stm32mp15
> >    clk: stm32mp1: new compatible for secure RCC support
> >    ARM: dts: stm32: define SCMI resources on stm32mp15
> >    ARM: dts: stm32: move clocks/resets to SCMI resources for stm32mp15
> >    dt-bindings: clock: stm32mp1 new compatible for secure rcc
> >    ARM: dts: stm32: introduce basic boot include on stm32mp15x board
> >
> >   .../bindings/clock/st,stm32mp1-rcc.yaml       |   6 +-
> >   arch/arm/boot/dts/stm32mp15-no-scmi.dtsi      | 158 ++++++
> >   arch/arm/boot/dts/stm32mp151.dtsi             | 127 +++--
> >   arch/arm/boot/dts/stm32mp153.dtsi             |   4 +-
> >   arch/arm/boot/dts/stm32mp157.dtsi             |   2 +-
> >   arch/arm/boot/dts/stm32mp15xc.dtsi            |   4 +-
> >   drivers/clk/Kconfig                           |  10 +
> >   drivers/clk/clk-stm32mp1.c                    | 495 +++++++++++++++---
> >   drivers/reset/Kconfig                         |   6 -
> >   drivers/reset/Makefile                        |   1 -
> >   drivers/reset/reset-stm32mp1.c                | 115 ----
> >   include/dt-bindings/clock/stm32mp1-clks.h     |  27 +
> >   include/dt-bindings/reset/stm32mp1-resets.h   |  15 +
> >   13 files changed, 704 insertions(+), 266 deletions(-)
> >   create mode 100644 arch/arm/boot/dts/stm32mp15-no-scmi.dtsi
> >   delete mode 100644 drivers/reset/reset-stm32mp1.c
> >