Skip to content

[6.6-velinux] Backported AMD ATL PRM-related fixes to resolve Venice DF Revision failure#111

Open
PvsNarasimha wants to merge 6 commits intoopenvelinux:6.6-velinuxfrom
PvsNarasimha:ATL_RPM_Patches
Open

[6.6-velinux] Backported AMD ATL PRM-related fixes to resolve Venice DF Revision failure#111
PvsNarasimha wants to merge 6 commits intoopenvelinux:6.6-velinuxfrom
PvsNarasimha:ATL_RPM_Patches

Conversation

@PvsNarasimha
Copy link
Copy Markdown

@PvsNarasimha PvsNarasimha commented Jan 28, 2026

  1. RAS/AMD/ATL: Return error codes from helper functions
  2. ACPI: PRM: Add acpi_prm_handler_available()
  3. ACPI: PRM: Add PRM handler direct call support
  4. RAS/AMD/ATL: Translate normalized to system physical addresses using PRM
  5. RAS/AMD/ATL: Add MI300 support
  6. RAS/AMD/ATL: Require PRM support for future systems

Unit test Results

root@venice-hostos:~# uname -r
6.6.95atlwithpatch+
root@venice-hostos:~# grep CONFIG_AMD_ATL /boot/config-$(uname -r)
CONFIG_AMD_ATL=y
CONFIG_AMD_ATL_PRM=y
root@venice-hostos:~# dmesg | grep -i amd_atl
root@venice-hostos:~#

root@venice-hostos:~# dmesg | grep -i amd_atl
[    4.084368] amd_atl: Failed to determine DF Revision
[    4.491979] amd_atl: Failed to determine DF Revision

root@venice-hostos:~# uname -r
6.6.95atlwithout+
root@venice-hostos:~# grep CONFIG_AMD_ATL /boot/config-$(uname -r)
CONFIG_AMD_ATL=m
root@venice-hostos:~#

yghannam and others added 6 commits January 28, 2026 01:56
commit 6553c68bc73dccfb3c8a9971ee40ed378adc0df4 upstream.

Pass up error codes from helper functions rather than discarding them.

Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Malathi <amalathi@amd.com>
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 83be4bee57f0374ff751aaff3fef4af0af66ec81 upstream.

Add a helper function to check if a PRM handler/module is present.

This can be used during init time by code that depends on a particular
handler. If the handler is not present, then the code does not need to
be loaded.

Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: "Mario Limonciello (AMD)" <superm1@kernel.org>
Acked-by: "Rafael J. Wysocki (Intel)" <rafael@kernel.org>
Link: https://patch.msgid.link/all/20251017-wip-atl-prm-v2-1-7ab1df4a5fbc@amd.com
Signed-off-by: Malathi <amalathi@amd.com>
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit f0fcdd2 upstream.

Platform Runtime Mechanism (PRM) handlers can be invoked from either the AML
interpreter or directly by an OS driver. Implement the latter.

  [ bp: Massage commit message. ]

Signed-off-by: John Allen <john.allen@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/20240730151731.15363-2-john.allen@amd.com
Signed-off-by: Malathi <amalathi@amd.com>
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 26e43c9 upstream.

AMD Zen-based systems report memory error addresses through machine
check banks representing Unified Memory Controllers (UMCs) in the form
of UMC relative "normalized" addresses. A normalized address must be
converted to a system physical address to be usable by the OS.

Future AMD platforms will provide a UEFI PRM module that implements a
number of address translation PRM handlers. This will provide an
interface for the OS to call platform specific code without requiring
the use of SMM or other heavy firmware operations.

Add support for the normalized to system physical address translation
PRM handler in the AMD Address Translation Library and prefer it over
native code if available. The GUID and parameter buffer structure are
specific to the normalized to system physical address handler provided
by the address translation PRM module included in future AMD systems.

The address translation PRM module is documented in chapter 22 of the
publicly available "AMD Family 1Ah Models 00h–0Fh and Models 10h–1Fh
ACPI v6.5 Porting Guide".

  [ bp: Massage commit message. ]

Signed-off-by: John Allen <john.allen@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20240730151731.15363-3-john.allen@amd.com
Signed-off-by: Malathi <amalathi@amd.com>
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 453f0ae upstream.

AMD MI300 systems include on-die HBM3 memory and a unique topology. And
they fall under Data Fabric version 4.5 in overall design.

Generally, topology information (IDs, etc.) is gathered from Data Fabric
registers. However, the unique topology for MI300 means that some
topology information is fixed in hardware and follows arbitrary
mappings. Furthermore, not all hardware instances are software-visible,
so register accesses must be adjusted.

Recognize and add helper functions for the new MI300 interleave modes.
Add lookup tables for fixed values where appropriate. Adjust how Die and
Node IDs are found and used.

Also, fix some register bitmasks that were mislabeled.

Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Co-developed-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20240128155950.1434067-1-yazen.ghannam@amd.com
Signed-off-by: Malathi <amalathi@amd.com>
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 187d1b27a1e436822c31e43aa58505f6dd8987e2 upstream.

Currently, the AMD Address Translation Library will fail to load for new,
unrecognized systems (based on Data Fabric revision). The intention is to
prevent the code from executing on new systems and returning incorrect
results.

Recent AMD systems, however, may provide UEFI PRM handlers for address
translation. This is code provided by the platform through BIOS tables.  These
are the preferred method for translation, and the Linux native code can be
used as a fallback.

Future AMD systems are expected to provide PRM handlers by default. And Linux
native code will not be used.

Adjust the ATL init code so that new, unrecognized systems will default to
using PRM handlers only.

Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: "Mario Limonciello (AMD)" <superm1@kernel.org>
Link: https://patch.msgid.link/all/20251017-wip-atl-prm-v2-2-7ab1df4a5fbc@amd.com
Signed-off-by: Malathi <amalathi@amd.com>
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
@PvsNarasimha PvsNarasimha changed the title Backport AMD ATL PRM-related fixes to resolve Venice DF Revision failure [6.6-velinux]Backport AMD ATL PRM-related fixes to resolve Venice DF Revision failure Jan 28, 2026
@PvsNarasimha PvsNarasimha changed the title [6.6-velinux]Backport AMD ATL PRM-related fixes to resolve Venice DF Revision failure [6.6-velinux] Backported AMD ATL PRM-related fixes to resolve Venice DF Revision failure Jan 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants