[PATCH 0/4] EDAC/altera: Add support for Agilex5 platform

[PATCH 0/4] EDAC/altera: Add support for Agilex5 platform

[Dinh Nguyen]

This series add preliminary EDAC support for the Agilex5 platform. The
EDAC module on the Agilex5 is a bit different from the previous Arria10
and Stratix10 platforms in that it has the full 7 interrupts.

global_sbe    - aggregate single-bit error (chained, drives IRQ domain)
global_dbe    - aggregate double-bit error (chained; DBE is no longer
                delivered exclusively through Asynchronous SError)
io96b0        - IO96B0 DRAM controller ECC
io96b1        - IO96B1 DRAM controller ECC
sdm_qspi_sbe  - SDM QSPI single-bit error
sdm_qspi_dbe  - SDM QSPI double-bit error
sdm_seu       - SDM single-event-upset

patch 1/4 : dt-bindings: edac: altera: agilex5: document new edac support
Introduce a new dt binding "altr,socfpga-agilex5-ecc-manager" that is
specific to the Agilex5 platform. Document the 7 interrupts.

Patch 2/4 : EDAC/altera: use flag to differentiate 64-bit platforms
Use match data to provide a method to differentiate different platforms.

Patch 3/4 : EDAC/altera: Add support for Agilex5 ECC manager
Modifies the Altera EDAC driver to support the Agilex5 platform.

Patch 4/4 : arm64: dts: socfpga: agilex5: add support for the ECC manager
Populates the base Agilex5 DTSI wit the EDAC IP.


Dinh Nguyen (4):
  dt-bindings: edac: altera: agilex5: document new edac support
  EDAC/altera: use flag to differentiate 64-bit platforms
  EDAC/altera: Add support for Agilex5 ECC manager
  arm64: dts: socfpga: agilex5: add support for the ECC manager

 .../edac/altr,socfpga-ecc-manager.yaml        |  23 +++-
 .../arm64/boot/dts/intel/socfpga_agilex5.dtsi |  68 ++++++++++++
 drivers/edac/altera_edac.c                    | 100 ++++++++++++++++--
 drivers/edac/altera_edac.h                    |  34 +++++-
 4 files changed, 212 insertions(+), 13 deletions(-)

-- 
2.42.0.411.g813d9a9188

[PATCH 1/4] dt-bindings: edac: altera: agilex5: document new edac support

[Dinh Nguyen]

The Agilex5 EDAC module supports ECC on a few additional peripherals. Along
with support for ocram, ethernet and USB, the Agilex5 EDAC adds support for
SDM QSPI, CRAM SEU and IO96B.

The Agilex5 EDAC also exposes up to 7 named interrupts on the manager
node. global_sbe and global_dbe are aggregate single/double-bit error
interrupts that fan-out through the manager's IRQ domain to the child
peripheral ECCs. The remaining named interrupts are routed directly from
dedicated controllers (IO96B memory controllers and Secure Device Manager)
to the GIC.

Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
 .../edac/altr,socfpga-ecc-manager.yaml        | 23 ++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/edac/altr,socfpga-ecc-manager.yaml b/Documentation/devicetree/bindings/edac/altr,socfpga-ecc-manager.yaml
index 136e8fccd429a..2ccb0f2163185 100644
--- a/Documentation/devicetree/bindings/edac/altr,socfpga-ecc-manager.yaml
+++ b/Documentation/devicetree/bindings/edac/altr,socfpga-ecc-manager.yaml
@@ -22,6 +22,9 @@ properties:
       - items:
           - const: altr,socfpga-s10-ecc-manager
           - const: altr,socfpga-a10-ecc-manager
+      - items:
+          - const: altr,socfpga-agilex5-ecc-manager
+          - const: altr,socfpga-a10-ecc-manager
       - const: altr,socfpga-a10-ecc-manager
       - const: altr,socfpga-ecc-manager
 
@@ -33,7 +36,25 @@ properties:
 
   interrupts:
     minItems: 1
-    maxItems: 2
+    items:
+      - description: Global single-bit error
+      - description: Global double-bit error
+      - description: IO96B0 DRAM controller error
+      - description: IO96B1 DRAM controller error
+      - description: SDM QSPI single-bit error
+      - description: SDM QSPI double-bit error
+      - description: SDM single-event
+
+  interrupt-names:
+    minItems: 1
+    items:
+      - const: global_sbe
+      - const: global_dbe
+      - const: io96b0
+      - const: io96b1
+      - const: sdm_qspi_sbe
+      - const: sdm_qspi_dbe
+      - const: sdm_seu
 
   interrupt-controller: true
 
-- 
2.42.0.411.g813d9a9188

Re: [PATCH 1/4] dt-bindings: edac: altera: agilex5: document new edac support

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Removing `maxItems: 2` from the global `interrupts` property to allow up to 7 items relaxes constraints for older hardware generations, allowing them to improperly specify up to 7 interrupts and bypass schema validation.
- [Medium] The `interrupt-names` property is introduced for the new `altr,socfpga-agilex5-ecc-manager` variant, but it is not conditionally enforced as a required property for Agilex5.
--

