linux-toradex.git/drivers/ras, branch v6.19 Linux kernel for Apalis and Colibri modules Merge tag 'efi-next-for-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi 2025-12-05T01:10:08+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-12-05T01:10:08+00:00 b1dd1e2f3e4ed970949ab4bb982bb0165f3e979d Pull EFI updates from Ard Biesheuvel: "The usual trickle of EFI contributions: - Parse SMBIOS tables in memory directly on Macbooks that do not implement the EFI SMBIOS protocol - Obtain EDID information from the primary display while running in the EFI stub, and expose it via bootparams on x86 (generic method is in the works, and will likely land during the next cycle) - Bring CPER handling for ARM systems up to data with the latest EFI spec changes - Various cosmetic changes" * tag 'efi-next-for-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: docs: efi: add CPER functions to driver-api efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs efi/cper: Add a new helper function to print bitmasks efi/cper: Adjust infopfx size to accept an extra space RAS: Report all ARM processor CPER information to userspace efi/libstub: x86: Store EDID in boot_params efi/libstub: gop: Add support for reading EDID efi/libstub: gop: Initialize screen_info in helper function efi/libstub: gop: Find GOP handle instead of GOP data efi: Fix trailing whitespace in header file efi/memattr: Convert efi_memattr_init() return type to void efi: stmm: fix kernel-doc "bad line" warnings efi/riscv: Remove the useless failure return message print efistub/x86: Add fallback for SMBIOS record lookup 
Pull EFI updates from Ard Biesheuvel:
 "The usual trickle of EFI contributions:

   - Parse SMBIOS tables in memory directly on Macbooks that do not
     implement the EFI SMBIOS protocol

   - Obtain EDID information from the primary display while running in
     the EFI stub, and expose it via bootparams on x86 (generic method
     is in the works, and will likely land during the next cycle)

   - Bring CPER handling for ARM systems up to data with the latest EFI
     spec changes

   - Various cosmetic changes"

* tag 'efi-next-for-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
  docs: efi: add CPER functions to driver-api
  efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs
  efi/cper: Add a new helper function to print bitmasks
  efi/cper: Adjust infopfx size to accept an extra space
  RAS: Report all ARM processor CPER information to userspace
  efi/libstub: x86: Store EDID in boot_params
  efi/libstub: gop: Add support for reading EDID
  efi/libstub: gop: Initialize screen_info in helper function
  efi/libstub: gop: Find GOP handle instead of GOP data
  efi: Fix trailing whitespace in header file
  efi/memattr: Convert efi_memattr_init() return type to void
  efi: stmm: fix kernel-doc "bad line" warnings
  efi/riscv: Remove the useless failure return message print
  efistub/x86: Add fallback for SMBIOS record lookup
