[PATCH v6 0/2] Add L1 and L2 error detection for A53, A57 and A72

[PATCH v6 0/2] Add L1 and L2 error detection for A53, A57 and A72

[Vijay Balakrishna]

Hello,

This is an attempt to revive [v5] series. I have attempted to address comments
and suggestions from Marc Zyngier since [v5]. Additionally, I have extended
support for A72 processors. Testing on a problematic A72 SoC has led to the
detection of Correctable Errors (CEs). I am eager to hear your suggestions and
feedback on this series.

Thanks,
Vijay

[v5] https://lore.kernel.org/all/20210401110615.15326-1-s.hauer@pengutronix.de/#t

Changes since v5:
- rebase on v6.15-rc1
- the syndrome registers for CPU/L2 memory errors are cleared only upon
  detecting an error and an isb() after for synchronization (Marc)
- "edac-enabled" hunk moved to initial patch to avoid breaking virtual
  environments (Marc)
- to ensure compatibility across all three families, we are not reporting
  "L1 Dirty RAM," documented only in the A53 TRM
- above prompted changing default CPU L1 error meesage from "unknown"
  to "Unspecified" 
- capturing CPUID/WAY information in L2 memory error log (Marc)
- module license from "GPL v2" to "GPL" (checkpatch.pl warning)
- extend support for A72

Changes since v4:
- Rebase on v5.12-rc5

Changes since v3:
- Add edac-enabled property to make EDAC 3support optional

Changes since v2:
- drop usage of virtual dt node (Robh)
- use read_sysreg_s instead of open coded variant (James Morse)
- separate error retrieving from error reporting
- use smp_call_function_single rather than smp_call_function_single_async
- make driver single instance and register all 'cpu' hierarchy up front once

Changes since v1:
- Split dt-binding into separate patch
- Sort local function variables in reverse-xmas tree order
- drop unnecessary comparison and make variable bool

Sascha Hauer (2):
  drivers/edac: Add L1 and L2 error detection for A53, A57 and A72
  dt-bindings: arm: cpus: Add edac-enabled property

 .../devicetree/bindings/arm/cpus.yaml         |   6 +
 drivers/edac/Kconfig                          |   9 +
 drivers/edac/Makefile                         |   1 +
 drivers/edac/cortex_arm64_l1_l2.c             | 225 ++++++++++++++++++
 4 files changed, 241 insertions(+)
 create mode 100644 drivers/edac/cortex_arm64_l1_l2.c


base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8
-- 
2.49.0

[PATCH 1/2] drivers/edac: Add L1 and L2 error detection for A53, A57 and A72

[Vijay Balakrishna]

From: Sascha Hauer <s.hauer@pengutronix.de>

The Cortex A53, A57 and A72 cores have error detection capabilities for
the L1/L2 Caches, this patch adds a driver for them. The selected errors
to detect/report have compatible bit assignments concerning CPU/L2 memory
error syndrome registers.

Unfortunately there is no robust way to inject errors into the caches,
so this driver doesn't contain any code to actually test it. It has
been tested though with code taken from an older version [1] of this
driver.  For reasons stated in thread [1], the error injection code is
not suitable for mainline, so it is removed from the driver.

[1] https://lore.kernel.org/all/1521073067-24348-1-git-send-email-york.sun@nxp.com/#t

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Co-developed-by: Vijay Balakrishna <vijayb@linux.microsoft.com>
Signed-off-by: Vijay Balakrishna <vijayb@linux.microsoft.com>
---
 drivers/edac/Kconfig              |   9 ++
 drivers/edac/Makefile             |   1 +
 drivers/edac/cortex_arm64_l1_l2.c | 225 ++++++++++++++++++++++++++++++
 3 files changed, 235 insertions(+)
 create mode 100644 drivers/edac/cortex_arm64_l1_l2.c

diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 19ad3c3b675d..20c15a18437f 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -576,4 +576,13 @@ config EDAC_LOONGSON
 	  errors (CE) only. Loongson-3A5000/3C5000/3D5000/3A6000/3C6000
 	  are compatible.
 
+config EDAC_CORTEX_ARM64_L1_L2
+	tristate "ARM Cortex A72/A57/A53"
+	depends on ARM64
+	help
+	  Support for L1/L2 cache error detection is provided for ARM Cortex
+	  A72, A57, and A53 processors. The selected subset of errors is common
+	  across these three MPCore processors, featuring compatible bit
+	  assignments in their CPU/L2 memory error syndrome registers.
+
 endif # EDAC
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index a8f2d8f6c894..157062410e61 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -88,3 +88,4 @@ obj-$(CONFIG_EDAC_NPCM)			+= npcm_edac.o
 obj-$(CONFIG_EDAC_ZYNQMP)		+= zynqmp_edac.o
 obj-$(CONFIG_EDAC_VERSAL)		+= versal_edac.o
 obj-$(CONFIG_EDAC_LOONGSON)		+= loongson_edac.o
