<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/ras/amd/atl/umc.c, branch linux-rolling-stable</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-rolling-stable</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-rolling-stable'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2025-11-24T16:00:37Z</updated>
<entry>
<title>RAS/AMD/ATL: Replace bitwise_xor_bits() with hweight16()</title>
<updated>2025-11-24T16:00:37Z</updated>
<author>
<name>Nikolay Borisov</name>
<email>nik.borisov@suse.com</email>
</author>
<published>2025-11-24T14:25:17Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=69acbdbbefbda7b7b32faa706a8f68c399c9e47b'/>
<id>urn:sha1:69acbdbbefbda7b7b32faa706a8f68c399c9e47b</id>
<content type='text'>
Doing hweight16() and checking whether the lsb is set is functionally
equivalent to what bitwise_xor_bits() does. In addition, it results in better
generated code as before gcc would inline the function 4 times.  With hweight16(),
the resulting code boils down to 2 instructions -  POPCNT and AND, and all
relevant CPUs support POPCNT.

An alternative would have been to use the __builtin_parity() function provided
by both Clang/GCC, however under some circumstances the compiler can choose not
to inline it but generate a library call which is unsupported in the kernel.

No functional changes.

  [ bp: Massage commit message. ]

Signed-off-by: Nikolay Borisov &lt;nik.borisov@suse.com&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Link: https://patch.msgid.link/20251124142517.1708451-1-nik.borisov@suse.com
</content>
</entry>
<entry>
<title>RAS/AMD/ATL: Require PRM support for future systems</title>
<updated>2025-10-27T18:56:41Z</updated>
<author>
<name>Yazen Ghannam</name>
<email>yazen.ghannam@amd.com</email>
</author>
<published>2025-10-17T13:26:29Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=187d1b27a1e436822c31e43aa58505f6dd8987e2'/>
<id>urn:sha1:187d1b27a1e436822c31e43aa58505f6dd8987e2</id>
<content type='text'>
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 &lt;yazen.ghannam@amd.com&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Reviewed-by: "Mario Limonciello (AMD)" &lt;superm1@kernel.org&gt;
Link: https://patch.msgid.link/all/20251017-wip-atl-prm-v2-2-7ab1df4a5fbc@amd.com
</content>
</entry>
<entry>
<title>RAS/AMD/FMPM: Get masked address</title>
<updated>2025-04-08T17:30:58Z</updated>
<author>
<name>Yazen Ghannam</name>
<email>yazen.ghannam@amd.com</email>
</author>
<published>2025-02-27T19:31:32Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=58029c39cdc54ac4f4dc40b4a9c05eed9f9b808a'/>
<id>urn:sha1:58029c39cdc54ac4f4dc40b4a9c05eed9f9b808a</id>
<content type='text'>
Some operations require checking, or ignoring, specific bits in an address
value. For example, this can be comparing address values to identify unique
structures.

Currently, the full address value is compared when filtering for duplicates.
This results in over counting and creation of extra records.  This gives the
impression that more unique events occurred than did in reality.

Mask the address for physical rows on MI300.

  [ bp: Simplify. ]

Fixes: 6f15e617cc99 ("RAS: Introduce a FRU memory poison manager")
Signed-off-by: Yazen Ghannam &lt;yazen.ghannam@amd.com&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Cc: stable@vger.kernel.org
</content>
</entry>
<entry>
<title>RAS/AMD/ATL: Include row[13] bit in row retirement</title>
<updated>2025-04-07T13:06:06Z</updated>
<author>
<name>Yazen Ghannam</name>
<email>yazen.ghannam@amd.com</email>
</author>
<published>2025-04-01T20:49:00Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=6c44e5354d4d16d9d891a419ca3f57abfe18ce7a'/>
<id>urn:sha1:6c44e5354d4d16d9d891a419ca3f57abfe18ce7a</id>
<content type='text'>
Based on feedback from hardware folks, row[13] is part of the variable
bits within a physical row (along with all column bits).

Only half the physical addresses affected by a row are calculated if
this bit is not included.

Add the row[13] bit to the row retirement flow.

