linux-toradex.git/drivers/edac/i10nm_base.c, branch v7.0-rc2

EDAC/{skx_common,skx,i10nm}: Make skx_register_mci() independent of pci_dev

2025-11-19T20:11:40+00:00

Memory controllers in the new Intel server CPUs, such as Diamond Rapids,
are presented as MMIO-based devices rather than PCI devices.
Modify skx_register_mci() to be independent of 'pci_dev' and use a generic
'dev' of 'struct device' to prepare for support of such MMIO-based memory
controllers.

Tested-by: Yi Lai 
Signed-off-by: Qiuxu Zhuo 
Signed-off-by: Tony Luck 
Link: https://patch.msgid.link/20251119134132.2389472-2-qiuxu.zhuo@intel.com

EDAC/i10nm: Reallocate skx_dev list if preconfigured cnt != runtime cnt

2025-08-19T23:24:57+00:00

Ideally, read the present DDR memory controller count first and then
allocate the skx_dev list using this count. However, this approach
requires adding a significant amount of code similar to
skx_get_all_bus_mappings() to obtain the PCI bus mappings for the first
socket and use these mappings along with the related PCI register offset
to read the memory controller count.

Given that the Granite Rapids CPU is the only one that can detect the
count of memory controllers at runtime (other CPUs use the count in the
configuration data), to reduce code complexity, reallocate the skx_dev
list only if the preconfigured count of DDR memory controllers differs
from the count read at runtime for Granite Rapids CPU.

Signed-off-by: Qiuxu Zhuo 
Signed-off-by: Tony Luck 
Link: https://lore.kernel.org/r/20250731145534.2759334-7-qiuxu.zhuo@intel.com

EDAC/i10nm: Skip DIMM enumeration on a disabled memory controller

2025-08-19T23:18:14+00:00

When loading the i10nm_edac driver on some Intel Granite Rapids servers,
a call trace may appear as follows:

  UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16
  shift exponent -66 is negative
  ...
  __ubsan_handle_shift_out_of_bounds+0x1e3/0x390
  skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common]
  i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac]
  skx_register_mci+0x159/0x220 [skx_edac_common]
  i10nm_init+0xcb0/0x1ff0 [i10nm_edac]
  ...

This occurs because some BIOS may disable a memory controller if there
aren't any memory DIMMs populated on this memory controller. The DIMMMTR
register of this disabled memory controller contains the invalid value
~0, resulting in the call trace above.

Fix this call trace by skipping DIMM enumeration on a disabled memory
controller.

Fixes: ba987eaaabf9 ("EDAC/i10nm: Add Intel Granite Rapids server support")
Reported-by: Jose Jesus Ambriz Meza 
Reported-by: Chia-Lin Kao (AceLan) 
Closes: https://lore.kernel.org/all/20250730063155.2612379-1-acelan.kao@canonical.com/
Signed-off-by: Qiuxu Zhuo 
Signed-off-by: Tony Luck 
Tested-by: Chia-Lin Kao (AceLan) 
Link: https://lore.kernel.org/r/20250806065707.3533345-1-qiuxu.zhuo@intel.com

EDAC/{skx_common,i10nm}: Use scnprintf() for safer buffer handling

2025-07-15T17:06:58+00:00

snprintf() is fragile when its return value will be used to append
additional data to a buffer. Use scnprintf() instead.

Signed-off-by: Wang Haoran 
Signed-off-by: Tony Luck 
Tested-by: Qiuxu Zhuo 
Reviewed-by: Qiuxu Zhuo 
Link: https://lore.kernel.org/r/20250715131700.1092720-1-haoranwangsec@gmail.com

EDAC/i10nm: Add Intel Granite Rapids-D support

2025-07-07T17:50:29+00:00

The Granite Rapids-D CPU model uses memory controller registers similar
to those of the Granite Rapids server CPU but with a different memory
controller MMIO base.

Add the Granite Rapids-D CPU model ID and use the new memory controller
MMIO base for EDAC support.

Signed-off-by: Qiuxu Zhuo 
Signed-off-by: Tony Luck 
Tested-by: VikasX Chougule 
Link: https://lore.kernel.org/r/20250704151609.7833-2-qiuxu.zhuo@intel.com

EDAC/i10nm: Fix the bitwise operation between variables of different sizes

2025-04-24T15:42:25+00:00

The tool of Smatch static checker reported the following warning:

  drivers/edac/i10nm_base.c:364 show_retry_rd_err_log()
  warn: should bitwise negate be 'ullong'?

This warning was due to the bitwise NOT/AND operations between
'status_mask' (a u32 type) and 'log' (a u64 type), which resulted in
the high 32 bits of 'log' were cleared.

This was a false positive warning, as only the low 32 bits of 'log' was
written to the first RRL memory controller register (a u32 type).

To improve code sanity, fix this warning by changing 'status_mask' to
a u64 type, ensuring it matches the size of 'log' for bitwise operations.

Reported-by: Dan Carpenter 
Closes: https://lore.kernel.org/all/aAih0KmEVq7ch6v2@stanley.mountain/
Signed-off-by: Qiuxu Zhuo 
Signed-off-by: Tony Luck 
Link: https://lore.kernel.org/r/20250424081454.2952632-1-qiuxu.zhuo@intel.com

EDAC/{skx_common,i10nm}: Add RRL support for Intel Granite Rapids server

2025-04-17T17:45:21+00:00

Compared to previous generations, Granite Rapids defines the RRL control
bits {en_patspr, noover, en} in different positions, adds an extra RRL set
for the new mode of the first patrol-scrub read error, and extends the
number of CORRERRCNT registers from 4 to 8, encoding one counter per
CORRERRCNT register.

Add a Granite Rapids reg_rrl configuration table and adjust the code to
accommodate the differences mentioned above for RRL support.

Signed-off-by: Qiuxu Zhuo 
Signed-off-by: Tony Luck 
Tested-by: Feng Xu 
Link: https://lore.kernel.org/r/20250417150724.1170168-8-qiuxu.zhuo@intel.com

EDAC/{skx_common,i10nm}: Refactor show_retry_rd_err_log()

2025-04-17T17:33:37+00:00

Make the {valid bit, overwritten status, number} of RRL registers and the
{number, offsets, widths} of per-channel CORRERRCNT registers configurable.
Refactor show_retry_rd_err_log() to use the configurable fields of struct
reg_rrl, making the code more scalable and simpler.

No functional changes intended.

Signed-off-by: Qiuxu Zhuo 
Signed-off-by: Tony Luck 
Tested-by: Feng Xu 
Link: https://lore.kernel.org/r/20250417150724.1170168-7-qiuxu.zhuo@intel.com

EDAC/{skx_common,i10nm}: Refactor enable_retry_rd_err_log()

2025-04-17T17:31:09+00:00

Refactor enable_retry_rd_err_log() using helper functions for both
DDR and HBM, making the RRL control bits configurable instead of
hard-coded. Additionally, explicitly define the four RRL modes for
better readability.

No functional changes intended.

Signed-off-by: Qiuxu Zhuo 
Signed-off-by: Tony Luck 
Tested-by: Feng Xu 
Link: https://lore.kernel.org/r/20250417150724.1170168-6-qiuxu.zhuo@intel.com

EDAC/{skx_common,i10nm}: Structure the per-channel RRL registers

2025-04-17T17:28:09+00:00

As the number of RRL (retry_rd_err_log) registers per memory channel
increases, the positions of the RRL control bits and the widths of the
RRL registers vary across different CPU generations. Adding RRL support
for a new CPU requires handling these differences throughout the
RRL-related code.

Structure the offsets, widths, control bit positions, set numbers, modes,
etc., of the per-channel RRL registers and make them configurable to
facilitate easier RRL support for new CPUs.

No functional changes are intended.

Signed-off-by: Qiuxu Zhuo 
Signed-off-by: Tony Luck 
Tested-by: Feng Xu 
Link: https://lore.kernel.org/r/20250417150724.1170168-5-qiuxu.zhuo@intel.com