Merge remote-tracking branches 'ras/edac-amd-atl', 'ras/edac-drivers' and 'ras/edac-misc' into edac-updates 2025-12-01T11:06:08+00:00 Borislav Petkov (AMD) bp@alien8.de 2025-12-01T11:06:08+00:00 e2349c5811ae642f6d948d1ee4bfc4a93566c178 Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> 
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
RAS/AMD/ATL: Replace bitwise_xor_bits() with hweight16() 2025-11-24T16:00:37+00:00 Nikolay Borisov nik.borisov@suse.com 2025-11-24T14:25:17+00:00 69acbdbbefbda7b7b32faa706a8f68c399c9e47b 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 <nik.borisov@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20251124142517.1708451-1-nik.borisov@suse.com 
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 <nik.borisov@suse.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20251124142517.1708451-1-nik.borisov@suse.com
RAS: Report all ARM processor CPER information to userspace 2025-11-21T08:42:02+00:00 Jason Tian jason@os.amperecomputing.com 2025-08-14T16:52:52+00:00 05954511b73e748d0370549ad9dd9cd95297d97a The ARM processor CPER record was added in UEFI v2.6 and remained unchanged up to v2.10. Yet, the original arm_event trace code added by e9279e83ad1f ("trace, ras: add ARM processor error trace event") is incomplete, as it only traces some fields of UAPI 2.6 table N.16, not exporting any information from tables N.17 to N.29 of the record. This is not enough for the user to be able to figure out what has exactly happened or to take appropriate action. According to the UEFI v2.9 specification chapter N2.4.4, the ARM processor error section includes: - several (ERR_INFO_NUM) ARM processor error information structures (Tables N.17 to N.20); - several (CONTEXT_INFO_NUM) ARM processor context information structures (Tables N.21 to N.29); - several vendor specific error information structures. The size is given by Section Length minus the size of the other fields. In addition, it also exports two fields that are parsed by the GHES driver when firmware reports it, e.g.: - error severity - CPU logical index Report all of these information to userspace via a the ARM tracepoint so that userspace can properly record the error and take decisions related to CPU core isolation according to error severity and other info. The updated ARM trace event now contains the following fields: ====================================== ============================= UEFI field on table N.16 ARM Processor trace fields ====================================== ============================= Validation handled when filling data for affinity MPIDR and running state. ERR_INFO_NUM pei_len CONTEXT_INFO_NUM ctx_len Section Length indirectly reported by pei_len, ctx_len and oem_len Error affinity level affinity MPIDR_EL1 mpidr MIDR_EL1 midr Running State running_state PSCI State psci_state Processor Error Information Structure pei_err - count at pei_len Processor Context ctx_err- count at ctx_len Vendor Specific Error Info oem - count at oem_len ====================================== ============================= It should be noted that decoding of tables N.17 to N.29, if needed, will be handled in userspace. That gives more flexibility, as there won't be any need to flood the kernel with micro-architecture specific error decoding. Also, decoding the other fields require a complex logic, and should be done for each of the several values inside the record field. So, let userspace daemons like rasdaemon decode them, parsing such tables and having vendor-specific micro-architecture-specific decoders. [mchehab: modified description, solved merge conflicts and fixed coding style] Signed-off-by: Jason Tian <jason@os.amperecomputing.com> Co-developed-by: Shengwei Luo <luoshengwei@huawei.com> Signed-off-by: Shengwei Luo <luoshengwei@huawei.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Daniel Ferguson <danielf@os.amperecomputing.com> # rebased Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Tested-by: Shiju Jose <shiju.jose@huawei.com> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Fixes: e9279e83ad1f ("trace, ras: add ARM processor error trace event") Link: https://uefi.org/specs/UEFI/2.10/Apx_N_Common_Platform_Error_Record.html#arm-processor-error-section Signed-off-by: Ard Biesheuvel <ardb@kernel.org> 
The ARM processor CPER record was added in UEFI v2.6 and remained
unchanged up to v2.10.

Yet, the original arm_event trace code added by

  e9279e83ad1f ("trace, ras: add ARM processor error trace event")

is incomplete, as it only traces some fields of UAPI 2.6 table N.16, not
exporting any information from tables N.17 to N.29 of the record.

This is not enough for the user to be able to figure out what has
exactly happened or to take appropriate action.

According to the UEFI v2.9 specification chapter N2.4.4, the ARM
processor error section includes:

- several (ERR_INFO_NUM) ARM processor error information structures
  (Tables N.17 to N.20);
- several (CONTEXT_INFO_NUM) ARM processor context information
  structures (Tables N.21 to N.29);
- several vendor specific error information structures. The
  size is given by Section Length minus the size of the other
  fields.

In addition, it also exports two fields that are parsed by the GHES
driver when firmware reports it, e.g.:

- error severity
- CPU logical index

Report all of these information to userspace via a the ARM tracepoint so
that userspace can properly record the error and take decisions related
to CPU core isolation according to error severity and other info.

The updated ARM trace event now contains the following fields:

======================================  =============================
UEFI field on table N.16                ARM Processor trace fields
======================================  =============================
Validation                              handled when filling data for
                                        affinity MPIDR and running
                                        state.
ERR_INFO_NUM                            pei_len
CONTEXT_INFO_NUM                        ctx_len
Section Length                          indirectly reported by
                                        pei_len, ctx_len and oem_len
Error affinity level                    affinity
MPIDR_EL1                               mpidr
MIDR_EL1                                midr
Running State                           running_state
PSCI State                              psci_state
Processor Error Information Structure   pei_err - count at pei_len
Processor Context                       ctx_err- count at ctx_len
Vendor Specific Error Info              oem - count at oem_len
======================================  =============================

It should be noted that decoding of tables N.17 to N.29, if needed, will
be handled in userspace. That gives more flexibility, as there won't be
any need to flood the kernel with micro-architecture specific error
decoding.

Also, decoding the other fields require a complex logic, and should be
done for each of the several values inside the record field.  So, let
userspace daemons like rasdaemon decode them, parsing such tables and
having vendor-specific micro-architecture-specific decoders.

 [mchehab: modified description, solved merge conflicts and fixed coding style]