--- Patch [1]: [PATCH 1/4] dt-bindings: edac: altera: agilex5: document new edac support ---
commit d266055949125966c496511b166440e55892f101
Author: Dinh Nguyen <dinguyen@kernel.org>

dt-bindings: edac: altera: agilex5: document new edac support

This commit adds EDAC support for Agilex5 peripherals, including SDM QSPI,
CRAM SEU, and IO96B. It updates the device tree bindings to include the new
compatible string and expands the interrupts and interrupt-names properties
to accommodate up to 7 interrupts for the new hardware variant.

> diff --git a/Documentation/devicetree/bindings/edac/altr,socfpga-ecc-manager.yaml b/Documentation/devicetree/bindings/edac/altr,socfpga-ecc-manager.yaml
> index 136e8fccd429a..2ccb0f2163185 100644
> --- a/Documentation/devicetree/bindings/edac/altr,socfpga-ecc-manager.yaml
> +++ b/Documentation/devicetree/bindings/edac/altr,socfpga-ecc-manager.yaml

[ ... ]

> @@ -33,7 +36,25 @@ properties:
>  
>    interrupts:
>      minItems: 1
> -    maxItems: 2
> +    items:
> +      - description: Global single-bit error
> +      - description: Global double-bit error
> +      - description: IO96B0 DRAM controller error
> +      - description: IO96B1 DRAM controller error
> +      - description: SDM QSPI single-bit error
> +      - description: SDM QSPI double-bit error
> +      - description: SDM single-event

[Severity: Medium]
Does removing the maxItems: 2 constraint here allow older hardware generations
(like S10 or A10) to mistakenly define up to 7 interrupts and silently pass
schema validation?

Should the binding use an allOf / if-then block to enforce maxItems: 2
specifically for the older compatibles?

> +
> +  interrupt-names:
> +    minItems: 1
> +    items:
> +      - const: global_sbe
> +      - const: global_dbe
> +      - const: io96b0
> +      - const: io96b1
> +      - const: sdm_qspi_sbe
> +      - const: sdm_qspi_dbe
> +      - const: sdm_seu

[Severity: Medium]
Will this allow device trees for Agilex5 to silently pass schema validation
even if they omit the interrupt-names entirely?

Should there be a conditional block enforcing interrupt-names as a required
property specifically for the altr,socfpga-agilex5-ecc-manager variant?

>  
>    interrupt-controller: true
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720201425.1538771-1-dinguyen@kernel.org?part=1

[PATCH 2/4] EDAC/altera: use flag to differentiate 64-bit platforms

[Dinh Nguyen]

In commit (d4486fc3098e "EDAC/altera: Use ECC manager compatible to select
A10/S10 IRQ layout"), it added a way to only differentiate Stratix10 from a
32-bit platform. In preparation to add support for Agilex5, it needs a way to
make a further differentiation.

Make use of the driver match data to hold a flag for different platforms,
specifically Stratix10 and Agilex5.

Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
 drivers/edac/altera_edac.c | 17 +++++++++--------
 drivers/edac/altera_edac.h |  5 ++++-
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index 777ba6efcc542..8a5b08e0d0583 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -1507,7 +1507,7 @@ static int altr_portb_setup(struct altr_edac_device_dev *device)
 	int edac_idx, rc;
 	struct device_node *np;
 	const struct edac_device_prv_data *prv = &a10_sdmmceccb_data;
-	bool is_s10 = device->edac->is_s10;
+	unsigned long flag = {unsigned long)device->edac->flag;
 
 	rc = altr_check_ecc_deps(device);
 	if (rc)
@@ -1555,7 +1555,7 @@ static int altr_portb_setup(struct altr_edac_device_dev *device)
 	 */
 
 	/* Using compatibles to determine the IRQ Index */
-	if (is_s10)
+	if (flag == SOCFPGA_S10)
 		altdev->sb_irq = irq_of_parse_and_map(np, 1);
 	else
 		altdev->sb_irq = irq_of_parse_and_map(np, 2);
@@ -1573,7 +1573,7 @@ static int altr_portb_setup(struct altr_edac_device_dev *device)
 		goto err_release_group_1;
 	}
 
