[PATCH v2 0/3] ARM: soc: ti: k3: Provide reset cause information

[PATCH v2 0/3] ARM: soc: ti: k3: Provide reset cause information

[A. Sverdlin]

From: Alexander Sverdlin <alexander.sverdlin@siemens.com>

Newer TI SoCs from K3 family (AM64x and newer) provide a detailed reset
cause information in RST_SRC register in the reset module within memory
mapped control registers. To make this information available in user space:

- provide the DT bindings for the reset registers
- add the rest registrs to the device trees of the corresponding SoCs
- conditionally add custom SYSFS attribute group (if particular SoC
  supports it) with "reset_reason" attribute providing the textual
  form of the reset cause as documented in AM62x Processors Technical
  Reference Manual.

The location for the newly provided information was inspired by
drivers/soc/tegra/pmc.c.

The series has been tested on AM623 (relevant DT is k3-am62-wakeup.dtsi).
Interestingly, K3 can have multiple bits asserted, for instance in case of
WDT-triggered reset:

$ cat /sys/bus/soc/devices/soc0/reset_reason
Reset Caused by MCU ESM Error
Reset Caused by Main ESM Error

Changelog:
v2: amended mfd/syscon.yaml instead of separate reset/ti,am64-rst.yaml

Alexander Sverdlin (3):
  dt-bindings: mfd: syscon: add binding for TI K3 platforms reset
    registers
  arm64: dts: ti: k3-*: Add am64x and newer reset registers
  soc: ti: k3-socinfo: Provide reset reason information

 .../devicetree/bindings/mfd/syscon.yaml       |  1 +
 .../soc/ti/ti,j721e-system-controller.yaml    | 11 +++
 arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi    |  5 ++
 arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi   |  5 ++
 arch/arm64/boot/dts/ti/k3-am64-main.dtsi      |  5 ++
 drivers/soc/ti/k3-socinfo.c                   | 88 +++++++++++++++++++
 6 files changed, 115 insertions(+)

-- 
2.52.0

[PATCH v2 1/3] dt-bindings: mfd: syscon: add binding for TI K3 platforms reset registers

[A. Sverdlin]

From: Alexander Sverdlin <alexander.sverdlin@siemens.com>

Add DT binding for Texas Instruments K3 Multicore SoC platforms reset
registers present on AM64x and newer members of the K3 family and consist
of the RST_CTRL, RST_STAT, RST_SRC and RST_MAGIC_WORD.

The planned usage is to provide reset reason information.

Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
---
Changelog:
v2: amended mfd/syscon.yaml instead of separate reset/ti,am64-rst.yaml

 Documentation/devicetree/bindings/mfd/syscon.yaml     |  1 +
 .../bindings/soc/ti/ti,j721e-system-controller.yaml   | 11 +++++++++++
 2 files changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
index e57add2bacd30..564fcb153a688 100644
--- a/Documentation/devicetree/bindings/mfd/syscon.yaml
+++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
@@ -240,6 +240,7 @@ properties:
               - ti,am62-usb-phy-ctrl
               - ti,am625-dss-oldi-io-ctrl
               - ti,am62p-cpsw-mac-efuse
+              - ti,am64-rst
               - ti,am654-dss-oldi-io-ctrl
               - ti,j784s4-acspcie-proxy-ctrl
               - ti,j784s4-pcie-ctrl
diff --git a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
index f3bd0be3b279f..b8063548f50ad 100644
--- a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
+++ b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
@@ -86,6 +86,12 @@ patternProperties:
     description:
       This is the DSS OLDI CTRL region.
 
+  "^rst@[0-9a-f]+$":
+    type: object
+    $ref: /schemas/mfd/syscon.yaml#
+    description:
+      The node corresponding to SoC reset registers block.
+
 required:
   - compatible
   - reg
@@ -133,5 +139,10 @@ examples:
             compatible = "ti,j784s4-pcie-ctrl", "syscon";
             reg = <0x4070 0x4>;
         };
+
+        rst@18170 {
+            compatible = "ti,am64-rst";
+            reg = <0x18170 0x10>;
+        };
     };
 ...
-- 
2.52.0

Re: [PATCH v2 1/3] dt-bindings: mfd: syscon: add binding for TI K3 platforms reset registers

