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

STALE1967d

Revision v2 of 4 in this series.

36 messages, 8 authors, 2021-03-12 · open the first message on its own page

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

From: <hidden>
Date: 2021-01-26 17:59:45 

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.

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

-- 
2.17.1


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

[PATCH v2 05/14] clk: stm32mp1: move RCC reset controller into RCC clock driver

From: <hidden>
Date: 2021-01-26 11:24:50 

From: Gabriel Fernandez <redacted>

RCC clock and reset controller shared same memory mapping.
As RCC clock driver is now a module, the best way to register clock
and reset controller is to do it in same driver.

Signed-off-by: Gabriel Fernandez <redacted>
---
 drivers/clk/clk-stm32mp1.c | 157 ++++++++++++++++++++++++++++++++++---
 1 file changed, 144 insertions(+), 13 deletions(-)

diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
index 530babc4c4b6..25e3f272344c 100644
--- a/drivers/clk/clk-stm32mp1.c
+++ b/drivers/clk/clk-stm32mp1.c
@@ -14,6 +14,7 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/platform_device.h>
+#include <linux/reset-controller.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
 
@@ -2050,16 +2051,18 @@ static const struct clock_config stm32mp1_clock_cfg[] = {
 		  _DIV(RCC_DBGCFGR, 0, 3, 0, ck_trace_div_table)),
 };
 