Signed-off-by: Jason Tian <jason@os.amperecomputing.com>
Co-developed-by: Shengwei Luo <luoshengwei@huawei.com>
Signed-off-by: Shengwei Luo <luoshengwei@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Daniel Ferguson <danielf@os.amperecomputing.com> # rebased
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Tested-by: Shiju Jose <shiju.jose@huawei.com>
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
Fixes: e9279e83ad1f ("trace, ras: add ARM processor error trace event")
Link: https://uefi.org/specs/UEFI/2.10/Apx_N_Common_Platform_Error_Record.html#arm-processor-error-section
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
RAS/CEC: Replace use of system_wq with system_percpu_wq 2025-11-07T12:48:28+00:00 Marco Crivellari marco.crivellari@suse.com 2025-11-06T11:24:54+00:00 24e3848a2e903fe614fbeef3048fa4fe91e46482 Switch to using system_percpu_wq because system_wq is going away as part of a workqueue restructuring. Currently if a user enqueues a work item using schedule_delayed_work() the used workqueue is "system_wq" (per-cpu workqueue) while queue_delayed_work() uses WORK_CPU_UNBOUND (used when a CPU is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use of WORK_CPU_UNBOUND again. This lack of consistency cannot be addressed without refactoring the API. For more details see those commits and the Link tag below. 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") [ bp: Massage commit message. ] Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de 
Switch to using system_percpu_wq because system_wq is going away as part of
a workqueue restructuring.

Currently if a user enqueues a work item using schedule_delayed_work() the
used workqueue is "system_wq" (per-cpu workqueue) while queue_delayed_work()
uses WORK_CPU_UNBOUND (used when a CPU is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use of
WORK_CPU_UNBOUND again.

This lack of consistency cannot be addressed without refactoring the API.
For more details see those commits and the Link tag below.

  128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
  930c2ea566af ("workqueue: Add new WQ_PERCPU flag")

  [ bp: Massage commit message. ]

Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de
RAS/AMD/ATL: Require PRM support for future systems 2025-10-27T18:56:41+00:00 Yazen Ghannam yazen.ghannam@amd.com 2025-10-17T13:26:29+00:00 187d1b27a1e436822c31e43aa58505f6dd8987e2 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 
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
RAS/AMD/ATL: Return error codes from helper functions 2025-10-17T12:38:42+00:00 Yazen Ghannam yazen.ghannam@amd.com 2025-10-06T15:10:27+00:00 6553c68bc73dccfb3c8a9971ee40ed378adc0df4 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> 
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>
RAS: Export log_non_standard_event() to drivers 2025-09-15T14:20:29+00:00 Shubhrajyoti Datta shubhrajyoti.datta@amd.com 2025-09-08T11:56:47+00:00 36e74c95638296b1f272d9d011d435ce62d8f11c The function log_non_standard_event() is responsible for logging platform-specific or vendor-defined RAS (Reliability, Availability, and Serviceability) events. Currently, this function is only available within the RAS subsystem, preventing external modules from leveraging its capabilities. Export it to drivers to log non-standard RAS events via EDAC. Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/20250908115649.22903-1-shubhrajyoti.datta@amd.com 
The function log_non_standard_event() is responsible for logging
platform-specific or vendor-defined RAS (Reliability, Availability, and
Serviceability) events. Currently, this function is only available within the
RAS subsystem, preventing external modules from leveraging its capabilities.

Export it to drivers to log non-standard RAS events via EDAC.

Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/20250908115649.22903-1-shubhrajyoti.datta@amd.com
Merge tag 'v6.15-rc5' into x86/cpu, to resolve conflicts 2025-05-06T08:00:58+00:00 Ingo Molnar mingo@kernel.org 2025-05-06T07:59:02+00:00 24035886d735e4ce1c4605638adafe1fa2988e7a Conflicts: tools/arch/x86/include/asm/cpufeatures.h Signed-off-by: Ingo Molnar <mingo@kernel.org> 
 Conflicts:
	tools/arch/x86/include/asm/cpufeatures.h

Signed-off-by: Ingo Molnar <mingo@kernel.org>
x86/platform/amd: Move the <asm/amd_node.h> header to <asm/amd/node.h> 2025-04-14T07:34:17+00:00 Ingo Molnar mingo@kernel.org 2025-04-13T08:41:44+00:00 0a35c9280a9105e601cfe23b7c15522a195fa412 Collect AMD specific platform header files in <asm/amd/*.h>. Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mario Limonciello <superm1@kernel.org> Link: https://lore.kernel.org/r/20250413084144.3746608-7-mingo@kernel.org 
Collect AMD specific platform header files in <asm/amd/*.h>.

Signed-off-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mario Limonciello <superm1@kernel.org>
Link: https://lore.kernel.org/r/20250413084144.3746608-7-mingo@kernel.org