[Rob Herring (Arm)]

On Mon, 16 Mar 2026 08:04:23 +0100, A. Sverdlin wrote:
> From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
> 
> Add DT binding for Texas Instruments K3 Multicore SoC platforms reset
> registers present on AM64x and newer members of the K3 family and consist
> of the RST_CTRL, RST_STAT, RST_SRC and RST_MAGIC_WORD.
> 
> The planned usage is to provide reset reason information.
> 
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
> ---
> Changelog:
> v2: amended mfd/syscon.yaml instead of separate reset/ti,am64-rst.yaml
> 
>  Documentation/devicetree/bindings/mfd/syscon.yaml     |  1 +
>  .../bindings/soc/ti/ti,j721e-system-controller.yaml   | 11 +++++++++++
>  2 files changed, 12 insertions(+)
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.example.dtb: scm-conf@100000 (ti,j721e-system-controller): rst@18170:compatible: ['ti,am64-rst'] does not contain items matching the given schema
	from schema $id: http://devicetree.org/schemas/soc/ti/ti,j721e-system-controller.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.example.dtb: scm-conf@100000 (ti,j721e-system-controller): rst@18170:compatible: ['ti,am64-rst'] is too short
	from schema $id: http://devicetree.org/schemas/soc/ti/ti,j721e-system-controller.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.example.dtb: scm-conf@100000 (ti,j721e-system-controller): rst@18170:compatible: 'oneOf' conditional failed, one must be fixed:
	['ti,am64-rst'] is too short
	'ti,am64-rst' is not one of ['microchip,sama7g5-sfrbu', 'microchip,sama7d65-sfrbu']
	'microchip,pic64gx-control-scb' was expected
	'microchip,pic64gx-sysreg-scb' was expected
	from schema $id: http://devicetree.org/schemas/soc/ti/ti,j721e-system-controller.yaml

doc reference errors (make refcheckdocs):

See https://patchwork.kernel.org/project/devicetree/patch/20260316070429.1545707-2-alexander.sverdlin@siemens.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

[PATCH v2 2/3] arm64: dts: ti: k3-*: Add am64x and newer reset registers

[A. Sverdlin]

From: Alexander Sverdlin <alexander.sverdlin@siemens.com>

Add the reset registers present on AM64x and newer SoCs carrying reset
cause information.

Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
---
Changelog:
v2: no changes

 arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi  | 5 +++++
 arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi | 5 +++++
 arch/arm64/boot/dts/ti/k3-am64-main.dtsi    | 5 +++++
 3 files changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
index 75aed3a88284d..954130e8f37ba 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-wakeup.dtsi
@@ -41,6 +41,11 @@ usb1_phy_ctrl: syscon@4018 {
 			compatible = "ti,am62-usb-phy-ctrl", "syscon";
 			reg = <0x4018 0x4>;
 		};