Fixes: 3b566b30b414 ("RAS/AMD/ATL: Add MI300 row retirement support")
Signed-off-by: Yazen Ghannam &lt;yazen.ghannam@amd.com&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20250401-fix-fmpm-extra-records-v1-1-840bcf7a8ac5@amd.com
</content>
</entry>
<entry>
<title>RAS/AMD/ATL: Translate normalized to system physical addresses using PRM</title>
<updated>2024-08-01T12:36:29Z</updated>
<author>
<name>John Allen</name>
<email>john.allen@amd.com</email>
</author>
<published>2024-07-30T15:17:31Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=26e43c9a894176e7b7f7eaff61aaf2748d4aa520'/>
<id>urn:sha1:26e43c9a894176e7b7f7eaff61aaf2748d4aa520</id>
<content type='text'>
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 &lt;john.allen@amd.com&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Link: https://lore.kernel.org/r/20240730151731.15363-3-john.allen@amd.com
</content>
</entry>
<entry>
<title>RAS/AMD/ATL: Use system settings for MI300 DRAM to normalized address translation</title>
<updated>2024-06-16T09:22:57Z</updated>
<author>
<name>Yazen Ghannam</name>
<email>yazen.ghannam@amd.com</email>
</author>
<published>2024-06-07T21:33:00Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ba437905b4fbf0ee1686c175069239a1cc292558'/>
<id>urn:sha1:ba437905b4fbf0ee1686c175069239a1cc292558</id>
<content type='text'>
The currently used normalized address format is not applicable to all
MI300 systems. This leads to incorrect results during address
translation.

Drop the fixed layout and construct the normalized address from system
settings.

Fixes: 87a612375307 ("RAS/AMD/ATL: Add MI300 DRAM to normalized address translation support")
Signed-off-by: Yazen Ghannam &lt;yazen.ghannam@amd.com&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Cc: &lt;stable@kernel.org&gt;
Link: https://lore.kernel.org/r/20240607-mi300-dram-xl-fix-v1-2-2f11547a178c@amd.com
</content>
</entry>
<entry>
<title>RAS/AMD/ATL: Fix MI300 bank hash</title>
<updated>2024-06-10T05:56:33Z</updated>
<author>
<name>Yazen Ghannam</name>
<email>yazen.ghannam@amd.com</email>
</author>
<published>2024-06-07T21:32:59Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fe8a08973a0dea9757394c5adbdc3c0a03b0b432'/>
<id>urn:sha1:fe8a08973a0dea9757394c5adbdc3c0a03b0b432</id>
<content type='text'>
Apply the SID bits to the correct offset in the Bank value. Do this in
the temporary value so they don't need to be masked off later.

Fixes: 87a612375307 ("RAS/AMD/ATL: Add MI300 DRAM to normalized address translation support")
Signed-off-by: Yazen Ghannam &lt;yazen.ghannam@amd.com&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Cc: &lt;stable@kernel.org&gt;
Link: https://lore.kernel.org/r/20240607-mi300-dram-xl-fix-v1-1-2f11547a178c@amd.com
</content>
</entry>
<entry>
<title>Merge tag 'edac_updates_for_v6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras</title>
<updated>2024-03-12T01:14:06Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2024-03-12T01:14:06Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b0402403e54ae9eb94ce1cbb53c7def776e97426'/>
<id>urn:sha1:b0402403e54ae9eb94ce1cbb53c7def776e97426</id>
<content type='text'>
Pull EDAC updates from Borislav Petkov:

 - Add a FRU (Field Replaceable Unit) memory poison manager which
   collects and manages previously encountered hw errors in order to
   save them to persistent storage across reboots. Previously recorded
   errors are "replayed" upon reboot in order to poison memory which has
   caused said errors in the past.

   The main use case is stacked, on-chip memory which cannot simply be
   replaced so poisoning faulty areas of it and thus making them
   inaccessible is the only strategy to prolong its lifetime.

 - Add an AMD address translation library glue which converts the
   reported addresses of hw errors into system physical addresses in
   order to be used by other subsystems like memory failure, for
   example. Add support for MI300 accelerators to that library.

 - igen6: Add support for Alder Lake-N SoC

 - i10nm: Add Grand Ridge support

 - The usual fixlets and cleanups

