RE: EDAC support for Arrow Lake-HX (8086:7d1c) - working out-of-tree driver, test hardware available

Emba Consulting <[email protected]> Mon, 13 Jul 2026 03:52:08 +0000
Newsgroups org.kernel.vger.linux-edac
Message-ID <SY9PR01MB10852E9F6484A7DDBF3E8D898A9FA2@SY9PR01MB10852.ausprd01.prod.outlook.com>
> What does your BIOS tell you about the ECC type: In-Band ECC or
> Out-of-Band ECC?

Out-of-Band. The populated DIMMs are physical 80-bit modules and the
BIOS reports ECC present (SMBIOS; consistent with out-of-band):

  dmidecode type 16: Error Correction Type: Single-bit ECC
  dmidecode type 17: Total Width: 80 bits / Data Width: 64 bits
                     (both DIMMs: SK hynix HMCG88AGBAA095N,
                      32 GiB DDR5-5600 ECC SODIMM, 2Rx8)

Register-level behaviour is consistent with the out-of-band /
ie31200-style design: on this die the rpl_s_cfg-family registers are
implemented and decode correctly against the physical population -
ECCERRLOG0/1 at MCHBAR+0xE048/0xE848 read as zero (no CE/UE observed
yet), MAD_DIMM_CH0/CH1 at 0xD80C/0xD810 decode to 16 GiB / 2-rank per
DDR5 subchannel (one 32 GiB 2Rx8 DIMM per controller), and the CAPID0
ECC bit reads ECC-capable. igen6_edac (in-band) has no 7d1c ID and
correctly never binds on this system.

Given that, would you take a patch adding 7d1c to ie31200_edac? The
open question from my first mail is whether rpl_s_cfg can be reused
as-is: its error-status clear is wrmsr_safe(0x791), while the public
EDC register documentation for this family (doc 835538) describes
clearing via PCI ERRSTS - if 0x791 isn't valid on this die it would
need a dedicated cfg. Happy to build and test either variant on this
machine and report back.

Thanks.