+
+		rst@18170 {
+			compatible = "ti,am64-rst";
+			reg = <0x18170 0x10>;
+		};
 	};
 
 	target-module@2b300050 {
diff --git a/arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
index 23877dadc98dc..7c94e6e16c069 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
@@ -39,6 +39,11 @@ usb1_phy_ctrl: syscon@4018 {
 			compatible = "ti,am62-usb-phy-ctrl", "syscon";
 			reg = <0x4018 0x4>;
 		};
+
+		rst@18170 {
+			compatible = "ti,am64-rst";
+			reg = <0x18170 0x10>;
+		};
 	};
 
 	target-module@2b300050 {
diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index 1b1d3970888b8..acbc7243cb16a 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -74,6 +74,11 @@ epwm_tbclk: clock-controller@4130 {
 			reg = <0x4130 0x4>;
 			#clock-cells = <1>;
 		};
+
+		rst@18170 {
+			compatible = "ti,am64-rst";
+			reg = <0x18170 0x10>;
+		};
 	};
 
 	gic500: interrupt-controller@1800000 {
-- 
2.52.0

[PATCH v2 3/3] soc: ti: k3-socinfo: Provide reset reason information

[A. Sverdlin]

From: Alexander Sverdlin <alexander.sverdlin@siemens.com>

Add reset_reason attribute decoging the RST_SRC register present in AM64x
and later SoCs of K3 family. Textual representation of the bits was taken
from the AM62x Processors Technical Reference Manual, except the POR, which
is not signalled explicitly by the reset module.

Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
---
Changelog:
v2: no changes

 drivers/soc/ti/k3-socinfo.c | 88 +++++++++++++++++++++++++++++++++++++
 1 file changed, 88 insertions(+)

diff --git a/drivers/soc/ti/k3-socinfo.c b/drivers/soc/ti/k3-socinfo.c
index 676041879eca3..3736c982fd0c8 100644
--- a/drivers/soc/ti/k3-socinfo.c
+++ b/drivers/soc/ti/k3-socinfo.c
@@ -45,6 +45,8 @@
 #define JTAG_ID_PARTNO_J722S		0xBBA0
 #define JTAG_ID_PARTNO_AM62LX		0xBBA7
 
+#define CTRL_MMR_RST_SRC		8
+
 static const struct k3_soc_id {
 	unsigned int id;
 	const char *family_name;
@@ -123,6 +125,90 @@ static const struct regmap_config k3_chipinfo_regmap_cfg = {
 	.reg_stride = 4,
 };
 
+static u32 k3_reset_source;
+static const char *const k3_reset_sources[] = {
+	[0]	= "Reset Caused by MCU Reset Pin",
+	[1]	= "Power On Reset",			/* Reserved in HW */
+	[2]	= "Main Reset Pin",
+	[4]	= "Thermal Reset",
+	[8]	= "Debug Subsystem Initiated Reset",
+	[12]	= "SMS Cold Reset",
+	[13]	= "SMS Warm Reset",
+	[16]	= "Software Warm Reset",
+	[20]	= "Software Main Warm Reset From MCU CTRL MMR",
+	[21]	= "Software Main Warm Reset from MAIN CTRL MMR",
+	[22]	= "Watchdog Initiated Reset",
+	[24]	= "Software Main Power On Reset From MCU CTRL MMR",
+	[25]	= "Software Main Power On Reset From MAIN CTRL MMR",
+	[30]	= "Reset Caused by Main ESM Error",
+	[31]	= "Reset Caused by MCU ESM Error",
+};
+
+static ssize_t reset_reason_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	int ret, i;
+	int total = 0;
+
+	for (i = ARRAY_SIZE(k3_reset_sources); i >= 0; i--) {
+		if (!k3_reset_sources[i] || !(k3_reset_source & BIT(i)))
+			continue;
+
+		ret = sprintf(buf + total, "%s\n", k3_reset_sources[i]);
+		if (ret < 0)
+			return ret;
+		total += ret;
+		/* Note that several reset sources may be active simultaneously */
+	}
+
+	return total;
+}
+
+static DEVICE_ATTR_RO(reset_reason);
+
+static struct attribute *k3_soc_attrs[] = {
+	&dev_attr_reset_reason.attr,
+	NULL
+};
+
+ATTRIBUTE_GROUPS(k3_soc);
+
+static const struct of_device_id k3_rst_id_table[] = {
+	{
+		.compatible	= "ti,am64-rst",
+	},
+	{}
+};
+
+static void k3_reset_reason_read(struct soc_device_attribute *soc_dev_attr)
+{
+	struct device_node *node = of_find_matching_node(NULL, k3_rst_id_table);
+	struct regmap *regmap;
+
+	/* AM65x/J721E do not have similar registers */
+	if (!node)
+		return;
+
+	regmap = device_node_to_regmap(node);
+	of_node_put(node);
+	if (IS_ERR(regmap)) {
+		pr_err("Cannot obtain %s regmap\n", k3_rst_id_table[0].compatible);
+		return;
+	}
+
+	regmap_read(regmap, CTRL_MMR_RST_SRC, &k3_reset_source);
+	/*
+	 * The register is only being cleared on POR, so we have to clear reset
+	 * source of the current boot manually
+	 */
+	regmap_write(regmap, CTRL_MMR_RST_SRC, k3_reset_source);
+
+	/* Simplify the code a bit and use HW-reserved bit for POR indication */
+	if (!k3_reset_source)
+		k3_reset_source |= BIT(1);
+
+	soc_dev_attr->custom_attr_group = k3_soc_groups[0];
+}
+
 static int k3_chipinfo_probe(struct platform_device *pdev)
 {
 	struct device_node *node = pdev->dev.of_node;
@@ -183,6 +269,8 @@ static int k3_chipinfo_probe(struct platform_device *pdev)
 	of_property_read_string(node, "model", &soc_dev_attr->machine);
 	of_node_put(node);
 
+	k3_reset_reason_read(soc_dev_attr);
+
 	soc_dev = soc_device_register(soc_dev_attr);
 	if (IS_ERR(soc_dev)) {
 		ret = PTR_ERR(soc_dev);
-- 
2.52.0

Re: [PATCH v2 3/3] soc: ti: k3-socinfo: Provide reset reason information

[Vignesh Raghavendra]

Hi,

Thanks for the patch!

On 16/03/26 12:34, A. Sverdlin wrote:
> From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
> 
> Add reset_reason attribute decoging the RST_SRC register present in AM64x

s/decoging/decoding . please run spellcheck on commit msg

> and later SoCs of K3 family. Textual representation of the bits was taken
> from the AM62x Processors Technical Reference Manual, except the POR, which
> is not signalled explicitly by the reset module.
> 
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>


There is support dumping reset reason in U-Boot for AM64x:
https://elixir.bootlin.com/u-boot/v2026.01/source/arch/arm/mach-k3/am64x/boot.c#L107

This conflicts with kernel as U-Boot currently clears the RST_SRC after read (Its
necessary to do so, to detect additional resets at bootloader level). So, this
information would be lost by the time kernel driver comes up.

Is there a usecase where kernel can make use of reset reason information exposed
via this driver? If so, the driver should at least take a cmdline param from 
bootloader in order to overcome above issue.

> ---
> Changelog:
> v2: no changes
> 
>  drivers/soc/ti/k3-socinfo.c | 88 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 88 insertions(+)
> 
> diff --git a/drivers/soc/ti/k3-socinfo.c b/drivers/soc/ti/k3-socinfo.c
> index 676041879eca3..3736c982fd0c8 100644
> --- a/drivers/soc/ti/k3-socinfo.c
> +++ b/drivers/soc/ti/k3-socinfo.c
> @@ -45,6 +45,8 @@
>  #define JTAG_ID_PARTNO_J722S		0xBBA0
>  #define JTAG_ID_PARTNO_AM62LX		0xBBA7
>  
> +#define CTRL_MMR_RST_SRC		8
> +
>  static const struct k3_soc_id {
>  	unsigned int id;
>  	const char *family_name;
> @@ -123,6 +125,90 @@ static const struct regmap_config k3_chipinfo_regmap_cfg = {
>  	.reg_stride = 4,
>  };
>  
> +static u32 k3_reset_source;
> +static const char *const k3_reset_sources[] = {
> +	[0]	= "Reset Caused by MCU Reset Pin",
> +	[1]	= "Power On Reset",			/* Reserved in HW */
> +	[2]	= "Main Reset Pin",
> +	[4]	= "Thermal Reset",
> +	[8]	= "Debug Subsystem Initiated Reset",
> +	[12]	= "SMS Cold Reset",
> +	[13]	= "SMS Warm Reset",
> +	[16]	= "Software Warm Reset",
> +	[20]	= "Software Main Warm Reset From MCU CTRL MMR",
> +	[21]	= "Software Main Warm Reset from MAIN CTRL MMR",
> +	[22]	= "Watchdog Initiated Reset",
> +	[24]	= "Software Main Power On Reset From MCU CTRL MMR",
> +	[25]	= "Software Main Power On Reset From MAIN CTRL MMR",
> +	[30]	= "Reset Caused by Main ESM Error",
> +	[31]	= "Reset Caused by MCU ESM Error",
> +};
> +
> +static ssize_t reset_reason_show(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> +	int ret, i;
> +	int total = 0;
> +
> +	for (i = ARRAY_SIZE(k3_reset_sources); i >= 0; i--) {
> +		if (!k3_reset_sources[i] || !(k3_reset_source & BIT(i)))
> +			continue;
> +
> +		ret = sprintf(buf + total, "%s\n", k3_reset_sources[i]);
> +		if (ret < 0)
> +			return ret;
> +		total += ret;
> +		/* Note that several reset sources may be active simultaneously */
> +	}
> +
> +	return total;
> +}
> +
> +static DEVICE_ATTR_RO(reset_reason);
> +
> +static struct attribute *k3_soc_attrs[] = {
> +	&dev_attr_reset_reason.attr,
> +	NULL
> +};
> +
> +ATTRIBUTE_GROUPS(k3_soc);
> +
> +static const struct of_device_id k3_rst_id_table[] = {
> +	{
> +		.compatible	= "ti,am64-rst",
> +	},
> +	{}
> +};
> +
> +static void k3_reset_reason_read(struct soc_device_attribute *soc_dev_attr)
> +{
> +	struct device_node *node = of_find_matching_node(NULL, k3_rst_id_table);
> +	struct regmap *regmap;
> +
> +	/* AM65x/J721E do not have similar registers */
> +	if (!node)
> +		return;
> +
> +	regmap = device_node_to_regmap(node);
> +	of_node_put(node);
> +	if (IS_ERR(regmap)) {
> +		pr_err("Cannot obtain %s regmap\n", k3_rst_id_table[0].compatible);
> +		return;
> +	}
> +
> +	regmap_read(regmap, CTRL_MMR_RST_SRC, &k3_reset_source);
> +	/*
> +	 * The register is only being cleared on POR, so we have to clear reset
> +	 * source of the current boot manually
> +	 */
> +	regmap_write(regmap, CTRL_MMR_RST_SRC, k3_reset_source);
> +
> +	/* Simplify the code a bit and use HW-reserved bit for POR indication */
> +	if (!k3_reset_source)
> +		k3_reset_source |= BIT(1);
> +
> +	soc_dev_attr->custom_attr_group = k3_soc_groups[0];
> +}
> +
>  static int k3_chipinfo_probe(struct platform_device *pdev)
>  {
>  	struct device_node *node = pdev->dev.of_node;
> @@ -183,6 +269,8 @@ static int k3_chipinfo_probe(struct platform_device *pdev)
>  	of_property_read_string(node, "model", &soc_dev_attr->machine);
>  	of_node_put(node);
>  
> +	k3_reset_reason_read(soc_dev_attr);
> +
>  	soc_dev = soc_device_register(soc_dev_attr);
>  	if (IS_ERR(soc_dev)) {
>  		ret = PTR_ERR(soc_dev);

-- 
Regards
Vignesh
https://ti.com/opensource

Re: [PATCH v2 3/3] soc: ti: k3-socinfo: Provide reset reason information

[Sverdlin, Alexander]

Hi Vignesh!

On Tue, 2026-03-17 at 11:18 +0530, Vignesh Raghavendra wrote:
> > and later SoCs of K3 family. Textual representation of the bits was taken
> > from the AM62x Processors Technical Reference Manual, except the POR, which
> > is not signalled explicitly by the reset module.
> > 
> > Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
> 
> 
> There is support dumping reset reason in U-Boot for AM64x:
> https://elixir.bootlin.com/u-boot/v2026.01/source/arch/arm/mach-k3/am64x/boot.c#L107
> 
> This conflicts with kernel as U-Boot currently clears the RST_SRC after read (Its
> necessary to do so, to detect additional resets at bootloader level). So, this
> information would be lost by the time kernel driver comes up.
> 
> Is there a usecase where kernel can make use of reset reason information exposed
> via this driver? If so, the driver should at least take a cmdline param from 
> bootloader in order to overcome above issue.

Thanks for the hint!
Too bad my U-Boot is that old I didn't notice it! ;-)

But your point makes the whole series pointless of course. We do need this
info for diagnostics, but seems that I need to look into U-Boot for the
implementation...

> > ---
> > Changelog:
> > v2: no changes
> > 
> >   drivers/soc/ti/k3-socinfo.c | 88 +++++++++++++++++++++++++++++++++++++
> >   1 file changed, 88 insertions(+)
> > 
> > diff --git a/drivers/soc/ti/k3-socinfo.c b/drivers/soc/ti/k3-socinfo.c
> > index 676041879eca3..3736c982fd0c8 100644
> > --- a/drivers/soc/ti/k3-socinfo.c
> > +++ b/drivers/soc/ti/k3-socinfo.c

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com