summaryrefslogtreecommitdiffstats
path: root/Documentation/firmware-guide/acpi
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/firmware-guide/acpi')
-rw-r--r--Documentation/firmware-guide/acpi/apei/einj.rst34
-rw-r--r--Documentation/firmware-guide/acpi/enumeration.rst12
-rw-r--r--Documentation/firmware-guide/acpi/index.rst1
-rw-r--r--Documentation/firmware-guide/acpi/method-customizing.rst89
4 files changed, 40 insertions, 96 deletions
diff --git a/Documentation/firmware-guide/acpi/apei/einj.rst b/Documentation/firmware-guide/acpi/apei/einj.rst
index d6b61d22f5..c52b9da08f 100644
--- a/Documentation/firmware-guide/acpi/apei/einj.rst
+++ b/Documentation/firmware-guide/acpi/apei/einj.rst
@@ -32,6 +32,10 @@ configuration::
CONFIG_ACPI_APEI
CONFIG_ACPI_APEI_EINJ
+...and to (optionally) enable CXL protocol error injection set::
+
+ CONFIG_ACPI_APEI_EINJ_CXL
+
The EINJ user interface is in <debugfs mount point>/apei/einj.
The following files belong to it:
@@ -118,6 +122,24 @@ The following files belong to it:
this actually works depends on what operations the BIOS actually
includes in the trigger phase.
+CXL error types are supported from ACPI 6.5 onwards (given a CXL port
+is present). The EINJ user interface for CXL error types is at
+<debugfs mount point>/cxl. The following files belong to it:
+
+- einj_types:
+
+ Provides the same functionality as available_error_types above, but
+ for CXL error types
+
+- $dport_dev/einj_inject:
+
+ Injects a CXL error type into the CXL port represented by $dport_dev,
+ where $dport_dev is the name of the CXL port (usually a PCIe device name).
+ Error injections targeting a CXL 2.0+ port can use the legacy interface
+ under <debugfs mount point>/apei/einj, while CXL 1.1/1.0 port injections
+ must use this file.
+
+
BIOS versions based on the ACPI 4.0 specification have limited options
in controlling where the errors are injected. Your BIOS may support an
extension (enabled with the param_extension=1 module parameter, or boot
@@ -181,6 +203,18 @@ You should see something like this in dmesg::
[22715.834759] EDAC sbridge MC3: PROCESSOR 0:306e7 TIME 1422553404 SOCKET 0 APIC 0
[22716.616173] EDAC MC3: 1 CE memory read error on CPU_SrcID#0_Channel#0_DIMM#0 (channel:0 slot:0 page:0x12345 offset:0x0 grain:32 syndrome:0x0 - area:DRAM err_code:0001:0090 socket:0 channel_mask:1 rank:0)
+A CXL error injection example with $dport_dev=0000:e0:01.1::
+
+ # cd /sys/kernel/debug/cxl/
+ # ls
+ 0000:e0:01.1 0000:0c:00.0
+ # cat einj_types # See which errors can be injected
+ 0x00008000 CXL.mem Protocol Correctable
+ 0x00010000 CXL.mem Protocol Uncorrectable non-fatal
+ 0x00020000 CXL.mem Protocol Uncorrectable fatal
+ # cd 0000:e0:01.1 # Navigate to dport to inject into
+ # echo 0x8000 > einj_inject # Inject error
+
Special notes for injection into SGX enclaves:
There may be a separate BIOS setup option to enable SGX injection.
diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst
index d79f693909..0165b09c09 100644
--- a/Documentation/firmware-guide/acpi/enumeration.rst
+++ b/Documentation/firmware-guide/acpi/enumeration.rst
@@ -595,7 +595,7 @@ bridges/switches of the board.
For example, let's assume we have a system with a PCIe serial port, an
Exar XR17V3521, soldered on the main board. This UART chip also includes
-16 GPIOs and we want to add the property ``gpio-line-names`` [1] to these pins.
+16 GPIOs and we want to add the property ``gpio-line-names`` [1]_ to these pins.
In this case, the ``lspci`` output for this component is::
07:00.0 Serial controller: Exar Corp. XR17V3521 Dual PCIe UART (rev 03)
@@ -637,7 +637,7 @@ of the chipset bridge (also called "root port") with address::
Bus: 0 - Device: 14 - Function: 1
To find this information, it is necessary to disassemble the BIOS ACPI tables,
-in particular the DSDT (see also [2])::
+in particular the DSDT (see also [2]_)::
mkdir ~/tables/
cd ~/tables/
@@ -667,7 +667,7 @@ device::
}
... other definitions follow ...
-and the _ADR method [3] returns exactly the device/function couple that
+and the _ADR method [3]_ returns exactly the device/function couple that
we are looking for. With this information and analyzing the above ``lspci``
output (both the devices list and the devices tree), we can write the following
ACPI description for the Exar PCIe UART, also adding the list of its GPIO line
@@ -724,10 +724,10 @@ created analyzing the position of the Exar UART in the PCI bus topology.
References
==========
-[1] Documentation/firmware-guide/acpi/gpio-properties.rst
+.. [1] Documentation/firmware-guide/acpi/gpio-properties.rst
-[2] Documentation/admin-guide/acpi/initrd_table_override.rst
+.. [2] Documentation/admin-guide/acpi/initrd_table_override.rst
-[3] ACPI Specifications, Version 6.3 - Paragraph 6.1.1 _ADR Address)
+.. [3] ACPI Specifications, Version 6.3 - Paragraph 6.1.1 _ADR Address)
https://uefi.org/sites/default/files/resources/ACPI_6_3_May16.pdf,
referenced 2020-11-18
diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst
index b6a42f4ffe..b246902f52 100644
--- a/Documentation/firmware-guide/acpi/index.rst
+++ b/Documentation/firmware-guide/acpi/index.rst
@@ -14,7 +14,6 @@ ACPI Support
dsd/phy
enumeration
osi
- method-customizing
method-tracing
DSD-properties-rules
debug
diff --git a/Documentation/firmware-guide/acpi/method-customizing.rst b/Documentation/firmware-guide/acpi/method-customizing.rst
deleted file mode 100644
index de3ebcaed4..0000000000
--- a/Documentation/firmware-guide/acpi/method-customizing.rst
+++ /dev/null
@@ -1,89 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-=======================================
-Linux ACPI Custom Control Method How To
-=======================================
-
-:Author: Zhang Rui <rui.zhang@intel.com>
-
-
-Linux supports customizing ACPI control methods at runtime.
-
-Users can use this to:
-
-1. override an existing method which may not work correctly,
- or just for debugging purposes.
-2. insert a completely new method in order to create a missing
- method such as _OFF, _ON, _STA, _INI, etc.
-
-For these cases, it is far simpler to dynamically install a single
-control method rather than override the entire DSDT, because kernel
-rebuild/reboot is not needed and test result can be got in minutes.
-
-.. note::
-
- - Only ACPI METHOD can be overridden, any other object types like
- "Device", "OperationRegion", are not recognized. Methods
- declared inside scope operators are also not supported.
-
- - The same ACPI control method can be overridden for many times,
- and it's always the latest one that used by Linux/kernel.
-
- - To get the ACPI debug object output (Store (AAAA, Debug)),
- please run::
-
- echo 1 > /sys/module/acpi/parameters/aml_debug_output
-
-
-1. override an existing method
-==============================
-a) get the ACPI table via ACPI sysfs I/F. e.g. to get the DSDT,
- just run "cat /sys/firmware/acpi/tables/DSDT > /tmp/dsdt.dat"
-b) disassemble the table by running "iasl -d dsdt.dat".
-c) rewrite the ASL code of the method and save it in a new file,
-d) package the new file (psr.asl) to an ACPI table format.
- Here is an example of a customized \_SB._AC._PSR method::
-
- DefinitionBlock ("", "SSDT", 1, "", "", 0x20080715)
- {
- Method (\_SB_.AC._PSR, 0, NotSerialized)
- {
- Store ("In AC _PSR", Debug)
- Return (ACON)
- }
- }
-
- Note that the full pathname of the method in ACPI namespace
- should be used.
-e) assemble the file to generate the AML code of the method.
- e.g. "iasl -vw 6084 psr.asl" (psr.aml is generated as a result)
- If parameter "-vw 6084" is not supported by your iASL compiler,
- please try a newer version.
-f) mount debugfs by "mount -t debugfs none /sys/kernel/debug"
-g) override the old method via the debugfs by running
- "cat /tmp/psr.aml > /sys/kernel/debug/acpi/custom_method"
-
-2. insert a new method
-======================
-This is easier than overriding an existing method.
-We just need to create the ASL code of the method we want to
-insert and then follow the step c) ~ g) in section 1.
-
-3. undo your changes
-====================
-The "undo" operation is not supported for a new inserted method
-right now, i.e. we can not remove a method currently.
-For an overridden method, in order to undo your changes, please
-save a copy of the method original ASL code in step c) section 1,
-and redo step c) ~ g) to override the method with the original one.
-
-
-.. note:: We can use a kernel with multiple custom ACPI method running,
- But each individual write to debugfs can implement a SINGLE
- method override. i.e. if we want to insert/override multiple
- ACPI methods, we need to redo step c) ~ g) for multiple times.
-
-.. note:: Be aware that root can mis-use this driver to modify arbitrary
- memory and gain additional rights, if root's privileges got
- restricted (for example if root is not allowed to load additional
- modules after boot).