All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex G." <mr.nuke.me@gmail.com>
To: gabriel.fernandez@foss.st.com,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre Torgue <alexandre.torgue@st.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Etienne Carriere <etienne.carriere@st.com>,
	marex@denx.de, Marek Vasut <marex@denx.de>
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
Date: Tue, 9 Mar 2021 15:50:16 -0600	[thread overview]
Message-ID: <2e04f814-b694-119d-fe8a-13e6df129536@gmail.com> (raw)
In-Reply-To: <20210126090120.19900-1-gabriel.fernandez@foss.st.com>

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.

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
> 

WARNING: multiple messages have this Message-ID (diff)
From: "Alex G." <mr.nuke.me@gmail.com>
To: gabriel.fernandez@foss.st.com,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre Torgue <alexandre.torgue@st.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Etienne Carriere <etienne.carriere@st.com>,
	marex@denx.de, Marek Vasut <marex@denx.de>
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
Date: Tue, 9 Mar 2021 15:50:16 -0600	[thread overview]
Message-ID: <2e04f814-b694-119d-fe8a-13e6df129536@gmail.com> (raw)
In-Reply-To: <20210126090120.19900-1-gabriel.fernandez@foss.st.com>

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.

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
> 

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

  parent reply	other threads:[~2021-03-09 21:51 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-26  9:01 [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode gabriel.fernandez
2021-01-26  9:01 ` gabriel.fernandez
2021-01-26  9:01 ` [PATCH v2 01/14] clk: stm32mp1: merge 'clk-hsi-div' and 'ck_hsi' into one clock gabriel.fernandez
2021-01-26  9:01   ` gabriel.fernandez
2021-01-26  9:01 ` [PATCH v2 02/14] clk: stm32mp1: merge 'ck_hse_rtc' and 'ck_rtc' " gabriel.fernandez
2021-01-26  9:01   ` gabriel.fernandez
2021-02-09  8:00   ` Stephen Boyd
2021-02-09  8:00     ` Stephen Boyd
2021-02-12  8:08     ` gabriel.fernandez
2021-02-12  8:08       ` gabriel.fernandez
     [not found]       ` <161369805767.1254594.5233096495913117772@swboyd.mtv.corp.google.com>
2021-02-23 16:34         ` gabriel.fernandez
2021-02-23 16:34           ` gabriel.fernandez
2021-01-26  9:01 ` [PATCH v2 03/14] clk: stm32mp1: remove intermediate pll clocks gabriel.fernandez
2021-01-26  9:01   ` gabriel.fernandez
2021-01-26  9:01 ` [PATCH v2 04/14] clk: stm32mp1: convert to module driver gabriel.fernandez
2021-01-26  9:01   ` gabriel.fernandez
2021-01-26  9:01 ` [PATCH v2 05/14] clk: stm32mp1: move RCC reset controller into RCC clock driver gabriel.fernandez
2021-01-26  9:01   ` gabriel.fernandez
2021-01-26  9:01 ` [PATCH v2 06/14] reset: stm32mp1: remove stm32mp1 reset gabriel.fernandez
2021-01-26  9:01   ` gabriel.fernandez
2021-01-26  9:01 ` [PATCH v2 07/14] dt-bindings: clock: add IDs for SCMI clocks on stm32mp15 gabriel.fernandez
2021-01-26  9:01   ` gabriel.fernandez
2021-02-09 17:52   ` Rob Herring
2021-02-09 17:52     ` Rob Herring
2021-01-26  9:01 ` [PATCH v2 08/14] dt-bindings: reset: add IDs for SCMI reset domains " gabriel.fernandez
2021-01-26  9:01   ` gabriel.fernandez
2021-02-09 17:53   ` Rob Herring
2021-02-09 17:53     ` Rob Herring
2021-01-26  9:01 ` [PATCH v2 09/14] dt-bindings: reset: add MCU HOLD BOOT ID " gabriel.fernandez
2021-01-26  9:01   ` gabriel.fernandez
2021-02-09 17:54   ` Rob Herring
2021-02-09 17:54     ` Rob Herring
2021-01-26  9:01 ` [PATCH v2 10/14] clk: stm32mp1: new compatible for secure RCC support gabriel.fernandez
2021-01-26  9:01   ` gabriel.fernandez
2021-01-26  9:01 ` [PATCH v2 11/14] ARM: dts: stm32: define SCMI resources on stm32mp15 gabriel.fernandez
2021-01-26  9:01   ` gabriel.fernandez
2021-01-26  9:01 ` [PATCH v2 12/14] ARM: dts: stm32: move clocks/resets to SCMI resources for stm32mp15 gabriel.fernandez
2021-01-26  9:01   ` gabriel.fernandez
2021-02-18  9:45   ` [Linux-stm32] " Ahmad Fatoum
2021-02-18  9:45     ` Ahmad Fatoum
2021-01-26  9:01 ` [PATCH v2 13/14] dt-bindings: clock: stm32mp1 new compatible for secure rcc gabriel.fernandez
2021-01-26  9:01   ` gabriel.fernandez
2021-02-09 17:56   ` Rob Herring
2021-02-09 17:56     ` Rob Herring
2021-01-26  9:01 ` [PATCH v2 14/14] ARM: dts: stm32: introduce basic boot include on stm32mp15x board gabriel.fernandez
2021-01-26  9:01   ` gabriel.fernandez
2021-03-09 21:50 ` Alex G. [this message]
2021-03-09 21:50   ` [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode Alex G.
2021-03-11  8:08   ` Alexandre TORGUE
2021-03-11 11:43     ` Marek Vasut
2021-03-11 11:43       ` Marek Vasut
2021-03-11 13:15       ` Alexandre TORGUE
2021-03-11 13:23         ` Marek Vasut
2021-03-11 13:23           ` Marek Vasut
2021-03-11 14:02       ` Alexandre TORGUE
2021-03-11 14:41         ` [Linux-stm32] " Ahmad Fatoum
2021-03-11 14:41           ` Ahmad Fatoum
2021-03-11 15:18           ` Alexandre TORGUE
2021-03-11 15:49             ` Ahmad Fatoum
2021-03-11 15:49               ` Ahmad Fatoum
2021-03-11 16:11           ` Marek Vasut
2021-03-11 16:11             ` Marek Vasut
2021-03-11 18:10             ` Alexandre TORGUE
2021-03-11 18:23               ` Alex G.
2021-03-11 18:23                 ` Alex G.
2021-03-11 20:09               ` Marek Vasut
2021-03-11 20:09                 ` Marek Vasut
2021-03-12  8:22                 ` Alexandre TORGUE

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2e04f814-b694-119d-fe8a-13e6df129536@gmail.com \
    --to=mr.nuke.me@gmail.com \
    --cc=alexandre.torgue@st.com \
    --cc=devicetree@vger.kernel.org \
    --cc=etienne.carriere@st.com \
    --cc=gabriel.fernandez@foss.st.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=marex@denx.de \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=mturquette@baylibre.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.