linux-toradex.git/drivers/edac/amd64_edac.h, branch v7.0-rc2

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: Remove unused register accesses

2024-06-12T09:33:45+00:00

A number of UMC registers are read only for the purpose of debug printing. They
are not used in any calculations. Nor do they have any specific debug value.

Remove them.

Signed-off-by: Yazen Ghannam 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Mario Limonciello 
Link: https://lore.kernel.org/r/20240606-fix-smn-bad-read-v4-1-ffde21931c3f@amd.com

EDAC/amd64: Remove unused struct member amd64_pvt::ext_nbcfg

2024-03-27T17:26:57+00:00

Commit

  cfe40fdb4a46 ("amd64_edac: add driver header")

added amd64_pvt struct with ext_nbcfg in it. But no one used that member
since then.

Therefore, remove it.

Found by https://github.com/jirislaby/clang-struct.

Signed-off-by: Jiri Slaby (SUSE) 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Yazen Ghannam 
Link: https://lore.kernel.org/r/20240213112051.27715-2-jirislaby@kernel.org
Signed-off-by: Borislav Petkov (AMD)

EDAC/amd64: Add support for family 0x19, models 0x90-9f devices

2023-11-29T10:21:05+00:00

AMD Models 90h-9fh are APUs. They have built-in HBM3 memory. ECC support
is enabled by default.

APU models have a single Data Fabric (DF) per Package. Each DF is
visible to the OS in the same way as chiplet-based systems like Zen2
CPUs and later. However, the Unified Memory Controllers (UMCs) are
arranged in the same way as GPU-based MI200 devices rather than
CPU-based systems.

Use the existing gpu_ops for hetergeneous systems to support enumeration
of nodes and memory topology with few fixups.

  [ bp: Massage comments. ]

Signed-off-by: Muralidhara M K 
Signed-off-by: Borislav Petkov (AMD) 
Link: https://lore.kernel.org/r/20231102114225.2006878-5-muralimk@amd.com

Merge tag 'ras_core_for_v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2023-06-26T22:09:18+00:00

Pull RAS updates from Borislav Petkov:

 - Add initial support for RAS hardware found on AMD server GPUs (MI200).

   Those GPUs and CPUs are connected together through the coherent
   fabric and the GPU memory controllers report errors through x86's MCA
   so EDAC needs to support them. The amd64_edac driver supports now HBM
   (High Bandwidth Memory) and thus such heterogeneous memory controller
   systems

 - Other small cleanups and improvements

* tag 'ras_core_for_v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  EDAC/amd64: Cache and use GPU node map
  EDAC/amd64: Add support for AMD heterogeneous Family 19h Model 30h-3Fh
  EDAC/amd64: Document heterogeneous system enumeration
  x86/MCE/AMD, EDAC/mce_amd: Decode UMC_V2 ECC errors
  x86/amd_nb: Re-sort and re-indent PCI defines
  x86/amd_nb: Add MI200 PCI IDs
  ras/debugfs: Fix error checking for debugfs_create_dir()
  x86/MCE: Check a hw error's address to determine proper recovery action

EDAC/amd64: Cache and use GPU node map

2023-06-19T11:01:44+00:00

AMD systems have historically provided an "AMD Node ID" that is a unique
identifier for each die in a multi-die package. This was associated with
a unique instance of the AMD Northbridge on a legacy system. And now it
is associated with a unique instance of the AMD Data Fabric on modern
systems. Each instance is referred to as a "Node"; this is an
AMD-specific term not to be confused with NUMA nodes.

The data fabric provides a number of interfaces accessible through a set
of functions in a single PCI device. There is one PCI device per Data
Fabric (AMD Node), and multi-die systems will see multiple such PCI
devices. The AMD Node ID matches a Node's position in the PCI hierarchy.
For example, the Node 0 is accessed using the first PCI device, Node 1
is accessed using the second, and so on. A logical CPU can find its AMD
Node ID using CPUID. Furthermore, the AMD Node ID is used within the
hardware fabric, so it is not purely a logical value.

Heterogeneous AMD systems, with a CPU Data Fabric connected to GPU data
fabrics, follow a similar convention. Each CPU and GPU die has a unique
AMD Node ID value, and each Node ID corresponds to PCI devices in
sequential order.

However, there are two caveats:
1) GPUs are not x86, and they don't have CPUID to read their AMD Node ID
like on CPUs. This means the value is more implicit and based on PCI
enumeration and hardware-specifics.
2) There is a gap in the hardware values for AMD Node IDs. Values 0-7
are for CPUs and values 8-15 are for GPUs.

For example, a system with one CPU die and two GPUs dies will have the
following values:
  CPU0 -> AMD Node 0
  GPU0 -> AMD Node 8
  GPU1 -> AMD Node 9

EDAC is the only subsystem where this has a practical effect. Memory
errors on AMD systems are commonly reported through MCA to a CPU on the
local AMD Node. The error information is passed along to EDAC where the
AMD EDAC modules use the AMD Node ID of reporting logical CPU to access
AMD Node information.

However, memory errors from a GPU die will be reported to the CPU die.
Therefore, the logical CPU's AMD Node ID can't be used since it won't
match the AMD Node ID of the GPU die. The AMD Node ID of the GPU die is
provided as part of the MCA information, and the value will match the
hardware enumeration (e.g. 8-15).

Handle this situation by discovering GPU dies the same way as CPU dies
in the AMD NB code. But do a "node id" fixup in AMD64 EDAC where it's
needed.

The GPU data fabrics provide a register with the base AMD Node ID for
their local "type", i.e. GPU data fabric. This value is the same for all
fabrics of the same type in a system.

Read and cache the base AMD Node ID from one of the GPU devices during
module initialization. Use this to fixup the "node id" when reporting
memory errors at runtime.

  [ bp: Squash a fix making gpu_node_map static as reported by
        Tom Rix .
    Link: https://lore.kernel.org/r/20230610210930.174074-1-trix@redhat.com ]

Signed-off-by: Yazen Ghannam 
Co-developed-by: Muralidhara M K 
Signed-off-by: Muralidhara M K 
Signed-off-by: Borislav Petkov (AMD) 
Link: https://lore.kernel.org/r/20230515113537.1052146-6-muralimk@amd.com

EDAC/amd64: Remove module version string

2023-05-10T13:49:52+00:00

The AMD64 EDAC module version information is not exposed through ABI
like MODULE_VERSION(). Instead it is printed during module init.

Version numbers can be confusing in cases where module updates are
partly backported resulting in a difference between upstream and
backported module versions.

Remove the AMD64 EDAC module version information to avoid user
confusion.

Signed-off-by: Yazen Ghannam 
Signed-off-by: Borislav Petkov (AMD) 
Link: https://lore.kernel.org/r/20230410190959.3367528-1-yazen.ghannam@amd.com

EDAC/amd64: Add get_err_info() to pvt->ops

2023-03-24T12:03:21+00:00

GPU Nodes will use a different method to determine the chip select
and channel of an error. A function pointer should be used rather than
introduce another branching condition.

Prepare for this by adding get_err_info() to pvt->ops. This function is
only called from the modern code path, so a legacy function is not
defined.

Make sure to call this after MCA_STATUS[SyndV] is checked, since the
csrow value is found in MCA_SYND.

  [ Yazen: rebased/reworked patch and reworded commit message. ]

Signed-off-by: Muralidhara M K 
Co-developed-by: Naveen Krishna Chatradhi 
Signed-off-by: Naveen Krishna Chatradhi 
Co-developed-by: Yazen Ghannam 
Signed-off-by: Yazen Ghannam 
Signed-off-by: Borislav Petkov (AMD) 
Link: https://lore.kernel.org/r/20230127170419.1824692-23-yazen.ghannam@amd.com