-	if (is_s10) {
+	if (flag == SOCFPGA_S10) {
 		/* Use IRQ to determine SError origin instead of assigning IRQ */
 		rc = of_property_read_u32_index(np, "interrupts", 1, &altdev->db_irq);
 		if (rc) {
@@ -1979,7 +1979,7 @@ static int altr_edac_a10_device_add(struct altr_arria10_edac *edac,
 		goto err_release_group1;
 	}
 
-	if (edac->is_s10) {
+	if (edac->flag == SOCFPGA_S10) {
 		/* Use IRQ to determine SError origin instead of assigning IRQ */
 		rc = of_property_read_u32_index(np, "interrupts", 0, &altdev->db_irq);
 		if (rc) {
@@ -2125,7 +2125,7 @@ static int altr_edac_a10_probe(struct platform_device *pdev)
 	platform_set_drvdata(pdev, edac);
 	INIT_LIST_HEAD(&edac->a10_ecc_devices);
 
-	edac->is_s10 = !!device_get_match_data(&pdev->dev);
+	edac->flag = (unsigned long)device_get_match_data(&pdev->dev);
 
 	edac->ecc_mgr_map =
 		altr_sysmgr_regmap_lookup_by_phandle(pdev->dev.of_node,
@@ -2158,8 +2158,8 @@ static int altr_edac_a10_probe(struct platform_device *pdev)
 	irq_set_chained_handler_and_data(edac->sb_irq,
 					 altr_edac_a10_irq_handler,
 					 edac);
-	if (edac->is_s10)
-	{
+
+	if (edac->flag == SOCFPGA_S10) {
 		int dberror, err_addr;
 
 		edac->panic_notifier.notifier_call = s10_edac_dberr_handler;
@@ -2210,7 +2210,8 @@ static int altr_edac_a10_probe(struct platform_device *pdev)
 
 static const struct of_device_id altr_edac_a10_of_match[] = {
 	{ .compatible = "altr,socfpga-a10-ecc-manager" },
-	{ .compatible = "altr,socfpga-s10-ecc-manager", .data = (void *)1 },
+	{ .compatible = "altr,socfpga-s10-ecc-manager",
+	  .data = (void *)SOCFPGA_S10 },
 	{},
 };
 MODULE_DEVICE_TABLE(of, altr_edac_a10_of_match);
diff --git a/drivers/edac/altera_edac.h b/drivers/edac/altera_edac.h
index 9387056fd65e3..74ab7bfc3e748 100644
--- a/drivers/edac/altera_edac.h
+++ b/drivers/edac/altera_edac.h
@@ -351,6 +351,9 @@ struct altr_sdram_mc_data {
 #define ECC_READ_EOVR                     0x2
 #define ECC_READ_EDOVR                    0x3
 
+#define SOCFPGA_S10                       0x1
+#define SOCFPGA_AGILEX5                   0x2
+
 struct altr_edac_device_dev;
 
 struct edac_device_prv_data {
@@ -394,7 +397,7 @@ struct altr_arria10_edac {
 	struct irq_chip		irq_chip;
 	struct list_head	a10_ecc_devices;
 	struct notifier_block	panic_notifier;
-	bool is_s10;
+	unsigned long		flag;
 };
 
 #endif	/* #ifndef _ALTERA_EDAC_H */
-- 
2.42.0.411.g813d9a9188

Re: [PATCH 2/4] EDAC/altera: use flag to differentiate 64-bit platforms

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [Low] A syntax error prevents compilation due to a typographical error in variable initialization.

Pre-existing issues:
- [High] The IRQ domain is leaked and chained IRQ handlers are left dangling on probe error paths.
- [High] The driver registers a panic notifier but never unregisters it, leading to a Use-After-Free on unbind.
--

--- Patch [2]: [PATCH 2/4] EDAC/altera: use flag to differentiate 64-bit platforms ---
commit 4db36eaf83f8ef9e44a35979b3fccecc08fabc69
Author: Dinh Nguyen <dinguyen@kernel.org>
Subject: EDAC/altera: use flag to differentiate 64-bit platforms

This commit introduces a flag to differentiate platforms like Stratix10 and
Agilex5 by storing it in the driver match data. It updates the device setup
and probe functions to check this flag instead of the boolean is_s10 field.

> diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
> --- a/drivers/edac/altera_edac.c
> +++ b/drivers/edac/altera_edac.c
> @@ -1507,7 +1507,7 @@ static int altr_portb_setup(struct altr_edac_device_dev *device)
>  	int edac_idx, rc;
>  	struct device_node *np;
>  	const struct edac_device_prv_data *prv = &a10_sdmmceccb_data;
> -	bool is_s10 = device->edac->is_s10;
> +	unsigned long flag = {unsigned long)device->edac->flag;

[Severity: Low]
Is there a syntax error in this type cast? Using a curly brace instead of a
parenthesis causes a build failure.

[ ... ]

> @@ -2152,8 +2152,8 @@ static int altr_edac_a10_probe(struct platform_device *pdev)
>  	irq_set_chained_handler_and_data(edac->sb_irq,
>  					 altr_edac_a10_irq_handler,
>  					 edac);
> -	if (edac->is_s10)
> -	{
> +
> +	if (edac->flag == SOCFPGA_S10) {

[Severity: High]
This is a pre-existing issue, but does this probe error path leak the chained
IRQ handler and IRQ domain?

In altr_edac_a10_probe(), irq_set_chained_handler_and_data() is called for
sb_irq. If a later step fails, like fetching db_irq:

	edac->db_irq = platform_get_irq(pdev, 1);
	if (edac->db_irq < 0)
		return edac->db_irq;

The probe function returns the error directly without unregistering the chained
handler. Since the edac structure is devm-allocated, it gets freed on probe
failure.

If the interrupt triggers later, could this cause a use-after-free when the
handler executes with a dangling edac pointer?

>  		int dberror, err_addr;
>  
>  		edac->panic_notifier.notifier_call = s10_edac_dberr_handler;
>  		atomic_notifier_chain_register(&panic_notifier_list,
>  					       &edac->panic_notifier);

[Severity: High]
This is a pre-existing issue, but does this driver ever unregister its panic
notifier?

The edac structure is devm-allocated, but I don't see a devm action or a 
.remove callback to unregister the panic_notifier.

If the driver is unbound via sysfs, devres will free the edac structure,
leaving a dangling pointer in panic_notifier_list.

Could a subsequent panic attempt to call the freed notifier block and trigger
a nested panic?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720201425.1538771-1-dinguyen@kernel.org?part=2

[PATCH 3/4] EDAC/altera: Add support for Agilex5 ECC manager

[Dinh Nguyen]

Add a new compatible "altr,socfpga-agilex5-ecc-manager" to the Arria10
EDAC manager driver. Unlike Stratix10/Agilex7, the Agilex5 ECC manager
exposes up to 7 named interrupts on its DT node:

  global_sbe    - aggregate single-bit error (chained, drives IRQ domain)
  global_dbe    - aggregate double-bit error (chained; DBE is no longer
                  delivered exclusively through Asynchronous SError)
  io96b0        - IO96B0 DRAM controller ECC
  io96b1        - IO96B1 DRAM controller ECC
  sdm_qspi_sbe  - SDM QSPI single-bit error
  sdm_qspi_dbe  - SDM QSPI double-bit error
  sdm_seu       - SDM single-event-upset

On Agilex5, retrieve all seven interrupts by name via
platform_get_irq_byname_optional() and stash them in a new
agilex5_irqs[] array on struct altr_arria10_edac so subsequent
peripheral support (IO96B, SDM QSPI, CRAM SEU) can consume them without
re-parsing the DT. Only global_sbe is mandatory; the rest are optional.

global_sbe is wired up as the chained SBE handler (replacing the legacy
index-0 lookup). When present, global_dbe is hooked into the same
altr_edac_a10_irq_handler() so that the existing sb_irq/db_irq demux
routes DBE events through the manager's IRQ domain. The SError-based
panic notifier path is preserved as a fall-back.

Legacy A10/S10 probe paths are unchanged.

Assisted-by: Cursor:claude-sonnet-4.7
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
 drivers/edac/altera_edac.c | 85 ++++++++++++++++++++++++++++++++++++--
 drivers/edac/altera_edac.h | 29 +++++++++++++
 2 files changed, 110 insertions(+), 4 deletions(-)

diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index 8a5b08e0d0583..44da63ef5d71e 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -1507,7 +1507,7 @@ static int altr_portb_setup(struct altr_edac_device_dev *device)
 	int edac_idx, rc;
 	struct device_node *np;
 	const struct edac_device_prv_data *prv = &a10_sdmmceccb_data;
-	unsigned long flag = {unsigned long)device->edac->flag;
+	unsigned long flag = (unsigned long)device->edac->flag;
 
 	rc = altr_check_ecc_deps(device);
 	if (rc)
@@ -2111,11 +2111,63 @@ static int s10_edac_dberr_handler(struct notifier_block *this,
 	return NOTIFY_DONE;
 }
 
+/*
+ * Ordered table of named interrupts published by an
+ * "altr,socfpga-agilex5-ecc-manager" device tree node. Indices match
+ * enum altr_agilex5_irq_idx. Only "global_sbe" is mandatory; the rest are
+ * optional so platforms can omit interrupts for unused subsystems.
+ */
+static const char * const altr_agilex5_irq_names[ALTR_AGILEX5_NUM_IRQS] = {
+	[ALTR_AGILEX5_IRQ_GLOBAL_SBE]   = "global_sbe",
+	[ALTR_AGILEX5_IRQ_GLOBAL_DBE]   = "global_dbe",
+	[ALTR_AGILEX5_IRQ_IO96B0]       = "io96b0",
+	[ALTR_AGILEX5_IRQ_IO96B1]       = "io96b1",
+	[ALTR_AGILEX5_IRQ_SDM_QSPI_SBE] = "sdm_qspi_sbe",
+	[ALTR_AGILEX5_IRQ_SDM_QSPI_DBE] = "sdm_qspi_dbe",
+	[ALTR_AGILEX5_IRQ_SDM_SEU]      = "sdm_seu",
+};
+
+/*
+ * Populate edac->agilex5_irqs[] from the named interrupts on the manager
+ * platform device. Missing optional interrupts are stored as a negative
+ * errno (-ENXIO) so that subsequent feature code can probe whether the
+ * resource exists. global_sbe is required because it drives the manager's
+ * IRQ domain dispatch path.
+ *
+ * platform_get_irq_byname_optional() can return -EPROBE_DEFER when the
+ * parent irqchip (e.g. the GIC) is not yet probed. Propagate that error
+ * up so the kernel re-tries the probe later instead of permanently
+ * disabling the named interrupt.
+ */
+static int altr_agilex5_get_named_irqs(struct platform_device *pdev,
+				       struct altr_arria10_edac *edac)
+{
+	int i, irq;
+
+	for (i = 0; i < ALTR_AGILEX5_NUM_IRQS; i++) {
+		irq = platform_get_irq_byname_optional(pdev,
+						       altr_agilex5_irq_names[i]);
+		if (irq == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
+
+		edac->agilex5_irqs[i] = irq > 0 ? irq : -ENXIO;
+	}
+
+	if (edac->agilex5_irqs[ALTR_AGILEX5_IRQ_GLOBAL_SBE] < 0) {
+		dev_err(&pdev->dev,
+			"Agilex5 ECC manager missing required 'global_sbe' interrupt\n");
+		return -ENODEV;
+	}
+
+	return 0;
+}
+
 /****************** Arria 10 EDAC Probe Function *********************/
 static int altr_edac_a10_probe(struct platform_device *pdev)
 {
 	struct altr_arria10_edac *edac;
 	struct device_node *child;
+	int rc;
 
 	edac = devm_kzalloc(&pdev->dev, sizeof(*edac), GFP_KERNEL);
 	if (!edac)
@@ -2151,14 +2203,31 @@ static int altr_edac_a10_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 
-	edac->sb_irq = platform_get_irq(pdev, 0);
-	if (edac->sb_irq < 0)
-		return edac->sb_irq;
+	if (edac->flag == SOCFPGA_AGILEX5) {
+		rc = altr_agilex5_get_named_irqs(pdev, edac);
+		if (rc)
+			return rc;
+
+		edac->sb_irq = edac->agilex5_irqs[ALTR_AGILEX5_IRQ_GLOBAL_SBE];
+	} else {
+		edac->sb_irq = platform_get_irq(pdev, 0);
+		if (edac->sb_irq < 0)
+			return edac->sb_irq;
+	}
 
 	irq_set_chained_handler_and_data(edac->sb_irq,
 					 altr_edac_a10_irq_handler,
 					 edac);
 
+	/*
+	 * Unlike Stratix10/Agilex7 (which deliver uncorrectable errors as
+	 * Asynchronous SError), Agilex5 routes the global double-bit error
+	 * through a dedicated SPI ("global_dbe"). Hook it into the same
+	 * chained handler so the existing sb_irq/db_irq demux in
+	 * altr_edac_a10_irq_handler() routes DBE events through the manager's
+	 * IRQ domain. The panic notifier below is still registered as a
+	 * fall-back for any DBEs that escape to SError.
+	 */
 	if (edac->flag == SOCFPGA_S10) {
 		int dberror, err_addr;
 
@@ -2181,6 +2250,12 @@ static int altr_edac_a10_probe(struct platform_device *pdev)
 			regmap_write(edac->ecc_mgr_map,
 				     S10_SYSMGR_UE_ADDR_OFST, 0);
 		}
+	} else if (edac->flag == SOCFPGA_AGILEX5 &&
+		   edac->agilex5_irqs[ALTR_AGILEX5_IRQ_GLOBAL_DBE] >= 0) {
+		edac->db_irq = edac->agilex5_irqs[ALTR_AGILEX5_IRQ_GLOBAL_DBE];
+		irq_set_chained_handler_and_data(edac->db_irq,
+						 altr_edac_a10_irq_handler,
+						 edac);
 	} else {
 		edac->db_irq = platform_get_irq(pdev, 1);
 		if (edac->db_irq < 0)
@@ -2212,6 +2287,8 @@ static const struct of_device_id altr_edac_a10_of_match[] = {
 	{ .compatible = "altr,socfpga-a10-ecc-manager" },
 	{ .compatible = "altr,socfpga-s10-ecc-manager",
 	  .data = (void *)SOCFPGA_S10 },
+	{ .compatible = "altr,socfpga-agilex5-ecc-manager",
+	  .data = (void *)SOCFPGA_AGILEX5 },
 	{},
 };
 MODULE_DEVICE_TABLE(of, altr_edac_a10_of_match);
diff --git a/drivers/edac/altera_edac.h b/drivers/edac/altera_edac.h
index 74ab7bfc3e748..30e35da7eb6a1 100644
--- a/drivers/edac/altera_edac.h
+++ b/drivers/edac/altera_edac.h
@@ -326,6 +326,27 @@ struct altr_sdram_mc_data {
 #define S10_DDR0_IRQ_MASK                 BIT(16)
 #define S10_DBE_IRQ_MASK                  0x3FFFE
 
+/************* Agilex5 Defines **************/
+/*
+ * The Agilex5 ECC manager exposes up to 7 named interrupts on the manager
+ * node. global_sbe and global_dbe are aggregate single/double-bit error
+ * interrupts that fan-out through the manager's IRQ domain to the child
+ * peripheral ECCs. The remaining named interrupts are routed directly from
+ * dedicated controllers (IO96B memory controllers and Secure Device Manager)
+ * to the GIC.
+ */
+#define ALTR_AGILEX5_NUM_IRQS             7
+
+enum altr_agilex5_irq_idx {
+	ALTR_AGILEX5_IRQ_GLOBAL_SBE,
+	ALTR_AGILEX5_IRQ_GLOBAL_DBE,
+	ALTR_AGILEX5_IRQ_IO96B0,
+	ALTR_AGILEX5_IRQ_IO96B1,
+	ALTR_AGILEX5_IRQ_SDM_QSPI_SBE,
+	ALTR_AGILEX5_IRQ_SDM_QSPI_DBE,
+	ALTR_AGILEX5_IRQ_SDM_SEU,
+};
+
 /* Define ECC Block Offsets for peripherals */
 #define ECC_BLK_ADDRESS_OFST              0x40
 #define ECC_BLK_RDATA0_OFST               0x44
@@ -398,6 +419,14 @@ struct altr_arria10_edac {
 	struct list_head	a10_ecc_devices;
 	struct notifier_block	panic_notifier;
 	unsigned long		flag;
+
+	/*
+	 * Agilex5 ECC manager supports up to ALTR_AGILEX5_NUM_IRQS named
+	 * interrupts. Entries are indexed by enum altr_agilex5_irq_idx and
+	 * hold the Linux virtual IRQ number, or a negative errno when the
+	 * corresponding interrupt was not provided in the device tree.
+	 */
+	int			agilex5_irqs[ALTR_AGILEX5_NUM_IRQS];
 };
 
 #endif	/* #ifndef _ALTERA_EDAC_H */
-- 
2.42.0.411.g813d9a9188

Re: [PATCH 3/4] EDAC/altera: Add support for Agilex5 ECC manager

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] A flawed if/else chain causes Agilex5 to incorrectly fall through to legacy A10 logic if the optional `global_dbe` interrupt is missing, leading to probe failure or interrupt hijacking, and prevents registration of the intended panic notifier fallback.

Pre-existing issues:
- [High] Probe error paths fail to unregister the IRQ domain and chained handlers, leading to Resource Leaks and Use-After-Free.
- [High] The platform driver lacks a .remove callback, causing severe Use-After-Frees on module unbind.
--

--- Patch [3]: [PATCH 3/4] EDAC/altera: Add support for Agilex5 ECC manager ---
commit fe27bbb114924237edb349c2779f0fc2899da926
Author: Dinh Nguyen <dinguyen@kernel.org>

EDAC/altera: Add support for Agilex5 ECC manager

This commit adds support for the Agilex5 ECC manager to the Arria10 EDAC
driver. It introduces parsing for up to seven named interrupts, routing the
mandatory global_sbe and optional global_dbe through the chained interrupt
handler.

> diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
> index e833869236914..13abce089ef1c 100644
> --- a/drivers/edac/altera_edac.c
> +++ b/drivers/edac/altera_edac.c
[ ... ]
> @@ -2145,14 +2197,31 @@ static int altr_edac_a10_probe(struct platform_device *pdev)
>  		return -ENOMEM;
>  	}
>  
> -	edac->sb_irq = platform_get_irq(pdev, 0);
> -	if (edac->sb_irq < 0)
> -		return edac->sb_irq;
> +	if (edac->flag == SOCFPGA_AGILEX5) {
> +		rc = altr_agilex5_get_named_irqs(pdev, edac);
> +		if (rc)
> +			return rc;

[Severity: High]
This is a pre-existing issue, but if altr_agilex5_get_named_irqs() returns
an error like -EPROBE_DEFER, does this return path leak the IRQ domain
created earlier in altr_edac_a10_probe()?

Because edac is allocated with devres, the memory will be freed, but the
IRQ domain might remain registered and point to the freed edac structure.

Could this lead to a use-after-free if the IRQ subsystem attempts to access
the domain's host_data?

> +
> +		edac->sb_irq = edac->agilex5_irqs[ALTR_AGILEX5_IRQ_GLOBAL_SBE];
> +	} else {
> +		edac->sb_irq = platform_get_irq(pdev, 0);
> +		if (edac->sb_irq < 0)
> +			return edac->sb_irq;
> +	}
>  
>  	irq_set_chained_handler_and_data(edac->sb_irq,
>  					 altr_edac_a10_irq_handler,
>  					 edac);
>  
> +	/*
> +	 * Unlike Stratix10/Agilex7 (which deliver uncorrectable errors as
> +	 * Asynchronous SError), Agilex5 routes the global double-bit error
> +	 * through a dedicated SPI ("global_dbe"). Hook it into the same
> +	 * chained handler so the existing sb_irq/db_irq demux in
> +	 * altr_edac_a10_irq_handler() routes DBE events through the manager's
> +	 * IRQ domain. The panic notifier below is still registered as a
> +	 * fall-back for any DBEs that escape to SError.
> +	 */
>  	if (edac->flag == SOCFPGA_S10) {

[Severity: High]
The comment above states the panic notifier is registered as a fallback
for Agilex5. However, this check only matches SOCFPGA_S10. Does this mean
the panic notifier is inadvertently skipped for Agilex5 devices?

>  		int dberror, err_addr;
>  
[ ... ]
> @@ -2175,6 +2244,12 @@ static int altr_edac_a10_probe(struct platform_device *pdev)
>  			regmap_write(edac->ecc_mgr_map,
>  				     S10_SYSMGR_UE_ADDR_OFST, 0);
>  		}
> +	} else if (edac->flag == SOCFPGA_AGILEX5 &&
> +		   edac->agilex5_irqs[ALTR_AGILEX5_IRQ_GLOBAL_DBE] >= 0) {
> +		edac->db_irq = edac->agilex5_irqs[ALTR_AGILEX5_IRQ_GLOBAL_DBE];
> +		irq_set_chained_handler_and_data(edac->db_irq,
> +						 altr_edac_a10_irq_handler,
> +						 edac);
>  	} else {
>  		edac->db_irq = platform_get_irq(pdev, 1);
>  		if (edac->db_irq < 0)
>  			return edac->db_irq;

[Severity: High]
If an Agilex5 device omits the optional GLOBAL_DBE interrupt, will it
incorrectly fall through to this else branch?

This would cause it to call platform_get_irq(pdev, 1). If the device has
other optional interrupts, this might incorrectly hijack one of them (like
io96b0) as the chained DBE handler. If it doesn't have other interrupts,
it might fail and abort the probe with -ENXIO.

Also, this is a pre-existing issue, but if platform_get_irq(pdev, 1) fails,
does returning an error here leave the sb_irq chained handler dangling?

Since it was registered earlier in altr_edac_a10_probe(), it could cause a
use-after-free when the interrupt fires and dereferences the devres-freed
edac pointer.

[ ... ]
> @@ -2206,6 +2281,8 @@ static const struct of_device_id altr_edac_a10_of_match[] = {
>  	{ .compatible = "altr,socfpga-a10-ecc-manager" },
>  	{ .compatible = "altr,socfpga-s10-ecc-manager",
>  	  .data = (void *)SOCFPGA_S10 },
> +	{ .compatible = "altr,socfpga-agilex5-ecc-manager",
> +	  .data = (void *)SOCFPGA_AGILEX5 },
>  	{},
>  };
>  MODULE_DEVICE_TABLE(of, altr_edac_a10_of_match);

[Severity: High]
This is a pre-existing issue, but does the platform driver lack a .remove
callback?

drivers/edac/altera_edac.c:
static struct platform_driver altr_edac_a10_driver = {
        .probe =  altr_edac_a10_probe,
        .driver = {
                .name = "socfpga_a10_ecc_manager",
                .of_match_table = altr_edac_a10_of_match,
        },
};

If the driver is unbound via sysfs, devres will automatically free the
edac struct and unmap MMIO regions. However, the chained IRQ handlers,
IRQ domain, and panic notifier remain registered.

Could this cause a use-after-free if a hardware interrupt or kernel panic
occurs after the module is unbound?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720201425.1538771-1-dinguyen@kernel.org?part=3

[PATCH 4/4] arm64: dts: socfpga: agilex5: add support for the ECC manager

[Dinh Nguyen]

Add the EDAC device to the base Agilex5 platform. Add OCRAM and Ethernet ECC
device support to the Agilex5 platform.

Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
 .../arm64/boot/dts/intel/socfpga_agilex5.dtsi | 68 +++++++++++++++++++
 1 file changed, 68 insertions(+)

diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
index b06c6d5d60eed..f30d476683b4a 100644
--- a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
@@ -370,6 +370,74 @@ dmac1: dma-controller@10000 {
 			};
 		};
 
+		eccmgr {
+			compatible = "altr,socfpga-agilex5-ecc-manager",
+				     "altr,socfpga-a10-ecc-manager";
+			altr,sysmgr-syscon = <&sysmgr>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 241 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 95 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 120 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "global_sbe", "global_dbe", "io96b0" , "io96b1",
+					  "sdm_qspi_sbe", "sdm_qspi_dbe", "sdm_seu";
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			ranges;
+
+			ocram-ecc@108cc000 {
+				compatible = "altr,socfpga-a10-ocram-ecc";
+				reg = <0x108cc000 0x100>;
+				interrupts = <1 IRQ_TYPE_LEVEL_HIGH>, <33 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+			emac0-rx-ecc@108c0000 {
+				compatible = "altr,socfpga-eth-mac-ecc";
+				reg = <0x108c0000 0x100>;
+				altr,ecc-parent = <&gmac0>;
+				interrupts = <4 IRQ_TYPE_LEVEL_HIGH>, <38 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+			emac0-tx-ecc@108c0400 {
+				compatible = "altr,socfpga-eth-mac-ecc";
+				reg = <0x108c0400 0x100>;
+				altr,ecc-parent = <&gmac0>;
+				interrupts = <5 IRQ_TYPE_LEVEL_HIGH>, <37 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+			emac1-rx-ecc@108c0800 {
+				compatible = "altr,socfpga-eth-mac-ecc";
+				reg = <0x108c0800 0x100>;
+				altr,ecc-parent = <&gmac1>;
+				interrupts = <6 IRQ_TYPE_LEVEL_HIGH>, <38 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+			emac1-tx-ecc@108c0c00 {
+				compatible = "altr,socfpga-eth-mac-ecc";
+				reg = <0x108c0c00 0x100>;
+				altr,ecc-parent = <&gmac1>;
+				interrupts = <7 IRQ_TYPE_LEVEL_HIGH>, <39 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+			emac2-rx-ecc@108c1000 {
+				compatible = "altr,socfpga-eth-mac-ecc";
+				reg = <0x108c1000 0x100>;
+				altr,ecc-parent = <&gmac2>;
+				interrupts = <8 IRQ_TYPE_LEVEL_HIGH>, <40 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+			emac2-tx-ecc@108c1400 {
+				compatible = "altr,socfpga-eth-mac-ecc";
+				reg = <0x108c1400 0x100>;
+				altr,ecc-parent = <&gmac2>;
+				interrupts = <9 IRQ_TYPE_LEVEL_HIGH>, <41 IRQ_TYPE_LEVEL_HIGH>;
+			};
+		};
+
 		rst: rstmgr@10d11000 {
 			compatible = "altr,stratix10-rst-mgr", "altr,rst-mgr";
 			reg = <0x10d11000 0x1000>;
-- 
2.42.0.411.g813d9a9188

Re: [PATCH 4/4] arm64: dts: socfpga: agilex5: add support for the ECC manager

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] Incorrect double-bit error (DBERR) interrupt index for `emac0-rx-ecc` causes interrupt collisions and probe failure.

Pre-existing issues:
- [High] The eccmgr IRQ mask and unmask functions fail for DBERR interrupts on 64-bit systems due to `BIT(hwirq)` truncation.
--

--- Patch [4]: [PATCH 4/4] arm64: dts: socfpga: agilex5: add support for the ECC manager ---
commit ee1cc5ec088dd853387503f3ab86c7b4f685d0e9
Author: Dinh Nguyen <dinguyen@kernel.org>
Subject: arm64: dts: socfpga: agilex5: add support for the ECC manager

This commit adds the EDAC device to the base Agilex5 platform. It also
adds OCRAM and Ethernet ECC device support to the device tree.

> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
> --- a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
[ ... ]
> +		eccmgr {
> +			compatible = "altr,socfpga-agilex5-ecc-manager",
> +				     "altr,socfpga-a10-ecc-manager";
[ ... ]
> +			ocram-ecc@108cc000 {
> +				compatible = "altr,socfpga-a10-ocram-ecc";
> +				reg = <0x108cc000 0x100>;
> +				interrupts = <1 IRQ_TYPE_LEVEL_HIGH>, <33 IRQ_TYPE_LEVEL_HIGH>;
> +			};

[Severity: High]
This is a pre-existing issue, but does routing double-bit error interrupts
like 33 through the eccmgr IRQ domain expose a truncation regression on
64-bit platforms?

Looking at a10_eccmgr_irq_mask() in drivers/edac/altera_edac.c:

a10_eccmgr_irq_mask() {
        ...
        regmap_write(edac->ecc_mgr_map, A10_SYSMGR_ECC_INTMASK_SET_OFST,
                     BIT(d->hwirq));
        ...
}

On ARM64, if d->hwirq is 33, BIT(33) produces a 64-bit value. Since
regmap_write() takes a 32-bit value parameter, won't this silently truncate
to 0?

The unmask variant has the same behavior, which means the generic IRQ
subsystem cannot mask or unmask these interrupts during an IRQ storm.

> +
> +			emac0-rx-ecc@108c0000 {
> +				compatible = "altr,socfpga-eth-mac-ecc";
> +				reg = <0x108c0000 0x100>;
> +				altr,ecc-parent = <&gmac0>;
> +				interrupts = <4 IRQ_TYPE_LEVEL_HIGH>, <38 IRQ_TYPE_LEVEL_HIGH>;
> +			};

[Severity: High]
Does emac0-rx-ecc claim the wrong double-bit error interrupt?

Since emac1-rx-ecc correctly claims interrupt 38 below, devm_request_irq()
will fail with -EBUSY when emac1-rx-ecc attempts to probe because the IRQ
is not shared.

If the single-bit error is 4, should the double-bit error be 36 instead of
38 to avoid this collision regression?

> +
> +			emac0-tx-ecc@108c0400 {
> +				compatible = "altr,socfpga-eth-mac-ecc";
> +				reg = <0x108c0400 0x100>;
> +				altr,ecc-parent = <&gmac0>;
> +				interrupts = <5 IRQ_TYPE_LEVEL_HIGH>, <37 IRQ_TYPE_LEVEL_HIGH>;
> +			};
> +
> +			emac1-rx-ecc@108c0800 {
> +				compatible = "altr,socfpga-eth-mac-ecc";
> +				reg = <0x108c0800 0x100>;
> +				altr,ecc-parent = <&gmac1>;
> +				interrupts = <6 IRQ_TYPE_LEVEL_HIGH>, <38 IRQ_TYPE_LEVEL_HIGH>;
> +			};
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720201425.1538771-1-dinguyen@kernel.org?part=4

Re: [PATCH 0/4] EDAC/altera: Add support for Agilex5 platform

[Borislav Petkov]

On Mon, Jul 20, 2026 at 03:14:21PM -0500, Dinh Nguyen wrote:
> This series add preliminary EDAC support for the Agilex5 platform.

So I'll be looking at new features to this driver only after all existing
Sashiko issues have been addressed.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette