kernel/linux.git/drivers/edac/amd64_edac.c, branch linux-7.1.y

EDAC/amd64: Add support for family 19h, models 40h-4fh

2026-03-19T18:03:25+00:00

Add support for Ryzen 6000 Zen3-based CPUs in the V3000 AMD Embedded SoC platform which uses ECC memory and would need RAS handling of hardware errors. Co-developed-by: Ramesh Garidapuri Signed-off-by: Ramesh Garidapuri Signed-off-by: Devang Vyas Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Yazen Ghannam Link: https://patch.msgid.link/20260317183453.3556588-1-devangnayanbhai.vyas@amd.com

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

EDAC/amd64: Avoid a -Wformat-security warning

2025-12-30T16:27:11+00:00

Using a variable as a format string causes a (default-disabled) warning: drivers/edac/amd64_edac.c: In function 'per_family_init': drivers/edac/amd64_edac.c:3914:17: error: format not a string literal and no format arguments [-Werror=format-security] 3914 | scnprintf(pvt->ctl_name, sizeof(pvt->ctl_name), tmp_name); | ^~~~~~~~~ The code here is safe, but in order to enable the warning by default in the future, change this instance to pass the name indirectly. Fixes: e9abd990aefd ("EDAC/amd64: Generate ctl_name string at runtime") Signed-off-by: Arnd Bergmann Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Avadhut Naik Reviewed-by: Qiuxu Zhuo Reviewed-by: Yazen Ghannam Link: https://patch.msgid.link/20251204100231.1034557-1-arnd@kernel.org

EDAC/amd64: Remove NUM_CONTROLLERS macro

2025-11-06T11:51:33+00:00

Currently, the NUM_CONTROLLERS macro is used to limit the amount of memory controllers (UMCs) available per node. The number of UMCs available per node, however, is already cached by the max_mcs variable of struct amd64_pvt. Allocate the relevant data structures dynamically using the variable instead of static allocation through the macro. The max_mcs variable is used for legacy systems too. These systems have a max of 2 controllers. Since the default value of max_mcs, set in per_family_init(), is 2, these legacy systems are also covered. Signed-off-by: Avadhut Naik Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/20251106015727.1987246-1-avadhut.naik@amd.com

EDAC/amd64: Generate ctl_name string at runtime

2025-11-06T11:35:59+00:00

Currently, the ctl_name string is statically assigned based on the family and model of the SOC when the amd64_edac module is loaded. The same, however, is not exactly needed as the string can be generated and assigned at runtime through scnprintf(). Remove all static assignments and generate the string at runtime. Also, cleanup the switch cases which became defunct and consolidate identical cases. Signed-off-by: Avadhut Naik Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/20251106015727.1987246-1-avadhut.naik@amd.com

EDAC/amd64: Add support for AMD family 1Ah-based newer models

2025-09-17T09:53:54+00:00

Add support for family 1Ah-based models 50h-57h, 90h-9Fh, A0h-AFh, and C0h-C7h. Also, raise the maximum memory controllers number as those machines support that many. Signed-off-by: Avadhut Naik Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/20250916203242.1281036-1-avadhut.naik@amd.com

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

2025-06-25T14:40:03+00:00

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

EDAC/amd64: Correct number of UMCs for family 19h models 70h-7fh

2025-06-16T21:11:14+00:00

AMD's Family 19h-based Models 70h-7fh support 4 unified memory controllers (UMC) per processor die. The amd64_edac driver, however, assumes only 2 UMCs are supported since max_mcs variable for the models has not been explicitly set to 4. The same results in incomplete or incorrect memory information being logged to dmesg by the module during initialization in some instances. Fixes: 6c79e42169fe ("EDAC/amd64: Add support for ECC on family 19h model 60h-7Fh") Closes: https://lore.kernel.org/all/27dc093f-ce27-4c71-9e81-786150a040b6@reox.at/ Reported-by: reox Signed-off-by: Avadhut Naik Signed-off-by: Borislav Petkov (AMD) Cc: stable@kernel.org Link: https://lore.kernel.org/20250613005233.2330627-1-avadhut.naik@amd.com

Merge branch 'x86/msr' into x86/core, to resolve conflicts

2025-05-13T08:42:06+00:00

Conflicts: arch/x86/boot/startup/sme.c arch/x86/coco/sev/core.c arch/x86/kernel/fpu/core.c arch/x86/kernel/fpu/xstate.c Semantic conflict: arch/x86/include/asm/sev-internal.h Signed-off-by: Ingo Molnar