[PATCH 0/5] power: Adding support for Microchip Sparx5 SoC

[PATCH 0/5] power: Adding support for Microchip Sparx5 SoC

[Lars Povlsen]

This is an add-on series to the main SoC Sparx5 series
(Message-ID: <20200513125532.24585-1-lars.povlsen@microchip.com>).

It adds reset support for Sparx5, using the ocelot reset driver.

It is expected that the DT patches are to be taken directly by the arm-soc
maintainers.

Lars Povlsen (5):
  dt-bindings: reset: ocelot: Add Sparx5 support
  power: reset: ocelot: Add support for Sparx5
  dt-bindings: reset: ocelot: Add documentation for
    'microchip,reset-switch-core' property
  power: reset: ocelot: Add support for reset switch on load time
  arm64: dts: sparx5: Add reset support

 .../bindings/power/reset/ocelot-reset.txt     | 13 ++-
 MAINTAINERS                                   |  1 +
 arch/arm64/boot/dts/microchip/sparx5.dtsi     | 11 +++
 drivers/power/reset/Kconfig                   |  3 +-
 drivers/power/reset/ocelot-reset.c            | 95 ++++++++++++++++---
 5 files changed, 105 insertions(+), 18 deletions(-)

--
2.26.2

[PATCH 0/5] power: Adding support for Microchip Sparx5 SoC

[Lars Povlsen]

This is an add-on series to the main SoC Sparx5 series
(Message-ID: <20200513125532.24585-1-lars.povlsen@microchip.com>).

It adds reset support for Sparx5, using the ocelot reset driver.

It is expected that the DT patches are to be taken directly by the arm-soc
maintainers.

Lars Povlsen (5):
  dt-bindings: reset: ocelot: Add Sparx5 support
  power: reset: ocelot: Add support for Sparx5
  dt-bindings: reset: ocelot: Add documentation for
    'microchip,reset-switch-core' property
  power: reset: ocelot: Add support for reset switch on load time
  arm64: dts: sparx5: Add reset support

 .../bindings/power/reset/ocelot-reset.txt     | 13 ++-
 MAINTAINERS                                   |  1 +
 arch/arm64/boot/dts/microchip/sparx5.dtsi     | 11 +++
 drivers/power/reset/Kconfig                   |  3 +-
 drivers/power/reset/ocelot-reset.c            | 95 ++++++++++++++++---
 5 files changed, 105 insertions(+), 18 deletions(-)

--
2.26.2

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

[PATCH 1/5] dt-bindings: reset: ocelot: Add Sparx5 support

[Lars Povlsen]

This adds the support for the Sparx5 SoC.

Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
---
 .../devicetree/bindings/power/reset/ocelot-reset.txt       | 7 +++++--
 MAINTAINERS                                                | 1 +
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
index 1b4213eb34731..4d530d8154848 100644
--- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
+++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
@@ -1,10 +1,13 @@
 Microsemi Ocelot reset controller

 The DEVCPU_GCB:CHIP_REGS have a SOFT_RST register that can be used to reset the
-SoC MIPS core.
+SoC core.
+
+The reset registers are both present in the MSCC vcoreiii MIPS and
+microchip Sparx5 armv8 SoC's.

 Required Properties:
- - compatible: "mscc,ocelot-chip-reset"
+ - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-reset"

 Example:
 	reset@1070008 {
diff --git a/MAINTAINERS b/MAINTAINERS
index 5aa28d6e39d4f..1db598723a1d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11230,6 +11230,7 @@ M:	Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
 L:	linux-mips@vger.kernel.org
 S:	Supported
 F:	Documentation/devicetree/bindings/mips/mscc.txt
+F:	Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
 F:	arch/mips/boot/dts/mscc/
 F:	arch/mips/configs/generic/board-ocelot.config
 F:	arch/mips/generic/board-ocelot.c
--
2.26.2

[PATCH 1/5] dt-bindings: reset: ocelot: Add Sparx5 support

[Lars Povlsen]

This adds the support for the Sparx5 SoC.

Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
---
 .../devicetree/bindings/power/reset/ocelot-reset.txt       | 7 +++++--
 MAINTAINERS                                                | 1 +
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
index 1b4213eb34731..4d530d8154848 100644
--- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
+++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
@@ -1,10 +1,13 @@
 Microsemi Ocelot reset controller

 The DEVCPU_GCB:CHIP_REGS have a SOFT_RST register that can be used to reset the
-SoC MIPS core.
+SoC core.
+
+The reset registers are both present in the MSCC vcoreiii MIPS and
+microchip Sparx5 armv8 SoC's.

 Required Properties:
- - compatible: "mscc,ocelot-chip-reset"
+ - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-reset"

 Example:
 	reset@1070008 {
diff --git a/MAINTAINERS b/MAINTAINERS
index 5aa28d6e39d4f..1db598723a1d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11230,6 +11230,7 @@ M:	Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
 L:	linux-mips@vger.kernel.org
 S:	Supported
 F:	Documentation/devicetree/bindings/mips/mscc.txt
+F:	Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
 F:	arch/mips/boot/dts/mscc/
 F:	arch/mips/configs/generic/board-ocelot.config
 F:	arch/mips/generic/board-ocelot.c
--
2.26.2

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

[PATCH 2/5] power: reset: ocelot: Add support for Sparx5

[Lars Povlsen]

This adds reset support for Sparx5 in the ocelot-reset driver.

Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
---
 drivers/power/reset/Kconfig        |  3 +-
 drivers/power/reset/ocelot-reset.c | 55 +++++++++++++++++++++++-------
 2 files changed, 44 insertions(+), 14 deletions(-)

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 8903803020805..9ecafbf9e64a6 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -118,10 +118,9 @@ config POWER_RESET_QCOM_PON
 
 config POWER_RESET_OCELOT_RESET
 	bool "Microsemi Ocelot reset driver"
-	depends on MSCC_OCELOT || COMPILE_TEST
 	select MFD_SYSCON
 	help
-	  This driver supports restart for Microsemi Ocelot SoC.
+	  This driver supports restart for Microsemi Ocelot SoC and similar.
 
 config POWER_RESET_PIIX4_POWEROFF
 	tristate "Intel PIIX4 power-off driver"
diff --git a/drivers/power/reset/ocelot-reset.c b/drivers/power/reset/ocelot-reset.c
index 419952c61fd01..f74e1dbb4ba36 100644
--- a/drivers/power/reset/ocelot-reset.c
+++ b/drivers/power/reset/ocelot-reset.c
@@ -15,15 +15,20 @@
 #include <linux/reboot.h>
 #include <linux/regmap.h>
 
+struct reset_props {
+	const char *syscon;
+	u32 protect_reg;
+	u32 vcore_protect;
+	u32 if_si_owner_bit;
+};
+
 struct ocelot_reset_context {
 	void __iomem *base;
 	struct regmap *cpu_ctrl;
+	const struct reset_props *props;
 	struct notifier_block restart_handler;
 };
 
-#define ICPU_CFG_CPU_SYSTEM_CTRL_RESET 0x20
-#define CORE_RST_PROTECT BIT(2)
-
 #define SOFT_CHIP_RST BIT(0)
 
 #define ICPU_CFG_CPU_SYSTEM_CTRL_GENERAL_CTRL	0x24
@@ -31,7 +36,6 @@ struct ocelot_reset_context {
 #define IF_SI_OWNER_SISL			0
 #define IF_SI_OWNER_SIBM			1
 #define IF_SI_OWNER_SIMC			2
-#define IF_SI_OWNER_OFFSET			4
 
 static int ocelot_restart_handle(struct notifier_block *this,
 				 unsigned long mode, void *cmd)
@@ -39,15 +43,18 @@ static int ocelot_restart_handle(struct notifier_block *this,
 	struct ocelot_reset_context *ctx = container_of(this, struct
 							ocelot_reset_context,
 							restart_handler);
+	u32 if_si_owner_bit = ctx->props->if_si_owner_bit;
 
 	/* Make sure the core is not protected from reset */
-	regmap_update_bits(ctx->cpu_ctrl, ICPU_CFG_CPU_SYSTEM_CTRL_RESET,
-			   CORE_RST_PROTECT, 0);
+	regmap_update_bits(ctx->cpu_ctrl, ctx->props->protect_reg,
+			   ctx->props->vcore_protect, 0);
 
 	/* Make the SI back to boot mode */
 	regmap_update_bits(ctx->cpu_ctrl, ICPU_CFG_CPU_SYSTEM_CTRL_GENERAL_CTRL,
-			   IF_SI_OWNER_MASK << IF_SI_OWNER_OFFSET,
-			   IF_SI_OWNER_SIBM << IF_SI_OWNER_OFFSET);
+			   IF_SI_OWNER_MASK << if_si_owner_bit,
+			   IF_SI_OWNER_SIBM << if_si_owner_bit);
+
+	pr_emerg("Resetting SoC\n");
 
 	writel(SOFT_CHIP_RST, ctx->base);
 
@@ -72,9 +79,13 @@ static int ocelot_reset_probe(struct platform_device *pdev)
 	if (IS_ERR(ctx->base))
 		return PTR_ERR(ctx->base);
 
-	ctx->cpu_ctrl = syscon_regmap_lookup_by_compatible("mscc,ocelot-cpu-syscon");
-	if (IS_ERR(ctx->cpu_ctrl))
+	ctx->props = device_get_match_data(dev);
+
+	ctx->cpu_ctrl = syscon_regmap_lookup_by_compatible(ctx->props->syscon);
+	if (IS_ERR(ctx->cpu_ctrl)) {
+		dev_err(dev, "No syscon map: %s\n", ctx->props->syscon);
 		return PTR_ERR(ctx->cpu_ctrl);
+	}
 
 	ctx->restart_handler.notifier_call = ocelot_restart_handle;
 	ctx->restart_handler.priority = 192;
@@ -85,9 +96,29 @@ static int ocelot_reset_probe(struct platform_device *pdev)
 	return err;
 }
 
+static const struct reset_props reset_props_ocelot = {
+	.syscon		 = "mscc,ocelot-cpu-syscon",
+	.protect_reg     = 0x20,
+	.vcore_protect   = BIT(2),
+	.if_si_owner_bit = 4,
+};
+
+static const struct reset_props reset_props_sparx5 = {
+	.syscon		 = "microchip,sparx5-cpu-syscon",
+	.protect_reg     = 0x84,
+	.vcore_protect   = BIT(10),
+	.if_si_owner_bit = 6,
+};
+
 static const struct of_device_id ocelot_reset_of_match[] = {
-	{ .compatible = "mscc,ocelot-chip-reset" },
-	{}
+	{
+		.compatible = "mscc,ocelot-chip-reset",
+		.data = &reset_props_ocelot
+	}, {
+		.compatible = "microchip,sparx5-chip-reset",
+		.data = &reset_props_sparx5
+	},
+	{ /*sentinel*/ }
 };
 
 static struct platform_driver ocelot_reset_driver = {
-- 
2.26.2

[PATCH 2/5] power: reset: ocelot: Add support for Sparx5

[Lars Povlsen]

This adds reset support for Sparx5 in the ocelot-reset driver.

Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
---
 drivers/power/reset/Kconfig        |  3 +-
 drivers/power/reset/ocelot-reset.c | 55 +++++++++++++++++++++++-------
 2 files changed, 44 insertions(+), 14 deletions(-)

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 8903803020805..9ecafbf9e64a6 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -118,10 +118,9 @@ config POWER_RESET_QCOM_PON
 
 config POWER_RESET_OCELOT_RESET
 	bool "Microsemi Ocelot reset driver"
-	depends on MSCC_OCELOT || COMPILE_TEST
 	select MFD_SYSCON
 	help
-	  This driver supports restart for Microsemi Ocelot SoC.
+	  This driver supports restart for Microsemi Ocelot SoC and similar.
 
 config POWER_RESET_PIIX4_POWEROFF
 	tristate "Intel PIIX4 power-off driver"
diff --git a/drivers/power/reset/ocelot-reset.c b/drivers/power/reset/ocelot-reset.c
index 419952c61fd01..f74e1dbb4ba36 100644
--- a/drivers/power/reset/ocelot-reset.c
+++ b/drivers/power/reset/ocelot-reset.c
@@ -15,15 +15,20 @@
 #include <linux/reboot.h>
 #include <linux/regmap.h>
 
+struct reset_props {
+	const char *syscon;
+	u32 protect_reg;
+	u32 vcore_protect;
+	u32 if_si_owner_bit;
+};
+
 struct ocelot_reset_context {
 	void __iomem *base;
 	struct regmap *cpu_ctrl;
+	const struct reset_props *props;
 	struct notifier_block restart_handler;
 };
 
-#define ICPU_CFG_CPU_SYSTEM_CTRL_RESET 0x20
-#define CORE_RST_PROTECT BIT(2)
-
 #define SOFT_CHIP_RST BIT(0)
 
 #define ICPU_CFG_CPU_SYSTEM_CTRL_GENERAL_CTRL	0x24
@@ -31,7 +36,6 @@ struct ocelot_reset_context {
 #define IF_SI_OWNER_SISL			0
 #define IF_SI_OWNER_SIBM			1
 #define IF_SI_OWNER_SIMC			2
-#define IF_SI_OWNER_OFFSET			4
 
 static int ocelot_restart_handle(struct notifier_block *this,
 				 unsigned long mode, void *cmd)
@@ -39,15 +43,18 @@ static int ocelot_restart_handle(struct notifier_block *this,
 	struct ocelot_reset_context *ctx = container_of(this, struct
 							ocelot_reset_context,
 							restart_handler);
+	u32 if_si_owner_bit = ctx->props->if_si_owner_bit;
 
 	/* Make sure the core is not protected from reset */
-	regmap_update_bits(ctx->cpu_ctrl, ICPU_CFG_CPU_SYSTEM_CTRL_RESET,
-			   CORE_RST_PROTECT, 0);
+	regmap_update_bits(ctx->cpu_ctrl, ctx->props->protect_reg,
+			   ctx->props->vcore_protect, 0);
 
 	/* Make the SI back to boot mode */
 	regmap_update_bits(ctx->cpu_ctrl, ICPU_CFG_CPU_SYSTEM_CTRL_GENERAL_CTRL,
-			   IF_SI_OWNER_MASK << IF_SI_OWNER_OFFSET,
-			   IF_SI_OWNER_SIBM << IF_SI_OWNER_OFFSET);
+			   IF_SI_OWNER_MASK << if_si_owner_bit,
+			   IF_SI_OWNER_SIBM << if_si_owner_bit);
+
+	pr_emerg("Resetting SoC\n");
 
 	writel(SOFT_CHIP_RST, ctx->base);
 
@@ -72,9 +79,13 @@ static int ocelot_reset_probe(struct platform_device *pdev)
 	if (IS_ERR(ctx->base))
 		return PTR_ERR(ctx->base);
 
-	ctx->cpu_ctrl = syscon_regmap_lookup_by_compatible("mscc,ocelot-cpu-syscon");
-	if (IS_ERR(ctx->cpu_ctrl))
+	ctx->props = device_get_match_data(dev);
+
+	ctx->cpu_ctrl = syscon_regmap_lookup_by_compatible(ctx->props->syscon);
+	if (IS_ERR(ctx->cpu_ctrl)) {
+		dev_err(dev, "No syscon map: %s\n", ctx->props->syscon);
 		return PTR_ERR(ctx->cpu_ctrl);
+	}
 
 	ctx->restart_handler.notifier_call = ocelot_restart_handle;
 	ctx->restart_handler.priority = 192;
@@ -85,9 +96,29 @@ static int ocelot_reset_probe(struct platform_device *pdev)
 	return err;
 }
 
+static const struct reset_props reset_props_ocelot = {
+	.syscon		 = "mscc,ocelot-cpu-syscon",
+	.protect_reg     = 0x20,
+	.vcore_protect   = BIT(2),
+	.if_si_owner_bit = 4,
+};
+
+static const struct reset_props reset_props_sparx5 = {
+	.syscon		 = "microchip,sparx5-cpu-syscon",
+	.protect_reg     = 0x84,
+	.vcore_protect   = BIT(10),
+	.if_si_owner_bit = 6,
+};
+
 static const struct of_device_id ocelot_reset_of_match[] = {
-	{ .compatible = "mscc,ocelot-chip-reset" },
-	{}
+	{
+		.compatible = "mscc,ocelot-chip-reset",
+		.data = &reset_props_ocelot
+	}, {
+		.compatible = "microchip,sparx5-chip-reset",
+		.data = &reset_props_sparx5
+	},
+	{ /*sentinel*/ }
 };
 
 static struct platform_driver ocelot_reset_driver = {
-- 
2.26.2


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

[PATCH 3/5] dt-bindings: reset: ocelot: Add documentation for 'microchip,reset-switch-core' property

[Lars Povlsen]

This documents the 'microchip,reset-switch-core' property in the
ocelot-reset driver.

Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
---
 .../devicetree/bindings/power/reset/ocelot-reset.txt        | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
index 4d530d8154848..20fff03753ad2 100644
--- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
+++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
@@ -9,9 +9,15 @@ microchip Sparx5 armv8 SoC's.
 Required Properties:
  - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-reset"

+Optional properties:
+- microchip,reset-switch-core : Perform a switch core reset at the
+  time of driver load. This is may be used to initialize the switch
+  core to a known state (before other drivers are loaded).
+
 Example:
 	reset@1070008 {
 		compatible = "mscc,ocelot-chip-reset";
 		reg = <0x1070008 0x4>;
+		microchip,reset-switch-core;
 	};

--
2.26.2

[PATCH 3/5] dt-bindings: reset: ocelot: Add documentation for 'microchip, reset-switch-core' property

[Lars Povlsen]

This documents the 'microchip,reset-switch-core' property in the
ocelot-reset driver.

Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
---
 .../devicetree/bindings/power/reset/ocelot-reset.txt        | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
index 4d530d8154848..20fff03753ad2 100644
--- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
+++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
@@ -9,9 +9,15 @@ microchip Sparx5 armv8 SoC's.
 Required Properties:
  - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-reset"

+Optional properties:
+- microchip,reset-switch-core : Perform a switch core reset at the
+  time of driver load. This is may be used to initialize the switch
+  core to a known state (before other drivers are loaded).
+
 Example:
 	reset@1070008 {
 		compatible = "mscc,ocelot-chip-reset";
 		reg = <0x1070008 0x4>;
+		microchip,reset-switch-core;
 	};

--
2.26.2

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

[PATCH 4/5] power: reset: ocelot: Add support for reset switch on load time

[Lars Povlsen]

This patch add support for resetting the networking switch core at
reset driver load time. It is useful in order to bring the switch core
in a known state after a reboot or after a bootloader may have been
using the switch for network access.

Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
---
 drivers/power/reset/ocelot-reset.c | 40 ++++++++++++++++++++++++++++--
 1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/drivers/power/reset/ocelot-reset.c b/drivers/power/reset/ocelot-reset.c
index f74e1dbb4ba36..a203c42e99d42 100644
--- a/drivers/power/reset/ocelot-reset.c
+++ b/drivers/power/reset/ocelot-reset.c
@@ -29,6 +29,7 @@ struct ocelot_reset_context {
 	struct notifier_block restart_handler;
 };
 
+#define SOFT_SWC_RST  BIT(1)
 #define SOFT_CHIP_RST BIT(0)
 
 #define ICPU_CFG_CPU_SYSTEM_CTRL_GENERAL_CTRL	0x24
@@ -37,6 +38,32 @@ struct ocelot_reset_context {
 #define IF_SI_OWNER_SIBM			1
 #define IF_SI_OWNER_SIMC			2
 
+static int ocelot_switch_core_reset(const struct ocelot_reset_context *ctx)
+{
+
+	const char *driver = "ocelot-reset";
+	int timeout;
+
+	pr_notice("%s: Resetting Switch Core\n", driver);
+
+	/* Make sure the core is PROTECTED from reset */
+	regmap_update_bits(ctx->cpu_ctrl, ctx->props->protect_reg,
+			   ctx->props->vcore_protect,
+			   ctx->props->vcore_protect);
+
+	writel(SOFT_SWC_RST, ctx->base);
+	for (timeout = 0; timeout < 100; timeout++) {
+		if ((readl(ctx->base) & SOFT_SWC_RST) == 0) {
+			pr_debug("%s: Switch Core Reset complete.\n", driver);
+			return 0;
+		}
+		udelay(1);
+	}
+
+	pr_warn("%s: Switch Core Reset timeout!\n", driver);
+	return -ENXIO;
+}
+
 static int ocelot_restart_handle(struct notifier_block *this,
 				 unsigned long mode, void *cmd)
 {
@@ -66,7 +93,6 @@ static int ocelot_reset_probe(struct platform_device *pdev)
 {
 	struct ocelot_reset_context *ctx;
 	struct resource *res;
-
 	struct device *dev = &pdev->dev;
 	int err;
 
@@ -87,6 +113,11 @@ static int ocelot_reset_probe(struct platform_device *pdev)
 		return PTR_ERR(ctx->cpu_ctrl);
 	}
 
+	/* Optionally, call switch reset function */
+	if (of_property_read_bool(pdev->dev.of_node,
+				  "microchip,reset-switch-core"))
+		ocelot_switch_core_reset(ctx);
+
 	ctx->restart_handler.notifier_call = ocelot_restart_handle;
 	ctx->restart_handler.priority = 192;
 	err = register_restart_handler(&ctx->restart_handler);
@@ -128,4 +159,9 @@ static struct platform_driver ocelot_reset_driver = {
 		.of_match_table = ocelot_reset_of_match,
 	},
 };
-builtin_platform_driver(ocelot_reset_driver);
+
+static int __init reset_init(void)
+{
+	return platform_driver_register(&ocelot_reset_driver);
+}
+postcore_initcall(reset_init);
-- 
2.26.2

[PATCH 4/5] power: reset: ocelot: Add support for reset switch on load time

[Lars Povlsen]

This patch add support for resetting the networking switch core at
reset driver load time. It is useful in order to bring the switch core
in a known state after a reboot or after a bootloader may have been
using the switch for network access.

Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
---
 drivers/power/reset/ocelot-reset.c | 40 ++++++++++++++++++++++++++++--
 1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/drivers/power/reset/ocelot-reset.c b/drivers/power/reset/ocelot-reset.c
index f74e1dbb4ba36..a203c42e99d42 100644
--- a/drivers/power/reset/ocelot-reset.c
+++ b/drivers/power/reset/ocelot-reset.c
@@ -29,6 +29,7 @@ struct ocelot_reset_context {
 	struct notifier_block restart_handler;
 };
 
+#define SOFT_SWC_RST  BIT(1)
 #define SOFT_CHIP_RST BIT(0)
 
 #define ICPU_CFG_CPU_SYSTEM_CTRL_GENERAL_CTRL	0x24
@@ -37,6 +38,32 @@ struct ocelot_reset_context {
 #define IF_SI_OWNER_SIBM			1
 #define IF_SI_OWNER_SIMC			2
 
+static int ocelot_switch_core_reset(const struct ocelot_reset_context *ctx)
+{
+
+	const char *driver = "ocelot-reset";
+	int timeout;
+
+	pr_notice("%s: Resetting Switch Core\n", driver);
+
+	/* Make sure the core is PROTECTED from reset */
+	regmap_update_bits(ctx->cpu_ctrl, ctx->props->protect_reg,
+			   ctx->props->vcore_protect,
+			   ctx->props->vcore_protect);
+
+	writel(SOFT_SWC_RST, ctx->base);
+	for (timeout = 0; timeout < 100; timeout++) {
+		if ((readl(ctx->base) & SOFT_SWC_RST) == 0) {
+			pr_debug("%s: Switch Core Reset complete.\n", driver);
+			return 0;
+		}
+		udelay(1);
+	}
+
+	pr_warn("%s: Switch Core Reset timeout!\n", driver);
+	return -ENXIO;
+}
+
 static int ocelot_restart_handle(struct notifier_block *this,
 				 unsigned long mode, void *cmd)
 {
@@ -66,7 +93,6 @@ static int ocelot_reset_probe(struct platform_device *pdev)
 {
 	struct ocelot_reset_context *ctx;
 	struct resource *res;
-
 	struct device *dev = &pdev->dev;
 	int err;
 
@@ -87,6 +113,11 @@ static int ocelot_reset_probe(struct platform_device *pdev)
 		return PTR_ERR(ctx->cpu_ctrl);
 	}
 
+	/* Optionally, call switch reset function */
+	if (of_property_read_bool(pdev->dev.of_node,
+				  "microchip,reset-switch-core"))
+		ocelot_switch_core_reset(ctx);
+
 	ctx->restart_handler.notifier_call = ocelot_restart_handle;
 	ctx->restart_handler.priority = 192;
 	err = register_restart_handler(&ctx->restart_handler);
@@ -128,4 +159,9 @@ static struct platform_driver ocelot_reset_driver = {
 		.of_match_table = ocelot_reset_of_match,
 	},
 };
-builtin_platform_driver(ocelot_reset_driver);
+
+static int __init reset_init(void)
+{
+	return platform_driver_register(&ocelot_reset_driver);
+}
+postcore_initcall(reset_init);
-- 
2.26.2


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

[PATCH 5/5] arm64: dts: sparx5: Add reset support

[Lars Povlsen]

This adds reset support to the Sparx5 SoC

Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
---
 arch/arm64/boot/dts/microchip/sparx5.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi b/arch/arm64/boot/dts/microchip/sparx5.dtsi
index b5cb3d8dc876b..3e94ac9e7dd51 100644
--- a/arch/arm64/boot/dts/microchip/sparx5.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
@@ -106,6 +106,17 @@ gic: interrupt-controller@600300000 {
 			interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
 		};
 
+		cpu_ctrl: syscon@600000000 {
+			compatible = "microchip,sparx5-cpu-syscon", "syscon";
+			reg = <0x6 0x00000000 0xd0>;
+		};
+
+		reset@611010008 {
+			compatible = "microchip,sparx5-chip-reset";
+			reg = <0x6 0x11010008 0x4>;
+			microchip,reset-switch-core;
+		};
+
 		uart0: serial@600100000 {
 			pinctrl-0 = <&uart_pins>;
 			pinctrl-names = "default";
-- 
2.26.2

[PATCH 5/5] arm64: dts: sparx5: Add reset support

[Lars Povlsen]

This adds reset support to the Sparx5 SoC

Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
---
 arch/arm64/boot/dts/microchip/sparx5.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi b/arch/arm64/boot/dts/microchip/sparx5.dtsi
index b5cb3d8dc876b..3e94ac9e7dd51 100644
--- a/arch/arm64/boot/dts/microchip/sparx5.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
@@ -106,6 +106,17 @@ gic: interrupt-controller@600300000 {
 			interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
 		};
 
+		cpu_ctrl: syscon@600000000 {
+			compatible = "microchip,sparx5-cpu-syscon", "syscon";
+			reg = <0x6 0x00000000 0xd0>;
+		};
+
+		reset@611010008 {
+			compatible = "microchip,sparx5-chip-reset";
+			reg = <0x6 0x11010008 0x4>;
+			microchip,reset-switch-core;
+		};
+
 		uart0: serial@600100000 {
 			pinctrl-0 = <&uart_pins>;
 			pinctrl-names = "default";
-- 
2.26.2


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

Re: [PATCH 3/5] dt-bindings: reset: ocelot: Add documentation for 'microchip,reset-switch-core' property

[Rob Herring]

On Wed, May 13, 2020 at 03:08:40PM +0200, Lars Povlsen wrote:
> This documents the 'microchip,reset-switch-core' property in the
> ocelot-reset driver.
> 
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> ---
>  .../devicetree/bindings/power/reset/ocelot-reset.txt        | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> index 4d530d8154848..20fff03753ad2 100644
> --- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> +++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> @@ -9,9 +9,15 @@ microchip Sparx5 armv8 SoC's.
>  Required Properties:
>   - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-reset"
> 
> +Optional properties:
> +- microchip,reset-switch-core : Perform a switch core reset at the
> +  time of driver load. This is may be used to initialize the switch
> +  core to a known state (before other drivers are loaded).

How do you know when other drivers are loaded? This could be a module 
perhaps. Doesn't seem like something that belongs in DT.

Can this behavior be implied with "microchip,sparx5-chip-reset"?

Rob

Re: [PATCH 3/5] dt-bindings: reset: ocelot: Add documentation for 'microchip,reset-switch-core' property

[Rob Herring]

On Wed, May 13, 2020 at 03:08:40PM +0200, Lars Povlsen wrote:
> This documents the 'microchip,reset-switch-core' property in the
> ocelot-reset driver.
> 
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> ---
>  .../devicetree/bindings/power/reset/ocelot-reset.txt        | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> index 4d530d8154848..20fff03753ad2 100644
> --- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> +++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> @@ -9,9 +9,15 @@ microchip Sparx5 armv8 SoC's.
>  Required Properties:
>   - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-reset"
> 
> +Optional properties:
> +- microchip,reset-switch-core : Perform a switch core reset at the
> +  time of driver load. This is may be used to initialize the switch
> +  core to a known state (before other drivers are loaded).

How do you know when other drivers are loaded? This could be a module 
perhaps. Doesn't seem like something that belongs in DT.

Can this behavior be implied with "microchip,sparx5-chip-reset"?

Rob

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

Re: [PATCH 3/5] dt-bindings: reset: ocelot: Add documentation for 'microchip,reset-switch-core' property

[Lars Povlsen]

Rob Herring writes:

> On Wed, May 13, 2020 at 03:08:40PM +0200, Lars Povlsen wrote:
>> This documents the 'microchip,reset-switch-core' property in the
>> ocelot-reset driver.
>>
>> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
>> ---
>>  .../devicetree/bindings/power/reset/ocelot-reset.txt        | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
>> index 4d530d8154848..20fff03753ad2 100644
>> --- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
>> +++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
>> @@ -9,9 +9,15 @@ microchip Sparx5 armv8 SoC's.
>>  Required Properties:
>>   - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-reset"
>>
>> +Optional properties:
>> +- microchip,reset-switch-core : Perform a switch core reset at the
>> +  time of driver load. This is may be used to initialize the switch
>> +  core to a known state (before other drivers are loaded).
>
> How do you know when other drivers are loaded? This could be a module
> perhaps. Doesn't seem like something that belongs in DT.
>

The reset driver is loaded at postcore_initcall() time, which ensures it
is loaded before other drivers using the switch core. I noticed other
drivers do the same to do low-level system reset and initialization at
early boot time.

> Can this behavior be implied with "microchip,sparx5-chip-reset"?

Since we need to cater for both modus operandi, I would need two driver
compatible strings per platform, which scales worse than a single
property.

The "microchip,reset-switch-core" is a device configuration property
which tells the system (driver) how the hw should be handled. Since you
do not *always* want to reset the switch core (f.ex. when implementing
systems with warm reboot), I think it makes perfect sense - but I may be
biased off course :-)

Thank you for (all) of your comments, by the way!

---Lars

>
> Rob

-- 
Lars Povlsen,
Microchip

Re: [PATCH 3/5] dt-bindings: reset: ocelot: Add documentation for 'microchip, reset-switch-core' property

[Lars Povlsen]

Rob Herring writes:

> On Wed, May 13, 2020 at 03:08:40PM +0200, Lars Povlsen wrote:
>> This documents the 'microchip,reset-switch-core' property in the
>> ocelot-reset driver.
>>
>> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
>> ---
>>  .../devicetree/bindings/power/reset/ocelot-reset.txt        | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
>> index 4d530d8154848..20fff03753ad2 100644
>> --- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
>> +++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
>> @@ -9,9 +9,15 @@ microchip Sparx5 armv8 SoC's.
>>  Required Properties:
>>   - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-reset"
>>
>> +Optional properties:
>> +- microchip,reset-switch-core : Perform a switch core reset at the
>> +  time of driver load. This is may be used to initialize the switch
>> +  core to a known state (before other drivers are loaded).
>
> How do you know when other drivers are loaded? This could be a module
> perhaps. Doesn't seem like something that belongs in DT.
>

The reset driver is loaded at postcore_initcall() time, which ensures it
is loaded before other drivers using the switch core. I noticed other
drivers do the same to do low-level system reset and initialization at
early boot time.

> Can this behavior be implied with "microchip,sparx5-chip-reset"?

Since we need to cater for both modus operandi, I would need two driver
compatible strings per platform, which scales worse than a single
property.

The "microchip,reset-switch-core" is a device configuration property
which tells the system (driver) how the hw should be handled. Since you
do not *always* want to reset the switch core (f.ex. when implementing
systems with warm reboot), I think it makes perfect sense - but I may be
biased off course :-)

Thank you for (all) of your comments, by the way!

---Lars

>
> Rob

-- 
Lars Povlsen,
Microchip

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

Re: [PATCH 3/5] dt-bindings: reset: ocelot: Add documentation for 'microchip,reset-switch-core' property

[Sebastian Reichel]

[-- Attachment #1.1: Type: text/plain, Size: 2323 bytes --]

Hi,

On Tue, Jun 02, 2020 at 11:49:08AM +0200, Lars Povlsen wrote:
> Rob Herring writes:
> > On Wed, May 13, 2020 at 03:08:40PM +0200, Lars Povlsen wrote:
> >> This documents the 'microchip,reset-switch-core' property in the
> >> ocelot-reset driver.
> >>
> >> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> >> ---
> >>  .../devicetree/bindings/power/reset/ocelot-reset.txt        | 6 ++++++
> >>  1 file changed, 6 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> >> index 4d530d8154848..20fff03753ad2 100644
> >> --- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> >> +++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> >> @@ -9,9 +9,15 @@ microchip Sparx5 armv8 SoC's.
> >>  Required Properties:
> >>   - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-reset"
> >>
> >> +Optional properties:
> >> +- microchip,reset-switch-core : Perform a switch core reset at the
> >> +  time of driver load. This is may be used to initialize the switch
> >> +  core to a known state (before other drivers are loaded).
> >
> > How do you know when other drivers are loaded? This could be a module
> > perhaps. Doesn't seem like something that belongs in DT.
> >
> 
> The reset driver is loaded at postcore_initcall() time, which ensures it
> is loaded before other drivers using the switch core. I noticed other
> drivers do the same to do low-level system reset and initialization at
> early boot time.
> 
> > Can this behavior be implied with "microchip,sparx5-chip-reset"?
> 
> Since we need to cater for both modus operandi, I would need two driver
> compatible strings per platform, which scales worse than a single
> property.
> 
> The "microchip,reset-switch-core" is a device configuration property
> which tells the system (driver) how the hw should be handled. Since you
> do not *always* want to reset the switch core (f.ex. when implementing
> systems with warm reboot), I think it makes perfect sense - but I may be
> biased off course :-)
> 
> Thank you for (all) of your comments, by the way!
> 
> ---Lars
> > Rob

Is this series still needed? Did I miss a follow-up?

-- Sebastian

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

Re: [PATCH 3/5] dt-bindings: reset: ocelot: Add documentation for 'microchip,reset-switch-core' property

[Lars Povlsen]

Sebastian Reichel writes:

> Hi,
> 
> On Tue, Jun 02, 2020 at 11:49:08AM +0200, Lars Povlsen wrote:
> > Rob Herring writes:
> > > On Wed, May 13, 2020 at 03:08:40PM +0200, Lars Povlsen wrote:
> > >> This documents the 'microchip,reset-switch-core' property in the
> > >> ocelot-reset driver.
> > >>
> > >> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> > >> ---
> > >>  .../devicetree/bindings/power/reset/ocelot-reset.txt        | 6 ++++++
> > >>  1 file changed, 6 insertions(+)
> > >>
> > >> diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-rese=
> t.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> > >> index 4d530d8154848..20fff03753ad2 100644
> > >> --- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> > >> +++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> > >> @@ -9,9 +9,15 @@ microchip Sparx5 armv8 SoC's.
> > >>  Required Properties:
> > >>   - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-res=
> et"
> > >>
> > >> +Optional properties:
> > >> +- microchip,reset-switch-core : Perform a switch core reset at the
> > >> +  time of driver load. This is may be used to initialize the switch
> > >> +  core to a known state (before other drivers are loaded).
> > >
> > > How do you know when other drivers are loaded? This could be a module
> > > perhaps. Doesn't seem like something that belongs in DT.
> > >
> > 
> > The reset driver is loaded at postcore_initcall() time, which ensures it
> > is loaded before other drivers using the switch core. I noticed other
> > drivers do the same to do low-level system reset and initialization at
> > early boot time.
> > 
> > > Can this behavior be implied with "microchip,sparx5-chip-reset"?
> > 
> > Since we need to cater for both modus operandi, I would need two driver
> > compatible strings per platform, which scales worse than a single
> > property.
> > 
> > The "microchip,reset-switch-core" is a device configuration property
> > which tells the system (driver) how the hw should be handled. Since you
> > do not *always* want to reset the switch core (f.ex. when implementing
> > systems with warm reboot), I think it makes perfect sense - but I may be
> > biased off course :-)
> > 
> > Thank you for (all) of your comments, by the way!
> > 
> > ---Lars
> > > Rob
> 
> Is this series still needed? Did I miss a follow-up?

Hi Sebastian!

Yes, the series is still needed, but the conversation died after my
last message.

If the DT-controlled reset property is too controversial, I am willing
to drop that part. (Rob just reviewed the bindings).

MCHP reference designs have GPIO resets, so we *could* get by without,
but new designs may this feature.

> -- Sebastian

---Lars

-- 
Lars Povlsen,
Microchip

Re: [PATCH 3/5] dt-bindings: reset: ocelot: Add documentation for 'microchip, reset-switch-core' property

[Lars Povlsen]

Sebastian Reichel writes:

> Hi,
> 
> On Tue, Jun 02, 2020 at 11:49:08AM +0200, Lars Povlsen wrote:
> > Rob Herring writes:
> > > On Wed, May 13, 2020 at 03:08:40PM +0200, Lars Povlsen wrote:
> > >> This documents the 'microchip,reset-switch-core' property in the
> > >> ocelot-reset driver.
> > >>
> > >> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> > >> ---
> > >>  .../devicetree/bindings/power/reset/ocelot-reset.txt        | 6 ++++++
> > >>  1 file changed, 6 insertions(+)
> > >>
> > >> diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-rese=
> t.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> > >> index 4d530d8154848..20fff03753ad2 100644
> > >> --- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> > >> +++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> > >> @@ -9,9 +9,15 @@ microchip Sparx5 armv8 SoC's.
> > >>  Required Properties:
> > >>   - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-res=
> et"
> > >>
> > >> +Optional properties:
> > >> +- microchip,reset-switch-core : Perform a switch core reset at the
> > >> +  time of driver load. This is may be used to initialize the switch
> > >> +  core to a known state (before other drivers are loaded).
> > >
> > > How do you know when other drivers are loaded? This could be a module
> > > perhaps. Doesn't seem like something that belongs in DT.
> > >
> > 
> > The reset driver is loaded at postcore_initcall() time, which ensures it
> > is loaded before other drivers using the switch core. I noticed other
> > drivers do the same to do low-level system reset and initialization at
> > early boot time.
> > 
> > > Can this behavior be implied with "microchip,sparx5-chip-reset"?
> > 
> > Since we need to cater for both modus operandi, I would need two driver
> > compatible strings per platform, which scales worse than a single
> > property.
> > 
> > The "microchip,reset-switch-core" is a device configuration property
> > which tells the system (driver) how the hw should be handled. Since you
> > do not *always* want to reset the switch core (f.ex. when implementing
> > systems with warm reboot), I think it makes perfect sense - but I may be
> > biased off course :-)
> > 
> > Thank you for (all) of your comments, by the way!
> > 
> > ---Lars
> > > Rob
> 
> Is this series still needed? Did I miss a follow-up?

Hi Sebastian!

Yes, the series is still needed, but the conversation died after my
last message.

If the DT-controlled reset property is too controversial, I am willing
to drop that part. (Rob just reviewed the bindings).

MCHP reference designs have GPIO resets, so we *could* get by without,
but new designs may this feature.

> -- Sebastian

---Lars

-- 
Lars Povlsen,
Microchip

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

Re: [PATCH 3/5] dt-bindings: reset: ocelot: Add documentation for 'microchip,reset-switch-core' property

[Lars Povlsen]

Lars Povlsen writes:

> Sebastian Reichel writes:
>
>> Hi,
>> 
>> On Tue, Jun 02, 2020 at 11:49:08AM +0200, Lars Povlsen wrote:
>> > Rob Herring writes:
>> > > On Wed, May 13, 2020 at 03:08:40PM +0200, Lars Povlsen wrote:
>> > >> This documents the 'microchip,reset-switch-core' property in the
>> > >> ocelot-reset driver.
>> > >>
>> > >> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
>> > >> ---
>> > >>  .../devicetree/bindings/power/reset/ocelot-reset.txt        | 6 ++++++
>> > >>  1 file changed, 6 insertions(+)
>> > >>
>> > >> diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-rese=
>> t.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
>> > >> index 4d530d8154848..20fff03753ad2 100644
>> > >> --- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
>> > >> +++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
>> > >> @@ -9,9 +9,15 @@ microchip Sparx5 armv8 SoC's.
>> > >>  Required Properties:
>> > >>   - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-res=
>> et"
>> > >>
>> > >> +Optional properties:
>> > >> +- microchip,reset-switch-core : Perform a switch core reset at the
>> > >> +  time of driver load. This is may be used to initialize the switch
>> > >> +  core to a known state (before other drivers are loaded).
>> > >
>> > > How do you know when other drivers are loaded? This could be a module
>> > > perhaps. Doesn't seem like something that belongs in DT.
>> > >
>> > 
>> > The reset driver is loaded at postcore_initcall() time, which ensures it
>> > is loaded before other drivers using the switch core. I noticed other
>> > drivers do the same to do low-level system reset and initialization at
>> > early boot time.
>> > 
>> > > Can this behavior be implied with "microchip,sparx5-chip-reset"?
>> > 
>> > Since we need to cater for both modus operandi, I would need two driver
>> > compatible strings per platform, which scales worse than a single
>> > property.
>> > 
>> > The "microchip,reset-switch-core" is a device configuration property
>> > which tells the system (driver) how the hw should be handled. Since you
>> > do not *always* want to reset the switch core (f.ex. when implementing
>> > systems with warm reboot), I think it makes perfect sense - but I may be
>> > biased off course :-)
>> > 
>> > Thank you for (all) of your comments, by the way!
>> > 
>> > ---Lars
>> > > Rob
>> 
>> Is this series still needed? Did I miss a follow-up?
>
> Hi Sebastian!
>
> Yes, the series is still needed, but the conversation died after my
> last message.
>
> If the DT-controlled reset property is too controversial, I am willing
> to drop that part. (Rob just reviewed the bindings).
>
> MCHP reference designs have GPIO resets, so we *could* get by without,
> but new designs may this feature.
>
>> -- Sebastian
>

Sebastian,

Any update on the patches? They're the last part of the original Sparx5
series, so I would love to get them done.

As previously stated, I could remove the "microchip,reset-switch-core"
parts if that's whats what holding it stuck.

---Lars

-- 
Lars Povlsen,
Microchip

Re: [PATCH 3/5] dt-bindings: reset: ocelot: Add documentation for 'microchip,reset-switch-core' property

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 3427 bytes --]

Hi,

On Wed, Sep 16, 2020 at 10:00:51AM +0200, Lars Povlsen wrote:
> Lars Povlsen writes:
> > Sebastian Reichel writes:
> >> On Tue, Jun 02, 2020 at 11:49:08AM +0200, Lars Povlsen wrote:
> >> > Rob Herring writes:
> >> > > On Wed, May 13, 2020 at 03:08:40PM +0200, Lars Povlsen wrote:
> >> > >> This documents the 'microchip,reset-switch-core' property in the
> >> > >> ocelot-reset driver.
> >> > >>
> >> > >> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> >> > >> ---
> >> > >>  .../devicetree/bindings/power/reset/ocelot-reset.txt        | 6 ++++++
> >> > >>  1 file changed, 6 insertions(+)
> >> > >>
> >> > >> diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-rese=
> >> t.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> >> > >> index 4d530d8154848..20fff03753ad2 100644
> >> > >> --- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> >> > >> +++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
> >> > >> @@ -9,9 +9,15 @@ microchip Sparx5 armv8 SoC's.
> >> > >>  Required Properties:
> >> > >>   - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-res=
> >> et"
> >> > >>
> >> > >> +Optional properties:
> >> > >> +- microchip,reset-switch-core : Perform a switch core reset at the
> >> > >> +  time of driver load. This is may be used to initialize the switch
> >> > >> +  core to a known state (before other drivers are loaded).
> >> > >
> >> > > How do you know when other drivers are loaded? This could be a module
> >> > > perhaps. Doesn't seem like something that belongs in DT.
> >> > >
> >> > 
> >> > The reset driver is loaded at postcore_initcall() time, which ensures it
> >> > is loaded before other drivers using the switch core. I noticed other
> >> > drivers do the same to do low-level system reset and initialization at
> >> > early boot time.
> >> > 
> >> > > Can this behavior be implied with "microchip,sparx5-chip-reset"?
> >> > 
> >> > Since we need to cater for both modus operandi, I would need two driver
> >> > compatible strings per platform, which scales worse than a single
> >> > property.
> >> > 
> >> > The "microchip,reset-switch-core" is a device configuration property
> >> > which tells the system (driver) how the hw should be handled. Since you
> >> > do not *always* want to reset the switch core (f.ex. when implementing
> >> > systems with warm reboot), I think it makes perfect sense - but I may be
> >> > biased off course :-)
> >> > 
> >> > Thank you for (all) of your comments, by the way!
> >> > 
> >> > ---Lars
> >> 
> >> Is this series still needed? Did I miss a follow-up?
> >
> > Hi Sebastian!
> >
> > Yes, the series is still needed, but the conversation died after my
> > last message.
> >
> > If the DT-controlled reset property is too controversial, I am willing
> > to drop that part. (Rob just reviewed the bindings).
> >
> > MCHP reference designs have GPIO resets, so we *could* get by without,
> > but new designs may this feature.
> >
> >> -- Sebastian
> >
> 
> Sebastian,
> 
> Any update on the patches? They're the last part of the original Sparx5
> series, so I would love to get them done.
> 
> As previously stated, I could remove the "microchip,reset-switch-core"
> parts if that's whats what holding it stuck.

I am waiting for Rob's Acked-by for the binding.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]