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

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Medium] Bitwise overflow and value truncation when unmasking double-bit error (DBE) interrupts.
--

commit a5d17bd160094d90efa7211d9c744f1d3da55629
Author: Dinh Nguyen <dinguyen@kernel.org>
Subject: arm64: dts: socfpga: agilex5: add support for the ECC manager

This commit adds the EDAC device and ECC manager nodes to the base Agilex5
platform. It introduces 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
> index b06c6d5d60eed..64e8bffd69df7 100644
> --- 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";
> +		altr,sysmgr-syscon = <&sysmgr>;
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		interrupt-parent = <&intc>;
> +		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 = <0 0 0 0xffffffff>;
> +
> +		ocram-ecc@108cc000 {
> +			compatible = "altr,socfpga-a10-ocram-ecc";
> +			reg = <0x108cc000 0x100>;
> +			interrupts = <1 IRQ_TYPE_LEVEL_HIGH>, <33 IRQ_TYPE_LEVEL_HIGH>;
> +		};

[Severity: Medium]
This is a pre-existing issue, but introducing interrupts with values >= 32
triggers a bitwise overflow and truncation bug in the altera_edac driver.

When the EDAC driver sets up DBE interrupts, it calls a10_eccmgr_irq_unmask()
with hwirq >= 32. The BIT(d->hwirq) macro computes 1UL << 33 (and up to 41
for the emac nodes).

drivers/edac/altera_edac.c:a10_eccmgr_irq_unmask() {
    ...
    regmap_write(edac->ecc_mgr_map, A10_SYSMGR_ECC_INTMASK_CLR_OFST,
                 BIT(d->hwirq));
    ...
}

Does this shift result in undefined behavior or truncation? On 64-bit
systems, this yields a 64-bit value which is silently truncated to 0 when
passed to regmap_write()'s 32-bit val parameter. On 32-bit systems, this
shift exceeds the width of unsigned long, typically yielding 0 at runtime.

The masking function a10_eccmgr_irq_mask() shares the exact same bitwise
overflow and truncation issue:

drivers/edac/altera_edac.c:a10_eccmgr_irq_mask() {
    ...
    regmap_write(edac->ecc_mgr_map, A10_SYSMGR_ECC_INTMASK_SET_OFST,
                 BIT(d->hwirq));
    ...
}

While the DBE interrupts may inadvertently remain unmasked because they
share the same hardware mask bit as single-bit errors, the specific
masking logic for DBE appears to fail because the computed mask evaluates
to 0.

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