kernel/git/stable/linux.git/drivers/acpi/apei/einj.c, branch master

EINJ: Add CXL error type support

2024-03-13T06:08:29+00:00

Move CXL protocol error types from einj.c (now einj-core.c) to einj-cxl.c. einj-cxl.c implements the necessary handling for CXL protocol error injection and exposes an API for the CXL core to use said functionality, while also allowing the EINJ module to be built without CXL support. Because CXL error types targeting CXL 1.0/1.1 ports require special handling, only allow them to be injected through the new cxl debugfs interface (next commit) and return an error when attempting to inject through the legacy interface. Reviewed-by: Jonathan Cameron Signed-off-by: Ben Cheatham Link: https://lore.kernel.org/r/20240311142508.31717-3-Benjamin.Cheatham@amd.com Signed-off-by: Dan Williams

EINJ: Migrate to a platform driver

2024-03-13T06:08:29+00:00

Change the EINJ module to install a platform device/driver on module init and move the module init() and exit() functions to driver probe and remove. This change allows the EINJ module to load regardless of whether setting up EINJ succeeds, which allows dependent modules to still load (i.e. the CXL core). Since EINJ may no longer be initialized when the module loads, any functions that are called from dependent/external modules should safegaurd against the case EINJ didn't load. Reviewed-by: Jonathan Cameron Reviewed-by: Dan Williams Signed-off-by: Ben Cheatham Link: https://lore.kernel.org/r/20240311142508.31717-2-Benjamin.Cheatham@amd.com Signed-off-by: Dan Williams

ACPI: APEI: EINJ: Add support for vendor defined error types

2023-11-21T20:10:44+00:00

Vendor-Defined Error types are supported by the platform apart from standard error types if bit 31 is set in the output of GET_ERROR_TYPE Error Injection Action.[1] While the errors themselves and the length of their associated "OEM Defined data structure" might vary between vendors, the physical address of this structure can be computed through vendor_extension and length fields of "SET_ERROR_TYPE_WITH_ADDRESS" and "Vendor Error Type Extension" Structures respectively.[2][3] Currently, however, the einj module only computes the physical address of Vendor Error Type Extension Structure. Neither does it compute the physical address of OEM Defined structure nor does it establish the memory mapping required for injecting Vendor-defined errors. Consequently, userspace tools have to establish the very mapping through /dev/mem, nopat kernel parameter and system calls like mmap/munmap initially before injecting Vendor-defined errors. Circumvent the issue by computing the physical address of OEM Defined data structure and establishing the required mapping with the structure. Create a new file "oem_error", if the system supports Vendor-defined errors, to export this mapping, through debugfs_create_blob(). Userspace tools can then populate their respective OEM Defined structure instances and just write to the file as part of injecting Vendor-defined Errors. Similarly, the tools can also read from the file if the system firmware provides some information through the OEM defined structure after error injection. [1] ACPI specification 6.5, section 18.6.4 [2] ACPI specification 6.5, Table 18.31 [3] ACPI specification 6.5, Table 18.32 Suggested-by: Yazen Ghannam Signed-off-by: Avadhut Naik Reviewed-by: Tony Luck Reviewed-by: Borislav Petkov (AMD) Signed-off-by: Rafael J. Wysocki

ACPI: APEI: EINJ: Refactor available_error_type_show()

2023-11-21T20:10:44+00:00

OSPM can discover the error injection capabilities of the platform by executing GET_ERROR_TYPE error injection action.[1] The action returns a DWORD representing a bitmap of platform supported error injections.[2] The available_error_type_show() function determines the bits set within this DWORD and provides a verbose output, from einj_error_type_string array, through /sys/kernel/debug/apei/einj/available_error_type file. The function however, assumes one to one correspondence between an error's position in the bitmap and its array entry offset. Consequently, some errors like Vendor Defined Error Type fail this assumption and will incorrectly be shown as not supported, even if their corresponding bit is set in the bitmap and they have an entry in the array. Navigate around the issue by converting einj_error_type_string into an array of structures with a predetermined mask for all error types corresponding to their bit position in the DWORD returned by GET_ERROR_TYPE action. The same breaks the aforementioned assumption resulting in all supported error types by a platform being outputted through the above available_error_type file. [1] ACPI specification 6.5, Table 18.25 [2] ACPI specification 6.5, Table 18.30 Suggested-by: Alexey Kardashevskiy Signed-off-by: Avadhut Naik Reviewed-by: Borislav Petkov (AMD) Reviewed-by: Tony Luck Signed-off-by: Rafael J. Wysocki

