linux/drivers/edac, branch v6.17

EDAC/altera: Delete an inappropriate dma_free_coherent() call

2025-08-25T11:56:16Z

dma_free_coherent() must only be called if the corresponding dma_alloc_coherent() call has succeeded. Calling it when the allocation fails leads to undefined behavior. Delete the wrong call. [ bp: Massage commit message. ] Fixes: 71bcada88b0f3 ("edac: altera: Add Altera SDRAM EDAC support") Signed-off-by: Salah Triki Signed-off-by: Borislav Petkov (AMD) Acked-by: Dinh Nguyen Cc: stable@vger.kernel.org Link: https://lore.kernel.org/aIrfzzqh4IzYtDVC@pc

Merge tag 'edac_updates_for_v6.17_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras

2025-07-29T23:30:38Z

Pull EDAC updates from Borislav Petkov: - i10nm: - switch to using scnprintf() - Add Granite Rapids-D support - synopsys: Make sure ECC error and counter registers are cleared during init/probing to avoid reporting stale errors - igen6: Add Wildcat Lake SoCs support - Make sure scrub features sysfs attributes are initialized properly - Allocate memory repair sysfs attributes statically to reduce stack usage - Fix DIMM module size computation for DIMMs with total capacity which is a non power-of-two number, in amd64_edac - Do not be too dramatic when reporting disabled memory controllers in igen6_edac - Add support to ie31200_edac for the following SoCs: - Core i5-14[67]00 - Bartless Lake-S SoCs - Raptor Lake-HX * tag 'edac_updates_for_v6.17_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: EDAC/{skx_common,i10nm}: Use scnprintf() for safer buffer handling EDAC/synopsys: Clear the ECC counters on init EDAC/ie31200: Add Intel Raptor Lake-HX SoCs support EDAC/igen6: Add Intel Wildcat Lake SoCs support EDAC/i10nm: Add Intel Granite Rapids-D support EDAC/mem_repair: Reduce stack usage in edac_mem_repair_get_desc() EDAC/igen6: Reduce log level to debug for absent memory controllers EDAC/ie31200: Document which CPUs correspond to each Raptor Lake-S device ID EDAC/ie31200: Enable support for Core i5-14600 and i7-14700 ie31200/EDAC: Add Intel Bartlett Lake-S SoCs support

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

2025-07-15T17:06:58Z

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/synopsys: Clear the ECC counters on init

2025-07-14T10:15:37Z

Clear the ECC error and counter registers during initialization/probe to avoid reporting stale errors that may have occurred before EDAC registration. For that, unify the Zynq and ZynqMP ECC state reading paths and simplify the code. [ bp: Massage commit message. Fix an -Wsometimes-uninitialized warning as reported by Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202507141048.obUv3ZUm-lkp@intel.com ] Signed-off-by: Shubhrajyoti Datta Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/20250713050753.7042-1-shubhrajyoti.datta@amd.com

EDAC/ie31200: Add Intel Raptor Lake-HX SoCs support

2025-07-07T17:53:47Z

Intel Raptor Lake-HX SoC shares the same memory controller registers as Raptor Lake-S SoC. Add a compute die ID for Raptor Lake-HX SoCs with Out-of-Band ECC capability for EDAC support. Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Tested-by: Laurens SEGHERS Link: https://lore.kernel.org/r/20250704151609.7833-4-qiuxu.zhuo@intel.com

EDAC/igen6: Add Intel Wildcat Lake SoCs support

2025-07-07T17:51:58Z

Intel Wildcat Lake is a mobile derivative of Panther Lake with one memory controller. Wildcat Lake SoCs share the same IBECC registers with Meteor Lake-P SoCs. Add a compute die ID and a new configuration structure for Wildcat Lake SoCs with In-Band ECC capability for EDAC support. Signed-off-by: Lili Li Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Link: https://lore.kernel.org/r/20250704151609.7833-3-qiuxu.zhuo@intel.com

EDAC/i10nm: Add Intel Granite Rapids-D support

2025-07-07T17:50:29Z

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: Initialize EDAC features sysfs attributes

2025-06-30T08:57:24Z

Fix the lockdep splat caused by missing sysfs_attr_init() calls for the recently added EDAC feature's sysfs attributes. In lockdep_init_map_type(), the check for the lock-class key if (!static_obj(key) && !is_dynamic_key(key)) causes the splat. Backtrace: RIP: 0010:lockdep_init_map_type Call Trace: __kernfs_create_file sysfs_add_file_mode_ns internal_create_group internal_create_groups device_add ? __init_waitqueue_head edac_dev_register devm_cxl_memdev_edac_register ? lock_acquire ? find_held_lock ? cxl_mem_probe ? cxl_mem_probe ? lockdep_hardirqs_on ? cxl_mem_probe cxl_mem_probe [ bp: Massage. ] Fixes: f90b738166fe ("EDAC: Add scrub control feature") Fixes: bcbd069b11b0 ("EDAC: Add a Error Check Scrub control feature") Fixes: 699ea5219c4b ("EDAC: Add a memory repair control feature") Reported-by: Dave Jiang Suggested-by: Jonathan Cameron Signed-off-by: Shiju Jose Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Jonathan Cameron Link: https://lore.kernel.org/20250626101344.1726-1-shiju.jose@huawei.com

EDAC/mem_repair: Reduce stack usage in edac_mem_repair_get_desc()

2025-06-26T14:18:41Z

Constructing an array on the stack adds complexity and can exceed the warning limit for per-function stack usage: drivers/edac/mem_repair.c:361:5: error: stack frame size (1296) exceeds limit (1280) in 'edac_mem_repair_get_desc' [-Werror,-Wframe-larger-than] Change this to have the actual attribute array allocated statically and then just add the instance number on the per-instance copy. Fixes: 699ea5219c4b ("EDAC: Add a memory repair control feature") Signed-off-by: Arnd Bergmann Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/20250620114135.4017183-1-arnd@kernel.org

EDAC/amd64: Fix size calculation for Non-Power-of-Two DIMMs

2025-06-25T14:40:03Z

Each Chip-Select (CS) of a Unified Memory Controller (UMC) on AMD Zen-based SOCs has an Address Mask and a Secondary Address Mask register associated with it. The amd64_edac module logs DIMM sizes on a per-UMC per-CS granularity during init using these two registers. Currently, the module primarily considers only the Address Mask register for computing DIMM sizes. The Secondary Address Mask register is only considered for odd CS. Additionally, if it has been considered, the Address Mask register is ignored altogether for that CS. For power-of-two DIMMs i.e. DIMMs whose total capacity is a power of two (32GB, 64GB, etc), this is not an issue since only the Address Mask register is used. For non-power-of-two DIMMs i.e., DIMMs whose total capacity is not a power of two (48GB, 96GB, etc), however, the Secondary Address Mask register is used in conjunction with the Address Mask register. However, since the module only considers either of the two registers for a CS, the size computed by the module is incorrect. The Secondary Address Mask register is not considered for even CS, and the Address Mask register is not considered for odd CS. Introduce a new helper function so that both Address Mask and Secondary Address Mask registers are considered, when valid, for computing DIMM sizes. Furthermore, also rename some variables for greater clarity. Fixes: 81f5090db843 ("EDAC/amd64: Support asymmetric dual-rank DIMMs") Closes: https://lore.kernel.org/dbec22b6-00f2-498b-b70d-ab6f8a5ec87e@natrix.lt Reported-by: Žilvinas Žaltiena Signed-off-by: Avadhut Naik Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Yazen Ghannam Tested-by: Žilvinas Žaltiena Cc: stable@vger.kernel.org Link: https://lore.kernel.org/20250529205013.403450-1-avadhut.naik@amd.com