Hi ALex

-----Original Message-----
From: Alex G. <redacted>
Sent: mardi 9 mars 2021 22:50
To: Gabriel FERNANDEZ - foss <redacted>; Michael
Turquette [off-list ref]; Stephen Boyd
[off-list ref]; Rob Herring [off-list ref]; Maxime Coquelin
[off-list ref]; Alexandre TORGUE
[off-list ref]; Philipp Zabel [off-list ref];
Etienne CARRIERE [off-list ref]; marex@denx.de; Marek
Vasut [off-list ref]
Cc: devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
clk@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-stm32@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@foss.st.com wrote:

quoted

From: Gabriel Fernandez <redacted>

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

quoted

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

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