ACPI: APEI: EINJ: warn on invalid argument when explicitly indicated by platform

2023-03-27T18:46:08+00:00

OSPM executes an EXECUTE_OPERATION action to instruct the platform to begin the injection operation, then executes a GET_COMMAND_STATUS action to determine the status of the completed operation. The ACPI Specification documented error codes[1] are: 0 = Success (Linux #define EINJ_STATUS_SUCCESS) 1 = Unknown failure (Linux #define EINJ_STATUS_FAIL) 2 = Invalid Access (Linux #define EINJ_STATUS_INVAL) The original code report -EBUSY for both "Unknown Failure" and "Invalid Access" cases. Actually, firmware could do some platform dependent sanity checks and returns different error codes, e.g. "Invalid Access" to indicate to the user that the parameters they supplied cannot be used for injection. To this end, fix to return -EINVAL in the __einj_error_inject() error handling case instead of always -EBUSY, when explicitly indicated by the platform in the status of the completed operation. [1] ACPI Specification 6.5 18.6.1. Error Injection Table Signed-off-by: Shuai Xue Reviewed-by: Tony Luck Signed-off-by: Rafael J. Wysocki

ACPI: APEI: EINJ: Add CXL error types

2023-03-20T17:33:00+00:00

ACPI 6.5 added six new error types for CXL. See chapter 18 table 18.30. Add strings for the new types so that Linux will list them in the /sys/kernel/debug/apei/einj/available_error_types file. It seems no other changes are needed. Linux already accepts the CXL codes (on a BIOS that advertises them). Signed-off-by: Tony Luck Reviewed-by: Davidlohr Bueso Reviewed-by: Dave Jiang Signed-off-by: Rafael J. Wysocki

ACPI: APEI: EINJ: Limit error type to 32-bit width

2023-01-30T15:40:05+00:00

The bit map of error types to inject is 32-bit width [1]. Add parameter check to reflect the fact. [1] ACPI Specification 6.4, Section 18.6.4. Error Types Signed-off-by: Shuai Xue Reviewed-by: Tony Luck Signed-off-by: Rafael J. Wysocki

ACPI: APEI: EINJ: Refactor available_error_type_show()

2022-12-07T17:16:12+00:00

Move error type descriptions into an array and loop over error types to improve readability and maintainability. Replace seq_printf() with seq_puts() as recommended by checkpatch.pl. Signed-off-by: Jay Lu Co-developed-by: Ben Cheatham Signed-off-by: Ben Cheatham Reviewed-by: Tony Luck Signed-off-by: Rafael J. Wysocki

ACPI: APEI: EINJ: Fix formatting errors

2022-12-07T17:16:12+00:00

Checkpatch reveals warnings and an error due to missing lines and incorrect indentations. Add the missing lines after declarations and fix the suspect indentations. Signed-off-by: Jay Lu Signed-off-by: Ben Cheatham Reviewed-by: Tony Luck Signed-off-by: Rafael J. Wysocki

ACPI: APEI: Fix _EINJ vs EFI_MEMORY_SP

2022-06-29T18:24:19+00:00

When a platform marks a memory range as "special purpose" it is not onlined as System RAM by default. However, it is still suitable for error injection. Add IORES_DESC_SOFT_RESERVED to einj_error_inject() as a permissible memory type in the sanity checking of the arguments to _EINJ. Fixes: 262b45ae3ab4 ("x86/efi: EFI soft reservation to E820 enumeration") Reviewed-by: Tony Luck Reported-by: Omar Avelar Signed-off-by: Dan Williams Signed-off-by: Rafael J. Wysocki