From: Marek Vasut <marex@denx.de> To: Alexandre TORGUE <alexandre.torgue@foss.st.com>, Alexandre TORGUE <alexandre.torgue@st.com>, "Alex G." <mr.nuke.me@gmail.com>, Gabriel FERNANDEZ - foss <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>, Philipp Zabel <p.zabel@pengutronix.de>, Etienne CARRIERE <etienne.carriere@st.com> Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-stm32@st-md-mailman.stormreply.com" <linux-stm32@st-md-mailman.stormreply.com> Subject: Re: [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode Date: Thu, 11 Mar 2021 14:23:11 +0100 [thread overview] Message-ID: <838b70a1-c02c-0433-ac3d-fc48874b132d@denx.de> (raw) In-Reply-To: <ac98b89f-9664-b89c-c12c-24c1cbd29b00@foss.st.com> On 3/11/21 2:15 PM, Alexandre TORGUE wrote: > Hi Marek Hello Alexandre, > 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. > > The dtbo usage could avoid to add another st board (actually a secure > config) in arch/arm/boot/dts. It isn't even a board, it is a configuration. Could you detect this secure/non-secure state at runtime, have both clock options in the DT, and handle it accordingly ? That might be even better option.
WARNING: multiple messages have this Message-ID (diff)
From: Marek Vasut <marex@denx.de> To: Alexandre TORGUE <alexandre.torgue@foss.st.com>, Alexandre TORGUE <alexandre.torgue@st.com>, "Alex G." <mr.nuke.me@gmail.com>, Gabriel FERNANDEZ - foss <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>, Philipp Zabel <p.zabel@pengutronix.de>, Etienne CARRIERE <etienne.carriere@st.com> Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-stm32@st-md-mailman.stormreply.com" <linux-stm32@st-md-mailman.stormreply.com> Subject: Re: [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode Date: Thu, 11 Mar 2021 14:23:11 +0100 [thread overview] Message-ID: <838b70a1-c02c-0433-ac3d-fc48874b132d@denx.de> (raw) In-Reply-To: <ac98b89f-9664-b89c-c12c-24c1cbd29b00@foss.st.com> On 3/11/21 2:15 PM, Alexandre TORGUE wrote: > Hi Marek Hello Alexandre, > 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. > > The dtbo usage could avoid to add another st board (actually a secure > config) in arch/arm/boot/dts. It isn't even a board, it is a configuration. Could you detect this secure/non-secure state at runtime, have both clock options in the DT, and handle it accordingly ? That might be even better option. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-03-11 13:24 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 ` [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode Alex G. 2021-03-09 21:50 ` 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 [this message] 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=838b70a1-c02c-0433-ac3d-fc48874b132d@denx.de \ --to=marex@denx.de \ --cc=alexandre.torgue@foss.st.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=mcoquelin.stm32@gmail.com \ --cc=mr.nuke.me@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: linkBe 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.