RE: [PATCH v2 0/8] Add Aspeed AST2700 SDRAM EDAC support

[Ryan Chen]

> 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.