-struct stm32_clock_match_data {
+struct stm32_rcc_match_data {
 	const struct clock_config *cfg;
 	unsigned int num;
 	unsigned int maxbinding;
+	u32 clear_offset;
 };
 
-static struct stm32_clock_match_data stm32mp1_data = {
+static struct stm32_rcc_match_data stm32mp1_data = {
 	.cfg		= stm32mp1_clock_cfg,
 	.num		= ARRAY_SIZE(stm32mp1_clock_cfg),
 	.maxbinding	= STM32MP1_LAST_CLK,
+	.clear_offset	= RCC_CLR,
 };
 
 static const struct of_device_id stm32mp1_match_data[] = {
@@ -2095,23 +2098,122 @@ static int stm32_register_hw_clk(struct device *dev,
 	return 0;
 }
 
-static int stm32_rcc_init(struct device *dev, void __iomem *base,
-			  const struct of_device_id *match_data)
+#define STM32_RESET_ID_MASK GENMASK(15, 0)
+
+struct stm32_reset_data {
+	/* reset lock */
+	spinlock_t			lock;
+	struct reset_controller_dev	rcdev;
+	void __iomem			*membase;
+	u32				clear_offset;
+};
+
+static inline struct stm32_reset_data *
+to_stm32_reset_data(struct reset_controller_dev *rcdev)
 {
-	struct clk_hw_onecell_data *clk_data;
-	struct clk_hw **hws;
-	const struct of_device_id *match;
-	const struct stm32_clock_match_data *data;
-	int err, n, max_binding;
+	return container_of(rcdev, struct stm32_reset_data, rcdev);
+}
 
-	match = of_match_node(match_data, dev_of_node(dev));
-	if (!match) {
-		dev_err(dev, "match data not found\n");
-		return -ENODEV;
+static int stm32_reset_update(struct reset_controller_dev *rcdev,
+			      unsigned long id, bool assert)
+{
+	struct stm32_reset_data *data = to_stm32_reset_data(rcdev);
+	int reg_width = sizeof(u32);
+	int bank = id / (reg_width * BITS_PER_BYTE);
+	int offset = id % (reg_width * BITS_PER_BYTE);
+
+	if (data->clear_offset) {
+		void __iomem *addr;
+
+		addr = data->membase + (bank * reg_width);
+		if (!assert)
+			addr += data->clear_offset;
+
+		writel(BIT(offset), addr);
+
+	} else {
+		unsigned long flags;
+		u32 reg;
+
+		spin_lock_irqsave(&data->lock, flags);
+
+		reg = readl(data->membase + (bank * reg_width));
+
+		if (assert)
+			reg |= BIT(offset);
+		else
+			reg &= ~BIT(offset);
+
+		writel(reg, data->membase + (bank * reg_width));
+
+		spin_unlock_irqrestore(&data->lock, flags);
 	}
 
+	return 0;
+}
+
+static int stm32_reset_assert(struct reset_controller_dev *rcdev,
+			      unsigned long id)
+{
+	return stm32_reset_update(rcdev, id, true);
+}
+
+static int stm32_reset_deassert(struct reset_controller_dev *rcdev,
+				unsigned long id)
+{
+	return stm32_reset_update(rcdev, id, false);
+}
+
+static int stm32_reset_status(struct reset_controller_dev *rcdev,
+			      unsigned long id)
+{
+	struct stm32_reset_data *data = to_stm32_reset_data(rcdev);
+	int reg_width = sizeof(u32);
+	int bank = id / (reg_width * BITS_PER_BYTE);
+	int offset = id % (reg_width * BITS_PER_BYTE);
+	u32 reg;
+
+	reg = readl(data->membase + (bank * reg_width));
+
+	return !!(reg & BIT(offset));
+}
+
+static const struct reset_control_ops stm32_reset_ops = {
+	.assert		= stm32_reset_assert,
+	.deassert	= stm32_reset_deassert,
+	.status		= stm32_reset_status,
+};
+
+static int stm32_rcc_reset_init(struct device *dev, void __iomem *base,
+				const struct of_device_id *match)
+{
+	const struct stm32_rcc_match_data *data = match->data;
+	struct stm32_reset_data *reset_data = NULL;
+
 	data = match->data;
 
+	reset_data = kzalloc(sizeof(*reset_data), GFP_KERNEL);
+	if (!reset_data)
+		return -ENOMEM;
+
+	reset_data->membase = base;
+	reset_data->rcdev.owner = THIS_MODULE;
+	reset_data->rcdev.ops = &stm32_reset_ops;
+	reset_data->rcdev.of_node = dev_of_node(dev);
+	reset_data->rcdev.nr_resets = STM32_RESET_ID_MASK;
+	reset_data->clear_offset = data->clear_offset;
+
+	return reset_controller_register(&reset_data->rcdev);
+}
+
+static int stm32_rcc_clock_init(struct device *dev, void __iomem *base,
+				const struct of_device_id *match)
+{
+	const struct stm32_rcc_match_data *data = match->data;
+	struct clk_hw_onecell_data *clk_data;
+	struct clk_hw **hws;
+	int err, n, max_binding;
+
 	max_binding =  data->maxbinding;
 
 	clk_data = devm_kzalloc(dev, struct_size(clk_data, hws, max_binding),
@@ -2140,6 +2242,35 @@ static int stm32_rcc_init(struct device *dev, void __iomem *base,
 	return of_clk_add_hw_provider(dev_of_node(dev), of_clk_hw_onecell_get, clk_data);
 }
 
+static int stm32_rcc_init(struct device *dev, void __iomem *base,
+			  const struct of_device_id *match_data)
+{
+	const struct of_device_id *match;
+	int err;
+
+	match = of_match_node(match_data, dev_of_node(dev));
+	if (!match) {
+		dev_err(dev, "match data not found\n");
+		return -ENODEV;
+	}
+
+	/* RCC Reset Configuration */
+	err = stm32_rcc_reset_init(dev, base, match);
+	if (err) {
+		pr_err("stm32mp1 reset failed to initialize\n");
+		return err;
+	}
+
+	/* RCC Clock Configuration */
+	err = stm32_rcc_clock_init(dev, base, match);
+	if (err) {
+		pr_err("stm32mp1 clock failed to initialize\n");
+		return err;
+	}
+
+	return 0;
+}
+
 static int stm32mp1_rcc_init(struct device *dev)
 {
 	void __iomem *base;
-- 
2.17.1


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

[PATCH v2 08/14] dt-bindings: reset: add IDs for SCMI reset domains on stm32mp15

From: <hidden>
Date: 2021-01-26 12:06:02 

From: Gabriel Fernandez <redacted>

stm32mp15 TZ secure firmware provides SCMI reset domains for
secure resources. This change defines the SCMI reset domain
identifiers used by SCMI agents and servers.

Stm32mp15 TZ secure firmware provides SCMI clocks for oscillators, some
PLL output and few secure aware interfaces. This change defines the
SCMI clock identifiers used by SCMI agents and servers.

Server SCMI0 exposes reset controllers for resources under RCC[TZEN]
configuration control.

Signed-off-by: Etienne Carriere <redacted>
Signed-off-by: Gabriel Fernandez <redacted>
---
 include/dt-bindings/reset/stm32mp1-resets.h | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/include/dt-bindings/reset/stm32mp1-resets.h b/include/dt-bindings/reset/stm32mp1-resets.h
index f0c3aaef67a0..bc71924faa54 100644
--- a/include/dt-bindings/reset/stm32mp1-resets.h
+++ b/include/dt-bindings/reset/stm32mp1-resets.h
@@ -105,4 +105,17 @@
 #define GPIOJ_R		19785
 #define GPIOK_R		19786
 
+/* SCMI reset domain identifiers */
+#define RST_SCMI0_SPI6		0
+#define RST_SCMI0_I2C4		1
+#define RST_SCMI0_I2C6		2
+#define RST_SCMI0_USART1	3
+#define RST_SCMI0_STGEN		4
+#define RST_SCMI0_GPIOZ		5
+#define RST_SCMI0_CRYP1		6
+#define RST_SCMI0_HASH1		7
+#define RST_SCMI0_RNG1		8
+#define RST_SCMI0_MDMA		9
+#define RST_SCMI0_MCU		10
+
 #endif /* _DT_BINDINGS_STM32MP1_RESET_H_ */
-- 
2.17.1


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

Re: [PATCH v2 08/14] dt-bindings: reset: add IDs for SCMI reset domains on stm32mp15

From: Rob Herring <robh@kernel.org>
Date: 2021-02-09 19:12:30 

On Tue, 26 Jan 2021 10:01:14 +0100, gabriel.fernandez@foss.st.com wrote:
From: Gabriel Fernandez <redacted>

stm32mp15 TZ secure firmware provides SCMI reset domains for
secure resources. This change defines the SCMI reset domain
identifiers used by SCMI agents and servers.

Stm32mp15 TZ secure firmware provides SCMI clocks for oscillators, some
PLL output and few secure aware interfaces. This change defines the
SCMI clock identifiers used by SCMI agents and servers.

Server SCMI0 exposes reset controllers for resources under RCC[TZEN]
configuration control.

Signed-off-by: Etienne Carriere <redacted>
Signed-off-by: Gabriel Fernandez <redacted>
---
 include/dt-bindings/reset/stm32mp1-resets.h | 13 +++++++++++++
 1 file changed, 13 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>

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

[PATCH v2 01/14] clk: stm32mp1: merge 'clk-hsi-div' and 'ck_hsi' into one clock

From: <hidden>
Date: 2021-01-26 17:59:45 

From: Gabriel Fernandez <redacted>

This patch is to prepare STM32MP1 clocks in trusted mode.
This Merge will facilitate to have a more coherent clock tree
in no trusted / trusted world.

Signed-off-by: Gabriel Fernandez <redacted>
---
 drivers/clk/clk-stm32mp1.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
index a875649df8b8..35d5aee8f9b0 100644
--- a/drivers/clk/clk-stm32mp1.c
+++ b/drivers/clk/clk-stm32mp1.c
@@ -1657,16 +1657,16 @@ static const struct stm32_mux_cfg ker_mux_cfg[M_LAST] = {
 };
 
 static const struct clock_config stm32mp1_clock_cfg[] = {
-	/* Oscillator divider */
-	DIV(NO_ID, "clk-hsi-div", "clk-hsi", CLK_DIVIDER_POWER_OF_TWO,
-	    RCC_HSICFGR, 0, 2, CLK_DIVIDER_READ_ONLY),
-
 	/*  External / Internal Oscillators */
 	GATE_MP1(CK_HSE, "ck_hse", "clk-hse", 0, RCC_OCENSETR, 8, 0),
 	/* ck_csi is used by IO compensation and should be critical */
 	GATE_MP1(CK_CSI, "ck_csi", "clk-csi", CLK_IS_CRITICAL,
 		 RCC_OCENSETR, 4, 0),
-	GATE_MP1(CK_HSI, "ck_hsi", "clk-hsi-div", 0, RCC_OCENSETR, 0, 0),
+	COMPOSITE(CK_HSI, "ck_hsi", PARENT("clk-hsi"), 0,
+		  _GATE_MP1(RCC_OCENSETR, 0, 0),
+		  _NO_MUX,
+		  _DIV(RCC_HSICFGR, 0, 2, CLK_DIVIDER_POWER_OF_TWO |
+		       CLK_DIVIDER_READ_ONLY, NULL)),
 	GATE(CK_LSI, "ck_lsi", "clk-lsi", 0, RCC_RDLSICR, 0, 0),
 	GATE(CK_LSE, "ck_lse", "clk-lse", 0, RCC_BDCR, 0, 0),
 
-- 
2.17.1


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

[PATCH v2 04/14] clk: stm32mp1: convert to module driver

From: <hidden>
Date: 2021-01-26 18:00:20 

From: Gabriel Fernandez <redacted>

Adds support for  probe deferral in way to prepare
integration of the security in RCC clock and reset
drivers.
Some kernel clocks will be provided by the SCMI drivers.
Since RCC clock driver create clocks which parents
are SCMI clocks, RCC clock driver probe can be deferred.

Signed-off-by: Etienne Carriere <redacted>
Signed-off-by: Gabriel Fernandez <redacted>
---
 drivers/clk/clk-stm32mp1.c | 121 ++++++++++++++++++++++++-------------
 1 file changed, 78 insertions(+), 43 deletions(-)

diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
index ee6968a2ad57..530babc4c4b6 100644
--- a/drivers/clk/clk-stm32mp1.c
+++ b/drivers/clk/clk-stm32mp1.c
@@ -10,8 +10,10 @@
 #include <linux/delay.h>
 #include <linux/err.h>
 #include <linux/io.h>
+#include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
+#include <linux/platform_device.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
 
@@ -469,7 +471,7 @@ static const struct clk_ops mp1_gate_clk_ops = {
 	.is_enabled	= clk_gate_is_enabled,
 };
 
-static struct clk_hw *_get_stm32_mux(void __iomem *base,
+static struct clk_hw *_get_stm32_mux(struct device *dev, void __iomem *base,
 				     const struct stm32_mux_cfg *cfg,
 				     spinlock_t *lock)
 {
@@ -478,7 +480,7 @@ static struct clk_hw *_get_stm32_mux(void __iomem *base,
 	struct clk_hw *mux_hw;
 
 	if (cfg->mmux) {
-		mmux = kzalloc(sizeof(*mmux), GFP_KERNEL);
+		mmux = devm_kzalloc(dev, sizeof(*mmux), GFP_KERNEL);
 		if (!mmux)
 			return ERR_PTR(-ENOMEM);
 
@@ -493,7 +495,7 @@ static struct clk_hw *_get_stm32_mux(void __iomem *base,
 		cfg->mmux->hws[cfg->mmux->nbr_clk++] = mux_hw;
 
 	} else {
-		mux = kzalloc(sizeof(*mux), GFP_KERNEL);
+		mux = devm_kzalloc(dev, sizeof(*mux), GFP_KERNEL);
 		if (!mux)
 			return ERR_PTR(-ENOMEM);
 
@@ -509,13 +511,13 @@ static struct clk_hw *_get_stm32_mux(void __iomem *base,
 	return mux_hw;
 }
 
-static struct clk_hw *_get_stm32_div(void __iomem *base,
+static struct clk_hw *_get_stm32_div(struct device *dev, void __iomem *base,
 				     const struct stm32_div_cfg *cfg,
 				     spinlock_t *lock)
 {
 	struct clk_divider *div;
 
-	div = kzalloc(sizeof(*div), GFP_KERNEL);
+	div = devm_kzalloc(dev, sizeof(*div), GFP_KERNEL);
 
 	if (!div)
 		return ERR_PTR(-ENOMEM);
@@ -530,16 +532,16 @@ static struct clk_hw *_get_stm32_div(void __iomem *base,
 	return &div->hw;
 }
 
-static struct clk_hw *
-_get_stm32_gate(void __iomem *base,
-		const struct stm32_gate_cfg *cfg, spinlock_t *lock)
+static struct clk_hw *_get_stm32_gate(struct device *dev, void __iomem *base,
+				      const struct stm32_gate_cfg *cfg,
+				      spinlock_t *lock)
 {
 	struct stm32_clk_mgate *mgate;
 	struct clk_gate *gate;
 	struct clk_hw *gate_hw;
 
 	if (cfg->mgate) {
-		mgate = kzalloc(sizeof(*mgate), GFP_KERNEL);
+		mgate = devm_kzalloc(dev, sizeof(*mgate), GFP_KERNEL);
 		if (!mgate)
 			return ERR_PTR(-ENOMEM);
 
@@ -554,7 +556,7 @@ _get_stm32_gate(void __iomem *base,
 		gate_hw = &mgate->gate.hw;
 
 	} else {
-		gate = kzalloc(sizeof(*gate), GFP_KERNEL);
+		gate = devm_kzalloc(dev, sizeof(*gate), GFP_KERNEL);
 		if (!gate)
 			return ERR_PTR(-ENOMEM);
 
@@ -592,7 +594,7 @@ clk_stm32_register_gate_ops(struct device *dev,
 	if (cfg->ops)
 		init.ops = cfg->ops;
 
-	hw = _get_stm32_gate(base, cfg, lock);
+	hw = _get_stm32_gate(dev, base, cfg, lock);
 	if (IS_ERR(hw))
 		return ERR_PTR(-ENOMEM);
 
@@ -623,7 +625,7 @@ clk_stm32_register_composite(struct device *dev,
 	gate_ops = NULL;
 
 	if (cfg->mux) {
-		mux_hw = _get_stm32_mux(base, cfg->mux, lock);
+		mux_hw = _get_stm32_mux(dev, base, cfg->mux, lock);
 
 		if (!IS_ERR(mux_hw)) {
 			mux_ops = &clk_mux_ops;
@@ -634,7 +636,7 @@ clk_stm32_register_composite(struct device *dev,
 	}
 
 	if (cfg->div) {
-		div_hw = _get_stm32_div(base, cfg->div, lock);
+		div_hw = _get_stm32_div(dev, base, cfg->div, lock);
 
 		if (!IS_ERR(div_hw)) {
 			div_ops = &clk_divider_ops;
@@ -645,7 +647,7 @@ clk_stm32_register_composite(struct device *dev,
 	}
 
 	if (cfg->gate) {
-		gate_hw = _get_stm32_gate(base, cfg->gate, lock);
+		gate_hw = _get_stm32_gate(dev, base, cfg->gate, lock);
 
 		if (!IS_ERR(gate_hw)) {
 			gate_ops = &clk_gate_ops;
@@ -890,7 +892,7 @@ static struct clk_hw *clk_register_pll(struct device *dev, const char *name,
 	struct clk_hw *hw;
 	int err;
 
-	element = kzalloc(sizeof(*element), GFP_KERNEL);
+	element = devm_kzalloc(dev, sizeof(*element), GFP_KERNEL);
 	if (!element)
 		return ERR_PTR(-ENOMEM);
 
@@ -914,10 +916,8 @@ static struct clk_hw *clk_register_pll(struct device *dev, const char *name,
 	hw = &element->hw;
 	err = clk_hw_register(dev, hw);
 
-	if (err) {
-		kfree(element);
+	if (err)
 		return ERR_PTR(err);
-	}
 
 	return hw;
 }
@@ -1028,7 +1028,7 @@ static struct clk_hw *clk_register_cktim(struct device *dev, const char *name,
 	struct clk_hw *hw;
 	int err;
 
-	tim_ker = kzalloc(sizeof(*tim_ker), GFP_KERNEL);
+	tim_ker = devm_kzalloc(dev, sizeof(*tim_ker), GFP_KERNEL);
 	if (!tim_ker)
 		return ERR_PTR(-ENOMEM);
 
@@ -1046,10 +1046,8 @@ static struct clk_hw *clk_register_cktim(struct device *dev, const char *name,
 	hw = &tim_ker->hw;
 	err = clk_hw_register(dev, hw);
 
-	if (err) {
-		kfree(tim_ker);
+	if (err)
 		return ERR_PTR(err);
-	}
 
 	return hw;
 }
@@ -2071,6 +2069,7 @@ static const struct of_device_id stm32mp1_match_data[] = {
 	},
 	{ }
 };
+MODULE_DEVICE_TABLE(of, stm32mp1_match_data);
 
 static int stm32_register_hw_clk(struct device *dev,
 				 struct clk_hw_onecell_data *clk_data,
@@ -2096,8 +2095,7 @@ static int stm32_register_hw_clk(struct device *dev,
 	return 0;
 }
 
-static int stm32_rcc_init(struct device_node *np,
-			  void __iomem *base,
+static int stm32_rcc_init(struct device *dev, void __iomem *base,
 			  const struct of_device_id *match_data)
 {
 	struct clk_hw_onecell_data *clk_data;
@@ -2106,9 +2104,9 @@ static int stm32_rcc_init(struct device_node *np,
 	const struct stm32_clock_match_data *data;
 	int err, n, max_binding;
 
-	match = of_match_node(match_data, np);
+	match = of_match_node(match_data, dev_of_node(dev));
 	if (!match) {
-		pr_err("%s: match data not found\n", __func__);
+		dev_err(dev, "match data not found\n");
 		return -ENODEV;
 	}
 
@@ -2116,8 +2114,8 @@ static int stm32_rcc_init(struct device_node *np,
 
 	max_binding =  data->maxbinding;
 
-	clk_data = kzalloc(struct_size(clk_data, hws, max_binding),
-			   GFP_KERNEL);
+	clk_data = devm_kzalloc(dev, struct_size(clk_data, hws, max_binding),
+				GFP_KERNEL);
 	if (!clk_data)
 		return -ENOMEM;
 
@@ -2129,36 +2127,73 @@ static int stm32_rcc_init(struct device_node *np,
 		hws[n] = ERR_PTR(-ENOENT);
 
 	for (n = 0; n < data->num; n++) {
-		err = stm32_register_hw_clk(NULL, clk_data, base, &rlock,
+		err = stm32_register_hw_clk(dev, clk_data, base, &rlock,
 					    &data->cfg[n]);
 		if (err) {
-			pr_err("%s: can't register  %s\n", __func__,
-			       data->cfg[n].name);
-
-			kfree(clk_data);
+			dev_err(dev, "Can't register clk %s: %d\n",
+				data->cfg[n].name, err);
 
 			return err;
 		}
 	}
 
-	return of_clk_add_hw_provider(np, of_clk_hw_onecell_get, clk_data);
+	return of_clk_add_hw_provider(dev_of_node(dev), of_clk_hw_onecell_get, clk_data);
 }
 
-static void stm32mp1_rcc_init(struct device_node *np)
+static int stm32mp1_rcc_init(struct device *dev)
 {
 	void __iomem *base;
+	int ret;
 
-	base = of_iomap(np, 0);
+	base = of_iomap(dev_of_node(dev), 0);
 	if (!base) {
-		pr_err("%pOFn: unable to map resource", np);
-		of_node_put(np);
-		return;
+		pr_err("%pOFn: unable to map resource", dev_of_node(dev));
+		ret = -ENOMEM;
+		goto out;
 	}
 
-	if (stm32_rcc_init(np, base, stm32mp1_match_data)) {
-		iounmap(base);
-		of_node_put(np);
+	ret = stm32_rcc_init(dev, base, stm32mp1_match_data);
+
+out:
+	if (ret) {
+		if (base)
+			iounmap(base);
+
+		of_node_put(dev_of_node(dev));
 	}
+
+	return ret;
+}
+
+static int stm32mp1_rcc_clocks_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+
+	return stm32mp1_rcc_init(dev);
+}
+
+static int stm32mp1_rcc_clocks_remove(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *child, *np = dev_of_node(dev);
+
+	for_each_available_child_of_node(np, child)
+		of_clk_del_provider(child);
+
+	return 0;
 }
 
-CLK_OF_DECLARE_DRIVER(stm32mp1_rcc, "st,stm32mp1-rcc", stm32mp1_rcc_init);
+static struct platform_driver stm32mp1_rcc_clocks_driver = {
+	.driver	= {
+		.name = "stm32mp1_rcc",
+		.of_match_table = stm32mp1_match_data,
+	},
+	.probe = stm32mp1_rcc_clocks_probe,
+	.remove = stm32mp1_rcc_clocks_remove,
+};
+
+static int __init stm32mp1_clocks_init(void)
+{
+	return platform_driver_register(&stm32mp1_rcc_clocks_driver);
+}
+core_initcall(stm32mp1_clocks_init);
-- 
2.17.1


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

[PATCH v2 03/14] clk: stm32mp1: remove intermediate pll clocks

From: <hidden>
Date: 2021-01-26 18:00:21 

From: Gabriel Fernandez <redacted>

This patch is to prepare STM32MP1 clocks in trusted mode.
Integrate the mux clock into pll clock will facilitate to have a more
coherent clock tree in no trusted / trusted mode.

Signed-off-by: Gabriel Fernandez <redacted>
---
 drivers/clk/clk-stm32mp1.c | 65 ++++++++++++++++++++++++--------------
 1 file changed, 42 insertions(+), 23 deletions(-)

diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
index 0e1d4427a8df..ee6968a2ad57 100644
--- a/drivers/clk/clk-stm32mp1.c
+++ b/drivers/clk/clk-stm32mp1.c
@@ -731,6 +731,7 @@ struct stm32_pll_obj {
 	spinlock_t *lock;
 	void __iomem *reg;
 	struct clk_hw hw;
+	struct clk_mux mux;
 };
 
 #define to_pll(_hw) container_of(_hw, struct stm32_pll_obj, hw)
@@ -745,6 +746,8 @@ struct stm32_pll_obj {
 #define FRAC_MASK	0x1FFF
 #define FRAC_SHIFT	3
 #define FRACLE		BIT(16)
+#define PLL_MUX_SHIFT	0
+#define PLL_MUX_MASK	3
 
 static int __pll_is_enabled(struct clk_hw *hw)
 {
@@ -856,16 +859,29 @@ static int pll_is_enabled(struct clk_hw *hw)
 	return ret;
 }
 
+static u8 pll_get_parent(struct clk_hw *hw)
+{
+	struct stm32_pll_obj *clk_elem = to_pll(hw);
+	struct clk_hw *mux_hw = &clk_elem->mux.hw;
+
+	__clk_hw_set_clk(mux_hw, hw);
+
+	return clk_mux_ops.get_parent(mux_hw);
+}
+
 static const struct clk_ops pll_ops = {
 	.enable		= pll_enable,
 	.disable	= pll_disable,
 	.recalc_rate	= pll_recalc_rate,
 	.is_enabled	= pll_is_enabled,
+	.get_parent	= pll_get_parent,
 };
 
 static struct clk_hw *clk_register_pll(struct device *dev, const char *name,
-				       const char *parent_name,
+				       const char * const *parent_names,
+				       int num_parents,
 				       void __iomem *reg,
+				       void __iomem *mux_reg,
 				       unsigned long flags,
 				       spinlock_t *lock)
 {
@@ -881,8 +897,15 @@ static struct clk_hw *clk_register_pll(struct device *dev, const char *name,
 	init.name = name;
 	init.ops = &pll_ops;
 	init.flags = flags;
-	init.parent_names = &parent_name;
-	init.num_parents = 1;
+	init.parent_names = parent_names;
+	init.num_parents = num_parents;
+
+	element->mux.lock = lock;
+	element->mux.reg =  mux_reg;
+	element->mux.shift = PLL_MUX_SHIFT;
+	element->mux.mask =  PLL_MUX_MASK;
+	element->mux.flags =  CLK_MUX_READ_ONLY;
+	element->mux.reg =  mux_reg;
 
 	element->hw.init = &init;
 	element->reg = reg;
@@ -1069,6 +1092,7 @@ static const struct clk_ops rtc_div_clk_ops = {
 
 struct stm32_pll_cfg {
 	u32 offset;
+	u32 muxoff;
 };
 
 static struct clk_hw *_clk_register_pll(struct device *dev,
@@ -1078,8 +1102,11 @@ static struct clk_hw *_clk_register_pll(struct device *dev,
 {
 	struct stm32_pll_cfg *stm_pll_cfg = cfg->cfg;
 
-	return clk_register_pll(dev, cfg->name, cfg->parent_name,
-				base + stm_pll_cfg->offset, cfg->flags, lock);
+	return clk_register_pll(dev, cfg->name, cfg->parent_names,
+				cfg->num_parents,
+				base + stm_pll_cfg->offset,
+				base + stm_pll_cfg->muxoff,
+				cfg->flags, lock);
 }
 
 struct stm32_cktim_cfg {
@@ -1189,14 +1216,16 @@ _clk_stm32_register_composite(struct device *dev,
 	.func		= _clk_hw_register_mux,\
 }
 
-#define PLL(_id, _name, _parent, _flags, _offset)\
+#define PLL(_id, _name, _parents, _flags, _offset_p, _offset_mux)\
 {\
 	.id		= _id,\
 	.name		= _name,\
-	.parent_name	= _parent,\
-	.flags		= _flags,\
+	.parent_names	= _parents,\
+	.num_parents	= ARRAY_SIZE(_parents),\
+	.flags		= CLK_IGNORE_UNUSED | (_flags),\
 	.cfg		=  &(struct stm32_pll_cfg) {\
-		.offset = _offset,\
+		.offset = _offset_p,\
+		.muxoff = _offset_mux,\
 	},\
 	.func		= _clk_register_pll,\
 }
@@ -1712,21 +1741,11 @@ static const struct clock_config stm32mp1_clock_cfg[] = {
 
 	FIXED_FACTOR(CK_HSE_DIV2, "clk-hse-div2", "ck_hse", 0, 1, 2),
 
-	/* ref clock pll */
-	MUX(NO_ID, "ref1", ref12_parents, CLK_OPS_PARENT_ENABLE, RCC_RCK12SELR,
-	    0, 2, CLK_MUX_READ_ONLY),
-
-	MUX(NO_ID, "ref3", ref3_parents, CLK_OPS_PARENT_ENABLE, RCC_RCK3SELR,
-	    0, 2, CLK_MUX_READ_ONLY),
-
-	MUX(NO_ID, "ref4", ref4_parents, CLK_OPS_PARENT_ENABLE, RCC_RCK4SELR,
-	    0, 2, CLK_MUX_READ_ONLY),
-
 	/* PLLs */
-	PLL(PLL1, "pll1", "ref1", CLK_IGNORE_UNUSED, RCC_PLL1CR),
-	PLL(PLL2, "pll2", "ref1", CLK_IGNORE_UNUSED, RCC_PLL2CR),
-	PLL(PLL3, "pll3", "ref3", CLK_IGNORE_UNUSED, RCC_PLL3CR),
-	PLL(PLL4, "pll4", "ref4", CLK_IGNORE_UNUSED, RCC_PLL4CR),
+	PLL(PLL1, "pll1", ref12_parents, 0, RCC_PLL1CR, RCC_RCK12SELR),
+	PLL(PLL2, "pll2", ref12_parents, 0, RCC_PLL2CR, RCC_RCK12SELR),
+	PLL(PLL3, "pll3", ref3_parents, 0, RCC_PLL3CR, RCC_RCK3SELR),
+	PLL(PLL4, "pll4", ref4_parents, 0, RCC_PLL4CR, RCC_RCK4SELR),
 
 	/* ODF */
 	COMPOSITE(PLL1_P, "pll1_p", PARENT("pll1"), 0,
-- 
2.17.1


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

[PATCH v2 06/14] reset: stm32mp1: remove stm32mp1 reset

From: <hidden>
Date: 2021-01-26 18:00:21 

From: Gabriel Fernandez <redacted>

st32mp1 RCC reset driver was moved into stm32mp1 RCC clock driver.

Signed-off-by: Gabriel Fernandez <redacted>
---
 drivers/reset/Kconfig          |   6 --
 drivers/reset/Makefile         |   1 -
 drivers/reset/reset-stm32mp1.c | 115 ---------------------------------
 3 files changed, 122 deletions(-)
 delete mode 100644 drivers/reset/reset-stm32mp1.c

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 71ab75a46491..6c58056f1732 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -188,12 +188,6 @@ config RESET_SIMPLE
 	   - Allwinner SoCs
 	   - ZTE's zx2967 family
 
-config RESET_STM32MP157
-	bool "STM32MP157 Reset Driver" if COMPILE_TEST
-	default MACH_STM32MP157
-	help
-	  This enables the RCC reset controller driver for STM32 MPUs.
-
 config RESET_SOCFPGA
 	bool "SoCFPGA Reset Driver" if COMPILE_TEST && !ARCH_SOCFPGA
 	default ARCH_SOCFPGA
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 1054123fd187..c17f5b3c641e 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -25,7 +25,6 @@ obj-$(CONFIG_RESET_QCOM_PDC) += reset-qcom-pdc.o
 obj-$(CONFIG_RESET_RASPBERRYPI) += reset-raspberrypi.o
 obj-$(CONFIG_RESET_SCMI) += reset-scmi.o
 obj-$(CONFIG_RESET_SIMPLE) += reset-simple.o
-obj-$(CONFIG_RESET_STM32MP157) += reset-stm32mp1.o
 obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
 obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_RESET_TI_SCI) += reset-ti-sci.o
diff --git a/drivers/reset/reset-stm32mp1.c b/drivers/reset/reset-stm32mp1.c
deleted file mode 100644
index b221a28041fa..000000000000
--- a/drivers/reset/reset-stm32mp1.c
+++ /dev/null
@@ -1,115 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Copyright (C) STMicroelectronics 2018 - All Rights Reserved
- * Author: Gabriel Fernandez <gabriel.fernandez@st.com> for STMicroelectronics.
- */
-
-#include <linux/device.h>
-#include <linux/err.h>
-#include <linux/io.h>
-#include <linux/of.h>
-#include <linux/platform_device.h>
-#include <linux/reset-controller.h>
-
-#define CLR_OFFSET 0x4
-
-struct stm32_reset_data {
-	struct reset_controller_dev	rcdev;
-	void __iomem			*membase;
-};
-
-static inline struct stm32_reset_data *
-to_stm32_reset_data(struct reset_controller_dev *rcdev)
-{
-	return container_of(rcdev, struct stm32_reset_data, rcdev);
-}
-
-static int stm32_reset_update(struct reset_controller_dev *rcdev,
-			      unsigned long id, bool assert)
-{
-	struct stm32_reset_data *data = to_stm32_reset_data(rcdev);
-	int reg_width = sizeof(u32);
-	int bank = id / (reg_width * BITS_PER_BYTE);
-	int offset = id % (reg_width * BITS_PER_BYTE);
-	void __iomem *addr;
-
-	addr = data->membase + (bank * reg_width);
-	if (!assert)
-		addr += CLR_OFFSET;
-
-	writel(BIT(offset), addr);
-
-	return 0;
-}
-
-static int stm32_reset_assert(struct reset_controller_dev *rcdev,
-			      unsigned long id)
-{
-	return stm32_reset_update(rcdev, id, true);
-}
-
-static int stm32_reset_deassert(struct reset_controller_dev *rcdev,
-				unsigned long id)
-{
-	return stm32_reset_update(rcdev, id, false);
-}
-
-static int stm32_reset_status(struct reset_controller_dev *rcdev,
-			      unsigned long id)
-{
-	struct stm32_reset_data *data = to_stm32_reset_data(rcdev);
-	int reg_width = sizeof(u32);
-	int bank = id / (reg_width * BITS_PER_BYTE);
-	int offset = id % (reg_width * BITS_PER_BYTE);
-	u32 reg;
-
-	reg = readl(data->membase + (bank * reg_width));
-
-	return !!(reg & BIT(offset));
-}
-
-static const struct reset_control_ops stm32_reset_ops = {
-	.assert		= stm32_reset_assert,
-	.deassert	= stm32_reset_deassert,
-	.status		= stm32_reset_status,
-};
-
-static const struct of_device_id stm32_reset_dt_ids[] = {
-	{ .compatible = "st,stm32mp1-rcc"},
-	{ /* sentinel */ },
-};
-
-static int stm32_reset_probe(struct platform_device *pdev)
-{
-	struct device *dev = &pdev->dev;
-	struct stm32_reset_data *data;
-	void __iomem *membase;
-	struct resource *res;
-
-	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
-	if (!data)
-		return -ENOMEM;
-
-	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	membase = devm_ioremap_resource(dev, res);
-	if (IS_ERR(membase))
-		return PTR_ERR(membase);
-
-	data->membase = membase;
-	data->rcdev.owner = THIS_MODULE;
-	data->rcdev.nr_resets = resource_size(res) * BITS_PER_BYTE;
-	data->rcdev.ops = &stm32_reset_ops;
-	data->rcdev.of_node = dev->of_node;
-
-	return devm_reset_controller_register(dev, &data->rcdev);
-}
-
-static struct platform_driver stm32_reset_driver = {
-	.probe	= stm32_reset_probe,
-	.driver = {
-		.name		= "stm32mp1-reset",
-		.of_match_table	= stm32_reset_dt_ids,
-	},
-};
-
-builtin_platform_driver(stm32_reset_driver);
-- 
2.17.1


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

[PATCH v2 02/14] clk: stm32mp1: merge 'ck_hse_rtc' and 'ck_rtc' into one clock

From: <hidden>
Date: 2021-01-26 18:00:21 

From: Gabriel Fernandez <redacted>

'ck_rtc' has multiple clocks as input (ck_hsi, ck_lsi, and ck_hse).
A divider is available only on the specific rtc input for ck_hse.
This Merge will facilitate to have a more coherent clock tree
in no trusted / trusted world.

Signed-off-by: Gabriel Fernandez <redacted>
---
 drivers/clk/clk-stm32mp1.c | 49 +++++++++++++++++++++++++++++++++-----
 1 file changed, 43 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
index 35d5aee8f9b0..0e1d4427a8df 100644
--- a/drivers/clk/clk-stm32mp1.c
+++ b/drivers/clk/clk-stm32mp1.c
@@ -245,7 +245,7 @@ static const char * const dsi_src[] = {
 };
 
 static const char * const rtc_src[] = {
-	"off", "ck_lse", "ck_lsi", "ck_hse_rtc"
+	"off", "ck_lse", "ck_lsi", "ck_hse"
 };
 
 static const char * const mco1_src[] = {
@@ -1031,6 +1031,42 @@ static struct clk_hw *clk_register_cktim(struct device *dev, const char *name,
 	return hw;
 }
 
+/* The divider of RTC clock concerns only ck_hse clock */
+#define HSE_RTC 3
+
+static unsigned long clk_divider_rtc_recalc_rate(struct clk_hw *hw,
+						 unsigned long parent_rate)
+{
+	if (clk_hw_get_parent(hw) == clk_hw_get_parent_by_index(hw, HSE_RTC))
+		return clk_divider_ops.recalc_rate(hw, parent_rate);
+
+	return parent_rate;
+}
+
+static long clk_divider_rtc_round_rate(struct clk_hw *hw, unsigned long rate,
+				       unsigned long *prate)
+{
+	if (clk_hw_get_parent(hw) == clk_hw_get_parent_by_index(hw, HSE_RTC))
+		return clk_divider_ops.round_rate(hw, rate, prate);
+
+	return *prate;
+}
+
+static int clk_divider_rtc_set_rate(struct clk_hw *hw, unsigned long rate,
+				    unsigned long parent_rate)
+{
+	if (clk_hw_get_parent(hw) == clk_hw_get_parent_by_index(hw, HSE_RTC))
+		return clk_divider_ops.set_rate(hw, rate, parent_rate);
+
+	return parent_rate;
+}
+
+static const struct clk_ops rtc_div_clk_ops = {
+	.recalc_rate	= clk_divider_rtc_recalc_rate,
+	.round_rate	= clk_divider_rtc_round_rate,
+	.set_rate	= clk_divider_rtc_set_rate,
+};
+
 struct stm32_pll_cfg {
 	u32 offset;
 };
@@ -1243,6 +1279,10 @@ _clk_stm32_register_composite(struct device *dev,
 	_STM32_DIV(_div_offset, _div_shift, _div_width,\
 		   _div_flags, _div_table, NULL)\
 
+#define _DIV_RTC(_div_offset, _div_shift, _div_width, _div_flags, _div_table)\
+	_STM32_DIV(_div_offset, _div_shift, _div_width,\
+		   _div_flags, _div_table, &rtc_div_clk_ops)
+
 #define _STM32_MUX(_offset, _shift, _width, _mux_flags, _mmux, _ops)\
 	.mux = &(struct stm32_mux_cfg) {\
 		&(struct mux_cfg) {\
@@ -1965,13 +2005,10 @@ static const struct clock_config stm32mp1_clock_cfg[] = {
 		  _DIV(RCC_ETHCKSELR, 4, 4, 0, NULL)),
 
 	/* RTC clock */
-	DIV(NO_ID, "ck_hse_rtc", "ck_hse", 0, RCC_RTCDIVR, 0, 6, 0),
-
-	COMPOSITE(RTC, "ck_rtc", rtc_src, CLK_OPS_PARENT_ENABLE |
-		   CLK_SET_RATE_PARENT,
+	COMPOSITE(RTC, "ck_rtc", rtc_src, CLK_OPS_PARENT_ENABLE,
 		  _GATE(RCC_BDCR, 20, 0),
 		  _MUX(RCC_BDCR, 16, 2, 0),
-		  _NO_DIV),
+		  _DIV_RTC(RCC_RTCDIVR, 0, 6, 0, NULL)),
 
 	/* MCO clocks */
 	COMPOSITE(CK_MCO1, "ck_mco1", mco1_src, CLK_OPS_PARENT_ENABLE |
-- 
2.17.1


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

Re: [PATCH v2 02/14] clk: stm32mp1: merge 'ck_hse_rtc' and 'ck_rtc' into one clock

From: Stephen Boyd <sboyd@kernel.org>
Date: 2021-02-09 08:01:31 

Quoting gabriel.fernandez@foss.st.com (2021-01-26 01:01:08)
quoted hunk
From: Gabriel Fernandez <redacted>

'ck_rtc' has multiple clocks as input (ck_hsi, ck_lsi, and ck_hse).
A divider is available only on the specific rtc input for ck_hse.
This Merge will facilitate to have a more coherent clock tree
in no trusted / trusted world.

Signed-off-by: Gabriel Fernandez <redacted>
---
 drivers/clk/clk-stm32mp1.c | 49 +++++++++++++++++++++++++++++++++-----
 1 file changed, 43 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
index 35d5aee8f9b0..0e1d4427a8df 100644
--- a/drivers/clk/clk-stm32mp1.c
+++ b/drivers/clk/clk-stm32mp1.c
@@ -245,7 +245,7 @@ static const char * const dsi_src[] = {
 };
 
 static const char * const rtc_src[] = {
-       "off", "ck_lse", "ck_lsi", "ck_hse_rtc"
+       "off", "ck_lse", "ck_lsi", "ck_hse"
 };
 
 static const char * const mco1_src[] = {
@@ -1031,6 +1031,42 @@ static struct clk_hw *clk_register_cktim(struct device *dev, const char *name,
        return hw;
 }
 
+/* The divider of RTC clock concerns only ck_hse clock */
+#define HSE_RTC 3
+
+static unsigned long clk_divider_rtc_recalc_rate(struct clk_hw *hw,
+                                                unsigned long parent_rate)
+{
+       if (clk_hw_get_parent(hw) == clk_hw_get_parent_by_index(hw, HSE_RTC))
+               return clk_divider_ops.recalc_rate(hw, parent_rate);
+
+       return parent_rate;
+}
+
+static long clk_divider_rtc_round_rate(struct clk_hw *hw, unsigned long rate,
+                                      unsigned long *prate)
+{
+       if (clk_hw_get_parent(hw) == clk_hw_get_parent_by_index(hw, HSE_RTC))
This clk op can be called at basically any time. Maybe this should use
the determine rate op and then look to see what the parent is that comes
in via the rate request structure? Or is the intention to keep this
pinned to one particular parent? Looking at this right now it doesn't
really make much sense why the current parent state should play into
what rate the clk can round to, unless there is some more clk flags
going on that constrain the ability to change this clk's parent.

+               return clk_divider_ops.round_rate(hw, rate, prate);
+
+       return *prate;
+}
+
+static int clk_divider_rtc_set_rate(struct clk_hw *hw, unsigned long rate,
+                                   unsigned long parent_rate)
+{
+       if (clk_hw_get_parent(hw) == clk_hw_get_parent_by_index(hw, HSE_RTC))
+               return clk_divider_ops.set_rate(hw, rate, parent_rate);
+
+       return parent_rate;
+}
+
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 02/14] clk: stm32mp1: merge 'ck_hse_rtc' and 'ck_rtc' into one clock

From: gabriel.fernandez@foss.st.com <hidden>
Date: 2021-02-12 08:10:07 

On 2/9/21 9:00 AM, Stephen Boyd wrote:
Quoting gabriel.fernandez@foss.st.com (2021-01-26 01:01:08)
quoted
From: Gabriel Fernandez <redacted>

'ck_rtc' has multiple clocks as input (ck_hsi, ck_lsi, and ck_hse).
A divider is available only on the specific rtc input for ck_hse.
This Merge will facilitate to have a more coherent clock tree
in no trusted / trusted world.

Signed-off-by: Gabriel Fernandez <redacted>
---
  drivers/clk/clk-stm32mp1.c | 49 +++++++++++++++++++++++++++++++++-----
  1 file changed, 43 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
index 35d5aee8f9b0..0e1d4427a8df 100644
--- a/drivers/clk/clk-stm32mp1.c
+++ b/drivers/clk/clk-stm32mp1.c
@@ -245,7 +245,7 @@ static const char * const dsi_src[] = {
  };
  
  static const char * const rtc_src[] = {
-       "off", "ck_lse", "ck_lsi", "ck_hse_rtc"
+       "off", "ck_lse", "ck_lsi", "ck_hse"
  };
  
  static const char * const mco1_src[] = {
@@ -1031,6 +1031,42 @@ static struct clk_hw *clk_register_cktim(struct device *dev, const char *name,
         return hw;
  }
  
+/* The divider of RTC clock concerns only ck_hse clock */
+#define HSE_RTC 3
+
+static unsigned long clk_divider_rtc_recalc_rate(struct clk_hw *hw,
+                                                unsigned long parent_rate)
+{
+       if (clk_hw_get_parent(hw) == clk_hw_get_parent_by_index(hw, HSE_RTC))
+               return clk_divider_ops.recalc_rate(hw, parent_rate);
+
+       return parent_rate;
+}
+
+static long clk_divider_rtc_round_rate(struct clk_hw *hw, unsigned long rate,
+                                      unsigned long *prate)
+{
+       if (clk_hw_get_parent(hw) == clk_hw_get_parent_by_index(hw, HSE_RTC))
This clk op can be called at basically any time. Maybe this should use
the determine rate op and then look to see what the parent is that comes
in via the rate request structure? Or is the intention to keep this
pinned to one particular parent? Looking at this right now it doesn't
really make much sense why the current parent state should play into
what rate the clk can round to, unless there is some more clk flags
going on that constrain the ability to change this clk's parent.
Yes the intention is to keep this pinned for one particular parent.

This divider is only applied on the 4th input of the MUX of the RTC and

doesn't affect the HSE frequency for all the system.


Oscillators
  -----
| lse |----------------+----------------> ck_lse
  -----                 |
  -----                 |
| lsi |------------+--------------------> ck_lsi
  -----             |   |
                    |   |
  -----             |   |
| hse |----+-------|---|----------------> ck_hse
  -----     |       |   |
            |       |   |         |\ mux
            |       |   |  OFF -->| \
            |       |   |         |  \     gate
            |       |   --------->|  |     ---
            |       |             |  |--->|   |--> ck_rtc
            |       ------------->|  |     ---
            |    -----------      |  |
             ----| % 1 to 64 |--->| /
                  -----------     |/
                    divider

I manage the RTC with a clock composite with a gate a mux and a specific 
rate ops for hse input.

That why i need to the parent state.

Best Regards

Gabriel
quoted
+               return clk_divider_ops.round_rate(hw, rate, prate);
+
+       return *prate;
+}
+
+static int clk_divider_rtc_set_rate(struct clk_hw *hw, unsigned long rate,
+                                   unsigned long parent_rate)
+{
+       if (clk_hw_get_parent(hw) == clk_hw_get_parent_by_index(hw, HSE_RTC))
+               return clk_divider_ops.set_rate(hw, rate, parent_rate);
+
+       return parent_rate;
+}
+
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 09/14] dt-bindings: reset: add MCU HOLD BOOT ID for SCMI reset domains on stm32mp15

From: <hidden>
Date: 2021-01-26 18:01:09 

From: Gabriel Fernandez <redacted>

Add ID to SCMI0 to exposes reset controller for the MCU HOLD BOOT resource.

Signed-off-by: Arnaud Pouliquen <redacted>
Signed-off-by: Gabriel Fernandez <redacted>
---
 include/dt-bindings/reset/stm32mp1-resets.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/dt-bindings/reset/stm32mp1-resets.h b/include/dt-bindings/reset/stm32mp1-resets.h
index bc71924faa54..f3a0ed317835 100644
--- a/include/dt-bindings/reset/stm32mp1-resets.h
+++ b/include/dt-bindings/reset/stm32mp1-resets.h
@@ -7,6 +7,7 @@
 #ifndef _DT_BINDINGS_STM32MP1_RESET_H_
 #define _DT_BINDINGS_STM32MP1_RESET_H_
 
+#define MCU_HOLD_BOOT_R	2144
 #define LTDC_R		3072
 #define DSI_R		3076
 #define DDRPERFM_R	3080
@@ -117,5 +118,6 @@
 #define RST_SCMI0_RNG1		8
 #define RST_SCMI0_MDMA		9
 #define RST_SCMI0_MCU		10
+#define RST_SCMI0_MCU_HOLD_BOOT	11
 
 #endif /* _DT_BINDINGS_STM32MP1_RESET_H_ */
-- 
2.17.1


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

Re: [PATCH v2 09/14] dt-bindings: reset: add MCU HOLD BOOT ID for SCMI reset domains on stm32mp15

From: Rob Herring <robh@kernel.org>
Date: 2021-02-09 19:26:47 

On Tue, 26 Jan 2021 10:01:15 +0100, gabriel.fernandez@foss.st.com wrote:
From: Gabriel Fernandez <redacted>

Add ID to SCMI0 to exposes reset controller for the MCU HOLD BOOT resource.

Signed-off-by: Arnaud Pouliquen <redacted>
Signed-off-by: Gabriel Fernandez <redacted>
---
 include/dt-bindings/reset/stm32mp1-resets.h | 2 ++
 1 file changed, 2 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>

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

[PATCH v2 07/14] dt-bindings: clock: add IDs for SCMI clocks on stm32mp15

From: <hidden>
Date: 2021-01-26 18:01:47 

From: Gabriel Fernandez <redacted>

stm32mp15 TZ secure firmware provides SCMI clocks for oscillators, some
PLL output and few secure aware interfaces.
This change defines the SCMI clock identifiers used by SCMI agents
and servers.
Server SCMI0 exposes clocks and reset controllers for resources under
RCC[TZEN] configuration control.
Server SCMI1 exposes clocks for resources under RCC[MCKPROT] control.

Signed-off-by: Etienne Carriere <redacted>
Signed-off-by: Gabriel Fernandez <redacted>
---
 include/dt-bindings/clock/stm32mp1-clks.h | 27 +++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/include/dt-bindings/clock/stm32mp1-clks.h b/include/dt-bindings/clock/stm32mp1-clks.h
index 4cdaf135829c..e02770b98e6c 100644
--- a/include/dt-bindings/clock/stm32mp1-clks.h
+++ b/include/dt-bindings/clock/stm32mp1-clks.h
@@ -248,4 +248,31 @@
 
 #define STM32MP1_LAST_CLK 232
 
+/* SCMI clock identifiers */
+#define CK_SCMI0_HSE		0
+#define CK_SCMI0_HSI		1
+#define CK_SCMI0_CSI		2
+#define CK_SCMI0_LSE		3
+#define CK_SCMI0_LSI		4
+#define CK_SCMI0_PLL2_Q		5
+#define CK_SCMI0_PLL2_R		6
+#define CK_SCMI0_MPU		7
+#define CK_SCMI0_AXI		8
+#define CK_SCMI0_BSEC		9
+#define CK_SCMI0_CRYP1		10
+#define CK_SCMI0_GPIOZ		11
+#define CK_SCMI0_HASH1		12
+#define CK_SCMI0_I2C4		13
+#define CK_SCMI0_I2C6		14
+#define CK_SCMI0_IWDG1		15
+#define CK_SCMI0_RNG1		16
+#define CK_SCMI0_RTC		17
+#define CK_SCMI0_RTCAPB		18
+#define CK_SCMI0_SPI6		19
+#define CK_SCMI0_USART1		20
+
+#define CK_SCMI1_PLL3_Q		0
+#define CK_SCMI1_PLL3_R		1
+#define CK_SCMI1_MCU		2
+
 #endif /* _DT_BINDINGS_STM32MP1_CLKS_H_ */
-- 
2.17.1


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

Re: [PATCH v2 07/14] dt-bindings: clock: add IDs for SCMI clocks on stm32mp15

From: Rob Herring <robh@kernel.org>
Date: 2021-02-09 19:08:23 

On Tue, 26 Jan 2021 10:01:13 +0100, gabriel.fernandez@foss.st.com wrote:
From: Gabriel Fernandez <redacted>

stm32mp15 TZ secure firmware provides SCMI clocks for oscillators, some
PLL output and few secure aware interfaces.
This change defines the SCMI clock identifiers used by SCMI agents
and servers.
Server SCMI0 exposes clocks and reset controllers for resources under
RCC[TZEN] configuration control.
Server SCMI1 exposes clocks for resources under RCC[MCKPROT] control.

Signed-off-by: Etienne Carriere <redacted>
Signed-off-by: Gabriel Fernandez <redacted>
---
 include/dt-bindings/clock/stm32mp1-clks.h | 27 +++++++++++++++++++++++
 1 file changed, 27 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>

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

[PATCH v2 10/14] clk: stm32mp1: new compatible for secure RCC support

From: <hidden>
Date: 2021-01-26 18:02:02 

From: Gabriel Fernandez <redacted>

Platform STM32MP1 can be used in configuration where some clock
resources cannot be accessed by Linux kernel when executing in non-secure
state of the CPU(s).
In such configuration, the RCC clock driver must not register clocks
it cannot access.
They are expected to be registered from another clock driver such
as the SCMI clock driver.
This change uses specific compatible string "st,stm32mp1-rcc-secure"
to specify RCC clock driver configuration where RCC is secure.

Signed-off-by: Etienne Carriere <redacted>
Signed-off-by: Gabriel Fernandez <redacted>
---
 drivers/clk/Kconfig        |  10 ++++
 drivers/clk/clk-stm32mp1.c | 101 ++++++++++++++++++++++++++++++++++++-
 2 files changed, 110 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 85856cff506c..52e9cf36731c 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -334,6 +334,16 @@ config COMMON_CLK_STM32MP157
 	help
 	  Support for stm32mp157 SoC family clocks
 
+config COMMON_CLK_STM32MP157_SCMI
+	bool "stm32mp157 Clock driver with Trusted Firmware"
+	depends on COMMON_CLK_STM32MP157
+	select COMMON_CLK_SCMI
+	select ARM_SCMI_PROTOCOL
+	default y
+	help
+	  Support for stm32mp157 SoC family clocks with Trusted Firmware using
+	  SCMI protocol.
+
 config COMMON_CLK_STM32F
 	def_bool COMMON_CLK && (MACH_STM32F429 || MACH_STM32F469 || MACH_STM32F746)
 	help
diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
index 25e3f272344c..132e1dd42dbd 100644
--- a/drivers/clk/clk-stm32mp1.c
+++ b/drivers/clk/clk-stm32mp1.c
@@ -2051,11 +2051,61 @@ static const struct clock_config stm32mp1_clock_cfg[] = {
 		  _DIV(RCC_DBGCFGR, 0, 3, 0, ck_trace_div_table)),
 };
 
+static const u32 stm32mp1_clock_secured[] = {
+	CK_HSE,
+	CK_HSI,
+	CK_CSI,
+	CK_LSI,
+	CK_LSE,
+	PLL1,
+	PLL2,
+	PLL1_P,
+	PLL2_P,
+	PLL2_Q,
+	PLL2_R,
+	CK_MPU,
+	CK_AXI,
+	SPI6,
+	I2C4,
+	I2C6,
+	USART1,
+	RTCAPB,
+	TZC1,
+	TZC2,
+	TZPC,
+	IWDG1,
+	BSEC,
+	STGEN,
+	GPIOZ,
+	CRYP1,
+	HASH1,
+	RNG1,
+	BKPSRAM,
+	RNG1_K,
+	STGEN_K,
+	SPI6_K,
+	I2C4_K,
+	I2C6_K,
+	USART1_K,
+	RTC,
+};
+
+static bool stm32_check_security(const struct clock_config *cfg)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(stm32mp1_clock_secured); i++)
+		if (cfg->id == stm32mp1_clock_secured[i])
+			return true;
+	return false;
+}
+
 struct stm32_rcc_match_data {
 	const struct clock_config *cfg;
 	unsigned int num;
 	unsigned int maxbinding;
 	u32 clear_offset;
+	bool (*check_security)(const struct clock_config *cfg);
 };
 
 static struct stm32_rcc_match_data stm32mp1_data = {
@@ -2065,11 +2115,23 @@ static struct stm32_rcc_match_data stm32mp1_data = {
 	.clear_offset	= RCC_CLR,
 };
 
+static struct stm32_rcc_match_data stm32mp1_data_secure = {
+	.cfg		= stm32mp1_clock_cfg,
+	.num		= ARRAY_SIZE(stm32mp1_clock_cfg),
+	.maxbinding	= STM32MP1_LAST_CLK,
+	.clear_offset	= RCC_CLR,
+	.check_security = &stm32_check_security
+};
+
 static const struct of_device_id stm32mp1_match_data[] = {
 	{
 		.compatible = "st,stm32mp1-rcc",
 		.data = &stm32mp1_data,
 	},
+	{
+		.compatible = "st,stm32mp1-rcc-secure",
+		.data = &stm32mp1_data_secure,
+	},
 	{ }
 };
 MODULE_DEVICE_TABLE(of, stm32mp1_match_data);
@@ -2229,6 +2291,9 @@ static int stm32_rcc_clock_init(struct device *dev, void __iomem *base,
 		hws[n] = ERR_PTR(-ENOENT);
 
 	for (n = 0; n < data->num; n++) {
+		if (data->check_security && data->check_security(&data->cfg[n]))
+			continue;
+
 		err = stm32_register_hw_clk(dev, clk_data, base, &rlock,
 					    &data->cfg[n]);
 		if (err) {
@@ -2296,11 +2361,45 @@ static int stm32mp1_rcc_init(struct device *dev)
 	return ret;
 }
 
+static int get_clock_deps(struct device *dev)
+{
+	static const char * const clock_deps_name[] = {
+		"hsi", "hse", "csi", "lsi", "lse",
+	};
+	size_t deps_size = sizeof(struct clk *) * ARRAY_SIZE(clock_deps_name);
+	struct clk **clk_deps;
+	int i;
+
+	clk_deps = devm_kzalloc(dev, deps_size, GFP_KERNEL);
+	if (!clk_deps)
+		return -ENOMEM;
+
+	for (i = 0; i < ARRAY_SIZE(clock_deps_name); i++) {
+		struct clk *clk = of_clk_get_by_name(dev_of_node(dev),
+						     clock_deps_name[i]);
+
+		if (IS_ERR(clk)) {
+			if (PTR_ERR(clk) != -EINVAL && PTR_ERR(clk) != -ENOENT)
+				return PTR_ERR(clk);
+		} else {
+			/* Device gets a reference count on the clock */
+			clk_deps[i] = devm_clk_get(dev, __clk_get_name(clk));
+			clk_put(clk);
+		}
+	}
+
+	return 0;
+}
+
 static int stm32mp1_rcc_clocks_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
+	int ret = get_clock_deps(dev);
+
+	if (!ret)
+		ret = stm32mp1_rcc_init(dev);
 
-	return stm32mp1_rcc_init(dev);
+	return ret;
 }
 
 static int stm32mp1_rcc_clocks_remove(struct platform_device *pdev)
-- 
2.17.1


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

[PATCH v2 11/14] ARM: dts: stm32: define SCMI resources on stm32mp15

From: <hidden>
Date: 2021-01-26 18:02:38 

From: Gabriel Fernandez <redacted>

Platform stm32mp15 relies on SCMI resources (clocks and reset domains).
This change adds SCMI resources description in the platform device
tree. SCMI resources uses a mailbox based on some shared memory and
a SMC mailbox notification.

SCMI0 exposes clocks and reset controllers for resources under RCC[TZEN]
configuration control. It is default enabled as SoC default
configuration is RCC[TZEN]=1.

SCMI1 exposes clocks for resources under RCC[MCKPROT] control. The node
is disabled by default as default configuration is RCC[MCKPROT]=0.

Signed-off-by: Etienne Carriere <redacted>
Signed-off-by: Gabriel Fernandez <redacted>
---
 arch/arm/boot/dts/stm32mp151.dtsi | 50 +++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/arch/arm/boot/dts/stm32mp151.dtsi b/arch/arm/boot/dts/stm32mp151.dtsi
index 3c75abacb374..da3647373365 100644
--- a/arch/arm/boot/dts/stm32mp151.dtsi
+++ b/arch/arm/boot/dts/stm32mp151.dtsi
@@ -30,6 +30,56 @@
 		interrupt-parent = <&intc>;
 	};
 
+	scmi_sram: sram@2ffff000 {
+		compatible = "mmio-sram";
+		reg = <0x2ffff000 0x1000>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0 0x2ffff000 0x1000>;
+
+		scmi0_shm: scmi_shm@0 {
+			reg = <0 0x80>;
+		};
+
+		scmi1_shm: scmi_shm@200 {
+			reg = <0x200 0x80>;
+		};
+	};
+
+	firmware {
+		scmi0: scmi0 {
+			compatible = "arm,scmi-smc";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			arm,smc-id = <0x82002000>;
+			shmem = <&scmi0_shm>;
+
+			scmi0_clk: protocol@14 {
+				reg = <0x14>;
+				#clock-cells = <1>;
+			};
+
+			scmi0_reset: protocol@16 {
+				reg = <0x16>;
+				#reset-cells = <1>;
+			};
+		};
+
+		scmi1: scmi1 {
+			compatible = "arm,scmi-smc";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			arm,smc-id = <0x82002001>;
+			shmem = <&scmi1_shm>;
+			status = "disabled";
+
+			scmi1_clk: protocol@14 {
+				reg = <0x14>;
+				#clock-cells = <1>;
+			};
+		};
+	};
+
 	psci {
 		compatible = "arm,psci-1.0";
 		method = "smc";
-- 
2.17.1


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

[PATCH v2 13/14] dt-bindings: clock: stm32mp1 new compatible for secure rcc

From: <hidden>
Date: 2021-01-26 18:03:00 

From: Gabriel Fernandez <redacted>

Introduce new compatible string "st,stm32mp1-rcc-secure" for
stm32mp1 clock driver when the device is configured with RCC
security support hardened.

Signed-off-by: Etienne Carriere <redacted>
Signed-off-by: Gabriel Fernandez <redacted>
---
 .../devicetree/bindings/clock/st,stm32mp1-rcc.yaml          | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml
index 4e385508f516..8b1ecb2ecdd5 100644
--- a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml
+++ b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml
@@ -54,7 +54,9 @@ properties:
 
   compatible:
     items:
-      - const: st,stm32mp1-rcc
+      - enum:
+          - st,stm32mp1-rcc-secure
+          - st,stm32mp1-rcc
       - const: syscon
 
   reg:
@@ -71,7 +73,7 @@ additionalProperties: false
 examples:
   - |
     rcc: rcc@50000000 {
-        compatible = "st,stm32mp1-rcc", "syscon";
+        compatible = "st,stm32mp1-rcc-secure", "syscon";
         reg = <0x50000000 0x1000>;
         #clock-cells = <1>;
         #reset-cells = <1>;
-- 
2.17.1


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

Re: [PATCH v2 13/14] dt-bindings: clock: stm32mp1 new compatible for secure rcc

From: Rob Herring <robh@kernel.org>
Date: 2021-02-09 19:26:46 

On Tue, 26 Jan 2021 10:01:19 +0100, gabriel.fernandez@foss.st.com wrote:
From: Gabriel Fernandez <redacted>

Introduce new compatible string "st,stm32mp1-rcc-secure" for
stm32mp1 clock driver when the device is configured with RCC
security support hardened.

Signed-off-by: Etienne Carriere <redacted>
Signed-off-by: Gabriel Fernandez <redacted>
---
 .../devicetree/bindings/clock/st,stm32mp1-rcc.yaml          | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>

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

[PATCH v2 14/14] ARM: dts: stm32: introduce basic boot include on stm32mp15x board

From: <hidden>
Date: 2021-01-26 18:03:08 

From: Gabriel Fernandez <redacted>

Include this .dtsi file to be backward compatible with old basic bootchain.

For example add:
include "stm32mp15-no-scmi.dtsi" in a stm32mp157c*.dts file.

Signed-off-by: Gabriel Fernandez <redacted>
---
 arch/arm/boot/dts/stm32mp15-no-scmi.dtsi | 158 +++++++++++++++++++++++
 1 file changed, 158 insertions(+)
 create mode 100644 arch/arm/boot/dts/stm32mp15-no-scmi.dtsi

diff --git a/arch/arm/boot/dts/stm32mp15-no-scmi.dtsi b/arch/arm/boot/dts/stm32mp15-no-scmi.dtsi
new file mode 100644
index 000000000000..4939f96da739
--- /dev/null
+++ b/arch/arm/boot/dts/stm32mp15-no-scmi.dtsi
@@ -0,0 +1,158 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) STMicroelectronics 2020 - All Rights Reserved
+ * Author: Gabriel Fernandez <gabriel.fernandez@st.com> for STMicroelectronics.
+ */
+
+/ {
+
+	clocks {
+		clk_hse: clk-hse {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <24000000>;
+		};
+
+		clk_hsi: clk-hsi {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <64000000>;
+		};
+
+		clk_lse: clk-lse {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <32768>;
+		};
+
+		clk_lsi: clk-lsi {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <32000>;
+		};
+
+		clk_csi: clk-csi {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <4000000>;
+		};
+	};
+
+	cpus {
+		cpu0: cpu@0 {
+			clocks = <&rcc CK_MPU>;
+		};
+
+		cpu1: cpu@1 {
+			clocks = <&rcc CK_MPU>;
+		};
+	};
+
+	reboot {
+		compatible = "syscon-reboot";
+		regmap = <&rcc>;
+		offset = <0x404>;
+		mask = <0x1>;
+	};
+
+	soc {
+		m_can1: can@4400e000 {
+			clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
+		};
+
+		m_can2: can@4400f000 {
+			clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
+		};
+
+		cryp1: cryp@54001000 {
+			clocks = <&rcc CRYP1>;
+			resets = <&rcc CRYP1_R>;
+		};
+
+		dsi: dsi@5a000000 {
+			clocks = <&rcc DSI_K>, <&clk_hse>, <&rcc DSI_PX>;
+		};
+	};
+
+	ahb {
+		m4_rproc: m4@10000000 {
+			resets = <&rcc MCU_R>, <&rcc MCU_HOLD_BOOT_R>;
+
+			m4_system_resources {
+				m4_cec: cec@40016000 {
+					clocks = <&rcc CEC_K>, <&rcc CK_LSE>;
+				};
+
+				m4_m_can1: can@4400e000 {
+					clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
+				};
+
+				m4_m_can2: can@4400f000 {
+					clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
+				};
+			};
+		};
+	};
+
+	firmware {
+		/delete-node/ scmi0;
+		/delete-node/ scmi1;
+	};
+	/delete-node/ sram@2ffff000;
+};
+
+&cec {
+	clocks = <&rcc CEC_K>, <&clk_lse>;
+};
+
+&gpioz {
+	clocks = <&rcc GPIOZ>;
+};
+
+&hash1 {
+	clocks = <&rcc HASH1>;
+	resets = <&rcc HASH1_R>;
+};
+
+&i2c4 {
+	clocks = <&rcc I2C4_K>;
+	resets = <&rcc I2C4_R>;
+};
+
+&i2c6 {
+	clocks = <&rcc I2C6_K>;
+	resets = <&rcc I2C6_R>;
+};
+
+&iwdg2 {
+	clocks = <&rcc IWDG2>, <&rcc CK_LSI>;
+};
+
+&mdma1 {
+	clocks = <&rcc MDMA>;
+	resets = <&rcc MDMA_R>;
+};
+
+&rcc {
+	compatible = "st,stm32mp1-rcc", "syscon";
+	clocks = <&clk_hse>, <&clk_hsi>, <&clk_csi>, <&clk_lse>, <&clk_lsi>;
+};
+
+&rng1 {
+	clocks = <&rcc RNG1_K>;
+	resets = <&rcc RNG1_R>;
+};
+
+&rtc {
+	clocks = <&rcc RTCAPB>, <&rcc RTC>;
+};
+
+&spi6 {
+	clocks = <&rcc SPI6_K>;
+	resets = <&rcc SPI6_R>;
+};
+
+&usart1 {
+	clocks = <&rcc USART1_K>;
+	resets = <&rcc USART1_R>;
+};
-- 
2.17.1


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

[PATCH v2 12/14] ARM: dts: stm32: move clocks/resets to SCMI resources for stm32mp15

From: <hidden>
Date: 2021-01-26 18:03:35 

From: Gabriel Fernandez <redacted>

This change reflects board hardware configuration where RCC security
features are configured for RCC[TZEN]=1 and RCC[MCKPROT]=0, that is
RCC TrustZone is hardened and RCC MCKPROT is disabled.

Clock and reset controllers that relate to SoC secure resources are
moved from a RCC clock/reset handle to a SCMI clock/reset_domain handle.

These clocks are all the platform oscillators (HSI/LSI/CSI/HSE/LSE),
clocks for few subsystem and peripheral interfaces.

This change add a SCMI clock dependency on RCC clock device since it
registers clocks which parent clocks are provided by the SCMI clock
driver. This change allows the RCC clock device probe to be deferred
until SCMI clocks are fully registered in the system.

Signed-off-by: Etienne Carriere <redacted>
Signed-off-by: Gabriel Fernandez <redacted>
---
 arch/arm/boot/dts/stm32mp151.dtsi  | 77 +++++++++++-------------------
 arch/arm/boot/dts/stm32mp153.dtsi  |  4 +-
 arch/arm/boot/dts/stm32mp157.dtsi  |  2 +-
 arch/arm/boot/dts/stm32mp15xc.dtsi |  4 +-
 4 files changed, 32 insertions(+), 55 deletions(-)

diff --git a/arch/arm/boot/dts/stm32mp151.dtsi b/arch/arm/boot/dts/stm32mp151.dtsi
index da3647373365..e06882e0611d 100644
--- a/arch/arm/boot/dts/stm32mp151.dtsi
+++ b/arch/arm/boot/dts/stm32mp151.dtsi
@@ -102,38 +102,6 @@
 		interrupt-parent = <&intc>;
 	};
 
-	clocks {
-		clk_hse: clk-hse {
-			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <24000000>;
-		};
-
-		clk_hsi: clk-hsi {
-			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <64000000>;
-		};
-
-		clk_lse: clk-lse {
-			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <32768>;
-		};
-
-		clk_lsi: clk-lsi {
-			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <32000>;
-		};
-
-		clk_csi: clk-csi {
-			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <4000000>;
-		};
-	};
-
 	thermal-zones {
 		cpu_thermal: cpu-thermal {
 			polling-delay-passive = <0>;
@@ -595,7 +563,7 @@
 			compatible = "st,stm32-cec";
 			reg = <0x40016000 0x400>;
 			interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc CEC_K>, <&clk_lse>;
+			clocks = <&rcc CEC_K>, <&scmi0_clk CK_SCMI0_LSE>;
 			clock-names = "cec", "hdmi-cec";
 			status = "disabled";
 		};
@@ -1156,10 +1124,17 @@
 		};
 
 		rcc: rcc@50000000 {
-			compatible = "st,stm32mp1-rcc", "syscon";
+			compatible = "st,stm32mp1-rcc-secure", "st,stm32mp1-rcc", "syscon";
 			reg = <0x50000000 0x1000>;
 			#clock-cells = <1>;
 			#reset-cells = <1>;
+
+			clock-names = "hse", "hsi", "csi", "lse", "lsi";
+			clocks = <&scmi0_clk CK_SCMI0_HSE>,
+				 <&scmi0_clk CK_SCMI0_HSI>,
+				 <&scmi0_clk CK_SCMI0_CSI>,
+				 <&scmi0_clk CK_SCMI0_LSE>,
+				 <&scmi0_clk CK_SCMI0_LSI>;
 		};
 
 		pwr_regulators: pwr@50001000 {
@@ -1342,8 +1317,8 @@
 			compatible = "st,stm32f756-hash";
 			reg = <0x54002000 0x400>;
 			interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc HASH1>;
-			resets = <&rcc HASH1_R>;
+			clocks = <&scmi0_clk CK_SCMI0_HASH1>;
+			resets = <&scmi0_reset RST_SCMI0_HASH1>;
 			dmas = <&mdma1 31 0x2 0x1000A02 0x0 0x0>;
 			dma-names = "in";
 			dma-maxburst = <2>;
@@ -1353,8 +1328,8 @@
 		rng1: rng@54003000 {
 			compatible = "st,stm32-rng";
 			reg = <0x54003000 0x400>;
-			clocks = <&rcc RNG1_K>;
-			resets = <&rcc RNG1_R>;
+			clocks = <&scmi0_clk CK_SCMI0_RNG1>;
+			resets = <&scmi0_reset RST_SCMI0_RNG1>;
 			status = "disabled";
 		};
 
@@ -1363,7 +1338,7 @@
 			reg = <0x58000000 0x1000>;
 			interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&rcc MDMA>;
-			resets = <&rcc MDMA_R>;
+			resets = <&scmi0_reset RST_SCMI0_MDMA>;
 			#dma-cells = <5>;
 			dma-channels = <32>;
 			dma-requests = <48>;
@@ -1524,7 +1499,7 @@
 		iwdg2: watchdog@5a002000 {
 			compatible = "st,stm32mp1-iwdg";
 			reg = <0x5a002000 0x400>;
-			clocks = <&rcc IWDG2>, <&rcc CK_LSI>;
+			clocks = <&rcc IWDG2>, <&scmi0_clk CK_SCMI0_LSI>;
 			clock-names = "pclk", "lsi";
 			status = "disabled";
 		};
@@ -1553,7 +1528,8 @@
 			compatible = "st,stm32h7-uart";
 			reg = <0x5c000000 0x400>;
 			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc USART1_K>;
+			clocks = <&scmi0_clk CK_SCMI0_USART1>;
+			resets = <&scmi0_reset RST_SCMI0_USART1>;
 			status = "disabled";
 		};
 
@@ -1563,8 +1539,8 @@
 			compatible = "st,stm32h7-spi";
 			reg = <0x5c001000 0x400>;
 			interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SPI6_K>;
-			resets = <&rcc SPI6_R>;
+			clocks = <&scmi0_clk CK_SCMI0_SPI6>;
+			resets = <&scmi0_reset RST_SCMI0_SPI6>;
 			dmas = <&mdma1 34 0x0 0x40008 0x0 0x0>,
 			       <&mdma1 35 0x0 0x40002 0x0 0x0>;
 			dma-names = "rx", "tx";
@@ -1577,8 +1553,8 @@
 			interrupt-names = "event", "error";
 			interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C4_K>;
-			resets = <&rcc I2C4_R>;
+			clocks = <&scmi0_clk CK_SCMI0_I2C4>;
+			resets = <&scmi0_reset RST_SCMI0_I2C4>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			st,syscfg-fmp = <&syscfg 0x4 0x8>;
@@ -1589,7 +1565,8 @@
 		rtc: rtc@5c004000 {
 			compatible = "st,stm32mp1-rtc";
 			reg = <0x5c004000 0x400>;
-			clocks = <&rcc RTCAPB>, <&rcc RTC>;
+			clocks = <&scmi0_clk CK_SCMI0_RTCAPB>,
+				 <&scmi0_clk CK_SCMI0_RTC>;
 			clock-names = "pclk", "rtc_ck";
 			interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
 			status = "disabled";
@@ -1614,8 +1591,8 @@
 			interrupt-names = "event", "error";
 			interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C6_K>;
-			resets = <&rcc I2C6_R>;
+			clocks = <&scmi0_clk CK_SCMI0_I2C6>;
+			resets = <&scmi0_reset RST_SCMI0_I2C6>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			st,syscfg-fmp = <&syscfg 0x4 0x20>;
@@ -1778,7 +1755,7 @@
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0 0x400>;
-				clocks = <&rcc GPIOZ>;
+				clocks = <&scmi0_clk CK_SCMI0_GPIOZ>;
 				st,bank-name = "GPIOZ";
 				st,bank-ioport = <11>;
 				status = "disabled";
@@ -1800,7 +1777,7 @@
 			reg = <0x10000000 0x40000>,
 			      <0x30000000 0x40000>,
 			      <0x38000000 0x10000>;
-			resets = <&rcc MCU_R>;
+			resets = <&scmi0_reset RST_SCMI0_MCU>;
 			st,syscfg-holdboot = <&rcc 0x10C 0x1>;
 			st,syscfg-tz = <&rcc 0x000 0x1>;
 			st,syscfg-pdds = <&pwr_mcu 0x0 0x1>;
diff --git a/arch/arm/boot/dts/stm32mp153.dtsi b/arch/arm/boot/dts/stm32mp153.dtsi
index 1c1889b194cf..db1273854675 100644
--- a/arch/arm/boot/dts/stm32mp153.dtsi
+++ b/arch/arm/boot/dts/stm32mp153.dtsi
@@ -30,7 +30,7 @@
 			interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-names = "int0", "int1";
-			clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
+			clocks = <&scmi0_clk CK_SCMI0_HSE>, <&rcc FDCAN_K>;
 			clock-names = "hclk", "cclk";
 			bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
 			status = "disabled";
@@ -43,7 +43,7 @@
 			interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-names = "int0", "int1";
-			clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
+			clocks = <&scmi0_clk CK_SCMI0_HSE>, <&rcc FDCAN_K>;
 			clock-names = "hclk", "cclk";
 			bosch,mram-cfg = <0x1400 0 0 32 0 0 2 2>;
 			status = "disabled";
diff --git a/arch/arm/boot/dts/stm32mp157.dtsi b/arch/arm/boot/dts/stm32mp157.dtsi
index 54e73ccea446..7b06c08e3a23 100644
--- a/arch/arm/boot/dts/stm32mp157.dtsi
+++ b/arch/arm/boot/dts/stm32mp157.dtsi
@@ -20,7 +20,7 @@
 		dsi: dsi@5a000000 {
 			compatible = "st,stm32-dsi";
 			reg = <0x5a000000 0x800>;
-			clocks = <&rcc DSI_K>, <&clk_hse>, <&rcc DSI_PX>;
+			clocks = <&rcc DSI_K>, <&scmi0_clk CK_SCMI0_HSE>, <&rcc DSI_PX>;
 			clock-names = "pclk", "ref", "px_clk";
 			resets = <&rcc DSI_R>;
 			reset-names = "apb";
diff --git a/arch/arm/boot/dts/stm32mp15xc.dtsi b/arch/arm/boot/dts/stm32mp15xc.dtsi
index b06a55a2fa18..435846883f25 100644
--- a/arch/arm/boot/dts/stm32mp15xc.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xc.dtsi
@@ -10,8 +10,8 @@
 			compatible = "st,stm32mp1-cryp";
 			reg = <0x54001000 0x400>;
 			interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc CRYP1>;
-			resets = <&rcc CRYP1_R>;
+			clocks = <&scmi0_clk CK_SCMI0_CRYP1>;
+			resets = <&scmi0_reset RST_SCMI0_CRYP1>;
 			status = "disabled";
 		};
 	};
-- 
2.17.1


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

Re: [Linux-stm32] [PATCH v2 12/14] ARM: dts: stm32: move clocks/resets to SCMI resources for stm32mp15

From: Ahmad Fatoum <a.fatoum@pengutronix.de>
Date: 2021-02-18 11:17:24 

Hello Gabriel,

On 26.01.21 10:01, gabriel.fernandez@foss.st.com wrote:
From: Gabriel Fernandez <redacted>

This change reflects board hardware configuration where RCC security
features are configured for RCC[TZEN]=1 and RCC[MCKPROT]=0, that is
RCC TrustZone is hardened and RCC MCKPROT is disabled.

Clock and reset controllers that relate to SoC secure resources are
moved from a RCC clock/reset handle to a SCMI clock/reset_domain handle.

These clocks are all the platform oscillators (HSI/LSI/CSI/HSE/LSE),
clocks for few subsystem and peripheral interfaces.

This change add a SCMI clock dependency on RCC clock device since it
registers clocks which parent clocks are provided by the SCMI clock
driver. This change allows the RCC clock device probe to be deferred
until SCMI clocks are fully registered in the system.
This would break existing boards, right? If so, you should move the
last patch in the series before this one and patch all existing boards
to use it. Maintainers of individual boards can then opt-in later by
deleting the arch/arm/boot/dts/stm32mp15-no-scmi.dtsi inclusion.

Cheers,
Ahmad
quoted hunk
Signed-off-by: Etienne Carriere <redacted>
Signed-off-by: Gabriel Fernandez <redacted>
---
 arch/arm/boot/dts/stm32mp151.dtsi  | 77 +++++++++++-------------------
 arch/arm/boot/dts/stm32mp153.dtsi  |  4 +-
 arch/arm/boot/dts/stm32mp157.dtsi  |  2 +-
 arch/arm/boot/dts/stm32mp15xc.dtsi |  4 +-
 4 files changed, 32 insertions(+), 55 deletions(-)

diff --git a/arch/arm/boot/dts/stm32mp151.dtsi b/arch/arm/boot/dts/stm32mp151.dtsi
index da3647373365..e06882e0611d 100644
--- a/arch/arm/boot/dts/stm32mp151.dtsi
+++ b/arch/arm/boot/dts/stm32mp151.dtsi
@@ -102,38 +102,6 @@
 		interrupt-parent = <&intc>;
 	};
 
-	clocks {
-		clk_hse: clk-hse {
-			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <24000000>;
-		};
-
-		clk_hsi: clk-hsi {
-			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <64000000>;
-		};
-
-		clk_lse: clk-lse {
-			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <32768>;
-		};
-
-		clk_lsi: clk-lsi {
-			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <32000>;
-		};
-
-		clk_csi: clk-csi {
-			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <4000000>;
-		};
-	};
-
 	thermal-zones {
 		cpu_thermal: cpu-thermal {
 			polling-delay-passive = <0>;
@@ -595,7 +563,7 @@
 			compatible = "st,stm32-cec";
 			reg = <0x40016000 0x400>;
 			interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc CEC_K>, <&clk_lse>;
+			clocks = <&rcc CEC_K>, <&scmi0_clk CK_SCMI0_LSE>;
 			clock-names = "cec", "hdmi-cec";
 			status = "disabled";
 		};
@@ -1156,10 +1124,17 @@
 		};
 
 		rcc: rcc@50000000 {
-			compatible = "st,stm32mp1-rcc", "syscon";
+			compatible = "st,stm32mp1-rcc-secure", "st,stm32mp1-rcc", "syscon";
 			reg = <0x50000000 0x1000>;
 			#clock-cells = <1>;
 			#reset-cells = <1>;
+
+			clock-names = "hse", "hsi", "csi", "lse", "lsi";
+			clocks = <&scmi0_clk CK_SCMI0_HSE>,
+				 <&scmi0_clk CK_SCMI0_HSI>,
+				 <&scmi0_clk CK_SCMI0_CSI>,
+				 <&scmi0_clk CK_SCMI0_LSE>,
+				 <&scmi0_clk CK_SCMI0_LSI>;
 		};
 
 		pwr_regulators: pwr@50001000 {
@@ -1342,8 +1317,8 @@
 			compatible = "st,stm32f756-hash";
 			reg = <0x54002000 0x400>;
 			interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc HASH1>;
-			resets = <&rcc HASH1_R>;
+			clocks = <&scmi0_clk CK_SCMI0_HASH1>;
+			resets = <&scmi0_reset RST_SCMI0_HASH1>;
 			dmas = <&mdma1 31 0x2 0x1000A02 0x0 0x0>;
 			dma-names = "in";
 			dma-maxburst = <2>;
@@ -1353,8 +1328,8 @@
 		rng1: rng@54003000 {
 			compatible = "st,stm32-rng";
 			reg = <0x54003000 0x400>;
-			clocks = <&rcc RNG1_K>;
-			resets = <&rcc RNG1_R>;
+			clocks = <&scmi0_clk CK_SCMI0_RNG1>;
+			resets = <&scmi0_reset RST_SCMI0_RNG1>;
 			status = "disabled";
 		};
 
@@ -1363,7 +1338,7 @@
 			reg = <0x58000000 0x1000>;
 			interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&rcc MDMA>;
-			resets = <&rcc MDMA_R>;
+			resets = <&scmi0_reset RST_SCMI0_MDMA>;
 			#dma-cells = <5>;
 			dma-channels = <32>;
 			dma-requests = <48>;
@@ -1524,7 +1499,7 @@
 		iwdg2: watchdog@5a002000 {
 			compatible = "st,stm32mp1-iwdg";
 			reg = <0x5a002000 0x400>;
-			clocks = <&rcc IWDG2>, <&rcc CK_LSI>;
+			clocks = <&rcc IWDG2>, <&scmi0_clk CK_SCMI0_LSI>;
 			clock-names = "pclk", "lsi";
 			status = "disabled";
 		};
@@ -1553,7 +1528,8 @@
 			compatible = "st,stm32h7-uart";
 			reg = <0x5c000000 0x400>;
 			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc USART1_K>;
+			clocks = <&scmi0_clk CK_SCMI0_USART1>;
+			resets = <&scmi0_reset RST_SCMI0_USART1>;
 			status = "disabled";
 		};
 
@@ -1563,8 +1539,8 @@
 			compatible = "st,stm32h7-spi";
 			reg = <0x5c001000 0x400>;
 			interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc SPI6_K>;
-			resets = <&rcc SPI6_R>;
+			clocks = <&scmi0_clk CK_SCMI0_SPI6>;
+			resets = <&scmi0_reset RST_SCMI0_SPI6>;
 			dmas = <&mdma1 34 0x0 0x40008 0x0 0x0>,
 			       <&mdma1 35 0x0 0x40002 0x0 0x0>;
 			dma-names = "rx", "tx";
@@ -1577,8 +1553,8 @@
 			interrupt-names = "event", "error";
 			interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C4_K>;
-			resets = <&rcc I2C4_R>;
+			clocks = <&scmi0_clk CK_SCMI0_I2C4>;
+			resets = <&scmi0_reset RST_SCMI0_I2C4>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			st,syscfg-fmp = <&syscfg 0x4 0x8>;
@@ -1589,7 +1565,8 @@
 		rtc: rtc@5c004000 {
 			compatible = "st,stm32mp1-rtc";
 			reg = <0x5c004000 0x400>;
-			clocks = <&rcc RTCAPB>, <&rcc RTC>;
+			clocks = <&scmi0_clk CK_SCMI0_RTCAPB>,
+				 <&scmi0_clk CK_SCMI0_RTC>;
 			clock-names = "pclk", "rtc_ck";
 			interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
 			status = "disabled";
@@ -1614,8 +1591,8 @@
 			interrupt-names = "event", "error";
 			interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc I2C6_K>;
-			resets = <&rcc I2C6_R>;
+			clocks = <&scmi0_clk CK_SCMI0_I2C6>;
+			resets = <&scmi0_reset RST_SCMI0_I2C6>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			st,syscfg-fmp = <&syscfg 0x4 0x20>;
@@ -1778,7 +1755,7 @@
 				interrupt-controller;
 				#interrupt-cells = <2>;
 				reg = <0 0x400>;
-				clocks = <&rcc GPIOZ>;
+				clocks = <&scmi0_clk CK_SCMI0_GPIOZ>;
 				st,bank-name = "GPIOZ";
 				st,bank-ioport = <11>;
 				status = "disabled";
@@ -1800,7 +1777,7 @@
 			reg = <0x10000000 0x40000>,
 			      <0x30000000 0x40000>,
 			      <0x38000000 0x10000>;
-			resets = <&rcc MCU_R>;
+			resets = <&scmi0_reset RST_SCMI0_MCU>;
 			st,syscfg-holdboot = <&rcc 0x10C 0x1>;
 			st,syscfg-tz = <&rcc 0x000 0x1>;
 			st,syscfg-pdds = <&pwr_mcu 0x0 0x1>;
diff --git a/arch/arm/boot/dts/stm32mp153.dtsi b/arch/arm/boot/dts/stm32mp153.dtsi
index 1c1889b194cf..db1273854675 100644
--- a/arch/arm/boot/dts/stm32mp153.dtsi
+++ b/arch/arm/boot/dts/stm32mp153.dtsi
@@ -30,7 +30,7 @@
 			interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-names = "int0", "int1";
-			clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
+			clocks = <&scmi0_clk CK_SCMI0_HSE>, <&rcc FDCAN_K>;
 			clock-names = "hclk", "cclk";
 			bosch,mram-cfg = <0x0 0 0 32 0 0 2 2>;
 			status = "disabled";
@@ -43,7 +43,7 @@
 			interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-names = "int0", "int1";
-			clocks = <&rcc CK_HSE>, <&rcc FDCAN_K>;
+			clocks = <&scmi0_clk CK_SCMI0_HSE>, <&rcc FDCAN_K>;
 			clock-names = "hclk", "cclk";
 			bosch,mram-cfg = <0x1400 0 0 32 0 0 2 2>;
 			status = "disabled";
diff --git a/arch/arm/boot/dts/stm32mp157.dtsi b/arch/arm/boot/dts/stm32mp157.dtsi
index 54e73ccea446..7b06c08e3a23 100644
--- a/arch/arm/boot/dts/stm32mp157.dtsi
+++ b/arch/arm/boot/dts/stm32mp157.dtsi
@@ -20,7 +20,7 @@
 		dsi: dsi@5a000000 {
 			compatible = "st,stm32-dsi";
 			reg = <0x5a000000 0x800>;
-			clocks = <&rcc DSI_K>, <&clk_hse>, <&rcc DSI_PX>;
+			clocks = <&rcc DSI_K>, <&scmi0_clk CK_SCMI0_HSE>, <&rcc DSI_PX>;
 			clock-names = "pclk", "ref", "px_clk";
 			resets = <&rcc DSI_R>;
 			reset-names = "apb";
diff --git a/arch/arm/boot/dts/stm32mp15xc.dtsi b/arch/arm/boot/dts/stm32mp15xc.dtsi
index b06a55a2fa18..435846883f25 100644
--- a/arch/arm/boot/dts/stm32mp15xc.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xc.dtsi
@@ -10,8 +10,8 @@
 			compatible = "st,stm32mp1-cryp";
 			reg = <0x54001000 0x400>;
 			interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&rcc CRYP1>;
-			resets = <&rcc CRYP1_R>;
+			clocks = <&scmi0_clk CK_SCMI0_CRYP1>;
+			resets = <&scmi0_reset RST_SCMI0_CRYP1>;
 			status = "disabled";
 		};
 	};
-- 
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 |

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

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

From: Alex G. <hidden>
Date: 2021-03-09 21:51:00 

On 1/26/21 3:01 AM, gabriel.fernandez@foss.st.com wrote:
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.

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

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

From: Alexandre TORGUE <hidden>
Date: 2021-03-11 08:10:41 

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

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

From: Marek Vasut <marex@denx.de>
Date: 2021-03-11 11:44:08 

On 3/11/21 9:08 AM, Alexandre TORGUE wrote:
Hi ALex
Hello everyone,

[...]
quoted
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:
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 third could be the less costly.
[...]

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

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

From: Alexandre TORGUE <alexandre.torgue@foss.st.com>
Date: 2021-03-11 13:17:37 

Hi Marek

On 3/11/21 12:43 PM, Marek Vasut wrote:
On 3/11/21 9:08 AM, Alexandre TORGUE wrote:
quoted
Hi ALex
Hello everyone,

[...]
quoted
quoted
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:
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.
quoted
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. >
quoted
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.
quoted
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.

Cheers

Alex


quoted
The third could be the less costly.
[...]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel





  

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

    

      From: Marek Vasut <marex@denx.de>

      Date: 2021-03-11 13:24:03 
    

  

  
On 3/11/21 2:15 PM, Alexandre TORGUE wrote:
Hi Marek
Hello Alexandre,

On 3/11/21 12:43 PM, Marek Vasut wrote:
quoted
On 3/11/21 9:08 AM, Alexandre TORGUE wrote:
quoted
Hi ALex
Hello everyone,

[...]

quoted
quoted
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:
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.

quoted
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. >
quoted
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.

quoted
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





  

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

    

      From: Alexandre TORGUE <alexandre.torgue@foss.st.com>

      Date: 2021-03-11 14:04:13 
    

  

  
Hi

On 3/11/21 12:43 PM, Marek Vasut wrote:
On 3/11/21 9:08 AM, Alexandre TORGUE wrote:
quoted
Hi ALex
Hello everyone,

[...]

quoted
quoted
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:
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.

quoted
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.

quoted
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.

quoted
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).

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

quoted
The third could be the less costly.
[...]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel





  

    
Re: [Linux-stm32] [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode

    

      From: Ahmad Fatoum <a.fatoum@pengutronix.de>

      Date: 2021-03-11 14:42:07 
    

  

  
Hello,

On 11.03.21 15:02, Alexandre TORGUE wrote:
On 3/11/21 12:43 PM, Marek Vasut wrote:
quoted
On 3/11/21 9:08 AM, Alexandre TORGUE wrote:
quoted
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.

quoted
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.

quoted
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

quoted
quoted
The third could be the less costly.
[...]
_______________________________________________
Linux-stm32 mailing list
Linux-stm32@st-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 |

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





  

    
Re: [Linux-stm32] [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode

    

      From: Alexandre TORGUE <alexandre.torgue@foss.st.com>

      Date: 2021-03-11 15:20:42 
    

  

  
Hi Ahmad

On 3/11/21 3:41 PM, Ahmad Fatoum wrote:
Hello,

On 11.03.21 15:02, Alexandre TORGUE wrote:
quoted
On 3/11/21 12:43 PM, Marek Vasut wrote:
quoted
On 3/11/21 9:08 AM, Alexandre TORGUE wrote:
quoted
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.

quoted
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.

quoted
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.
Discussing with tf-a and u-boot guys, this solution could imply hard 
synchronization between tf-a/u-boot. The most simple remains a "secure" dts.

regards
Alex

Cheers,
Ahmad

quoted
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

quoted
quoted
The third could be the less costly.
[...]
_______________________________________________
Linux-stm32 mailing list
Linux-stm32@st-md-mailman.stormreply.com
https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel





  

    
Re: [Linux-stm32] [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode

    

      From: Ahmad Fatoum <a.fatoum@pengutronix.de>

      Date: 2021-03-11 15:50:06 
    

  

  
Hello,

On 11.03.21 16:18, Alexandre TORGUE wrote:
quoted
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.
Discussing with tf-a and u-boot guys, this solution could imply hard synchronization between tf-a/u-boot. The most simple remains a "secure" dts.
OP-TEE can be configured via CFG_EXTERNAL_DTB_OVERLAY to pass
along an overlay that describes the reserved memory regions it uses.

A similiar approach could work here. The only synchronization you need
in Linux is to keep phandles that the overlay can reference.

Cheers,
Ahmad

regards
Alex

quoted
Cheers,
Ahmad

quoted
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

quoted
quoted
The third could be the less costly.
[...]
_______________________________________________
Linux-stm32 mailing list
Linux-stm32@st-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 |

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





  

    
Re: [Linux-stm32] [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode

    

      From: Marek Vasut <marex@denx.de>

      Date: 2021-03-11 16:12:59 
    

  

  
On 3/11/21 3:41 PM, Ahmad Fatoum wrote:
Hello,
Hi,

On 11.03.21 15:02, Alexandre TORGUE wrote:
quoted
On 3/11/21 12:43 PM, Marek Vasut wrote:
quoted
On 3/11/21 9:08 AM, Alexandre TORGUE wrote:
quoted
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.

quoted
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.

quoted
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.
That sounds good and it is something e.g. R-Car already does, it merges 
DT fragment from prior stages at U-Boot level and then passes the result 
to Linux.

So on ST hardware, the same could very well happen and it would work for 
both non-ATF / ATF / ATF+TEE options.

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





  

    
Re: [Linux-stm32] [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode

    

      From: Alexandre TORGUE <alexandre.torgue@foss.st.com>

      Date: 2021-03-11 18:12:10 
    

  

  
Hi Guys

On 3/11/21 5:11 PM, Marek Vasut wrote:
On 3/11/21 3:41 PM, Ahmad Fatoum wrote:
quoted
Hello,
Hi,

quoted
On 11.03.21 15:02, Alexandre TORGUE wrote:
quoted
On 3/11/21 12:43 PM, Marek Vasut wrote:
quoted
On 3/11/21 9:08 AM, Alexandre TORGUE wrote:
quoted
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.

quoted
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.

quoted
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.
That sounds good and it is something e.g. R-Car already does, it merges 
DT fragment from prior stages at U-Boot level and then passes the result 
to Linux.

So on ST hardware, the same could very well happen and it would work for 
both non-ATF / ATF / ATF+TEE options.
Even this solution sounds good but we are currently not able to do it in 
our TF-A/u-boot so not feasible for the moment. So we have to find a 
solution for now. Create a new dtb can be this solution. Our internal 
strategy is to use scmi on our official ST board. It will be a really 
drawback to include a "no-scmi.dtsi" in DH boards (for example) and to 
create a stm32mp157c-noscmi-dk2.dts ?



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





  

    
Re: [Linux-stm32] [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode

    

      From: Alex G. <hidden>

      Date: 2021-03-11 18:24:41 
    

  

  

On 3/11/21 12:10 PM, Alexandre TORGUE wrote:
Hi Guys

On 3/11/21 5:11 PM, Marek Vasut wrote:
quoted
On 3/11/21 3:41 PM, Ahmad Fatoum wrote:
quoted
Hello,
Hi,

quoted
On 11.03.21 15:02, Alexandre TORGUE wrote:
quoted
On 3/11/21 12:43 PM, Marek Vasut wrote:
quoted
On 3/11/21 9:08 AM, Alexandre TORGUE wrote:
quoted
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.

quoted
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.

quoted
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.
That sounds good and it is something e.g. R-Car already does, it 
merges DT fragment from prior stages at U-Boot level and then passes 
the result to Linux.

So on ST hardware, the same could very well happen and it would work 
for both non-ATF / ATF / ATF+TEE options.
Even this solution sounds good but we are currently not able to do it in 
our TF-A/u-boot so not feasible for the moment. So we have to find a 
solution for now. Create a new dtb can be this solution. Our internal 
strategy is to use scmi on our official ST board. It will be a really 
drawback to include a "no-scmi.dtsi" in DH boards (for example) and to 
create a stm32mp157c-noscmi-dk2.dts ?
It could work, as long as all users are reminded to change their build 
scripts to pick up a "-noscmi.dtb". I suspect that if this were the case 
we'll see quite a few bug reports saying "stm32mp1 no longer boots with 
kernel v5.13".

I didn't think of this originally, though u-boot already does the DTB 
patching for OPTEE reserved memory regions. It's not too hard to also 
patch in the SCMI clocks at boot. In u-boot's case, runtime detection 
might even be feasible.

Alex

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





  

    
Re: [Linux-stm32] [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode

    

      From: Marek Vasut <marex@denx.de>

      Date: 2021-03-11 20:10:20 
    

  

  
On 3/11/21 7:10 PM, Alexandre TORGUE wrote:
Hi Guys

On 3/11/21 5:11 PM, Marek Vasut wrote:
quoted
On 3/11/21 3:41 PM, Ahmad Fatoum wrote:
quoted
Hello,
Hi,

quoted
On 11.03.21 15:02, Alexandre TORGUE wrote:
quoted
On 3/11/21 12:43 PM, Marek Vasut wrote:
quoted
On 3/11/21 9:08 AM, Alexandre TORGUE wrote:
quoted
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.

quoted
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.

quoted
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.
That sounds good and it is something e.g. R-Car already does, it 
merges DT fragment from prior stages at U-Boot level and then passes 
the result to Linux.

So on ST hardware, the same could very well happen and it would work 
for both non-ATF / ATF / ATF+TEE options.
Even this solution sounds good but we are currently not able to do it in 
our TF-A/u-boot so not feasible for the moment.
Why not ? U-Boot is perfectly capable of merging prior stage DT and DT 
loaded from elsewhere. See R-Car3 for example.

So we have to find a 
solution for now. Create a new dtb can be this solution. Our internal 
strategy is to use scmi on our official ST board. It will be a really 
drawback to include a "no-scmi.dtsi" in DH boards (for example) and to 
create a stm32mp157c-noscmi-dk2.dts ?
I would highly prefer the SCMI to be opt-in, not opt-out.

But still, isn't it possible to auto-detect the board configuration in 
Linux and pick the clock enumeration based on that automatically ?

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





  

    
Re: [Linux-stm32] [PATCH v2 00/14] Introduce STM32MP1 RCC in secured mode

    

      From: Alexandre TORGUE <alexandre.torgue@foss.st.com>

      Date: 2021-03-12 08:24:38 
    

  

  
Hi Marek

On 3/11/21 9:09 PM, Marek Vasut wrote:
On 3/11/21 7:10 PM, Alexandre TORGUE wrote:
quoted
Hi Guys

On 3/11/21 5:11 PM, Marek Vasut wrote:
quoted
On 3/11/21 3:41 PM, Ahmad Fatoum wrote:
quoted
Hello,
Hi,

quoted
On 11.03.21 15:02, Alexandre TORGUE wrote:
quoted
On 3/11/21 12:43 PM, Marek Vasut wrote:
quoted
On 3/11/21 9:08 AM, Alexandre TORGUE wrote:
quoted
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.

quoted
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.

quoted
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.
That sounds good and it is something e.g. R-Car already does, it 
merges DT fragment from prior stages at U-Boot level and then passes 
the result to Linux.

So on ST hardware, the same could very well happen and it would work 
for both non-ATF / ATF / ATF+TEE options.
Even this solution sounds good but we are currently not able to do it 
in our TF-A/u-boot so not feasible for the moment.
Why not ? U-Boot is perfectly capable of merging prior stage DT and DT 
loaded from elsewhere. See R-Car3 for example.
Ok, We will check what it is possible to do by this way before taking a 
decision.

Thanks
Alex

quoted
So we have to find a solution for now. Create a new dtb can be this 
solution. Our internal strategy is to use scmi on our official ST 
board. It will be a really drawback to include a "no-scmi.dtsi" in DH 
boards (for example) and to create a stm32mp157c-noscmi-dk2.dts ?
I would highly prefer the SCMI to be opt-in, not opt-out.

But still, isn't it possible to auto-detect the board configuration in 
Linux and pick the clock enumeration based on that automatically ?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel




    
  

  
    

      

        Keyboard shortcuts
      

      

        
          
hback out one level

          
jnext message in thread

          
kprevious message in thread

          
ldrill in

          
Escclose help / fold thread tree

          
?toggle this help