| Message ID | 20260824-edac-v2-0-c8d8bb693586@aspeedtech.com |
|---|---|
| Headers | show |
| Series | Add Aspeed AST2700 SDRAM EDAC support | expand |
On Mon, Aug 24, 2026 at 10:42:27AM +0800, Ryan Chen wrote: > Add ECC error reporting for the Aspeed AST2700 SoC to the existing > aspeed_edac driver. > > The AST2700 memory controller keeps the same overall EDAC programming > model as the earlier Aspeed BMC SoCs, but uses a different register > layout, a split interrupt status/clear/mask scheme and DDR4/DDR5 memory. > Rather than fork the driver, the existing code is first tidied and > generalised, then the AST2700 is added as one more per-SoC variant. > > Patches 2-5 are bug fixes and cleanups to the existing driver. Patches 6 > and 7 rework the implementation to accommodate the AST2700. Patch 8 adds > the AST2700 support itself. Sashiko has comments: https://sashiko.dev/#/patchset/20260824-edac-v2-0-c8d8bb693586%40aspeedtech.com Please address them: if valid, fix them, if not, explain why they don't need to be fixed. Btw, I don't see Stefan reviewing this driver and his last mail on LKML is from 2025 so it looks like we'll orphan this driver too. Thx.
> Subject: Re: [PATCH v2 0/8] Add Aspeed AST2700 SDRAM EDAC support > > On Mon, Aug 24, 2026 at 10:42:27AM +0800, Ryan Chen wrote: > > Add ECC error reporting for the Aspeed AST2700 SoC to the existing > > aspeed_edac driver. > > > > The AST2700 memory controller keeps the same overall EDAC programming > > model as the earlier Aspeed BMC SoCs, but uses a different register > > layout, a split interrupt status/clear/mask scheme and DDR4/DDR5 memory. > > Rather than fork the driver, the existing code is first tidied and > > generalised, then the AST2700 is added as one more per-SoC variant. > > > > Patches 2-5 are bug fixes and cleanups to the existing driver. Patches > > 6 and 7 rework the implementation to accommodate the AST2700. Patch 8 > > adds the AST2700 support itself. > > Sashiko has comments: > > https://sashiko.dev/#/patchset/20260824-edac-v2-0-c8d8bb693586%40aspeed > tech.com > > Please address them: if valid, fix them, if not, explain why they don't need to > be fixed. > > Btw, I don't see Stefan reviewing this driver and his last mail on LKML is from > 2025 so it looks like we'll orphan this driver too. > > Thx. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette Hello Boris, Thanks your review. I've already replied to both of Sashiko's findings on their respective threads: 6/8: https://sashiko.dev/#/message/TY2PPF5CB9A1BE61E82EEE55F3F725362CCF2AD2%40TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com 8/8: https://sashiko.dev/#/message/TY2PPF5CB9A1BE62172BCC358347C4836CCF2AD2%40TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com Short version: neither needs a code change. On 8/8 the premise doesn't hold - u-boot masks every implemented DRAMC interrupt source (INT_MASK reads GENMASK(16, 0), bits 31:17 are not implemented), so no non-ECC source can raise the line and the spurious detector cannot kick in. On 6/8 no goto crosses the scoped_guard(), so the hazard cleanup.h describes cannot occur. Details are in the replies. On the maintainership: I'd be happy to take EDAC-AST2500 over if Stefan no longer has the time. I work on these SoCs at ASPEED, so I have the hardware and documentation for all four variants and I'm actively extending the driver.
On Tue, 2026-09-08 at 07:13 +0000, Ryan Chen wrote: > > > Subject: Re: [PATCH v2 0/8] Add Aspeed AST2700 SDRAM EDAC support > > > > On Mon, Aug 24, 2026 at 10:42:27AM +0800, Ryan Chen wrote: > > > Add ECC error reporting for the Aspeed AST2700 SoC to the existing > > > aspeed_edac driver. > > > > > > The AST2700 memory controller keeps the same overall EDAC programming > > > model as the earlier Aspeed BMC SoCs, but uses a different register > > > layout, a split interrupt status/clear/mask scheme and DDR4/DDR5 memory. > > > Rather than fork the driver, the existing code is first tidied and > > > generalised, then the AST2700 is added as one more per-SoC variant. > > > > > > Patches 2-5 are bug fixes and cleanups to the existing driver. Patches > > > 6 and 7 rework the implementation to accommodate the AST2700. Patch 8 > > > adds the AST2700 support itself. > > > > Sashiko has comments: > > > > https://sashiko.dev/#/patchset/20260824-edac-v2-0-c8d8bb693586%40aspeed > > tech.com > > > > Please address them: if valid, fix them, if not, explain why they don't need to > > be fixed. > > > > Btw, I don't see Stefan reviewing this driver and his last mail on LKML is from > > 2025 so it looks like we'll orphan this driver too. > > > > Thx. > > > > -- > > Regards/Gruss, > > Boris. > > > > https://people.kernel.org/tglx/notes-about-netiquette > > Hello Boris, > Thanks your review. > > I've already replied to both of Sashiko's findings on their respective > threads: > 6/8: https://sashiko.dev/#/message/TY2PPF5CB9A1BE61E82EEE55F3F725362CCF2AD2%40TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com > 8/8: https://sashiko.dev/#/message/TY2PPF5CB9A1BE62172BCC358347C4836CCF2AD2%40TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com > > Short version: neither needs a code change. On 8/8 the premise doesn't > hold - u-boot masks every implemented DRAMC interrupt source > (INT_MASK reads GENMASK(16, 0), bits 31:17 are not implemented), so no > non-ECC source can raise the line and the spurious detector cannot > kick in. I feel this is a fragile analysis given multiple components involved. I think it would be easier and safer (both in terms of kernel behaviour and guarding against change in u-boot behaviour) if we have the kernel driver take complete ownership of the interrupt configuration. Andrew
> Subject: Re: [PATCH v2 0/8] Add Aspeed AST2700 SDRAM EDAC support > > On Tue, 2026-09-08 at 07:13 +0000, Ryan Chen wrote: > > > > > Subject: Re: [PATCH v2 0/8] Add Aspeed AST2700 SDRAM EDAC support > > > > > > On Mon, Aug 24, 2026 at 10:42:27AM +0800, Ryan Chen wrote: > > > > Add ECC error reporting for the Aspeed AST2700 SoC to the existing > > > > aspeed_edac driver. > > > > > > > > The AST2700 memory controller keeps the same overall EDAC > > > > programming model as the earlier Aspeed BMC SoCs, but uses a > > > > different register layout, a split interrupt status/clear/mask scheme and > DDR4/DDR5 memory. > > > > Rather than fork the driver, the existing code is first tidied and > > > > generalised, then the AST2700 is added as one more per-SoC variant. > > > > > > > > Patches 2-5 are bug fixes and cleanups to the existing driver. > > > > Patches > > > > 6 and 7 rework the implementation to accommodate the AST2700. > > > > Patch 8 adds the AST2700 support itself. > > > > > > Sashiko has comments: > > > > > > https://sashiko.dev/#/patchset/20260824-edac-v2-0-c8d8bb693586%40asp > > > eed > > > tech.com > > > > > > Please address them: if valid, fix them, if not, explain why they > > > don't need to be fixed. > > > > > > Btw, I don't see Stefan reviewing this driver and his last mail on > > > LKML is from > > > 2025 so it looks like we'll orphan this driver too. > > > > > > Thx. > > > > > > -- > > > Regards/Gruss, > > > Boris. > > > > > > https://people.kernel.org/tglx/notes-about-netiquette > > > > Hello Boris, > > Thanks your review. > > > > I've already replied to both of Sashiko's findings on their respective > > threads: > > 6/8: > > > https://sashiko.dev/#/message/TY2PPF5CB9A1BE61E82EEE55F3F725362CCF2A > D2 > > %40TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com > > 8/8: > > > https://sashiko.dev/#/message/TY2PPF5CB9A1BE62172BCC358347C4836CCF2 > AD2 > > %40TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com > > > > Short version: neither needs a code change. On 8/8 the premise doesn't > > hold - u-boot masks every implemented DRAMC interrupt source (INT_MASK > > reads GENMASK(16, 0), bits 31:17 are not implemented), so no non-ECC > > source can raise the line and the spurious detector cannot kick in. > > I feel this is a fragile analysis given multiple components involved. I think it > would be easier and safer (both in terms of kernel behaviour and guarding > against change in u-boot behaviour) if we have the kernel driver take complete > ownership of the interrupt configuration. > Hello Andrew. Thanks your review. I will modify with following. #define AST2700_INT_ALL GENMASK(16, 0) static void ast2700_set_irq(struct aspeed_edac *priv, bool enable) { + u32 val = AST2700_INT_ALL; guard(raw_spinlock_irqsave)(&priv->lock); if (enable) val &= ~AST2700_INT_ECC; writel(val, priv->regs + AST2700_INT_MASK); } static int config_irq(struct mem_ctl_info *mci, struct platform_device *pdev) { ... + priv->chip->set_irq(priv, false); rc = devm_request_irq(&pdev->dev, irq, priv->chip->isr, IRQF_TRIGGER_HIGH, DRV_NAME, mci); if (rc) return rc; priv->irq = irq; /* enable interrupts */ priv->chip->set_irq(priv, true); return 0; }
Add ECC error reporting for the Aspeed AST2700 SoC to the existing aspeed_edac driver. The AST2700 memory controller keeps the same overall EDAC programming model as the earlier Aspeed BMC SoCs, but uses a different register layout, a split interrupt status/clear/mask scheme and DDR4/DDR5 memory. Rather than fork the driver, the existing code is first tidied and generalised, then the AST2700 is added as one more per-SoC variant. Patches 2-5 are bug fixes and cleanups to the existing driver. Patches 6 and 7 rework the implementation to accommodate the AST2700. Patch 8 adds the AST2700 support itself. Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com> --- Changes in v2: - New patch: free the ECC interrupt before the mem_ctl_info in aspeed_remove(). The interrupt is requested with devm_request_irq() and is only released after .remove() has returned, so edac_mc_free() could free the handler's context while the handler was still running on another CPU. - Acquire the register lock with the irqsave variant in init_csrows() and in aspeed_probe(). The interrupt handler takes the same lock in hardirq context, so taking it with interrupts enabled would have tripped lockdep on the first reported error. - Move the dev_dbg() of the interrupt status register out of the raw_spinlock critical section in the interrupt handler. - Opt aspeed_edac.o into context analysis in drivers/edac/Makefile. The check is opt-in per object, so without it the __guarded_by() annotation added by the same patch was never actually verified. - Return IRQ_NONE from ast2700_dramc_isr() when no ECC interrupt status bit is set; the handler clears only the ECC bits, so unconditionally claiming the interrupt could livelock the level-triggered line. - Tested v2 on both AST2600 and AST2700 by injecting a correctable error with the memory controller's ECC error injection; each is reported as a CE with the expected failure address. - Link to v1: https://lore.kernel.org/r/20260812-edac-v1-0-03992edea297@aspeedtech.com --- Ryan Chen (8): dt-bindings: edac: aspeed: Add AST2700 SDRAM EDAC EDAC/aspeed: Set the DIMM grain EDAC/aspeed: Free the interrupt before the mem_ctl_info on remove EDAC/aspeed: Clean up whitespace and include ordering EDAC/aspeed: Free the mem_ctl_info unconditionally on remove EDAC/aspeed: Replace regmap with direct register access EDAC/aspeed: Abstract SoC differences behind chip data EDAC/aspeed: Add AST2700 support .../bindings/edac/aspeed,ast2400-sdram-edac.yaml | 6 +- drivers/edac/Makefile | 1 + drivers/edac/aspeed_edac.c | 426 ++++++++++++++------- 3 files changed, 284 insertions(+), 149 deletions(-) --- base-commit: 5464985e42c04e335fb30e38fbc409c997db9bec change-id: 20260625-edac-8e960e02e7f7 Best regards,