* tag 'edac_updates_for_v6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras:
  EDAC/versal: Convert to platform remove callback returning void
  RAS/AMD/FMPM: Fix off by one when unwinding on error
  RAS/AMD/FMPM: Add debugfs interface to print record entries
  RAS/AMD/FMPM: Save SPA values
  RAS: Export helper to get ras_debugfs_dir
  RAS/AMD/ATL: Fix bit overflow in denorm_addr_df4_np2()
  RAS: Introduce a FRU memory poison manager
  RAS/AMD/ATL: Add MI300 row retirement support
  Documentation: Move RAS section to admin-guide
  EDAC/versal: Make the bit position of injected errors configurable
  EDAC/i10nm: Add Intel Grand Ridge micro-server support
  EDAC/igen6: Add one more Intel Alder Lake-N SoC support
  RAS/AMD/ATL: Add MI300 DRAM to normalized address translation support
  RAS/AMD/ATL: Fix array overflow in get_logical_coh_st_fabric_id_mi300()
  RAS/AMD/ATL: Add MI300 support
  Documentation: RAS: Add index and address translation section
  EDAC/amd64: Use new AMD Address Translation Library
  RAS: Introduce AMD Address Translation Library
  EDAC/synopsys: Convert to devm_platform_ioremap_resource()
</content>
</entry>
<entry>
<title>RAS/AMD/ATL: Add MI300 row retirement support</title>
<updated>2024-02-14T16:10:06Z</updated>
<author>
<name>Yazen Ghannam</name>
<email>yazen.ghannam@amd.com</email>
</author>
<published>2024-02-14T03:35:15Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3b566b30b41401888ee0e8eb904a1e7a6693794b'/>
<id>urn:sha1:3b566b30b41401888ee0e8eb904a1e7a6693794b</id>
<content type='text'>
DRAM row retirement depends on model-specific information that is best
done within the AMD Address Translation Library.

Export a generic wrapper function for other modules to use. Add any
model-specific helpers here.

Signed-off-by: Yazen Ghannam &lt;yazen.ghannam@amd.com&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Link: https://lore.kernel.org/r/20240214033516.1344948-2-yazen.ghannam@amd.com
</content>
</entry>
<entry>
<title>RAS/AMD/ATL: Add MI300 DRAM to normalized address translation support</title>
<updated>2024-02-01T15:28:56Z</updated>
<author>
<name>Yazen Ghannam</name>
<email>yazen.ghannam@amd.com</email>
</author>
<published>2024-01-31T16:57:32Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=87a61237530769d5a7a750fbc747ac0d1b2e18c1'/>
<id>urn:sha1:87a61237530769d5a7a750fbc747ac0d1b2e18c1</id>
<content type='text'>
Zen-based AMD systems report DRAM ECC errors through Unified Memory
Controller (UMC) MCA banks. The value provided in MCA_ADDR is
a "normalized" address which represents the UMC's view of its managed
memory. The normalized address must be translated to a system physical
address for software to take action.

MI300 systems, uniquely, do not provide a normalized address in MCA_ADDR
for DRAM ECC errors. Rather, the "DRAM" address is reported. This value
includes identifiers for the bank, row, column, pseudochannel and stack
of the memory location.

The DRAM address must be converted to a normalized address in order to
be further translated to a system physical address.

Add helper functions to do the DRAM to normalized translation for MI300
systems. The method is based on the fixed hardware layout of the on-chip
memory.

  [ bp: Massage commit message, decapitalize some, rename function. ]

Signed-off-by: Yazen Ghannam &lt;yazen.ghannam@amd.com&gt;
Co-developed-by: Muralidhara M K &lt;muralidhara.mk@amd.com&gt;
Signed-off-by: Muralidhara M K &lt;muralidhara.mk@amd.com&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Tested-by: Muralidhara M K &lt;muralidhara.mk@amd.com&gt;
Link: https://lore.kernel.org/r/20240131165732.88297-1-yazen.ghannam@amd.com
</content>
</entry>
</feed>