+obj-$(CONFIG_EDAC_CORTEX_ARM64_L1_L2)	+= cortex_arm64_l1_l2.o
diff --git a/drivers/edac/cortex_arm64_l1_l2.c b/drivers/edac/cortex_arm64_l1_l2.c
new file mode 100644
index 000000000000..2ffe20212acb
--- /dev/null
+++ b/drivers/edac/cortex_arm64_l1_l2.c
@@ -0,0 +1,225 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Cortex A72, A57 and A53 EDAC L1 and L2 cache error detection
+ *
+ * Copyright (c) 2020 Pengutronix, Sascha Hauer <s.hauer@pengutronix.de>
+ *
+ * Based on Code from:
+ * Copyright (c) 2018, NXP Semiconductor
+ * Author: York Sun <york.sun@nxp.com>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/of_device.h>
+#include <linux/bitfield.h>
+#include <asm/smp_plat.h>
+
+#include "edac_module.h"
+
+#define DRVNAME				"cortex-arm64-edac"
+
+#define CPUMERRSR_EL1_RAMID		GENMASK(30, 24)
+
+#define CPUMERRSR_EL1_VALID		BIT(31)
+#define CPUMERRSR_EL1_FATAL		BIT(63)
+
+#define L1_I_TAG_RAM			0x00
+#define L1_I_DATA_RAM			0x01
+#define L1_D_TAG_RAM			0x08
+#define L1_D_DATA_RAM			0x09
+#define TLB_RAM				0x18
+
+#define L2MERRSR_EL1_CPUID_WAY	GENMASK(21, 18)
+
+#define L2MERRSR_EL1_VALID		BIT(31)
+#define L2MERRSR_EL1_FATAL		BIT(63)
+
+struct merrsr {
+	u64 cpumerr;
+	u64 l2merr;
+};
+
+#define MESSAGE_SIZE 64
+
+#define SYS_CPUMERRSR_EL1			sys_reg(3, 1, 15, 2, 2)
+#define SYS_L2MERRSR_EL1			sys_reg(3, 1, 15, 2, 3)
+
+static struct cpumask compat_mask;
+
+static void report_errors(struct edac_device_ctl_info *edac_ctl, int cpu,
+			  struct merrsr *merrsr)
+{
+	char msg[MESSAGE_SIZE];
+	u64 cpumerr = merrsr->cpumerr;
+	u64 l2merr = merrsr->l2merr;
+
+	if (cpumerr & CPUMERRSR_EL1_VALID) {
+		const char *str;
+		bool fatal = cpumerr & CPUMERRSR_EL1_FATAL;
+
+		switch (FIELD_GET(CPUMERRSR_EL1_RAMID, cpumerr)) {
+		case L1_I_TAG_RAM:
+			str = "L1-I Tag RAM";
+			break;
+		case L1_I_DATA_RAM:
+			str = "L1-I Data RAM";
+			break;
+		case L1_D_TAG_RAM:
+			str = "L1-D Tag RAM";
+			break;
+		case L1_D_DATA_RAM:
+			str = "L1-D Data RAM";
+			break;
+		case TLB_RAM:
+			str = "TLB RAM";
+			break;
+		default:
+			str = "Unspecified";
+			break;
+		}
+
+		snprintf(msg, MESSAGE_SIZE, "%s %s error(s) on CPU %d",
+			 str, fatal ? "fatal" : "correctable", cpu);
+
+		if (fatal)
+			edac_device_handle_ue(edac_ctl, cpu, 0, msg);
+		else
+			edac_device_handle_ce(edac_ctl, cpu, 0, msg);
+
+		write_sysreg_s(0, SYS_CPUMERRSR_EL1);
+		isb();
+	}
+
+	if (l2merr & L2MERRSR_EL1_VALID) {
+		bool fatal = l2merr & L2MERRSR_EL1_FATAL;
+
+		snprintf(msg, MESSAGE_SIZE, "L2 %s error(s) on CPU %d CPUID/WAY 0x%x",
+			 fatal ? "fatal" : "correctable", cpu,
+			 FIELD_GET(L2MERRSR_EL1_CPUID_WAY, l2merr));
+		if (fatal)
+			edac_device_handle_ue(edac_ctl, cpu, 1, msg);
+		else
+			edac_device_handle_ce(edac_ctl, cpu, 1, msg);
+
+		write_sysreg_s(0, SYS_L2MERRSR_EL1);
+		isb();
+	}
+}
+
+static void read_errors(void *data)
+{
+	struct merrsr *merrsr = data;
+
+	merrsr->cpumerr = read_sysreg_s(SYS_CPUMERRSR_EL1);
+	merrsr->l2merr = read_sysreg_s(SYS_L2MERRSR_EL1);
+}
+
+static void cortex_arm64_edac_check(struct edac_device_ctl_info *edac_ctl)
+{
+	struct merrsr merrsr;
+	int cpu;
+
+	for_each_cpu_and(cpu, cpu_online_mask, &compat_mask) {
+		smp_call_function_single(cpu, read_errors, &merrsr, true);
+		report_errors(edac_ctl, cpu, &merrsr);
+	}
+}
+
+static int cortex_arm64_edac_probe(struct platform_device *pdev)
+{
+	struct edac_device_ctl_info *edac_ctl;
+	struct device *dev = &pdev->dev;
+	int rc;
+
+	edac_ctl = edac_device_alloc_ctl_info(0, "cpu",
+					      num_possible_cpus(), "L", 2, 1, NULL, 0,
+					      edac_device_alloc_index());
+	if (!edac_ctl)
+		return -ENOMEM;
+
+	edac_ctl->edac_check = cortex_arm64_edac_check;
+	edac_ctl->dev = dev;
+	edac_ctl->mod_name = dev_name(dev);
+	edac_ctl->dev_name = dev_name(dev);
+	edac_ctl->ctl_name = DRVNAME;
+	dev_set_drvdata(dev, edac_ctl);
+
+	rc = edac_device_add_device(edac_ctl);
+	if (rc)
+		goto out_dev;
+
+	return 0;
+
+out_dev:
+	edac_device_free_ctl_info(edac_ctl);
+
+	return rc;
+}
+
+static int cortex_arm64_edac_remove(struct platform_device *pdev)
+{
+	struct edac_device_ctl_info *edac_ctl = dev_get_drvdata(&pdev->dev);
+
+	edac_device_del_device(edac_ctl->dev);
+	edac_device_free_ctl_info(edac_ctl);
+
+	return 0;
+}
+
+static const struct of_device_id cortex_arm64_edac_of_match[] = {
+	{ .compatible = "arm,cortex-a53" },
+	{ .compatible = "arm,cortex-a57" },
+	{ .compatible = "arm,cortex-a72" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, cortex_arm64_edac_of_match);
+
+static struct platform_driver cortex_arm64_edac_driver = {
+	.probe = cortex_arm64_edac_probe,
+	.remove = cortex_arm64_edac_remove,
+	.driver = {
+		.name = DRVNAME,
+	},
+};
+
+static int __init cortex_arm64_edac_driver_init(void)
+{
+	struct device_node *np;
+	int cpu;
+	struct platform_device *pdev;
+	int err;
+
+	for_each_possible_cpu(cpu) {
+		np = of_get_cpu_node(cpu, NULL);
+
+		if (!of_match_node(cortex_arm64_edac_of_match, np))
+			continue;
+		if (!of_property_read_bool(np, "edac-enabled"))
+			continue;
+		cpumask_set_cpu(cpu, &compat_mask);
+	}
+
+	if (cpumask_empty(&compat_mask))
+		return 0;
+
+	err = platform_driver_register(&cortex_arm64_edac_driver);
+	if (err)
+		return err;
+
+	pdev = platform_device_register_simple(DRVNAME, -1, NULL, 0);
+	if (IS_ERR(pdev)) {
+		pr_err("failed to register cortex arm64 edac device\n");
+		platform_driver_unregister(&cortex_arm64_edac_driver);
+		return PTR_ERR(pdev);
+	}
+
+	return 0;
+}
+
+device_initcall(cortex_arm64_edac_driver_init);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Sascha Hauer <s.hauer@pengutronix.de>");
+MODULE_DESCRIPTION("Cortex A72, A57 and A53 L1 and L2 cache EDAC driver");
-- 
2.49.0

[PATCH 2/2] dt-bindings: arm: cpus: Add edac-enabled property

[Vijay Balakrishna]

From: Sascha Hauer <s.hauer@pengutronix.de>

Some ARM Cortex CPUs like the A53, A57 and A72 have Error Detection And
Correction (EDAC) support on their L1 and L2 caches. This is implemented
in implementation defined registers, so usage of this functionality is
not safe in virtualized environments or when EL3 already uses these
registers. This patch adds a edac-enabled flag which can be explicitly
set when EDAC can be used.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
[vijayb: Added A72 to the commit message]
Signed-off-by: Vijay Balakrishna <vijayb@linux.microsoft.com>
---
 Documentation/devicetree/bindings/arm/cpus.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
index 2e666b2a4dcd..18d649a18552 100644
--- a/Documentation/devicetree/bindings/arm/cpus.yaml
+++ b/Documentation/devicetree/bindings/arm/cpus.yaml
@@ -331,6 +331,12 @@ properties:
       corresponding to the index of an SCMI performance domain provider, must be
       "perf".
 
+  edac-enabled:
+    $ref: '/schemas/types.yaml#/definitions/flag'
+    description:
+      Some CPUs support Error Detection And Correction (EDAC) on their L1 and
+      L2 caches. This flag marks this function as usable.
+
   qcom,saw:
     $ref: /schemas/types.yaml#/definitions/phandle
     description: |
-- 
2.49.0

Re: [PATCH 2/2] dt-bindings: arm: cpus: Add edac-enabled property

[Krzysztof Kozlowski]

On 10/04/2025 01:36, Vijay Balakrishna wrote:
> From: Sascha Hauer <s.hauer@pengutronix.de>
> 
> Some ARM Cortex CPUs like the A53, A57 and A72 have Error Detection And
> Correction (EDAC) support on their L1 and L2 caches. This is implemented
> in implementation defined registers, so usage of this functionality is
> not safe in virtualized environments or when EL3 already uses these
> registers. This patch adds a edac-enabled flag which can be explicitly
> set when EDAC can be used.

Can't hypervisor tell you that?

> 
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> [vijayb: Added A72 to the commit message]
> Signed-off-by: Vijay Balakrishna <vijayb@linux.microsoft.com>
> ---
>  Documentation/devicetree/bindings/arm/cpus.yaml | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
> index 2e666b2a4dcd..18d649a18552 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.yaml
> +++ b/Documentation/devicetree/bindings/arm/cpus.yaml
> @@ -331,6 +331,12 @@ properties:
>        corresponding to the index of an SCMI performance domain provider, must be
>        "perf".
>  
> +  edac-enabled:
> +    $ref: '/schemas/types.yaml#/definitions/flag'

Drop quotes - look at every other line.

<form letter>
Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC. It might happen, that command when run on an older
kernel, gives you outdated entries. Therefore please be sure you base
your patches on recent Linux kernel.

Tools like b4 or scripts/get_maintainer.pl provide you proper list of
people, so fix your workflow. Tools might also fail if you work on some
ancient tree (don't, instead use mainline) or work on fork of kernel
(don't, instead use mainline). Just use b4 and everything should be
fine, although remember about `b4 prep --auto-to-cc` if you added new
patches to the patchset.

You missed at least devicetree list (maybe more), so this won't be
tested by automated tooling. Performing review on untested code might be
a waste of time.

Please kindly resend and include all necessary To/Cc entries.
</form letter>



Best regards,
Krzysztof

Re: [PATCH 2/2] dt-bindings: arm: cpus: Add edac-enabled property

[Marc Zyngier]

On Thu, 10 Apr 2025 07:00:55 +0100,
Krzysztof Kozlowski <krzk@kernel.org> wrote:
> 
> On 10/04/2025 01:36, Vijay Balakrishna wrote:
> > From: Sascha Hauer <s.hauer@pengutronix.de>
> > 
> > Some ARM Cortex CPUs like the A53, A57 and A72 have Error Detection And
> > Correction (EDAC) support on their L1 and L2 caches. This is implemented
> > in implementation defined registers, so usage of this functionality is
> > not safe in virtualized environments or when EL3 already uses these
> > registers. This patch adds a edac-enabled flag which can be explicitly
> > set when EDAC can be used.
> 
> Can't hypervisor tell you that?

No, it can't. This is not an architecture feature, and KVM will gladly
inject an UNDEF exception if the guest tries to use this.

Which is yet another reason why this whole exercise is futile.

	M.

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH 2/2] dt-bindings: arm: cpus: Add edac-enabled property

[Tyler Hicks (Microsoft)]

On 2025-04-10 08:10:18, Marc Zyngier wrote:
> On Thu, 10 Apr 2025 07:00:55 +0100,
> Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > 
> > On 10/04/2025 01:36, Vijay Balakrishna wrote:
> > > From: Sascha Hauer <s.hauer@pengutronix.de>
> > > 
> > > Some ARM Cortex CPUs like the A53, A57 and A72 have Error Detection And
> > > Correction (EDAC) support on their L1 and L2 caches. This is implemented
> > > in implementation defined registers, so usage of this functionality is
> > > not safe in virtualized environments or when EL3 already uses these
> > > registers. This patch adds a edac-enabled flag which can be explicitly
> > > set when EDAC can be used.
> > 
> > Can't hypervisor tell you that?
> 
> No, it can't. This is not an architecture feature, and KVM will gladly
> inject an UNDEF exception if the guest tries to use this.
> 
> Which is yet another reason why this whole exercise is futile.

Hi Marc - could you clarify why this is futile for baremetal or were you just
referring to virtualized environments?

Thanks!

Tyler

> 
> 	M.
> 
> -- 
> Without deviation from the norm, progress is not possible.

Re: [PATCH 2/2] dt-bindings: arm: cpus: Add edac-enabled property

[Marc Zyngier]

On Thu, 10 Apr 2025 15:30:17 +0100,
"Tyler Hicks (Microsoft)" <code@tyhicks.com> wrote:
> 
> On 2025-04-10 08:10:18, Marc Zyngier wrote:
> > On Thu, 10 Apr 2025 07:00:55 +0100,
> > Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > > 
> > > On 10/04/2025 01:36, Vijay Balakrishna wrote:
> > > > From: Sascha Hauer <s.hauer@pengutronix.de>
> > > > 
> > > > Some ARM Cortex CPUs like the A53, A57 and A72 have Error Detection And
> > > > Correction (EDAC) support on their L1 and L2 caches. This is implemented
> > > > in implementation defined registers, so usage of this functionality is
> > > > not safe in virtualized environments or when EL3 already uses these
> > > > registers. This patch adds a edac-enabled flag which can be explicitly
> > > > set when EDAC can be used.
> > > 
> > > Can't hypervisor tell you that?
> > 
> > No, it can't. This is not an architecture feature, and KVM will gladly
> > inject an UNDEF exception if the guest tries to use this.
> > 
> > Which is yet another reason why this whole exercise is futile.
> 
> Hi Marc - could you clarify why this is futile for baremetal or were you just
> referring to virtualized environments?

This is futile in general. This sort of stuff only makes sense if you
can take useful action upon detecting an error, such as cache
scrubbing. Here, this is just telling you "bang, you're dead", without
any other recourse. You are not even sure you'll be able to actually
*run* this code. You cannot identify what the blast radius.

We have some other EDAC implementation for arm64 CPUs (XGene,
ThunderX), and they are all perfectly useless (I have them in my
collection of horrors). I know you are familiar enough with the RAS
architecture to appreciate the difference with a contemporary
implementation that would actually do the right thing.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH 2/2] dt-bindings: arm: cpus: Add edac-enabled property

[Tyler Hicks (Microsoft)]

On 2025-04-10 17:23:26, Marc Zyngier wrote:
> On Thu, 10 Apr 2025 15:30:17 +0100,
> "Tyler Hicks (Microsoft)" <code@tyhicks.com> wrote:
> > 
> > On 2025-04-10 08:10:18, Marc Zyngier wrote:
> > > On Thu, 10 Apr 2025 07:00:55 +0100,
> > > Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > > > 
> > > > On 10/04/2025 01:36, Vijay Balakrishna wrote:
> > > > > From: Sascha Hauer <s.hauer@pengutronix.de>
> > > > > 
> > > > > Some ARM Cortex CPUs like the A53, A57 and A72 have Error Detection And
> > > > > Correction (EDAC) support on their L1 and L2 caches. This is implemented
> > > > > in implementation defined registers, so usage of this functionality is
> > > > > not safe in virtualized environments or when EL3 already uses these
> > > > > registers. This patch adds a edac-enabled flag which can be explicitly
> > > > > set when EDAC can be used.
> > > > 
> > > > Can't hypervisor tell you that?
> > > 
> > > No, it can't. This is not an architecture feature, and KVM will gladly
> > > inject an UNDEF exception if the guest tries to use this.
> > > 
> > > Which is yet another reason why this whole exercise is futile.
> > 
> > Hi Marc - could you clarify why this is futile for baremetal or were you just
> > referring to virtualized environments?
> 
> This is futile in general. This sort of stuff only makes sense if you
> can take useful action upon detecting an error, such as cache
> scrubbing. Here, this is just telling you "bang, you're dead", without
> any other recourse. You are not even sure you'll be able to actually
> *run* this code. You cannot identify what the blast radius.

We want to use it for monitoring purposes to let us know when a system needs to
be replaced. Knowing the number of Correctable Errors that a specific system is
encountering will help prioritize the replacement of that faulty system.

Also, if we can find some breadcrumbs of an Uncorrectable Error (UE) occurring
just before an important process crashes or before the kernel crashing, then we
can avoid expensive manual debugging and simply replace the system. Automation
can be implemented to dig through the kernel core dump contents to look for a
UE log message from this driver and a kernel engineer will never have to look
at the dump.

> We have some other EDAC implementation for arm64 CPUs (XGene,
> ThunderX), and they are all perfectly useless (I have them in my
> collection of horrors). I know you are familiar enough with the RAS
> architecture to appreciate the difference with a contemporary
> implementation that would actually do the right thing.

Yes, those are nice luxuries to have in the newer implementations but there are
still a lot of older systems in use and making do with what capabilities the
older hardware provides is still useful.

Tyler

> 
> Thanks,
> 
> 	M.
> 
> -- 
> Without deviation from the norm, progress is not possible.

Re: [PATCH 1/2] drivers/edac: Add L1 and L2 error detection for A53, A57 and A72

[Tyler Hicks (Microsoft)]

On 2025-04-09 16:36:24, Vijay Balakrishna wrote:
> From: Sascha Hauer <s.hauer@pengutronix.de>
> 
> The Cortex A53, A57 and A72 cores have error detection capabilities for
> the L1/L2 Caches, this patch adds a driver for them. The selected errors
> to detect/report have compatible bit assignments concerning CPU/L2 memory
> error syndrome registers.
> 
> Unfortunately there is no robust way to inject errors into the caches,
> so this driver doesn't contain any code to actually test it. It has
> been tested though with code taken from an older version [1] of this
> driver.  For reasons stated in thread [1], the error injection code is
> not suitable for mainline, so it is removed from the driver.
> 
> [1] https://lore.kernel.org/all/1521073067-24348-1-git-send-email-york.sun@nxp.com/#t
> 
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> Co-developed-by: Vijay Balakrishna <vijayb@linux.microsoft.com>
> Signed-off-by: Vijay Balakrishna <vijayb@linux.microsoft.com>
> ---
>  drivers/edac/Kconfig              |   9 ++
>  drivers/edac/Makefile             |   1 +
>  drivers/edac/cortex_arm64_l1_l2.c | 225 ++++++++++++++++++++++++++++++
>  3 files changed, 235 insertions(+)
>  create mode 100644 drivers/edac/cortex_arm64_l1_l2.c
> 
> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index 19ad3c3b675d..20c15a18437f 100644
> --- a/drivers/edac/Kconfig
> +++ b/drivers/edac/Kconfig
> @@ -576,4 +576,13 @@ config EDAC_LOONGSON
>  	  errors (CE) only. Loongson-3A5000/3C5000/3D5000/3A6000/3C6000
>  	  are compatible.
>  
> +config EDAC_CORTEX_ARM64_L1_L2
> +	tristate "ARM Cortex A72/A57/A53"
> +	depends on ARM64
> +	help
> +	  Support for L1/L2 cache error detection is provided for ARM Cortex
> +	  A72, A57, and A53 processors. The selected subset of errors is common
> +	  across these three MPCore processors, featuring compatible bit
> +	  assignments in their CPU/L2 memory error syndrome registers.
> +
>  endif # EDAC
> diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
> index a8f2d8f6c894..157062410e61 100644
> --- a/drivers/edac/Makefile
> +++ b/drivers/edac/Makefile
> @@ -88,3 +88,4 @@ obj-$(CONFIG_EDAC_NPCM)			+= npcm_edac.o
>  obj-$(CONFIG_EDAC_ZYNQMP)		+= zynqmp_edac.o
>  obj-$(CONFIG_EDAC_VERSAL)		+= versal_edac.o
>  obj-$(CONFIG_EDAC_LOONGSON)		+= loongson_edac.o
> +obj-$(CONFIG_EDAC_CORTEX_ARM64_L1_L2)	+= cortex_arm64_l1_l2.o
> diff --git a/drivers/edac/cortex_arm64_l1_l2.c b/drivers/edac/cortex_arm64_l1_l2.c
> new file mode 100644
> index 000000000000..2ffe20212acb
> --- /dev/null
> +++ b/drivers/edac/cortex_arm64_l1_l2.c
> @@ -0,0 +1,225 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Cortex A72, A57 and A53 EDAC L1 and L2 cache error detection
> + *
> + * Copyright (c) 2020 Pengutronix, Sascha Hauer <s.hauer@pengutronix.de>
> + *
> + * Based on Code from:
> + * Copyright (c) 2018, NXP Semiconductor
> + * Author: York Sun <york.sun@nxp.com>
> + *
> + */
> +
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_device.h>
> +#include <linux/bitfield.h>
> +#include <asm/smp_plat.h>
> +
> +#include "edac_module.h"
> +
> +#define DRVNAME				"cortex-arm64-edac"
> +
> +#define CPUMERRSR_EL1_RAMID		GENMASK(30, 24)
> +
> +#define CPUMERRSR_EL1_VALID		BIT(31)
> +#define CPUMERRSR_EL1_FATAL		BIT(63)
> +
> +#define L1_I_TAG_RAM			0x00
> +#define L1_I_DATA_RAM			0x01
> +#define L1_D_TAG_RAM			0x08
> +#define L1_D_DATA_RAM			0x09
> +#define TLB_RAM				0x18
> +
> +#define L2MERRSR_EL1_CPUID_WAY	GENMASK(21, 18)
> +
> +#define L2MERRSR_EL1_VALID		BIT(31)
> +#define L2MERRSR_EL1_FATAL		BIT(63)
> +
> +struct merrsr {
> +	u64 cpumerr;
> +	u64 l2merr;
> +};
> +
> +#define MESSAGE_SIZE 64
> +
> +#define SYS_CPUMERRSR_EL1			sys_reg(3, 1, 15, 2, 2)
> +#define SYS_L2MERRSR_EL1			sys_reg(3, 1, 15, 2, 3)
> +
> +static struct cpumask compat_mask;
> +
> +static void report_errors(struct edac_device_ctl_info *edac_ctl, int cpu,
> +			  struct merrsr *merrsr)
> +{
> +	char msg[MESSAGE_SIZE];
> +	u64 cpumerr = merrsr->cpumerr;
> +	u64 l2merr = merrsr->l2merr;
> +
> +	if (cpumerr & CPUMERRSR_EL1_VALID) {
> +		const char *str;
> +		bool fatal = cpumerr & CPUMERRSR_EL1_FATAL;
> +
> +		switch (FIELD_GET(CPUMERRSR_EL1_RAMID, cpumerr)) {
> +		case L1_I_TAG_RAM:
> +			str = "L1-I Tag RAM";
> +			break;
> +		case L1_I_DATA_RAM:
> +			str = "L1-I Data RAM";
> +			break;
> +		case L1_D_TAG_RAM:
> +			str = "L1-D Tag RAM";
> +			break;
> +		case L1_D_DATA_RAM:
> +			str = "L1-D Data RAM";
> +			break;
> +		case TLB_RAM:
> +			str = "TLB RAM";
> +			break;
> +		default:
> +			str = "Unspecified";
> +			break;
> +		}
> +
> +		snprintf(msg, MESSAGE_SIZE, "%s %s error(s) on CPU %d",
> +			 str, fatal ? "fatal" : "correctable", cpu);
> +
> +		if (fatal)
> +			edac_device_handle_ue(edac_ctl, cpu, 0, msg);
> +		else
> +			edac_device_handle_ce(edac_ctl, cpu, 0, msg);
> +
> +		write_sysreg_s(0, SYS_CPUMERRSR_EL1);
> +		isb();

I think the register writes and barriers should happen much closer to the
register reads, in read_errors(). Looking back at Marc's feedback on v5, I
think his most important piece of feedback was to only clear the register when
the valid bit is set to avoid accidentally clobbering an error that came in
between the register read and write.

By moving the register writes into report_errors() in this v6 series, there's
now a much larger window where new errors could occur between the register
read and the register write. Those new errors would be silently lost/ignored.
Reducing the window to the least number of cycles seems important for accurate
reporting.

> +	}
> +
> +	if (l2merr & L2MERRSR_EL1_VALID) {
> +		bool fatal = l2merr & L2MERRSR_EL1_FATAL;
> +
> +		snprintf(msg, MESSAGE_SIZE, "L2 %s error(s) on CPU %d CPUID/WAY 0x%x",
> +			 fatal ? "fatal" : "correctable", cpu,
> +			 FIELD_GET(L2MERRSR_EL1_CPUID_WAY, l2merr));
> +		if (fatal)
> +			edac_device_handle_ue(edac_ctl, cpu, 1, msg);
> +		else
> +			edac_device_handle_ce(edac_ctl, cpu, 1, msg);
> +
> +		write_sysreg_s(0, SYS_L2MERRSR_EL1);
> +		isb();
> +	}
> +}
> +
> +static void read_errors(void *data)
> +{
> +	struct merrsr *merrsr = data;
> +
> +	merrsr->cpumerr = read_sysreg_s(SYS_CPUMERRSR_EL1);
> +	merrsr->l2merr = read_sysreg_s(SYS_L2MERRSR_EL1);
> +}
> +
> +static void cortex_arm64_edac_check(struct edac_device_ctl_info *edac_ctl)
> +{
> +	struct merrsr merrsr;
> +	int cpu;
> +
> +	for_each_cpu_and(cpu, cpu_online_mask, &compat_mask) {
> +		smp_call_function_single(cpu, read_errors, &merrsr, true);
> +		report_errors(edac_ctl, cpu, &merrsr);
> +	}
> +}
> +
> +static int cortex_arm64_edac_probe(struct platform_device *pdev)
> +{
> +	struct edac_device_ctl_info *edac_ctl;
> +	struct device *dev = &pdev->dev;
> +	int rc;
> +
> +	edac_ctl = edac_device_alloc_ctl_info(0, "cpu",
> +					      num_possible_cpus(), "L", 2, 1, NULL, 0,
> +					      edac_device_alloc_index());
> +	if (!edac_ctl)
> +		return -ENOMEM;
> +
> +	edac_ctl->edac_check = cortex_arm64_edac_check;
> +	edac_ctl->dev = dev;
> +	edac_ctl->mod_name = dev_name(dev);
> +	edac_ctl->dev_name = dev_name(dev);
> +	edac_ctl->ctl_name = DRVNAME;
> +	dev_set_drvdata(dev, edac_ctl);
> +
> +	rc = edac_device_add_device(edac_ctl);
> +	if (rc)
> +		goto out_dev;
> +
> +	return 0;
> +
> +out_dev:
> +	edac_device_free_ctl_info(edac_ctl);
> +
> +	return rc;
> +}
> +
> +static int cortex_arm64_edac_remove(struct platform_device *pdev)
> +{
> +	struct edac_device_ctl_info *edac_ctl = dev_get_drvdata(&pdev->dev);
> +
> +	edac_device_del_device(edac_ctl->dev);
> +	edac_device_free_ctl_info(edac_ctl);
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id cortex_arm64_edac_of_match[] = {
> +	{ .compatible = "arm,cortex-a53" },
> +	{ .compatible = "arm,cortex-a57" },
> +	{ .compatible = "arm,cortex-a72" },
> +	{}
> +};
> +MODULE_DEVICE_TABLE(of, cortex_arm64_edac_of_match);
> +
> +static struct platform_driver cortex_arm64_edac_driver = {
> +	.probe = cortex_arm64_edac_probe,
> +	.remove = cortex_arm64_edac_remove,
> +	.driver = {
> +		.name = DRVNAME,
> +	},
> +};
> +
> +static int __init cortex_arm64_edac_driver_init(void)
> +{
> +	struct device_node *np;
> +	int cpu;
> +	struct platform_device *pdev;
> +	int err;
> +
> +	for_each_possible_cpu(cpu) {
> +		np = of_get_cpu_node(cpu, NULL);

Copilot correctly points out that we don't check np for NULL here. I think
of_match_node() handles that fine but we get fairly deep into the call stack
before it is caught. Let's go ahead and proactive check the return value.

More importantly, it pointed out that we don't call of_node_put(np) before
moving onto the next CPU. This would result in a refcount issue and will need
to be fixed.

Thanks!

Tyler

> +
> +		if (!of_match_node(cortex_arm64_edac_of_match, np))
> +			continue;
> +		if (!of_property_read_bool(np, "edac-enabled"))
> +			continue;
> +		cpumask_set_cpu(cpu, &compat_mask);
> +	}
> +
> +	if (cpumask_empty(&compat_mask))
> +		return 0;
> +
> +	err = platform_driver_register(&cortex_arm64_edac_driver);
> +	if (err)
> +		return err;
> +
> +	pdev = platform_device_register_simple(DRVNAME, -1, NULL, 0);
> +	if (IS_ERR(pdev)) {
> +		pr_err("failed to register cortex arm64 edac device\n");
> +		platform_driver_unregister(&cortex_arm64_edac_driver);
> +		return PTR_ERR(pdev);
> +	}
> +
> +	return 0;
> +}
> +
> +device_initcall(cortex_arm64_edac_driver_init);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Sascha Hauer <s.hauer@pengutronix.de>");
> +MODULE_DESCRIPTION("Cortex A72, A57 and A53 L1 and L2 cache EDAC driver");
> -- 
> 2.49.0
> 

Re: [PATCH 1/2] drivers/edac: Add L1 and L2 error detection for A53, A57 and A72

[Vijay Balakrishna]

On 4/10/2025 1:04 PM, Tyler Hicks (Microsoft) wrote:
>> +		snprintf(msg, MESSAGE_SIZE, "%s %s error(s) on CPU %d",
>> +			 str, fatal ? "fatal" : "correctable", cpu);
>> +
>> +		if (fatal)
>> +			edac_device_handle_ue(edac_ctl, cpu, 0, msg);
>> +		else
>> +			edac_device_handle_ce(edac_ctl, cpu, 0, msg);
>> +
>> +		write_sysreg_s(0, SYS_CPUMERRSR_EL1);
>> +		isb();
> I think the register writes and barriers should happen much closer to the
> register reads, in read_errors(). Looking back at Marc's feedback on v5, I
> think his most important piece of feedback was to only clear the register when
> the valid bit is set to avoid accidentally clobbering an error that came in
> between the register read and write.
> 
> By moving the register writes into report_errors() in this v6 series, there's
> now a much larger window where new errors could occur between the register
> read and the register write. Those new errors would be silently lost/ignored.
> Reducing the window to the least number of cycles seems important for accurate
> reporting.

Moving clear to report_errors() is wrong actually, it has be cleared 
from the CPU, from read_errors() which is a SMP call. Let me share new 
version with changes.

Thanks,
Vijay

Re: [PATCH 1/2] drivers/edac: Add L1 and L2 error detection for A53, A57 and A72

[Vijay Balakrishna]

On 4/10/2025 1:04 PM, Tyler Hicks (Microsoft) wrote:
>> +static int __init cortex_arm64_edac_driver_init(void)
>> +{
>> +	struct device_node *np;
>> +	int cpu;
>> +	struct platform_device *pdev;
>> +	int err;
>> +
>> +	for_each_possible_cpu(cpu) {
>> +		np = of_get_cpu_node(cpu, NULL);
> Copilot correctly points out that we don't check np for NULL here. I think
> of_match_node() handles that fine but we get fairly deep into the call stack
> before it is caught. Let's go ahead and proactive check the return value.
> 
> More importantly, it pointed out that we don't call of_node_put(np) before
> moving onto the next CPU. This would result in a refcount issue and will need
> to be fixed.

Good catch. Let me change in next version.

Thanks,
Vijay

Re: [PATCH 2/2] dt-bindings: arm: cpus: Add edac-enabled property

[Borislav Petkov]

On Thu, Apr 10, 2025 at 05:23:26PM +0100, Marc Zyngier wrote:
> We have some other EDAC implementation for arm64 CPUs (XGene,
> ThunderX), and they are all perfectly useless (I have them in my
> collection of horrors).

Oh oh, can I remove, can I remove?

My trigger finger is itching to kill some more useless code...

Thx.

Re: [PATCH 2/2] dt-bindings: arm: cpus: Add edac-enabled property

[Marc Zyngier]

On Fri, 11 Apr 2025 21:02:07 +0100,
Borislav Petkov <bp@alien8.de> wrote:
> 
> On Thu, Apr 10, 2025 at 05:23:26PM +0100, Marc Zyngier wrote:
> > We have some other EDAC implementation for arm64 CPUs (XGene,
> > ThunderX), and they are all perfectly useless (I have them in my
> > collection of horrors).
> 
> Oh oh, can I remove, can I remove?
> 
> My trigger finger is itching to kill some more useless code...

The drivers do report ECC errors being corrected, which indicates that
the HW itself is doing its job. Yes, I buy cheap memory from eBay.

Do we need actual drivers to output crap on the console? Probably not,
but I'm the wrong person to ask -- I only keep these machines alive to
remind me how things can go horribly wrong.

I don't think there is any harm in keeping this crap around. It
compiles, and if it breaks, I'll fix it. I'm not convinced we need any
more of it though, specially for CPUs that are over a decade old.

	M.

-- 
Without deviation from the norm, progress is not possible.