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

Hi,

I have Arrow Lake-HX hardware running sideband (80-bit) DDR5 ECC SODIMMs
and wanted EDAC error reporting for it. As of current mainline no driver
matches this die: igen6_edac covers the in-band-ECC Arrow Lake-U/H compute
dies (0x7d06/0x7d20/0x7d30), and ie31200_edac (which gained Raptor Lake-S,
Raptor Lake-HX and Bartlett Lake-S support recently) has no 7dxx IDs.

I wrote an out-of-tree driver derived from ie31200_edac and it works on my
machine - both IMCs register, DIMM topology decodes exactly, counters are
live, clean load/unload:

  https://github.com/zs311521/edac-arl-hx

Hardware:
- Intel Core Ultra 9 285HX (Arrow Lake-HX), stepping 2, microcode 0x11b,
  host bridge 00:00.0 = 8086:7d1c rev 01 (Minisforum MS-02)
- 2x SK hynix HMCG88AGBAA095N 32GB DDR5-5600 ECC SODIMM (2Rx8, one per IMC)
- BIOS reports Single-bit ECC active; MCHBAR = 0xfedc0000

Findings, in case they are useful:
- The register layout matches rpl_s_cfg for topology and error-log offsets.
  I validated from userspace before loading anything: MAD_DIMM at
  MCHBAR+0xd80c/+0xd810 decodes the physical population exactly (16 GiB,
  2 ranks, x8 per subchannel), ECCERRLOG at +0xe048/+0xe848, two IMC
  windows at BIT(16) stride.
- I deliberately did NOT reuse the MSR 0x791 error-log clear: the public
  EDC documentation for this family (doc 835538) describes clearing via
  PCI ERRSTS instead, and I could not verify the MSR's semantics on this
  die, so my module defaults to a no-write polling mode with
  report-on-change latching.
- Channel count is derived from MAD_DIMM population rather than CAPID0.
- My BIOS exposes no ACPI EINJ table, so I have not been able to exercise
  a real corrected error end to end.

Questions, so this can become a proper mainline patch (which I am happy to
write and submit as a dedicated cfg in ie31200_edac if you can confirm):

1. Is MSR 0x791 valid with the same semantics on ARL-HX, or should the
   error-log clear go through ERRSTS (or something else) on this die?
2. Is corrected-error CMCI delivery confirmed for ARL-HX out-of-band ECC,
   i.e. is .cmci = true correct here?
3. Should ARL-HX reuse rpl_s_cfg or get a dedicated cfg? The rank/width
   field widths in the ARL documentation look narrower than rpl_s_cfg's
   masks.

I can test patches on this machine and provide Tested-by.

Thanks,
Zura