Pull ACPI updates from Rafael Wysocki: "These rearrange the ACPI documentation by converting it to the .rst format and splitting it into clear categories (admin guide, driver API, firmware guide), switch over multiple users of a problematic library function to a new better one, update the ACPICA code in the kernel to a new upstream release, fix a few issues, improve power device management diagnostics and do some cleanups. Specifics: - Convert the ACPI documentation in the kernel source tree to the .rst format and split it into the admin guide, driver API and firmware guide parts (Changbin Du). - Add a PRP0001 usage example to the ACPI documentation (Thomas Preston). - Switch over the users of the acpi_dev_get_first_match_name() library function which turned out to be problematic to a new, better one called acpi_dev_get_first_match_dev() (Andy Shevchenko, YueHaibing). - Update the ACPICA code in the kernel to upstream release 20190405 including: * Null pointer dereference check in acpi_ns_delete_node() (Erik Schmauss). * Multiple macro and function name changes (Bob Moore). * Predefined operation region name fix (Erik Schmauss). - Fix hibernation issue on systems using the Baytrail and Cherrytrail Intel SoCs introduced during the 4.20 development cycle (Hans de Goede). - Add Sony VPCEH3U1E to the backlight quirk list (Zhang Rui). - Fix button handling during system resume (Zhang Rui). - Add a device PM diagnostic message (Rafael Wysocki). - Clean up the code, comments and white space in multiple places (Bjorn Helgaas, Gustavo Silva, Kefeng Wang)" * tag 'acpi-5.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (53 commits) Documentation: ACPI: move video_extension.txt to firmware-guide/acpi and convert to reST Documentation: ACPI: move ssdt-overlays.txt to admin-guide/acpi and convert to reST Documentation: ACPI: move lpit.txt to firmware-guide/acpi and convert to reST Documentation: ACPI: move cppc_sysfs.txt to admin-guide/acpi and convert to reST Documentation: ACPI: move apei/einj.txt to firmware-guide/acpi and convert to reST Documentation: ACPI: move apei/output_format.txt to firmware-guide/acpi and convert to reST Documentation: ACPI: move aml-debugger.txt to firmware-guide/acpi and convert to reST Documentation: ACPI: move method-tracing.txt to firmware-guide/acpi and convert to rsST Documentation: ACPI: move debug.txt to firmware-guide/acpi and convert to reST Documentation: ACPI: move dsd/data-node-references.txt to firmware-guide/acpi and convert to reST Documentation: ACPI: move dsd/graph.txt to firmware-guide/acpi and convert to reST Documentation: ACPI: move acpi-lid.txt to firmware-guide/acpi and convert to reST Documentation: ACPI: move i2c-muxes.txt to firmware-guide/acpi and convert to reST Documentation: ACPI: move dsdt-override.txt to admin-guide/acpi and convert to reST Documentation: ACPI: move initrd_table_override.txt to admin-guide/acpi and convert to reST Documentation: ACPI: move method-customizing.txt to firmware-guide/acpi and convert to reST Documentation: ACPI: move gpio-properties.txt to firmware-guide/acpi and convert to reST Documentation: ACPI: move DSD-properties-rules.txt to firmware-guide/acpi and covert to reST Documentation: ACPI: move scan_handlers.txt to driver-api/acpi and convert to reST Documentation: ACPI: move linuxized-acpica.txt to driver-api/acpi and convert to reST ...
Unified · Split
| @@ -1,66 +0,0 @@ | ||
| 1 | −The AML Debugger | |
| 2 | − | |
| 3 | −Copyright (C) 2016, Intel Corporation | |
| 4 | −Author: Lv Zheng <lv.zheng@intel.com> | |
| 5 | − | |
| 6 | − | |
| 7 | −This document describes the usage of the AML debugger embedded in the Linux | |
| 8 | −kernel. | |
| 9 | − | |
| 10 | −1. Build the debugger | |
| 11 | − | |
| 12 | − The following kernel configuration items are required to enable the AML | |
| 13 | − debugger interface from the Linux kernel: | |
| 14 | − | |
| 15 | − CONFIG_ACPI_DEBUGGER=y | |
| 16 | − CONFIG_ACPI_DEBUGGER_USER=m | |
| 17 | − | |
| 18 | − The userspace utilities can be built from the kernel source tree using | |
| 19 | − the following commands: | |
| 20 | − | |
| 21 | − $ cd tools | |
| 22 | − $ make acpi | |
| 23 | − | |
| 24 | − The resultant userspace tool binary is then located at: | |
| 25 | − | |
| 26 | − tools/power/acpi/acpidbg | |
| 27 | − | |
| 28 | − It can be installed to system directories by running "make install" (as a | |
| 29 | − sufficiently privileged user). | |
| 30 | − | |
| 31 | −2. Start the userspace debugger interface | |
| 32 | − | |
| 33 | − After booting the kernel with the debugger built-in, the debugger can be | |
| 34 | − started by using the following commands: | |
| 35 | − | |
| 36 | − # mount -t debugfs none /sys/kernel/debug | |
| 37 | − # modprobe acpi_dbg | |
| 38 | − # tools/power/acpi/acpidbg | |
| 39 | − | |
| 40 | − That spawns the interactive AML debugger environment where you can execute | |
| 41 | − debugger commands. | |
| 42 | − | |
| 43 | − The commands are documented in the "ACPICA Overview and Programmer Reference" | |
| 44 | − that can be downloaded from | |
| 45 | − | |
| 46 | − https://acpica.org/documentation | |
| 47 | − | |
| 48 | − The detailed debugger commands reference is located in Chapter 12 "ACPICA | |
| 49 | − Debugger Reference". The "help" command can be used for a quick reference. | |
| 50 | − | |
| 51 | −3. Stop the userspace debugger interface | |
| 52 | − | |
| 53 | − The interactive debugger interface can be closed by pressing Ctrl+C or using | |
| 54 | − the "quit" or "exit" commands. When finished, unload the module with: | |
| 55 | − | |
| 56 | − # rmmod acpi_dbg | |
| 57 | − | |
| 58 | − The module unloading may fail if there is an acpidbg instance running. | |
| 59 | − | |
| 60 | −4. Run the debugger in a script | |
| 61 | − | |
| 62 | − It may be useful to run the AML debugger in a test script. "acpidbg" supports | |
| 63 | − this in a special "batch" mode. For example, the following command outputs | |
| 64 | − the entire ACPI namespace: | |
| 65 | − | |
| 66 | − # acpidbg -b "namespace" | |
| @@ -1,147 +0,0 @@ | ||
| 1 | − APEI output format | |
| 2 | − ~~~~~~~~~~~~~~~~~~ | |
| 3 | − | |
| 4 | −APEI uses printk as hardware error reporting interface, the output | |
| 5 | −format is as follow. | |
| 6 | − | |
| 7 | −<error record> := | |
| 8 | −APEI generic hardware error status | |
| 9 | −severity: <integer>, <severity string> | |
| 10 | −section: <integer>, severity: <integer>, <severity string> | |
| 11 | −flags: <integer> | |
| 12 | −<section flags strings> | |
| 13 | −fru_id: <uuid string> | |
| 14 | −fru_text: <string> | |
| 15 | −section_type: <section type string> | |
| 16 | −<section data> | |
| 17 | − | |
| 18 | −<severity string>* := recoverable | fatal | corrected | info | |
| 19 | − | |
| 20 | −<section flags strings># := | |
| 21 | −[primary][, containment warning][, reset][, threshold exceeded]\ | |
| 22 | −[, resource not accessible][, latent error] | |
| 23 | − | |
| 24 | −<section type string> := generic processor error | memory error | \ | |
| 25 | −PCIe error | unknown, <uuid string> | |
| 26 | − | |
| 27 | −<section data> := | |
| 28 | −<generic processor section data> | <memory section data> | \ | |
| 29 | −<pcie section data> | <null> | |
| 30 | − | |
| 31 | −<generic processor section data> := | |
| 32 | −[processor_type: <integer>, <proc type string>] | |
| 33 | −[processor_isa: <integer>, <proc isa string>] | |
| 34 | −[error_type: <integer> | |
| 35 | −<proc error type strings>] | |
| 36 | −[operation: <integer>, <proc operation string>] | |
| 37 | −[flags: <integer> | |
| 38 | −<proc flags strings>] | |
| 39 | −[level: <integer>] | |
| 40 | −[version_info: <integer>] | |
| 41 | −[processor_id: <integer>] | |
| 42 | −[target_address: <integer>] | |
| 43 | −[requestor_id: <integer>] | |
| 44 | −[responder_id: <integer>] | |
| 45 | −[IP: <integer>] | |
| 46 | − | |
| 47 | −<proc type string>* := IA32/X64 | IA64 | |
| 48 | − | |
| 49 | −<proc isa string>* := IA32 | IA64 | X64 | |
| 50 | − | |
| 51 | −<processor error type strings># := | |
| 52 | −[cache error][, TLB error][, bus error][, micro-architectural error] | |
| 53 | − | |
| 54 | −<proc operation string>* := unknown or generic | data read | data write | \ | |
| 55 | −instruction execution | |
| 56 | − | |
| 57 | −<proc flags strings># := | |
| 58 | −[restartable][, precise IP][, overflow][, corrected] | |
| 59 | − | |
| 60 | −<memory section data> := | |
| 61 | −[error_status: <integer>] | |
| 62 | −[physical_address: <integer>] | |
| 63 | −[physical_address_mask: <integer>] | |
| 64 | −[node: <integer>] | |
| 65 | −[card: <integer>] | |
| 66 | −[module: <integer>] | |
| 67 | −[bank: <integer>] | |
| 68 | −[device: <integer>] | |
| 69 | −[row: <integer>] | |
| 70 | −[column: <integer>] | |
| 71 | −[bit_position: <integer>] | |
| 72 | −[requestor_id: <integer>] | |
| 73 | −[responder_id: <integer>] | |
| 74 | −[target_id: <integer>] | |
| 75 | −[error_type: <integer>, <mem error type string>] | |
| 76 | − | |
| 77 | −<mem error type string>* := | |
| 78 | −unknown | no error | single-bit ECC | multi-bit ECC | \ | |
| 79 | −single-symbol chipkill ECC | multi-symbol chipkill ECC | master abort | \ | |
| 80 | −target abort | parity error | watchdog timeout | invalid address | \ | |
| 81 | −mirror Broken | memory sparing | scrub corrected error | \ | |
| 82 | −scrub uncorrected error | |
| 83 | − | |
| 84 | −<pcie section data> := | |
| 85 | −[port_type: <integer>, <pcie port type string>] | |
| 86 | −[version: <integer>.<integer>] | |
| 87 | −[command: <integer>, status: <integer>] | |
| 88 | −[device_id: <integer>:<integer>:<integer>.<integer> | |
| 89 | −slot: <integer> | |
| 90 | −secondary_bus: <integer> | |
| 91 | −vendor_id: <integer>, device_id: <integer> | |
| 92 | −class_code: <integer>] | |
| 93 | −[serial number: <integer>, <integer>] | |
| 94 | −[bridge: secondary_status: <integer>, control: <integer>] | |
| 95 | −[aer_status: <integer>, aer_mask: <integer> | |
| 96 | −<aer status string> | |
| 97 | −[aer_uncor_severity: <integer>] | |
| 98 | −aer_layer=<aer layer string>, aer_agent=<aer agent string> | |
| 99 | −aer_tlp_header: <integer> <integer> <integer> <integer>] | |
| 100 | − | |
| 101 | −<pcie port type string>* := PCIe end point | legacy PCI end point | \ | |
| 102 | −unknown | unknown | root port | upstream switch port | \ | |
| 103 | −downstream switch port | PCIe to PCI/PCI-X bridge | \ | |
| 104 | −PCI/PCI-X to PCIe bridge | root complex integrated endpoint device | \ | |
| 105 | −root complex event collector | |
| 106 | − | |
| 107 | −if section severity is fatal or recoverable | |
| 108 | −<aer status string># := | |
| 109 | −unknown | unknown | unknown | unknown | Data Link Protocol | \ | |
| 110 | −unknown | unknown | unknown | unknown | unknown | unknown | unknown | \ | |
| 111 | −Poisoned TLP | Flow Control Protocol | Completion Timeout | \ | |
| 112 | −Completer Abort | Unexpected Completion | Receiver Overflow | \ | |
| 113 | −Malformed TLP | ECRC | Unsupported Request | |
| 114 | −else | |
| 115 | −<aer status string># := | |
| 116 | −Receiver Error | unknown | unknown | unknown | unknown | unknown | \ | |
| 117 | −Bad TLP | Bad DLLP | RELAY_NUM Rollover | unknown | unknown | unknown | \ | |
| 118 | −Replay Timer Timeout | Advisory Non-Fatal | |
| 119 | −fi | |
| 120 | − | |
| 121 | −<aer layer string> := | |
| 122 | −Physical Layer | Data Link Layer | Transaction Layer | |
| 123 | − | |
| 124 | −<aer agent string> := | |
| 125 | −Receiver ID | Requester ID | Completer ID | Transmitter ID | |
| 126 | − | |
| 127 | −Where, [] designate corresponding content is optional | |
| 128 | − | |
| 129 | −All <field string> description with * has the following format: | |
| 130 | − | |
| 131 | −field: <integer>, <field string> | |
| 132 | − | |
| 133 | −Where value of <integer> should be the position of "string" in <field | |
| 134 | −string> description. Otherwise, <field string> will be "unknown". | |
| 135 | − | |
| 136 | −All <field strings> description with # has the following format: | |
| 137 | − | |
| 138 | −field: <integer> | |
| 139 | −<field strings> | |
| 140 | − | |
| 141 | −Where each string in <fields strings> corresponding to one set bit of | |
| 142 | −<integer>. The bit position is the position of "string" in <field | |
| 143 | −strings> description. | |
| 144 | − | |
| 145 | −For more detailed explanation of every field, please refer to UEFI | |
| 146 | −specification version 2.3 or later, section Appendix N: Common | |
| 147 | −Platform Error Record. | |
| @@ -1,58 +0,0 @@ | ||
| 1 | −ACPI I2C Muxes | |
| 2 | −-------------- | |
| 3 | − | |
| 4 | −Describing an I2C device hierarchy that includes I2C muxes requires an ACPI | |
| 5 | −Device () scope per mux channel. | |
| 6 | − | |
| 7 | −Consider this topology: | |
| 8 | − | |
| 9 | −+------+ +------+ | |
| 10 | −| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50) | |
| 11 | −| | | 0x70 |--CH01--> i2c client B (0x50) | |
| 12 | −+------+ +------+ | |
| 13 | − | |
| 14 | −which corresponds to the following ASL: | |
| 15 | − | |
| 16 | −Device (SMB1) | |
| 17 | −{ | |
| 18 | − Name (_HID, ...) | |
| 19 | − Device (MUX0) | |
| 20 | − { | |
| 21 | − Name (_HID, ...) | |
| 22 | − Name (_CRS, ResourceTemplate () { | |
| 23 | − I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED, | |
| 24 | − AddressingMode7Bit, "^SMB1", 0x00, | |
| 25 | − ResourceConsumer,,) | |
| 26 | − } | |
| 27 | − | |
| 28 | − Device (CH00) | |
| 29 | − { | |
| 30 | − Name (_ADR, 0) | |
| 31 | − | |
| 32 | − Device (CLIA) | |
| 33 | − { | |
| 34 | − Name (_HID, ...) | |
| 35 | − Name (_CRS, ResourceTemplate () { | |
| 36 | − I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED, | |
| 37 | − AddressingMode7Bit, "^CH00", 0x00, | |
| 38 | − ResourceConsumer,,) | |
| 39 | − } | |
| 40 | − } | |
| 41 | − } | |
| 42 | − | |
| 43 | − Device (CH01) | |
| 44 | − { | |
| 45 | − Name (_ADR, 1) | |
| 46 | − | |
| 47 | − Device (CLIB) | |
| 48 | − { | |
| 49 | − Name (_HID, ...) | |
| 50 | − Name (_CRS, ResourceTemplate () { | |
| 51 | − I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED, | |
| 52 | − AddressingMode7Bit, "^CH01", 0x00, | |
| 53 | − ResourceConsumer,,) | |
| 54 | − } | |
| 55 | − } | |
| 56 | − } | |
| 57 | − } | |
| 58 | −} | |
| @@ -1,111 +0,0 @@ | ||
| 1 | −Upgrading ACPI tables via initrd | |
| 2 | −================================ | |
| 3 | − | |
| 4 | −1) Introduction (What is this about) | |
| 5 | −2) What is this for | |
| 6 | −3) How does it work | |
| 7 | −4) References (Where to retrieve userspace tools) | |
| 8 | − | |
| 9 | −1) What is this about | |
| 10 | −--------------------- | |
| 11 | − | |
| 12 | −If the ACPI_TABLE_UPGRADE compile option is true, it is possible to | |
| 13 | −upgrade the ACPI execution environment that is defined by the ACPI tables | |
| 14 | −via upgrading the ACPI tables provided by the BIOS with an instrumented, | |
| 15 | −modified, more recent version one, or installing brand new ACPI tables. | |
| 16 | − | |
| 17 | −When building initrd with kernel in a single image, option | |
| 18 | −ACPI_TABLE_OVERRIDE_VIA_BUILTIN_INITRD should also be true for this | |
| 19 | −feature to work. | |
| 20 | − | |
| 21 | −For a full list of ACPI tables that can be upgraded/installed, take a look | |
| 22 | −at the char *table_sigs[MAX_ACPI_SIGNATURE]; definition in | |
| 23 | −drivers/acpi/tables.c. | |
| 24 | −All ACPI tables iasl (Intel's ACPI compiler and disassembler) knows should | |
| 25 | −be overridable, except: | |
| 26 | − - ACPI_SIG_RSDP (has a signature of 6 bytes) | |
| 27 | − - ACPI_SIG_FACS (does not have an ordinary ACPI table header) | |
| 28 | −Both could get implemented as well. | |
| 29 | − | |
| 30 | − | |
| 31 | −2) What is this for | |
| 32 | −------------------- | |
| 33 | − | |
| 34 | −Complain to your platform/BIOS vendor if you find a bug which is so severe | |
| 35 | −that a workaround is not accepted in the Linux kernel. And this facility | |
| 36 | −allows you to upgrade the buggy tables before your platform/BIOS vendor | |
| 37 | −releases an upgraded BIOS binary. | |
| 38 | − | |
| 39 | −This facility can be used by platform/BIOS vendors to provide a Linux | |
| 40 | −compatible environment without modifying the underlying platform firmware. | |
| 41 | − | |
| 42 | −This facility also provides a powerful feature to easily debug and test | |
| 43 | −ACPI BIOS table compatibility with the Linux kernel by modifying old | |
| 44 | −platform provided ACPI tables or inserting new ACPI tables. | |
| 45 | − | |
| 46 | −It can and should be enabled in any kernel because there is no functional | |
| 47 | −change with not instrumented initrds. | |
| 48 | − | |
| 49 | − | |
| 50 | −3) How does it work | |
| 51 | −------------------- | |
| 52 | − | |
| 53 | −# Extract the machine's ACPI tables: | |
| 54 | −cd /tmp | |
| 55 | −acpidump >acpidump | |
| 56 | −acpixtract -a acpidump | |
| 57 | −# Disassemble, modify and recompile them: | |
| 58 | −iasl -d *.dat | |
| 59 | −# For example add this statement into a _PRT (PCI Routing Table) function | |
| 60 | −# of the DSDT: | |
| 61 | −Store("HELLO WORLD", debug) | |
| 62 | −# And increase the OEM Revision. For example, before modification: | |
| 63 | −DefinitionBlock ("DSDT.aml", "DSDT", 2, "INTEL ", "TEMPLATE", 0x00000000) | |
| 64 | −# After modification: | |
| 65 | −DefinitionBlock ("DSDT.aml", "DSDT", 2, "INTEL ", "TEMPLATE", 0x00000001) | |
| 66 | −iasl -sa dsdt.dsl | |
| 67 | −# Add the raw ACPI tables to an uncompressed cpio archive. | |
| 68 | −# They must be put into a /kernel/firmware/acpi directory inside the cpio | |
| 69 | −# archive. Note that if the table put here matches a platform table | |
| 70 | −# (similar Table Signature, and similar OEMID, and similar OEM Table ID) | |
| 71 | −# with a more recent OEM Revision, the platform table will be upgraded by | |
| 72 | −# this table. If the table put here doesn't match a platform table | |
| 73 | −# (dissimilar Table Signature, or dissimilar OEMID, or dissimilar OEM Table | |
| 74 | −# ID), this table will be appended. | |
| 75 | −mkdir -p kernel/firmware/acpi | |
| 76 | −cp dsdt.aml kernel/firmware/acpi | |
| 77 | −# A maximum of "NR_ACPI_INITRD_TABLES (64)" tables are currently allowed | |
| 78 | −# (see osl.c): | |
| 79 | −iasl -sa facp.dsl | |
| 80 | −iasl -sa ssdt1.dsl | |
| 81 | −cp facp.aml kernel/firmware/acpi | |
| 82 | −cp ssdt1.aml kernel/firmware/acpi | |
| 83 | −# The uncompressed cpio archive must be the first. Other, typically | |
| 84 | −# compressed cpio archives, must be concatenated on top of the uncompressed | |
| 85 | −# one. Following command creates the uncompressed cpio archive and | |
| 86 | −# concatenates the original initrd on top: | |
| 87 | −find kernel | cpio -H newc --create > /boot/instrumented_initrd | |
| 88 | −cat /boot/initrd >>/boot/instrumented_initrd | |
| 89 | −# reboot with increased acpi debug level, e.g. boot params: | |
| 90 | −acpi.debug_level=0x2 acpi.debug_layer=0xFFFFFFFF | |
| 91 | −# and check your syslog: | |
| 92 | −[ 1.268089] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] | |
| 93 | −[ 1.272091] [ACPI Debug] String [0x0B] "HELLO WORLD" | |
| 94 | − | |
| 95 | −iasl is able to disassemble and recompile quite a lot different, | |
| 96 | −also static ACPI tables. | |
| 97 | − | |
| 98 | − | |
| 99 | −4) Where to retrieve userspace tools | |
| 100 | −------------------------------------ | |
| 101 | − | |
| 102 | −iasl and acpixtract are part of Intel's ACPICA project: | |
| 103 | −http://acpica.org/ | |
| 104 | −and should be packaged by distributions (for example in the acpica package | |
| 105 | −on SUSE). | |
| 106 | − | |
| 107 | −acpidump can be found in Len Browns pmtools: | |
| 108 | −ftp://kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools/acpidump | |
| 109 | −This tool is also part of the acpica package on SUSE. | |
| 110 | −Alternatively, used ACPI tables can be retrieved via sysfs in latest kernels: | |
| 111 | −/sys/firmware/acpi/tables | |
| @@ -1,73 +0,0 @@ | ||
| 1 | −Linux ACPI Custom Control Method How To | |
| 2 | −======================================= | |
| 3 | − | |
| 4 | −Written by Zhang Rui <rui.zhang@intel.com> | |
| 5 | − | |
| 6 | − | |
| 7 | −Linux supports customizing ACPI control methods at runtime. | |
| 8 | − | |
| 9 | −Users can use this to | |
| 10 | −1. override an existing method which may not work correctly, | |
| 11 | − or just for debugging purposes. | |
| 12 | −2. insert a completely new method in order to create a missing | |
| 13 | − method such as _OFF, _ON, _STA, _INI, etc. | |
| 14 | −For these cases, it is far simpler to dynamically install a single | |
| 15 | −control method rather than override the entire DSDT, because kernel | |
| 16 | −rebuild/reboot is not needed and test result can be got in minutes. | |
| 17 | − | |
| 18 | −Note: Only ACPI METHOD can be overridden, any other object types like | |
| 19 | − "Device", "OperationRegion", are not recognized. Methods | |
| 20 | − declared inside scope operators are also not supported. | |
| 21 | −Note: The same ACPI control method can be overridden for many times, | |
| 22 | − and it's always the latest one that used by Linux/kernel. | |
| 23 | −Note: To get the ACPI debug object output (Store (AAAA, Debug)), | |
| 24 | − please run "echo 1 > /sys/module/acpi/parameters/aml_debug_output". | |
| 25 | − | |
| 26 | −1. override an existing method | |
| 27 | − a) get the ACPI table via ACPI sysfs I/F. e.g. to get the DSDT, | |
| 28 | − just run "cat /sys/firmware/acpi/tables/DSDT > /tmp/dsdt.dat" | |
| 29 | − b) disassemble the table by running "iasl -d dsdt.dat". | |
| 30 | − c) rewrite the ASL code of the method and save it in a new file, | |
| 31 | − d) package the new file (psr.asl) to an ACPI table format. | |
| 32 | − Here is an example of a customized \_SB._AC._PSR method, | |
| 33 | − | |
| 34 | − DefinitionBlock ("", "SSDT", 1, "", "", 0x20080715) | |
| 35 | − { | |
| 36 | − Method (\_SB_.AC._PSR, 0, NotSerialized) | |
| 37 | − { | |
| 38 | − Store ("In AC _PSR", Debug) | |
| 39 | − Return (ACON) | |
| 40 | − } | |
| 41 | − } | |
| 42 | − Note that the full pathname of the method in ACPI namespace | |
| 43 | − should be used. | |
| 44 | − e) assemble the file to generate the AML code of the method. | |
| 45 | − e.g. "iasl -vw 6084 psr.asl" (psr.aml is generated as a result) | |
| 46 | − If parameter "-vw 6084" is not supported by your iASL compiler, | |
| 47 | − please try a newer version. | |
| 48 | − f) mount debugfs by "mount -t debugfs none /sys/kernel/debug" | |
| 49 | − g) override the old method via the debugfs by running | |
| 50 | − "cat /tmp/psr.aml > /sys/kernel/debug/acpi/custom_method" | |
| 51 | − | |
| 52 | −2. insert a new method | |
| 53 | − This is easier than overriding an existing method. | |
| 54 | − We just need to create the ASL code of the method we want to | |
| 55 | − insert and then follow the step c) ~ g) in section 1. | |
| 56 | − | |
| 57 | −3. undo your changes | |
| 58 | − The "undo" operation is not supported for a new inserted method | |
| 59 | − right now, i.e. we can not remove a method currently. | |
| 60 | − For an overridden method, in order to undo your changes, please | |
| 61 | − save a copy of the method original ASL code in step c) section 1, | |
| 62 | − and redo step c) ~ g) to override the method with the original one. | |
| 63 | − | |
| 64 | − | |
| 65 | −Note: We can use a kernel with multiple custom ACPI method running, | |
| 66 | − But each individual write to debugfs can implement a SINGLE | |
| 67 | − method override. i.e. if we want to insert/override multiple | |
| 68 | − ACPI methods, we need to redo step c) ~ g) for multiple times. | |
| 69 | − | |
| 70 | −Note: Be aware that root can mis-use this driver to modify arbitrary | |
| 71 | − memory and gain additional rights, if root's privileges got | |
| 72 | − restricted (for example if root is not allowed to load additional | |
| 73 | − modules after boot). | |
| @@ -1,192 +0,0 @@ | ||
| 1 | −ACPICA Trace Facility | |
| 2 | − | |
| 3 | −Copyright (C) 2015, Intel Corporation | |
| 4 | −Author: Lv Zheng <lv.zheng@intel.com> | |
| 5 | − | |
| 6 | − | |
| 7 | −Abstract: | |
| 8 | − | |
| 9 | −This document describes the functions and the interfaces of the method | |
| 10 | −tracing facility. | |
| 11 | − | |
| 12 | −1. Functionalities and usage examples: | |
| 13 | − | |
| 14 | − ACPICA provides method tracing capability. And two functions are | |
| 15 | − currently implemented using this capability. | |
| 16 | − | |
| 17 | − A. Log reducer | |
| 18 | − ACPICA subsystem provides debugging outputs when CONFIG_ACPI_DEBUG is | |
| 19 | − enabled. The debugging messages which are deployed via | |
| 20 | − ACPI_DEBUG_PRINT() macro can be reduced at 2 levels - per-component | |
| 21 | − level (known as debug layer, configured via | |
| 22 | − /sys/module/acpi/parameters/debug_layer) and per-type level (known as | |
| 23 | − debug level, configured via /sys/module/acpi/parameters/debug_level). | |
| 24 | − | |
| 25 | − But when the particular layer/level is applied to the control method | |
| 26 | − evaluations, the quantity of the debugging outputs may still be too | |
| 27 | − large to be put into the kernel log buffer. The idea thus is worked out | |
| 28 | − to only enable the particular debug layer/level (normally more detailed) | |
| 29 | − logs when the control method evaluation is started, and disable the | |
| 30 | − detailed logging when the control method evaluation is stopped. | |
| 31 | − | |
| 32 | − The following command examples illustrate the usage of the "log reducer" | |
| 33 | − functionality: | |
| 34 | − a. Filter out the debug layer/level matched logs when control methods | |
| 35 | − are being evaluated: | |
| 36 | − # cd /sys/module/acpi/parameters | |
| 37 | − # echo "0xXXXXXXXX" > trace_debug_layer | |
| 38 | − # echo "0xYYYYYYYY" > trace_debug_level | |
| 39 | − # echo "enable" > trace_state | |
| 40 | − b. Filter out the debug layer/level matched logs when the specified | |
| 41 | − control method is being evaluated: | |
| 42 | − # cd /sys/module/acpi/parameters | |
| 43 | − # echo "0xXXXXXXXX" > trace_debug_layer | |
| 44 | − # echo "0xYYYYYYYY" > trace_debug_level | |
| 45 | − # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name | |
| 46 | − # echo "method" > /sys/module/acpi/parameters/trace_state | |
| 47 | − c. Filter out the debug layer/level matched logs when the specified | |
| 48 | − control method is being evaluated for the first time: | |
| 49 | − # cd /sys/module/acpi/parameters | |
| 50 | − # echo "0xXXXXXXXX" > trace_debug_layer | |
| 51 | − # echo "0xYYYYYYYY" > trace_debug_level | |
| 52 | − # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name | |
| 53 | − # echo "method-once" > /sys/module/acpi/parameters/trace_state | |
| 54 | − Where: | |
| 55 | − 0xXXXXXXXX/0xYYYYYYYY: Refer to Documentation/acpi/debug.txt for | |
| 56 | − possible debug layer/level masking values. | |
| 57 | − \PPPP.AAAA.TTTT.HHHH: Full path of a control method that can be found | |
| 58 | − in the ACPI namespace. It needn't be an entry | |
| 59 | − of a control method evaluation. | |
| 60 | − | |
| 61 | − B. AML tracer | |
| 62 | − | |
| 63 | − There are special log entries added by the method tracing facility at | |
| 64 | − the "trace points" the AML interpreter starts/stops to execute a control | |
| 65 | − method, or an AML opcode. Note that the format of the log entries are | |
| 66 | − subject to change: | |
| 67 | − [ 0.186427] exdebug-0398 ex_trace_point : Method Begin [0xf58394d8:\_SB.PCI0.LPCB.ECOK] execution. | |
| 68 | − [ 0.186630] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905c88:If] execution. | |
| 69 | − [ 0.186820] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905cc0:LEqual] execution. | |
| 70 | − [ 0.187010] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905a20:-NamePath-] execution. | |
| 71 | − [ 0.187214] exdebug-0398 ex_trace_point : Opcode End [0xf5905a20:-NamePath-] execution. | |
| 72 | − [ 0.187407] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905f60:One] execution. | |
| 73 | − [ 0.187594] exdebug-0398 ex_trace_point : Opcode End [0xf5905f60:One] execution. | |
| 74 | − [ 0.187789] exdebug-0398 ex_trace_point : Opcode End [0xf5905cc0:LEqual] execution. | |
| 75 | − [ 0.187980] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905cc0:Return] execution. | |
| 76 | − [ 0.188146] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905f60:One] execution. | |
| 77 | − [ 0.188334] exdebug-0398 ex_trace_point : Opcode End [0xf5905f60:One] execution. | |
| 78 | − [ 0.188524] exdebug-0398 ex_trace_point : Opcode End [0xf5905cc0:Return] execution. | |
| 79 | − [ 0.188712] exdebug-0398 ex_trace_point : Opcode End [0xf5905c88:If] execution. | |
| 80 | − [ 0.188903] exdebug-0398 ex_trace_point : Method End [0xf58394d8:\_SB.PCI0.LPCB.ECOK] execution. | |
| 81 | − | |
| 82 | − Developers can utilize these special log entries to track the AML | |
| 83 | − interpretion, thus can aid issue debugging and performance tuning. Note | |
| 84 | − that, as the "AML tracer" logs are implemented via ACPI_DEBUG_PRINT() | |
| 85 | − macro, CONFIG_ACPI_DEBUG is also required to be enabled for enabling | |
| 86 | − "AML tracer" logs. | |
| 87 | − | |
| 88 | − The following command examples illustrate the usage of the "AML tracer" | |
| 89 | − functionality: | |
| 90 | − a. Filter out the method start/stop "AML tracer" logs when control | |
| 91 | − methods are being evaluated: | |
| 92 | − # cd /sys/module/acpi/parameters | |
| 93 | − # echo "0x80" > trace_debug_layer | |
| 94 | − # echo "0x10" > trace_debug_level | |
| 95 | − # echo "enable" > trace_state | |
| 96 | − b. Filter out the method start/stop "AML tracer" when the specified | |
| 97 | − control method is being evaluated: | |
| 98 | − # cd /sys/module/acpi/parameters | |
| 99 | − # echo "0x80" > trace_debug_layer | |
| 100 | − # echo "0x10" > trace_debug_level | |
| 101 | − # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name | |
| 102 | − # echo "method" > trace_state | |
| 103 | − c. Filter out the method start/stop "AML tracer" logs when the specified | |
| 104 | − control method is being evaluated for the first time: | |
| 105 | − # cd /sys/module/acpi/parameters | |
| 106 | − # echo "0x80" > trace_debug_layer | |
| 107 | − # echo "0x10" > trace_debug_level | |
| 108 | − # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name | |
| 109 | − # echo "method-once" > trace_state | |
| 110 | − d. Filter out the method/opcode start/stop "AML tracer" when the | |
| 111 | − specified control method is being evaluated: | |
| 112 | − # cd /sys/module/acpi/parameters | |
| 113 | − # echo "0x80" > trace_debug_layer | |
| 114 | − # echo "0x10" > trace_debug_level | |
| 115 | − # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name | |
| 116 | − # echo "opcode" > trace_state | |
| 117 | − e. Filter out the method/opcode start/stop "AML tracer" when the | |
| 118 | − specified control method is being evaluated for the first time: | |
| 119 | − # cd /sys/module/acpi/parameters | |
| 120 | − # echo "0x80" > trace_debug_layer | |
| 121 | − # echo "0x10" > trace_debug_level | |
| 122 | − # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name | |
| 123 | − # echo "opcode-opcode" > trace_state | |
| 124 | − | |
| 125 | − Note that all above method tracing facility related module parameters can | |
| 126 | − be used as the boot parameters, for example: | |
| 127 | − acpi.trace_debug_layer=0x80 acpi.trace_debug_level=0x10 \ | |
| 128 | − acpi.trace_method_name=\_SB.LID0._LID acpi.trace_state=opcode-once | |
| 129 | − | |
| 130 | −2. Interface descriptions: | |
| 131 | − | |
| 132 | − All method tracing functions can be configured via ACPI module | |
| 133 | − parameters that are accessible at /sys/module/acpi/parameters/: | |
| 134 | − | |
| 135 | − trace_method_name | |
| 136 | − The full path of the AML method that the user wants to trace. | |
| 137 | − Note that the full path shouldn't contain the trailing "_"s in its | |
| 138 | − name segments but may contain "\" to form an absolute path. | |
| 139 | − | |
| 140 | − trace_debug_layer | |
| 141 | − The temporary debug_layer used when the tracing feature is enabled. | |
| 142 | − Using ACPI_EXECUTER (0x80) by default, which is the debug_layer | |
| 143 | − used to match all "AML tracer" logs. | |
| 144 | − | |
| 145 | − trace_debug_level | |
| 146 | − The temporary debug_level used when the tracing feature is enabled. | |
| 147 | − Using ACPI_LV_TRACE_POINT (0x10) by default, which is the | |
| 148 | − debug_level used to match all "AML tracer" logs. | |
| 149 | − | |
| 150 | − trace_state | |
| 151 | − The status of the tracing feature. | |
| 152 | − Users can enable/disable this debug tracing feature by executing | |
| 153 | − the following command: | |
| 154 | − # echo string > /sys/module/acpi/parameters/trace_state | |
| 155 | − Where "string" should be one of the following: | |
| 156 | − "disable" | |
| 157 | − Disable the method tracing feature. | |
| 158 | − "enable" | |
| 159 | − Enable the method tracing feature. | |
| 160 | − ACPICA debugging messages matching | |
| 161 | − "trace_debug_layer/trace_debug_level" during any method | |
| 162 | − execution will be logged. | |
| 163 | − "method" | |
| 164 | − Enable the method tracing feature. | |
| 165 | − ACPICA debugging messages matching | |
| 166 | − "trace_debug_layer/trace_debug_level" during method execution | |
| 167 | − of "trace_method_name" will be logged. | |
| 168 | − "method-once" | |
| 169 | − Enable the method tracing feature. | |
| 170 | − ACPICA debugging messages matching | |
| 171 | − "trace_debug_layer/trace_debug_level" during method execution | |
| 172 | − of "trace_method_name" will be logged only once. | |
| 173 | − "opcode" | |
| 174 | − Enable the method tracing feature. | |
| 175 | − ACPICA debugging messages matching | |
| 176 | − "trace_debug_layer/trace_debug_level" during method/opcode | |
| 177 | − execution of "trace_method_name" will be logged. | |
| 178 | − "opcode-once" | |
| 179 | − Enable the method tracing feature. | |
| 180 | − ACPICA debugging messages matching | |
| 181 | − "trace_debug_layer/trace_debug_level" during method/opcode | |
| 182 | − execution of "trace_method_name" will be logged only once. | |
| 183 | − Note that, the difference between the "enable" and other feature | |
| 184 | − enabling options are: | |
| 185 | − 1. When "enable" is specified, since | |
| 186 | − "trace_debug_layer/trace_debug_level" shall apply to all control | |
| 187 | − method evaluations, after configuring "trace_state" to "enable", | |
| 188 | − "trace_method_name" will be reset to NULL. | |
| 189 | − 2. When "method/opcode" is specified, if | |
| 190 | − "trace_method_name" is NULL when "trace_state" is configured to | |
| 191 | − these options, the "trace_debug_layer/trace_debug_level" will | |
| 192 | − apply to all control method evaluations. | |
| @@ -1,172 +0,0 @@ | ||
| 1 | − | |
| 2 | −In order to support ACPI open-ended hardware configurations (e.g. development | |
| 3 | −boards) we need a way to augment the ACPI configuration provided by the firmware | |
| 4 | −image. A common example is connecting sensors on I2C / SPI buses on development | |
| 5 | −boards. | |
| 6 | − | |
| 7 | −Although this can be accomplished by creating a kernel platform driver or | |
| 8 | −recompiling the firmware image with updated ACPI tables, neither is practical: | |
| 9 | −the former proliferates board specific kernel code while the latter requires | |
| 10 | −access to firmware tools which are often not publicly available. | |
| 11 | − | |
| 12 | −Because ACPI supports external references in AML code a more practical | |
| 13 | −way to augment firmware ACPI configuration is by dynamically loading | |
| 14 | −user defined SSDT tables that contain the board specific information. | |
| 15 | − | |
| 16 | −For example, to enumerate a Bosch BMA222E accelerometer on the I2C bus of the | |
| 17 | −Minnowboard MAX development board exposed via the LSE connector [1], the | |
| 18 | −following ASL code can be used: | |
| 19 | − | |
| 20 | −DefinitionBlock ("minnowmax.aml", "SSDT", 1, "Vendor", "Accel", 0x00000003) | |
| 21 | −{ | |
| 22 | − External (\_SB.I2C6, DeviceObj) | |
| 23 | − | |
| 24 | − Scope (\_SB.I2C6) | |
| 25 | − { | |
| 26 | − Device (STAC) | |
| 27 | − { | |
| 28 | − Name (_ADR, Zero) | |
| 29 | − Name (_HID, "BMA222E") | |
| 30 | − | |
| 31 | − Method (_CRS, 0, Serialized) | |
| 32 | − { | |
| 33 | − Name (RBUF, ResourceTemplate () | |
| 34 | − { | |
| 35 | − I2cSerialBus (0x0018, ControllerInitiated, 0x00061A80, | |
| 36 | − AddressingMode7Bit, "\\_SB.I2C6", 0x00, | |
| 37 | − ResourceConsumer, ,) | |
| 38 | − GpioInt (Edge, ActiveHigh, Exclusive, PullDown, 0x0000, | |
| 39 | − "\\_SB.GPO2", 0x00, ResourceConsumer, , ) | |
| 40 | − { // Pin list | |
| 41 | − 0 | |
| 42 | − } | |
| 43 | − }) | |
| 44 | − Return (RBUF) | |
| 45 | − } | |
| 46 | − } | |
| 47 | − } | |
| 48 | −} | |
| 49 | − | |
| 50 | −which can then be compiled to AML binary format: | |
| 51 | − | |
| 52 | −$ iasl minnowmax.asl | |
| 53 | − | |
| 54 | −Intel ACPI Component Architecture | |
| 55 | −ASL Optimizing Compiler version 20140214-64 [Mar 29 2014] | |
| 56 | −Copyright (c) 2000 - 2014 Intel Corporation | |
| 57 | − | |
| 58 | −ASL Input: minnomax.asl - 30 lines, 614 bytes, 7 keywords | |
| 59 | −AML Output: minnowmax.aml - 165 bytes, 6 named objects, 1 executable opcodes | |
| 60 | − | |
| 61 | −[1] http://wiki.minnowboard.org/MinnowBoard_MAX#Low_Speed_Expansion_Connector_.28Top.29 | |
| 62 | − | |
| 63 | −The resulting AML code can then be loaded by the kernel using one of the methods | |
| 64 | −below. | |
| 65 | − | |
| 66 | −== Loading ACPI SSDTs from initrd == | |
| 67 | − | |
| 68 | −This option allows loading of user defined SSDTs from initrd and it is useful | |
| 69 | −when the system does not support EFI or when there is not enough EFI storage. | |
| 70 | − | |
| 71 | −It works in a similar way with initrd based ACPI tables override/upgrade: SSDT | |
| 72 | −aml code must be placed in the first, uncompressed, initrd under the | |
| 73 | −"kernel/firmware/acpi" path. Multiple files can be used and this will translate | |
| 74 | −in loading multiple tables. Only SSDT and OEM tables are allowed. See | |
| 75 | −initrd_table_override.txt for more details. | |
| 76 | − | |
| 77 | −Here is an example: | |
| 78 | − | |
| 79 | −# Add the raw ACPI tables to an uncompressed cpio archive. | |
| 80 | −# They must be put into a /kernel/firmware/acpi directory inside the | |
| 81 | −# cpio archive. | |
| 82 | −# The uncompressed cpio archive must be the first. | |
| 83 | −# Other, typically compressed cpio archives, must be | |
| 84 | −# concatenated on top of the uncompressed one. | |
| 85 | −mkdir -p kernel/firmware/acpi | |
| 86 | −cp ssdt.aml kernel/firmware/acpi | |
| 87 | − | |
| 88 | −# Create the uncompressed cpio archive and concatenate the original initrd | |
| 89 | −# on top: | |
| 90 | −find kernel | cpio -H newc --create > /boot/instrumented_initrd | |
| 91 | −cat /boot/initrd >>/boot/instrumented_initrd | |
| 92 | − | |
| 93 | −== Loading ACPI SSDTs from EFI variables == | |
| 94 | − | |
| 95 | −This is the preferred method, when EFI is supported on the platform, because it | |
| 96 | −allows a persistent, OS independent way of storing the user defined SSDTs. There | |
| 97 | −is also work underway to implement EFI support for loading user defined SSDTs | |
| 98 | −and using this method will make it easier to convert to the EFI loading | |
| 99 | −mechanism when that will arrive. | |
| 100 | − | |
| 101 | −In order to load SSDTs from an EFI variable the efivar_ssdt kernel command line | |
| 102 | −parameter can be used. The argument for the option is the variable name to | |
| 103 | −use. If there are multiple variables with the same name but with different | |
| 104 | −vendor GUIDs, all of them will be loaded. | |
| 105 | − | |
| 106 | −In order to store the AML code in an EFI variable the efivarfs filesystem can be | |
| 107 | −used. It is enabled and mounted by default in /sys/firmware/efi/efivars in all | |
| 108 | −recent distribution. | |
| 109 | − | |
| 110 | −Creating a new file in /sys/firmware/efi/efivars will automatically create a new | |
| 111 | −EFI variable. Updating a file in /sys/firmware/efi/efivars will update the EFI | |
| 112 | −variable. Please note that the file name needs to be specially formatted as | |
| 113 | −"Name-GUID" and that the first 4 bytes in the file (little-endian format) | |
| 114 | −represent the attributes of the EFI variable (see EFI_VARIABLE_MASK in | |
| 115 | −include/linux/efi.h). Writing to the file must also be done with one write | |
| 116 | −operation. | |
| 117 | − | |
| 118 | −For example, you can use the following bash script to create/update an EFI | |
| 119 | −variable with the content from a given file: | |
| 120 | − | |
| 121 | −#!/bin/sh -e | |
| 122 | − | |
| 123 | −while ! [ -z "$1" ]; do | |
| 124 | − case "$1" in | |
| 125 | − "-f") filename="$2"; shift;; | |
| 126 | − "-g") guid="$2"; shift;; | |
| 127 | − *) name="$1";; | |
| 128 | − esac | |
| 129 | − shift | |
| 130 | −done | |
| 131 | − | |
| 132 | −usage() | |
| 133 | −{ | |
| 134 | − echo "Syntax: ${0##*/} -f filename [ -g guid ] name" | |
| 135 | − exit 1 | |
| 136 | −} | |
| 137 | − | |
| 138 | −[ -n "$name" -a -f "$filename" ] || usage | |
| 139 | − | |
| 140 | −EFIVARFS="/sys/firmware/efi/efivars" | |
| 141 | − | |
| 142 | −[ -d "$EFIVARFS" ] || exit 2 | |
| 143 | − | |
| 144 | −if stat -tf $EFIVARFS | grep -q -v de5e81e4; then | |
| 145 | − mount -t efivarfs none $EFIVARFS | |
| 146 | −fi | |
| 147 | − | |
| 148 | −# try to pick up an existing GUID | |
| 149 | −[ -n "$guid" ] || guid=$(find "$EFIVARFS" -name "$name-*" | head -n1 | cut -f2- -d-) | |
| 150 | − | |
| 151 | −# use a randomly generated GUID | |
| 152 | −[ -n "$guid" ] || guid="$(cat /proc/sys/kernel/random/uuid)" | |
| 153 | − | |
| 154 | −# efivarfs expects all of the data in one write | |
| 155 | −tmp=$(mktemp) | |
| 156 | −/bin/echo -ne "\007\000\000\000" | cat - $filename > $tmp | |
| 157 | −dd if=$tmp of="$EFIVARFS/$name-$guid" bs=$(stat -c %s $tmp) | |
| 158 | −rm $tmp | |
| 159 | − | |
| 160 | −== Loading ACPI SSDTs from configfs == | |
| 161 | − | |
| 162 | −This option allows loading of user defined SSDTs from userspace via the configfs | |
| 163 | −interface. The CONFIG_ACPI_CONFIGFS option must be select and configfs must be | |
| 164 | −mounted. In the following examples, we assume that configfs has been mounted in | |
| 165 | −/config. | |
| 166 | − | |
| 167 | −New tables can be loading by creating new directories in /config/acpi/table/ and | |
| 168 | −writing the SSDT aml code in the aml attribute: | |
| 169 | − | |
| 170 | −cd /config/acpi/table | |
| 171 | −mkdir my_ssdt | |
| 172 | −cat ~/ssdt.aml > my_ssdt/aml | |
| @@ -1,5 +1,11 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 1 | 2 | |
| 2 | − Collaborative Processor Performance Control (CPPC) | |
| 3 | +================================================== | |
| 4 | +Collaborative Processor Performance Control (CPPC) | |
| 5 | +================================================== | |
| 6 | + | |
| 7 | +CPPC | |
| 8 | +==== | |
| 3 | 9 | |
| 4 | 10 | CPPC defined in the ACPI spec describes a mechanism for the OS to manage the |
| 5 | 11 | performance of a logical processor on a contigious and abstract performance |
| @@ -10,31 +16,28 @@ For more details on CPPC please refer to the ACPI specification at: · 4 unmodified lines | ||
| 10 | 16 | |
| 11 | 17 | http://uefi.org/specifications |
| 12 | 18 | |
| 13 | −Some of the CPPC registers are exposed via sysfs under: | |
| 14 | − | |
| 15 | −/sys/devices/system/cpu/cpuX/acpi_cppc/ | |
| 16 | − | |
| 17 | −for each cpu X | |
| 19 | +Some of the CPPC registers are exposed via sysfs under:: | |
| 18 | 20 | |
| 19 | −-------------------------------------------------------------------------------- | |
| 21 | + /sys/devices/system/cpu/cpuX/acpi_cppc/ | |
| 20 | 22 | |
| 21 | −$ ls -lR /sys/devices/system/cpu/cpu0/acpi_cppc/ | |
| 22 | −/sys/devices/system/cpu/cpu0/acpi_cppc/: | |
| 23 | −total 0 | |
| 24 | −-r--r--r-- 1 root root 65536 Mar 5 19:38 feedback_ctrs | |
| 25 | −-r--r--r-- 1 root root 65536 Mar 5 19:38 highest_perf | |
| 26 | −-r--r--r-- 1 root root 65536 Mar 5 19:38 lowest_freq | |
| 27 | −-r--r--r-- 1 root root 65536 Mar 5 19:38 lowest_nonlinear_perf | |
| 28 | −-r--r--r-- 1 root root 65536 Mar 5 19:38 lowest_perf | |
| 29 | −-r--r--r-- 1 root root 65536 Mar 5 19:38 nominal_freq | |
| 30 | −-r--r--r-- 1 root root 65536 Mar 5 19:38 nominal_perf | |
| 31 | −-r--r--r-- 1 root root 65536 Mar 5 19:38 reference_perf | |
| 32 | −-r--r--r-- 1 root root 65536 Mar 5 19:38 wraparound_time | |
| 23 | +for each cpu X:: | |
| 33 | 24 | |
| 34 | −-------------------------------------------------------------------------------- | |
| 25 | + $ ls -lR /sys/devices/system/cpu/cpu0/acpi_cppc/ | |
| 26 | + /sys/devices/system/cpu/cpu0/acpi_cppc/: | |
| 27 | + total 0 | |
| 28 | + -r--r--r-- 1 root root 65536 Mar 5 19:38 feedback_ctrs | |
| 29 | + -r--r--r-- 1 root root 65536 Mar 5 19:38 highest_perf | |
| 30 | + -r--r--r-- 1 root root 65536 Mar 5 19:38 lowest_freq | |
| 31 | + -r--r--r-- 1 root root 65536 Mar 5 19:38 lowest_nonlinear_perf | |
| 32 | + -r--r--r-- 1 root root 65536 Mar 5 19:38 lowest_perf | |
| 33 | + -r--r--r-- 1 root root 65536 Mar 5 19:38 nominal_freq | |
| 34 | + -r--r--r-- 1 root root 65536 Mar 5 19:38 nominal_perf | |
| 35 | + -r--r--r-- 1 root root 65536 Mar 5 19:38 reference_perf | |
| 36 | + -r--r--r-- 1 root root 65536 Mar 5 19:38 wraparound_time | |
| 35 | 37 | |
| 36 | 38 | * highest_perf : Highest performance of this processor (abstract scale). |
| 37 | −* nominal_perf : Highest sustained performance of this processor (abstract scale). | |
| 39 | +* nominal_perf : Highest sustained performance of this processor | |
| 40 | + (abstract scale). | |
| 38 | 41 | * lowest_nonlinear_perf : Lowest performance of this processor with nonlinear |
| 39 | 42 | power savings (abstract scale). |
| 40 | 43 | * lowest_perf : Lowest performance of this processor (abstract scale). |
| @@ -48,22 +51,26 @@ total 0 · 7 unmodified lines | ||
| 48 | 51 | * feedback_ctrs : Includes both Reference and delivered performance counter. |
| 49 | 52 | Reference counter ticks up proportional to processor's reference performance. |
| 50 | 53 | Delivered counter ticks up proportional to processor's delivered performance. |
| 51 | −* wraparound_time: Minimum time for the feedback counters to wraparound (seconds). | |
| 54 | +* wraparound_time: Minimum time for the feedback counters to wraparound | |
| 55 | + (seconds). | |
| 52 | 56 | * reference_perf : Performance level at which reference performance counter |
| 53 | 57 | accumulates (abstract scale). |
| 54 | 58 | |
| 55 | −-------------------------------------------------------------------------------- | |
| 56 | 59 | |
| 57 | − Computing Average Delivered Performance | |
| 60 | +Computing Average Delivered Performance | |
| 61 | +======================================= | |
| 62 | + | |
| 63 | +Below describes the steps to compute the average performance delivered by | |
| 64 | +taking two different snapshots of feedback counters at time T1 and T2. | |
| 65 | + | |
| 66 | + T1: Read feedback_ctrs as fbc_t1 | |
| 67 | + Wait or run some workload | |
| 58 | 68 | |
| 59 | −Below describes the steps to compute the average performance delivered by taking | |
| 60 | −two different snapshots of feedback counters at time T1 and T2. | |
| 69 | + T2: Read feedback_ctrs as fbc_t2 | |
| 61 | 70 | |
| 62 | −T1: Read feedback_ctrs as fbc_t1 | |
| 63 | − Wait or run some workload | |
| 64 | −T2: Read feedback_ctrs as fbc_t2 | |
| 71 | +:: | |
| 65 | 72 | |
| 66 | −delivered_counter_delta = fbc_t2[del] - fbc_t1[del] | |
| 67 | −reference_counter_delta = fbc_t2[ref] - fbc_t1[ref] | |
| 73 | + delivered_counter_delta = fbc_t2[del] - fbc_t1[del] | |
| 74 | + reference_counter_delta = fbc_t2[ref] - fbc_t1[ref] | |
| 68 | 75 | |
| 69 | −delivered_perf = (refernce_perf x delivered_counter_delta) / reference_counter_delta | |
| 76 | + delivered_perf = (refernce_perf x delivered_counter_delta) / reference_counter_delta | |
| @@ -1,6 +1,12 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | + | |
| 3 | +=============== | |
| 4 | +Overriding DSDT | |
| 5 | +=============== | |
| 6 | + | |
| 1 | 7 | Linux supports a method of overriding the BIOS DSDT: |
| 2 | 8 | |
| 3 | −CONFIG_ACPI_CUSTOM_DSDT builds the image into the kernel. | |
| 9 | +CONFIG_ACPI_CUSTOM_DSDT - builds the image into the kernel. | |
| 4 | 10 | |
| 5 | 11 | When to use this method is described in detail on the |
| 6 | 12 | Linux/ACPI home page: |
| @@ -0,0 +1,14 @@ | ||
| 1 | +============ | |
| 2 | +ACPI Support | |
| 3 | +============ | |
| 4 | + | |
| 5 | +Here we document in detail how to interact with various mechanisms in | |
| 6 | +the Linux ACPI support. | |
| 7 | + | |
| 8 | +.. toctree:: | |
| 9 | + :maxdepth: 1 | |
| 10 | + | |
| 11 | + initrd_table_override | |
| 12 | + dsdt-override | |
| 13 | + ssdt-overlays | |
| 14 | + cppc_sysfs | |
| @@ -0,0 +1,115 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | + | |
| 3 | +================================ | |
| 4 | +Upgrading ACPI tables via initrd | |
| 5 | +================================ | |
| 6 | + | |
| 7 | +What is this about | |
| 8 | +================== | |
| 9 | + | |
| 10 | +If the ACPI_TABLE_UPGRADE compile option is true, it is possible to | |
| 11 | +upgrade the ACPI execution environment that is defined by the ACPI tables | |
| 12 | +via upgrading the ACPI tables provided by the BIOS with an instrumented, | |
| 13 | +modified, more recent version one, or installing brand new ACPI tables. | |
| 14 | + | |
| 15 | +When building initrd with kernel in a single image, option | |
| 16 | +ACPI_TABLE_OVERRIDE_VIA_BUILTIN_INITRD should also be true for this | |
| 17 | +feature to work. | |
| 18 | + | |
| 19 | +For a full list of ACPI tables that can be upgraded/installed, take a look | |
| 20 | +at the char `*table_sigs[MAX_ACPI_SIGNATURE];` definition in | |
| 21 | +drivers/acpi/tables.c. | |
| 22 | + | |
| 23 | +All ACPI tables iasl (Intel's ACPI compiler and disassembler) knows should | |
| 24 | +be overridable, except: | |
| 25 | + | |
| 26 | + - ACPI_SIG_RSDP (has a signature of 6 bytes) | |
| 27 | + - ACPI_SIG_FACS (does not have an ordinary ACPI table header) | |
| 28 | + | |
| 29 | +Both could get implemented as well. | |
| 30 | + | |
| 31 | + | |
| 32 | +What is this for | |
| 33 | +================ | |
| 34 | + | |
| 35 | +Complain to your platform/BIOS vendor if you find a bug which is so severe | |
| 36 | +that a workaround is not accepted in the Linux kernel. And this facility | |
| 37 | +allows you to upgrade the buggy tables before your platform/BIOS vendor | |
| 38 | +releases an upgraded BIOS binary. | |
| 39 | + | |
| 40 | +This facility can be used by platform/BIOS vendors to provide a Linux | |
| 41 | +compatible environment without modifying the underlying platform firmware. | |
| 42 | + | |
| 43 | +This facility also provides a powerful feature to easily debug and test | |
| 44 | +ACPI BIOS table compatibility with the Linux kernel by modifying old | |
| 45 | +platform provided ACPI tables or inserting new ACPI tables. | |
| 46 | + | |
| 47 | +It can and should be enabled in any kernel because there is no functional | |
| 48 | +change with not instrumented initrds. | |
| 49 | + | |
| 50 | + | |
| 51 | +How does it work | |
| 52 | +================ | |
| 53 | +:: | |
| 54 | + | |
| 55 | + # Extract the machine's ACPI tables: | |
| 56 | + cd /tmp | |
| 57 | + acpidump >acpidump | |
| 58 | + acpixtract -a acpidump | |
| 59 | + # Disassemble, modify and recompile them: | |
| 60 | + iasl -d *.dat | |
| 61 | + # For example add this statement into a _PRT (PCI Routing Table) function | |
| 62 | + # of the DSDT: | |
| 63 | + Store("HELLO WORLD", debug) | |
| 64 | + # And increase the OEM Revision. For example, before modification: | |
| 65 | + DefinitionBlock ("DSDT.aml", "DSDT", 2, "INTEL ", "TEMPLATE", 0x00000000) | |
| 66 | + # After modification: | |
| 67 | + DefinitionBlock ("DSDT.aml", "DSDT", 2, "INTEL ", "TEMPLATE", 0x00000001) | |
| 68 | + iasl -sa dsdt.dsl | |
| 69 | + # Add the raw ACPI tables to an uncompressed cpio archive. | |
| 70 | + # They must be put into a /kernel/firmware/acpi directory inside the cpio | |
| 71 | + # archive. Note that if the table put here matches a platform table | |
| 72 | + # (similar Table Signature, and similar OEMID, and similar OEM Table ID) | |
| 73 | + # with a more recent OEM Revision, the platform table will be upgraded by | |
| 74 | + # this table. If the table put here doesn't match a platform table | |
| 75 | + # (dissimilar Table Signature, or dissimilar OEMID, or dissimilar OEM Table | |
| 76 | + # ID), this table will be appended. | |
| 77 | + mkdir -p kernel/firmware/acpi | |
| 78 | + cp dsdt.aml kernel/firmware/acpi | |
| 79 | + # A maximum of "NR_ACPI_INITRD_TABLES (64)" tables are currently allowed | |
| 80 | + # (see osl.c): | |
| 81 | + iasl -sa facp.dsl | |
| 82 | + iasl -sa ssdt1.dsl | |
| 83 | + cp facp.aml kernel/firmware/acpi | |
| 84 | + cp ssdt1.aml kernel/firmware/acpi | |
| 85 | + # The uncompressed cpio archive must be the first. Other, typically | |
| 86 | + # compressed cpio archives, must be concatenated on top of the uncompressed | |
| 87 | + # one. Following command creates the uncompressed cpio archive and | |
| 88 | + # concatenates the original initrd on top: | |
| 89 | + find kernel | cpio -H newc --create > /boot/instrumented_initrd | |
| 90 | + cat /boot/initrd >>/boot/instrumented_initrd | |
| 91 | + # reboot with increased acpi debug level, e.g. boot params: | |
| 92 | + acpi.debug_level=0x2 acpi.debug_layer=0xFFFFFFFF | |
| 93 | + # and check your syslog: | |
| 94 | + [ 1.268089] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] | |
| 95 | + [ 1.272091] [ACPI Debug] String [0x0B] "HELLO WORLD" | |
| 96 | + | |
| 97 | +iasl is able to disassemble and recompile quite a lot different, | |
| 98 | +also static ACPI tables. | |
| 99 | + | |
| 100 | + | |
| 101 | +Where to retrieve userspace tools | |
| 102 | +================================= | |
| 103 | + | |
| 104 | +iasl and acpixtract are part of Intel's ACPICA project: | |
| 105 | +http://acpica.org/ | |
| 106 | + | |
| 107 | +and should be packaged by distributions (for example in the acpica package | |
| 108 | +on SUSE). | |
| 109 | + | |
| 110 | +acpidump can be found in Len Browns pmtools: | |
| 111 | +ftp://kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools/acpidump | |
| 112 | + | |
| 113 | +This tool is also part of the acpica package on SUSE. | |
| 114 | +Alternatively, used ACPI tables can be retrieved via sysfs in latest kernels: | |
| 115 | +/sys/firmware/acpi/tables | |
| @@ -0,0 +1,180 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | + | |
| 3 | +============= | |
| 4 | +SSDT Overlays | |
| 5 | +============= | |
| 6 | + | |
| 7 | +In order to support ACPI open-ended hardware configurations (e.g. development | |
| 8 | +boards) we need a way to augment the ACPI configuration provided by the firmware | |
| 9 | +image. A common example is connecting sensors on I2C / SPI buses on development | |
| 10 | +boards. | |
| 11 | + | |
| 12 | +Although this can be accomplished by creating a kernel platform driver or | |
| 13 | +recompiling the firmware image with updated ACPI tables, neither is practical: | |
| 14 | +the former proliferates board specific kernel code while the latter requires | |
| 15 | +access to firmware tools which are often not publicly available. | |
| 16 | + | |
| 17 | +Because ACPI supports external references in AML code a more practical | |
| 18 | +way to augment firmware ACPI configuration is by dynamically loading | |
| 19 | +user defined SSDT tables that contain the board specific information. | |
| 20 | + | |
| 21 | +For example, to enumerate a Bosch BMA222E accelerometer on the I2C bus of the | |
| 22 | +Minnowboard MAX development board exposed via the LSE connector [1], the | |
| 23 | +following ASL code can be used:: | |
| 24 | + | |
| 25 | + DefinitionBlock ("minnowmax.aml", "SSDT", 1, "Vendor", "Accel", 0x00000003) | |
| 26 | + { | |
| 27 | + External (\_SB.I2C6, DeviceObj) | |
| 28 | + | |
| 29 | + Scope (\_SB.I2C6) | |
| 30 | + { | |
| 31 | + Device (STAC) | |
| 32 | + { | |
| 33 | + Name (_ADR, Zero) | |
| 34 | + Name (_HID, "BMA222E") | |
| 35 | + | |
| 36 | + Method (_CRS, 0, Serialized) | |
| 37 | + { | |
| 38 | + Name (RBUF, ResourceTemplate () | |
| 39 | + { | |
| 40 | + I2cSerialBus (0x0018, ControllerInitiated, 0x00061A80, | |
| 41 | + AddressingMode7Bit, "\\_SB.I2C6", 0x00, | |
| 42 | + ResourceConsumer, ,) | |
| 43 | + GpioInt (Edge, ActiveHigh, Exclusive, PullDown, 0x0000, | |
| 44 | + "\\_SB.GPO2", 0x00, ResourceConsumer, , ) | |
| 45 | + { // Pin list | |
| 46 | + 0 | |
| 47 | + } | |
| 48 | + }) | |
| 49 | + Return (RBUF) | |
| 50 | + } | |
| 51 | + } | |
| 52 | + } | |
| 53 | + } | |
| 54 | + | |
| 55 | +which can then be compiled to AML binary format:: | |
| 56 | + | |
| 57 | + $ iasl minnowmax.asl | |
| 58 | + | |
| 59 | + Intel ACPI Component Architecture | |
| 60 | + ASL Optimizing Compiler version 20140214-64 [Mar 29 2014] | |
| 61 | + Copyright (c) 2000 - 2014 Intel Corporation | |
| 62 | + | |
| 63 | + ASL Input: minnomax.asl - 30 lines, 614 bytes, 7 keywords | |
| 64 | + AML Output: minnowmax.aml - 165 bytes, 6 named objects, 1 executable opcodes | |
| 65 | + | |
| 66 | +[1] http://wiki.minnowboard.org/MinnowBoard_MAX#Low_Speed_Expansion_Connector_.28Top.29 | |
| 67 | + | |
| 68 | +The resulting AML code can then be loaded by the kernel using one of the methods | |
| 69 | +below. | |
| 70 | + | |
| 71 | +Loading ACPI SSDTs from initrd | |
| 72 | +============================== | |
| 73 | + | |
| 74 | +This option allows loading of user defined SSDTs from initrd and it is useful | |
| 75 | +when the system does not support EFI or when there is not enough EFI storage. | |
| 76 | + | |
| 77 | +It works in a similar way with initrd based ACPI tables override/upgrade: SSDT | |
| 78 | +aml code must be placed in the first, uncompressed, initrd under the | |
| 79 | +"kernel/firmware/acpi" path. Multiple files can be used and this will translate | |
| 80 | +in loading multiple tables. Only SSDT and OEM tables are allowed. See | |
| 81 | +initrd_table_override.txt for more details. | |
| 82 | + | |
| 83 | +Here is an example:: | |
| 84 | + | |
| 85 | + # Add the raw ACPI tables to an uncompressed cpio archive. | |
| 86 | + # They must be put into a /kernel/firmware/acpi directory inside the | |
| 87 | + # cpio archive. | |
| 88 | + # The uncompressed cpio archive must be the first. | |
| 89 | + # Other, typically compressed cpio archives, must be | |
| 90 | + # concatenated on top of the uncompressed one. | |
| 91 | + mkdir -p kernel/firmware/acpi | |
| 92 | + cp ssdt.aml kernel/firmware/acpi | |
| 93 | + | |
| 94 | + # Create the uncompressed cpio archive and concatenate the original initrd | |
| 95 | + # on top: | |
| 96 | + find kernel | cpio -H newc --create > /boot/instrumented_initrd | |
| 97 | + cat /boot/initrd >>/boot/instrumented_initrd | |
| 98 | + | |
| 99 | +Loading ACPI SSDTs from EFI variables | |
| 100 | +===================================== | |
| 101 | + | |
| 102 | +This is the preferred method, when EFI is supported on the platform, because it | |
| 103 | +allows a persistent, OS independent way of storing the user defined SSDTs. There | |
| 104 | +is also work underway to implement EFI support for loading user defined SSDTs | |
| 105 | +and using this method will make it easier to convert to the EFI loading | |
| 106 | +mechanism when that will arrive. | |
| 107 | + | |
| 108 | +In order to load SSDTs from an EFI variable the efivar_ssdt kernel command line | |
| 109 | +parameter can be used. The argument for the option is the variable name to | |
| 110 | +use. If there are multiple variables with the same name but with different | |
| 111 | +vendor GUIDs, all of them will be loaded. | |
| 112 | + | |
| 113 | +In order to store the AML code in an EFI variable the efivarfs filesystem can be | |
| 114 | +used. It is enabled and mounted by default in /sys/firmware/efi/efivars in all | |
| 115 | +recent distribution. | |
| 116 | + | |
| 117 | +Creating a new file in /sys/firmware/efi/efivars will automatically create a new | |
| 118 | +EFI variable. Updating a file in /sys/firmware/efi/efivars will update the EFI | |
| 119 | +variable. Please note that the file name needs to be specially formatted as | |
| 120 | +"Name-GUID" and that the first 4 bytes in the file (little-endian format) | |
| 121 | +represent the attributes of the EFI variable (see EFI_VARIABLE_MASK in | |
| 122 | +include/linux/efi.h). Writing to the file must also be done with one write | |
| 123 | +operation. | |
| 124 | + | |
| 125 | +For example, you can use the following bash script to create/update an EFI | |
| 126 | +variable with the content from a given file:: | |
| 127 | + | |
| 128 | + #!/bin/sh -e | |
| 129 | + | |
| 130 | + while ! [ -z "$1" ]; do | |
| 131 | + case "$1" in | |
| 132 | + "-f") filename="$2"; shift;; | |
| 133 | + "-g") guid="$2"; shift;; | |
| 134 | + *) name="$1";; | |
| 135 | + esac | |
| 136 | + shift | |
| 137 | + done | |
| 138 | + | |
| 139 | + usage() | |
| 140 | + { | |
| 141 | + echo "Syntax: ${0##*/} -f filename [ -g guid ] name" | |
| 142 | + exit 1 | |
| 143 | + } | |
| 144 | + | |
| 145 | + [ -n "$name" -a -f "$filename" ] || usage | |
| 146 | + | |
| 147 | + EFIVARFS="/sys/firmware/efi/efivars" | |
| 148 | + | |
| 149 | + [ -d "$EFIVARFS" ] || exit 2 | |
| 150 | + | |
| 151 | + if stat -tf $EFIVARFS | grep -q -v de5e81e4; then | |
| 152 | + mount -t efivarfs none $EFIVARFS | |
| 153 | + fi | |
| 154 | + | |
| 155 | + # try to pick up an existing GUID | |
| 156 | + [ -n "$guid" ] || guid=$(find "$EFIVARFS" -name "$name-*" | head -n1 | cut -f2- -d-) | |
| 157 | + | |
| 158 | + # use a randomly generated GUID | |
| 159 | + [ -n "$guid" ] || guid="$(cat /proc/sys/kernel/random/uuid)" | |
| 160 | + | |
| 161 | + # efivarfs expects all of the data in one write | |
| 162 | + tmp=$(mktemp) | |
| 163 | + /bin/echo -ne "\007\000\000\000" | cat - $filename > $tmp | |
| 164 | + dd if=$tmp of="$EFIVARFS/$name-$guid" bs=$(stat -c %s $tmp) | |
| 165 | + rm $tmp | |
| 166 | + | |
| 167 | +Loading ACPI SSDTs from configfs | |
| 168 | +================================ | |
| 169 | + | |
| 170 | +This option allows loading of user defined SSDTs from userspace via the configfs | |
| 171 | +interface. The CONFIG_ACPI_CONFIGFS option must be select and configfs must be | |
| 172 | +mounted. In the following examples, we assume that configfs has been mounted in | |
| 173 | +/config. | |
| 174 | + | |
| 175 | +New tables can be loading by creating new directories in /config/acpi/table/ and | |
| 176 | +writing the SSDT aml code in the aml attribute:: | |
| 177 | + | |
| 178 | + cd /config/acpi/table | |
| 179 | + mkdir my_ssdt | |
| 180 | + cat ~/ssdt.aml > my_ssdt/aml | |
| @@ -77,6 +77,7 @@ configure specific aspects of kernel behavior to your liking. · 76 unmodified lines | ||
| 77 | 77 | LSM/index |
| 78 | 78 | mm/index |
| 79 | 79 | perf-security |
| 80 | + acpi/index | |
| 80 | 81 | |
| 81 | 82 | .. only:: subproject and html |
| 82 | 83 | |
| @@ -0,0 +1,9 @@ | ||
| 1 | +============ | |
| 2 | +ACPI Support | |
| 3 | +============ | |
| 4 | + | |
| 5 | +.. toctree:: | |
| 6 | + :maxdepth: 2 | |
| 7 | + | |
| 8 | + linuxized-acpica | |
| 9 | + scan_handlers | |
| @@ -1,31 +1,37 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | +.. include:: <isonum.txt> | |
| 3 | + | |
| 4 | +============================================================ | |
| 1 | 5 | Linuxized ACPICA - Introduction to ACPICA Release Automation |
| 6 | +============================================================ | |
| 2 | 7 | |
| 3 | −Copyright (C) 2013-2016, Intel Corporation | |
| 4 | −Author: Lv Zheng <lv.zheng@intel.com> | |
| 8 | +:Copyright: |copy| 2013-2016, Intel Corporation | |
| 5 | 9 | |
| 10 | +:Author: Lv Zheng <lv.zheng@intel.com> | |
| 6 | 11 | |
| 7 | −Abstract: | |
| 8 | 12 | |
| 13 | +Abstract | |
| 14 | +======== | |
| 9 | 15 | This document describes the ACPICA project and the relationship between |
| 10 | 16 | ACPICA and Linux. It also describes how ACPICA code in drivers/acpi/acpica, |
| 11 | 17 | include/acpi and tools/power/acpi is automatically updated to follow the |
| 12 | 18 | upstream. |
| 13 | 19 | |
| 20 | +ACPICA Project | |
| 21 | +============== | |
| 14 | 22 | |
| 15 | −1. ACPICA Project | |
| 16 | − | |
| 17 | − The ACPI Component Architecture (ACPICA) project provides an operating | |
| 18 | − system (OS)-independent reference implementation of the Advanced | |
| 19 | − Configuration and Power Interface Specification (ACPI). It has been | |
| 20 | − adapted by various host OSes. By directly integrating ACPICA, Linux can | |
| 21 | − also benefit from the application experiences of ACPICA from other host | |
| 22 | − OSes. | |
| 23 | +The ACPI Component Architecture (ACPICA) project provides an operating | |
| 24 | +system (OS)-independent reference implementation of the Advanced | |
| 25 | +Configuration and Power Interface Specification (ACPI). It has been | |
| 26 | +adapted by various host OSes. By directly integrating ACPICA, Linux can | |
| 27 | +also benefit from the application experiences of ACPICA from other host | |
| 28 | +OSes. | |
| 23 | 29 | |
| 24 | − The homepage of ACPICA project is: www.acpica.org, it is maintained and | |
| 25 | − supported by Intel Corporation. | |
| 30 | +The homepage of ACPICA project is: www.acpica.org, it is maintained and | |
| 31 | +supported by Intel Corporation. | |
| 26 | 32 | |
| 27 | − The following figure depicts the Linux ACPI subsystem where the ACPICA | |
| 28 | − adaptation is included: | |
| 33 | +The following figure depicts the Linux ACPI subsystem where the ACPICA | |
| 34 | +adaptation is included:: | |
| 29 | 35 | |
| 30 | 36 | +---------------------------------------------------------+ |
| 31 | 37 | | | |
| @@ -71,21 +77,27 @@ upstream. · 39 unmodified lines | ||
| 71 | 77 | |
| 72 | 78 | Figure 1. Linux ACPI Software Components |
| 73 | 79 | |
| 74 | − NOTE: | |
| 80 | +.. note:: | |
| 75 | 81 | A. OS Service Layer - Provided by Linux to offer OS dependent |
| 76 | 82 | implementation of the predefined ACPICA interfaces (acpi_os_*). |
| 83 | + :: | |
| 84 | + | |
| 77 | 85 | include/acpi/acpiosxf.h |
| 78 | 86 | drivers/acpi/osl.c |
| 79 | 87 | include/acpi/platform |
| 80 | 88 | include/asm/acenv.h |
| 81 | 89 | B. ACPICA Functionality - Released from ACPICA code base to offer |
| 82 | 90 | OS independent implementation of the ACPICA interfaces (acpi_*). |
| 91 | + :: | |
| 92 | + | |
| 83 | 93 | drivers/acpi/acpica |
| 84 | 94 | include/acpi/ac*.h |
| 85 | 95 | tools/power/acpi |
| 86 | 96 | C. Linux/ACPI Functionality - Providing Linux specific ACPI |
| 87 | 97 | functionality to the other Linux kernel subsystems and user space |
| 88 | 98 | programs. |
| 99 | + :: | |
| 100 | + | |
| 89 | 101 | drivers/acpi |
| 90 | 102 | include/linux/acpi.h |
| 91 | 103 | include/linux/acpi*.h |
| @@ -95,24 +107,27 @@ upstream. · 3 unmodified lines | ||
| 95 | 107 | ACPI subsystem to offer architecture specific implementation of the |
| 96 | 108 | ACPI interfaces. They are Linux specific components and are out of |
| 97 | 109 | the scope of this document. |
| 110 | + :: | |
| 111 | + | |
| 98 | 112 | include/asm/acpi.h |
| 99 | 113 | include/asm/acpi*.h |
| 100 | 114 | arch/*/acpi |
| 101 | 115 | |
| 102 | −2. ACPICA Release | |
| 116 | +ACPICA Release | |
| 117 | +============== | |
| 103 | 118 | |
| 104 | − The ACPICA project maintains its code base at the following repository URL: | |
| 105 | − https://github.com/acpica/acpica.git. As a rule, a release is made every | |
| 106 | − month. | |
| 119 | +The ACPICA project maintains its code base at the following repository URL: | |
| 120 | +https://github.com/acpica/acpica.git. As a rule, a release is made every | |
| 121 | +month. | |
| 107 | 122 | |
| 108 | − As the coding style adopted by the ACPICA project is not acceptable by | |
| 109 | − Linux, there is a release process to convert the ACPICA git commits into | |
| 110 | − Linux patches. The patches generated by this process are referred to as | |
| 111 | − "linuxized ACPICA patches". The release process is carried out on a local | |
| 112 | − copy the ACPICA git repository. Each commit in the monthly release is | |
| 113 | − converted into a linuxized ACPICA patch. Together, they form the monthly | |
| 114 | − ACPICA release patchset for the Linux ACPI community. This process is | |
| 115 | − illustrated in the following figure: | |
| 123 | +As the coding style adopted by the ACPICA project is not acceptable by | |
| 124 | +Linux, there is a release process to convert the ACPICA git commits into | |
| 125 | +Linux patches. The patches generated by this process are referred to as | |
| 126 | +"linuxized ACPICA patches". The release process is carried out on a local | |
| 127 | +copy the ACPICA git repository. Each commit in the monthly release is | |
| 128 | +converted into a linuxized ACPICA patch. Together, they form the monthly | |
| 129 | +ACPICA release patchset for the Linux ACPI community. This process is | |
| 130 | +illustrated in the following figure:: | |
| 116 | 131 | |
| 117 | 132 | +-----------------------------+ |
| 118 | 133 | | acpica / master (-) commits | |
| @@ -153,7 +168,7 @@ upstream. · 34 unmodified lines | ||
| 153 | 168 | |
| 154 | 169 | Figure 2. ACPICA -> Linux Upstream Process |
| 155 | 170 | |
| 156 | − NOTE: | |
| 171 | +.. note:: | |
| 157 | 172 | A. Linuxize Utilities - Provided by the ACPICA repository, including a |
| 158 | 173 | utility located in source/tools/acpisrc folder and a number of |
| 159 | 174 | scripts located in generate/linux folder. |
| @@ -170,19 +185,20 @@ upstream. · 10 unmodified lines | ||
| 170 | 185 | following kernel configuration options: |
| 171 | 186 | CONFIG_ACPI/CONFIG_ACPI_DEBUG/CONFIG_ACPI_DEBUGGER |
| 172 | 187 | |
| 173 | −3. ACPICA Divergences | |
| 188 | +ACPICA Divergences | |
| 189 | +================== | |
| 174 | 190 | |
| 175 | − Ideally, all of the ACPICA commits should be converted into Linux patches | |
| 176 | − automatically without manual modifications, the "linux / master" tree should | |
| 177 | − contain the ACPICA code that exactly corresponds to the ACPICA code | |
| 178 | − contained in "new linuxized acpica" tree and it should be possible to run | |
| 179 | − the release process fully automatically. | |
| 191 | +Ideally, all of the ACPICA commits should be converted into Linux patches | |
| 192 | +automatically without manual modifications, the "linux / master" tree should | |
| 193 | +contain the ACPICA code that exactly corresponds to the ACPICA code | |
| 194 | +contained in "new linuxized acpica" tree and it should be possible to run | |
| 195 | +the release process fully automatically. | |
| 180 | 196 | |
| 181 | − As a matter of fact, however, there are source code differences between | |
| 182 | − the ACPICA code in Linux and the upstream ACPICA code, referred to as | |
| 183 | − "ACPICA Divergences". | |
| 197 | +As a matter of fact, however, there are source code differences between | |
| 198 | +the ACPICA code in Linux and the upstream ACPICA code, referred to as | |
| 199 | +"ACPICA Divergences". | |
| 184 | 200 | |
| 185 | − The various sources of ACPICA divergences include: | |
| 201 | +The various sources of ACPICA divergences include: | |
| 186 | 202 | 1. Legacy divergences - Before the current ACPICA release process was |
| 187 | 203 | established, there already had been divergences between Linux and |
| 188 | 204 | ACPICA. Over the past several years those divergences have been greatly |
| @@ -213,11 +229,12 @@ upstream. · 24 unmodified lines | ||
| 213 | 229 | rebased on the ACPICA side in order to offer better solutions, new ACPICA |
| 214 | 230 | divergences are generated. |
| 215 | 231 | |
| 216 | −4. ACPICA Development | |
| 232 | +ACPICA Development | |
| 233 | +================== | |
| 217 | 234 | |
| 218 | − This paragraph guides Linux developers to use the ACPICA upstream release | |
| 219 | − utilities to obtain Linux patches corresponding to upstream ACPICA commits | |
| 220 | − before they become available from the ACPICA release process. | |
| 235 | +This paragraph guides Linux developers to use the ACPICA upstream release | |
| 236 | +utilities to obtain Linux patches corresponding to upstream ACPICA commits | |
| 237 | +before they become available from the ACPICA release process. | |
| 221 | 238 | |
| 222 | 239 | 1. Cherry-pick an ACPICA commit |
| 223 | 240 | |
| @@ -225,7 +242,7 @@ upstream. · 1 unmodified line | ||
| 225 | 242 | you want to cherry pick must be committed into the local repository. |
| 226 | 243 | |
| 227 | 244 | Then the gen-patch.sh command can help to cherry-pick an ACPICA commit |
| 228 | − from the ACPICA local repository: | |
| 245 | + from the ACPICA local repository:: | |
| 229 | 246 | |
| 230 | 247 | $ git clone https://github.com/acpica/acpica |
| 231 | 248 | $ cd acpica |
| @@ -240,7 +257,7 @@ upstream. · 8 unmodified lines | ||
| 240 | 257 | changes that haven't been applied to Linux yet. |
| 241 | 258 | |
| 242 | 259 | You can generate the ACPICA release series yourself and rebase your code on |
| 243 | − top of the generated ACPICA release patches: | |
| 260 | + top of the generated ACPICA release patches:: | |
| 244 | 261 | |
| 245 | 262 | $ git clone https://github.com/acpica/acpica |
| 246 | 263 | $ cd acpica |
| @@ -254,7 +271,7 @@ upstream. · 7 unmodified lines | ||
| 254 | 271 | 3. Inspect the current divergences |
| 255 | 272 | |
| 256 | 273 | If you have local copies of both Linux and upstream ACPICA, you can generate |
| 257 | − a diff file indicating the state of the current divergences: | |
| 274 | + a diff file indicating the state of the current divergences:: | |
| 258 | 275 | |
| 259 | 276 | # git clone https://github.com/acpica/acpica |
| 260 | 277 | # git clone http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git |
| @@ -1,7 +1,13 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | +.. include:: <isonum.txt> | |
| 3 | + | |
| 4 | +================== | |
| 1 | 5 | ACPI Scan Handlers |
| 6 | +================== | |
| 7 | + | |
| 8 | +:Copyright: |copy| 2012, Intel Corporation | |
| 2 | 9 | |
| 3 | −Copyright (C) 2012, Intel Corporation | |
| 4 | −Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> | |
| 10 | +:Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> | |
| 5 | 11 | |
| 6 | 12 | During system initialization and ACPI-based device hot-add, the ACPI namespace |
| 7 | 13 | is scanned in search of device objects that generally represent various pieces |
| @@ -30,14 +36,14 @@ to configure that link so that the kernel can use it. · 22 unmodified lines | ||
| 30 | 36 | Those additional configuration tasks usually depend on the type of the hardware |
| 31 | 37 | component represented by the given device node which can be determined on the |
| 32 | 38 | basis of the device node's hardware ID (HID). They are performed by objects |
| 33 | −called ACPI scan handlers represented by the following structure: | |
| 39 | +called ACPI scan handlers represented by the following structure:: | |
| 34 | 40 | |
| 35 | −struct acpi_scan_handler { | |
| 36 | − const struct acpi_device_id *ids; | |
| 37 | − struct list_head list_node; | |
| 38 | − int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id); | |
| 39 | − void (*detach)(struct acpi_device *dev); | |
| 40 | −}; | |
| 41 | + struct acpi_scan_handler { | |
| 42 | + const struct acpi_device_id *ids; | |
| 43 | + struct list_head list_node; | |
| 44 | + int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id); | |
| 45 | + void (*detach)(struct acpi_device *dev); | |
| 46 | + }; | |
| 41 | 47 | |
| 42 | 48 | where ids is the list of IDs of device nodes the given handler is supposed to |
| 43 | 49 | take care of, list_node is the hook to the global list of ACPI scan handlers |
| @@ -56,6 +56,7 @@ available subsections can be seen below. · 55 unmodified lines | ||
| 56 | 56 | slimbus |
| 57 | 57 | soundwire/index |
| 58 | 58 | fpga/index |
| 59 | + acpi/index | |
| 59 | 60 | |
| 60 | 61 | .. only:: subproject and html |
| 61 | 62 | |
| @@ -1,8 +1,11 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | + | |
| 3 | +================================== | |
| 1 | 4 | _DSD Device Properties Usage Rules |
| 2 | −---------------------------------- | |
| 5 | +================================== | |
| 3 | 6 | |
| 4 | 7 | Properties, Property Sets and Property Subsets |
| 5 | −---------------------------------------------- | |
| 8 | +============================================== | |
| 6 | 9 | |
| 7 | 10 | The _DSD (Device Specific Data) configuration object, introduced in ACPI 5.1, |
| 8 | 11 | allows any type of device configuration data to be provided via the ACPI |
| @@ -18,7 +21,7 @@ specific type) associated with it. · 9 unmodified lines | ||
| 18 | 21 | |
| 19 | 22 | In the ACPI _DSD context it is an element of the sub-package following the |
| 20 | 23 | generic Device Properties UUID in the _DSD return package as specified in the |
| 21 | −Device Properties UUID definition document [1]. | |
| 24 | +Device Properties UUID definition document [1]_. | |
| 22 | 25 | |
| 23 | 26 | It also may be regarded as the definition of a key and the associated data type |
| 24 | 27 | that can be returned by _DSD in the Device Properties UUID sub-package for a |
| @@ -33,14 +36,14 @@ Property subsets are nested collections of properties. Each of them is · 8 unmodified lines | ||
| 33 | 36 | associated with an additional key (name) allowing the subset to be referred |
| 34 | 37 | to as a whole (and to be treated as a separate entity). The canonical |
| 35 | 38 | representation of property subsets is via the mechanism specified in the |
| 36 | −Hierarchical Properties Extension UUID definition document [2]. | |
| 39 | +Hierarchical Properties Extension UUID definition document [2]_. | |
| 37 | 40 | |
| 38 | 41 | Property sets may be hierarchical. That is, a property set may contain |
| 39 | 42 | multiple property subsets that each may contain property subsets of its |
| 40 | 43 | own and so on. |
| 41 | 44 | |
| 42 | 45 | General Validity Rule for Property Sets |
| 43 | −--------------------------------------- | |
| 46 | +======================================= | |
| 44 | 47 | |
| 45 | 48 | Valid property sets must follow the guidance given by the Device Properties UUID |
| 46 | 49 | definition document [1]. |
| @@ -73,7 +76,7 @@ suitable for the ACPI environment and consequently they cannot belong to a valid · 26 unmodified lines | ||
| 73 | 76 | property set. |
| 74 | 77 | |
| 75 | 78 | Property Sets and Device Tree Bindings |
| 76 | −-------------------------------------- | |
| 79 | +====================================== | |
| 77 | 80 | |
| 78 | 81 | It often is useful to make _DSD return property sets that follow Device Tree |
| 79 | 82 | bindings. |
| @@ -91,7 +94,7 @@ expected to automatically work in the ACPI environment regardless of their · 11 unmodified lines | ||
| 91 | 94 | contents. |
| 92 | 95 | |
| 93 | 96 | References |
| 94 | −---------- | |
| 97 | +========== | |
| 95 | 98 | |
| 96 | −[1] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf | |
| 97 | −[2] http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf | |
| 99 | +.. [1] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf | |
| 100 | +.. [2] http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf | |
| @@ -1,13 +1,18 @@ | ||
| 1 | −Special Usage Model of the ACPI Control Method Lid Device | |
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | +.. include:: <isonum.txt> | |
| 2 | 3 | |
| 3 | −Copyright (C) 2016, Intel Corporation | |
| 4 | −Author: Lv Zheng <lv.zheng@intel.com> | |
| 4 | +========================================================= | |
| 5 | +Special Usage Model of the ACPI Control Method Lid Device | |
| 6 | +========================================================= | |
| 5 | 7 | |
| 8 | +:Copyright: |copy| 2016, Intel Corporation | |
| 6 | 9 | |
| 7 | −Abstract: | |
| 10 | +:Author: Lv Zheng <lv.zheng@intel.com> | |
| 8 | 11 | |
| 9 | −Platforms containing lids convey lid state (open/close) to OSPMs using a | |
| 10 | −control method lid device. To implement this, the AML tables issue | |
| 12 | +Abstract | |
| 13 | +======== | |
| 14 | +Platforms containing lids convey lid state (open/close) to OSPMs | |
| 15 | +using a control method lid device. To implement this, the AML tables issue | |
| 11 | 16 | Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has |
| 12 | 17 | changed. The _LID control method for the lid device must be implemented to |
| 13 | 18 | report the "current" state of the lid as either "opened" or "closed". |
| @@ -19,7 +24,8 @@ taken into account. This document describes the restrictions and the · 5 unmodified lines | ||
| 19 | 24 | expections of the Linux ACPI lid device driver. |
| 20 | 25 | |
| 21 | 26 | |
| 22 | −1. Restrictions of the returning value of the _LID control method | |
| 27 | +Restrictions of the returning value of the _LID control method | |
| 28 | +============================================================== | |
| 23 | 29 | |
| 24 | 30 | The _LID control method is described to return the "current" lid state. |
| 25 | 31 | However the word of "current" has ambiguity, some buggy AML tables return |
| @@ -30,7 +36,8 @@ initial returning value. When the AML tables implement this control method · 4 unmodified lines | ||
| 30 | 36 | with cached value, the initial returning value is likely not reliable. |
| 31 | 37 | There are platforms always retun "closed" as initial lid state. |
| 32 | 38 | |
| 33 | −2. Restrictions of the lid state change notifications | |
| 39 | +Restrictions of the lid state change notifications | |
| 40 | +================================================== | |
| 34 | 41 | |
| 35 | 42 | There are buggy AML tables never notifying when the lid device state is |
| 36 | 43 | changed to "opened". Thus the "opened" notification is not guaranteed. But |
| @@ -39,18 +46,22 @@ state is changed to "closed". The "closed" notification is normally used to · 2 unmodified lines | ||
| 39 | 46 | trigger some system power saving operations on Windows. Since it is fully |
| 40 | 47 | tested, it is reliable from all AML tables. |
| 41 | 48 | |
| 42 | −3. Expections for the userspace users of the ACPI lid device driver | |
| 49 | +Expections for the userspace users of the ACPI lid device driver | |
| 50 | +================================================================ | |
| 43 | 51 | |
| 44 | 52 | The ACPI button driver exports the lid state to the userspace via the |
| 45 | −following file: | |
| 53 | +following file:: | |
| 54 | + | |
| 46 | 55 | /proc/acpi/button/lid/LID0/state |
| 56 | + | |
| 47 | 57 | This file actually calls the _LID control method described above. And given |
| 48 | 58 | the previous explanation, it is not reliable enough on some platforms. So |
| 49 | 59 | it is advised for the userspace program to not to solely rely on this file |
| 50 | 60 | to determine the actual lid state. |
| 51 | 61 | |
| 52 | 62 | The ACPI button driver emits the following input event to the userspace: |
| 53 | − SW_LID | |
| 63 | + * SW_LID | |
| 64 | + | |
| 54 | 65 | The ACPI lid device driver is implemented to try to deliver the platform |
| 55 | 66 | triggered events to the userspace. However, given the fact that the buggy |
| 56 | 67 | firmware cannot make sure "opened"/"closed" events are paired, the ACPI |
| @@ -59,20 +70,25 @@ button driver uses the following 3 modes in order not to trigger issues. · 2 unmodified lines | ||
| 59 | 70 | If the userspace hasn't been prepared to ignore the unreliable "opened" |
| 60 | 71 | events and the unreliable initial state notification, Linux users can use |
| 61 | 72 | the following kernel parameters to handle the possible issues: |
| 73 | + | |
| 62 | 74 | A. button.lid_init_state=method: |
| 63 | 75 | When this option is specified, the ACPI button driver reports the |
| 64 | 76 | initial lid state using the returning value of the _LID control method |
| 65 | 77 | and whether the "opened"/"closed" events are paired fully relies on the |
| 66 | 78 | firmware implementation. |
| 79 | + | |
| 67 | 80 | This option can be used to fix some platforms where the returning value |
| 68 | 81 | of the _LID control method is reliable but the initial lid state |
| 69 | 82 | notification is missing. |
| 83 | + | |
| 70 | 84 | This option is the default behavior during the period the userspace |
| 71 | 85 | isn't ready to handle the buggy AML tables. |
| 86 | + | |
| 72 | 87 | B. button.lid_init_state=open: |
| 73 | 88 | When this option is specified, the ACPI button driver always reports the |
| 74 | 89 | initial lid state as "opened" and whether the "opened"/"closed" events |
| 75 | 90 | are paired fully relies on the firmware implementation. |
| 91 | + | |
| 76 | 92 | This may fix some platforms where the returning value of the _LID |
| 77 | 93 | control method is not reliable and the initial lid state notification is |
| 78 | 94 | missing. |
| @@ -80,6 +96,7 @@ B. button.lid_init_state=open: · 1 unmodified line | ||
| 80 | 96 | If the userspace has been prepared to ignore the unreliable "opened" events |
| 81 | 97 | and the unreliable initial state notification, Linux users should always |
| 82 | 98 | use the following kernel parameter: |
| 99 | + | |
| 83 | 100 | C. button.lid_init_state=ignore: |
| 84 | 101 | When this option is specified, the ACPI button driver never reports the |
| 85 | 102 | initial lid state and there is a compensation mechanism implemented to |
| @@ -89,6 +106,7 @@ C. button.lid_init_state=ignore: · 3 unmodified lines | ||
| 89 | 106 | notifications can be delivered to the userspace when the lid is actually |
| 90 | 107 | opens given that some AML tables do not send "opened" notifications |
| 91 | 108 | reliably. |
| 109 | + | |
| 92 | 110 | In this mode, if everything is correctly implemented by the platform |
| 93 | 111 | firmware, the old userspace programs should still work. Otherwise, the |
| 94 | 112 | new userspace programs are required to work with the ACPI button driver. |
| @@ -0,0 +1,75 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | +.. include:: <isonum.txt> | |
| 3 | + | |
| 4 | +================ | |
| 5 | +The AML Debugger | |
| 6 | +================ | |
| 7 | + | |
| 8 | +:Copyright: |copy| 2016, Intel Corporation | |
| 9 | +:Author: Lv Zheng <lv.zheng@intel.com> | |
| 10 | + | |
| 11 | + | |
| 12 | +This document describes the usage of the AML debugger embedded in the Linux | |
| 13 | +kernel. | |
| 14 | + | |
| 15 | +1. Build the debugger | |
| 16 | +===================== | |
| 17 | + | |
| 18 | +The following kernel configuration items are required to enable the AML | |
| 19 | +debugger interface from the Linux kernel:: | |
| 20 | + | |
| 21 | + CONFIG_ACPI_DEBUGGER=y | |
| 22 | + CONFIG_ACPI_DEBUGGER_USER=m | |
| 23 | + | |
| 24 | +The userspace utilities can be built from the kernel source tree using | |
| 25 | +the following commands:: | |
| 26 | + | |
| 27 | + $ cd tools | |
| 28 | + $ make acpi | |
| 29 | + | |
| 30 | +The resultant userspace tool binary is then located at:: | |
| 31 | + | |
| 32 | + tools/power/acpi/acpidbg | |
| 33 | + | |
| 34 | +It can be installed to system directories by running "make install" (as a | |
| 35 | +sufficiently privileged user). | |
| 36 | + | |
| 37 | +2. Start the userspace debugger interface | |
| 38 | +========================================= | |
| 39 | + | |
| 40 | +After booting the kernel with the debugger built-in, the debugger can be | |
| 41 | +started by using the following commands:: | |
| 42 | + | |
| 43 | + # mount -t debugfs none /sys/kernel/debug | |
| 44 | + # modprobe acpi_dbg | |
| 45 | + # tools/power/acpi/acpidbg | |
| 46 | + | |
| 47 | +That spawns the interactive AML debugger environment where you can execute | |
| 48 | +debugger commands. | |
| 49 | + | |
| 50 | +The commands are documented in the "ACPICA Overview and Programmer Reference" | |
| 51 | +that can be downloaded from | |
| 52 | + | |
| 53 | +https://acpica.org/documentation | |
| 54 | + | |
| 55 | +The detailed debugger commands reference is located in Chapter 12 "ACPICA | |
| 56 | +Debugger Reference". The "help" command can be used for a quick reference. | |
| 57 | + | |
| 58 | +3. Stop the userspace debugger interface | |
| 59 | +======================================== | |
| 60 | + | |
| 61 | +The interactive debugger interface can be closed by pressing Ctrl+C or using | |
| 62 | +the "quit" or "exit" commands. When finished, unload the module with:: | |
| 63 | + | |
| 64 | + # rmmod acpi_dbg | |
| 65 | + | |
| 66 | +The module unloading may fail if there is an acpidbg instance running. | |
| 67 | + | |
| 68 | +4. Run the debugger in a script | |
| 69 | +=============================== | |
| 70 | + | |
| 71 | +It may be useful to run the AML debugger in a test script. "acpidbg" supports | |
| 72 | +this in a special "batch" mode. For example, the following command outputs | |
| 73 | +the entire ACPI namespace:: | |
| 74 | + | |
| 75 | + # acpidbg -b "namespace" | |
| @@ -1,13 +1,16 @@ | ||
| 1 | − APEI Error INJection | |
| 2 | − ~~~~~~~~~~~~~~~~~~~~ | |
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | + | |
| 3 | +==================== | |
| 4 | +APEI Error INJection | |
| 5 | +==================== | |
| 3 | 6 | |
| 4 | 7 | EINJ provides a hardware error injection mechanism. It is very useful |
| 5 | 8 | for debugging and testing APEI and RAS features in general. |
| 6 | 9 | |
| 7 | 10 | You need to check whether your BIOS supports EINJ first. For that, look |
| 8 | −for early boot messages similar to this one: | |
| 11 | +for early boot messages similar to this one:: | |
| 9 | 12 | |
| 10 | −ACPI: EINJ 0x000000007370A000 000150 (v01 INTEL 00000001 INTL 00000001) | |
| 13 | + ACPI: EINJ 0x000000007370A000 000150 (v01 INTEL 00000001 INTL 00000001) | |
| 11 | 14 | |
| 12 | 15 | which shows that the BIOS is exposing an EINJ table - it is the |
| 13 | 16 | mechanism through which the injection is done. |
| @@ -23,11 +26,11 @@ order to see the APEI,EINJ,... functionality supported and exposed by · 9 unmodified lines | ||
| 23 | 26 | the BIOS menu. |
| 24 | 27 | |
| 25 | 28 | To use EINJ, make sure the following are options enabled in your kernel |
| 26 | −configuration: | |
| 29 | +configuration:: | |
| 27 | 30 | |
| 28 | −CONFIG_DEBUG_FS | |
| 29 | −CONFIG_ACPI_APEI | |
| 30 | −CONFIG_ACPI_APEI_EINJ | |
| 31 | + CONFIG_DEBUG_FS | |
| 32 | + CONFIG_ACPI_APEI | |
| 33 | + CONFIG_ACPI_APEI_EINJ | |
| 31 | 34 | |
| 32 | 35 | The EINJ user interface is in <debugfs mount point>/apei/einj. |
| 33 | 36 | |
| @@ -37,20 +40,22 @@ The following files belong to it: · 3 unmodified lines | ||
| 37 | 40 | |
| 38 | 41 | This file shows which error types are supported: |
| 39 | 42 | |
| 43 | + ================ =================================== | |
| 40 | 44 | Error Type Value Error Description |
| 41 | − ================ ================= | |
| 42 | − 0x00000001 Processor Correctable | |
| 43 | − 0x00000002 Processor Uncorrectable non-fatal | |
| 44 | − 0x00000004 Processor Uncorrectable fatal | |
| 45 | − 0x00000008 Memory Correctable | |
| 46 | − 0x00000010 Memory Uncorrectable non-fatal | |
| 47 | − 0x00000020 Memory Uncorrectable fatal | |
| 48 | − 0x00000040 PCI Express Correctable | |
| 49 | − 0x00000080 PCI Express Uncorrectable fatal | |
| 50 | − 0x00000100 PCI Express Uncorrectable non-fatal | |
| 51 | − 0x00000200 Platform Correctable | |
| 52 | − 0x00000400 Platform Uncorrectable non-fatal | |
| 53 | − 0x00000800 Platform Uncorrectable fatal | |
| 45 | + ================ =================================== | |
| 46 | + 0x00000001 Processor Correctable | |
| 47 | + 0x00000002 Processor Uncorrectable non-fatal | |
| 48 | + 0x00000004 Processor Uncorrectable fatal | |
| 49 | + 0x00000008 Memory Correctable | |
| 50 | + 0x00000010 Memory Uncorrectable non-fatal | |
| 51 | + 0x00000020 Memory Uncorrectable fatal | |
| 52 | + 0x00000040 PCI Express Correctable | |
| 53 | + 0x00000080 PCI Express Uncorrectable fatal | |
| 54 | + 0x00000100 PCI Express Uncorrectable non-fatal | |
| 55 | + 0x00000200 Platform Correctable | |
| 56 | + 0x00000400 Platform Uncorrectable non-fatal | |
| 57 | + 0x00000800 Platform Uncorrectable fatal | |
| 58 | + ================ =================================== | |
| 54 | 59 | |
| 55 | 60 | The format of the file contents are as above, except present are only |
| 56 | 61 | the available error types. |
| @@ -73,9 +78,12 @@ The following files belong to it: · 16 unmodified lines | ||
| 73 | 78 | injection. Value is a bitmask as specified in ACPI5.0 spec for the |
| 74 | 79 | SET_ERROR_TYPE_WITH_ADDRESS data structure: |
| 75 | 80 | |
| 76 | − Bit 0 - Processor APIC field valid (see param3 below). | |
| 77 | − Bit 1 - Memory address and mask valid (param1 and param2). | |
| 78 | − Bit 2 - PCIe (seg,bus,dev,fn) valid (see param4 below). | |
| 81 | + Bit 0 | |
| 82 | + Processor APIC field valid (see param3 below). | |
| 83 | + Bit 1 | |
| 84 | + Memory address and mask valid (param1 and param2). | |
| 85 | + Bit 2 | |
| 86 | + PCIe (seg,bus,dev,fn) valid (see param4 below). | |
| 79 | 87 | |
| 80 | 88 | If set to zero, legacy behavior is mimicked where the type of |
| 81 | 89 | injection specifies just one bit set, and param1 is multiplexed. |
| @@ -121,7 +129,7 @@ BIOS versions based on the ACPI 5.0 specification have more control over · 39 unmodified lines | ||
| 121 | 129 | the target of the injection. For processor-related errors (type 0x1, 0x2 |
| 122 | 130 | and 0x4), you can set flags to 0x3 (param3 for bit 0, and param1 and |
| 123 | 131 | param2 for bit 1) so that you have more information added to the error |
| 124 | −signature being injected. The actual data passed is this: | |
| 132 | +signature being injected. The actual data passed is this:: | |
| 125 | 133 | |
| 126 | 134 | memory_address = param1; |
| 127 | 135 | memory_address_range = param2; |
| @@ -131,7 +139,7 @@ signature being injected. The actual data passed is this: · 3 unmodified lines | ||
| 131 | 139 | For memory errors (type 0x8, 0x10 and 0x20) the address is set using |
| 132 | 140 | param1 with a mask in param2 (0x0 is equivalent to all ones). For PCI |
| 133 | 141 | express errors (type 0x40, 0x80 and 0x100) the segment, bus, device and |
| 134 | −function are specified using param1: | |
| 142 | +function are specified using param1:: | |
| 135 | 143 | |
| 136 | 144 | 31 24 23 16 15 11 10 8 7 0 |
| 137 | 145 | +-------------------------------------------------+ |
| @@ -152,26 +160,26 @@ documentation for details (and expect changes to this API if vendors · 14 unmodified lines | ||
| 152 | 160 | creativity in using this feature expands beyond our expectations). |
| 153 | 161 | |
| 154 | 162 | |
| 155 | −An error injection example: | |
| 163 | +An error injection example:: | |
| 156 | 164 | |
| 157 | −# cd /sys/kernel/debug/apei/einj | |
| 158 | −# cat available_error_type # See which errors can be injected | |
| 159 | −0x00000002 Processor Uncorrectable non-fatal | |
| 160 | −0x00000008 Memory Correctable | |
| 161 | −0x00000010 Memory Uncorrectable non-fatal | |
| 162 | −# echo 0x12345000 > param1 # Set memory address for injection | |
| 163 | −# echo $((-1 << 12)) > param2 # Mask 0xfffffffffffff000 - anywhere in this page | |
| 164 | −# echo 0x8 > error_type # Choose correctable memory error | |
| 165 | −# echo 1 > error_inject # Inject now | |
| 165 | + # cd /sys/kernel/debug/apei/einj | |
| 166 | + # cat available_error_type # See which errors can be injected | |
| 167 | + 0x00000002 Processor Uncorrectable non-fatal | |
| 168 | + 0x00000008 Memory Correctable | |
| 169 | + 0x00000010 Memory Uncorrectable non-fatal | |
| 170 | + # echo 0x12345000 > param1 # Set memory address for injection | |
| 171 | + # echo $((-1 << 12)) > param2 # Mask 0xfffffffffffff000 - anywhere in this page | |
| 172 | + # echo 0x8 > error_type # Choose correctable memory error | |
| 173 | + # echo 1 > error_inject # Inject now | |
| 166 | 174 | |
| 167 | −You should see something like this in dmesg: | |
| 175 | +You should see something like this in dmesg:: | |
| 168 | 176 | |
| 169 | −[22715.830801] EDAC sbridge MC3: HANDLING MCE MEMORY ERROR | |
| 170 | −[22715.834759] EDAC sbridge MC3: CPU 0: Machine Check Event: 0 Bank 7: 8c00004000010090 | |
| 171 | −[22715.834759] EDAC sbridge MC3: TSC 0 | |
| 172 | −[22715.834759] EDAC sbridge MC3: ADDR 12345000 EDAC sbridge MC3: MISC 144780c86 | |
| 173 | −[22715.834759] EDAC sbridge MC3: PROCESSOR 0:306e7 TIME 1422553404 SOCKET 0 APIC 0 | |
| 174 | −[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) | |
| 177 | + [22715.830801] EDAC sbridge MC3: HANDLING MCE MEMORY ERROR | |
| 178 | + [22715.834759] EDAC sbridge MC3: CPU 0: Machine Check Event: 0 Bank 7: 8c00004000010090 | |
| 179 | + [22715.834759] EDAC sbridge MC3: TSC 0 | |
| 180 | + [22715.834759] EDAC sbridge MC3: ADDR 12345000 EDAC sbridge MC3: MISC 144780c86 | |
| 181 | + [22715.834759] EDAC sbridge MC3: PROCESSOR 0:306e7 TIME 1422553404 SOCKET 0 APIC 0 | |
| 182 | + [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) | |
| 175 | 183 | |
| 176 | 184 | For more information about EINJ, please refer to ACPI specification |
| 177 | 185 | version 4.0, section 17.5 and ACPI 5.0, section 18.6. |
| @@ -0,0 +1,150 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | + | |
| 3 | +================== | |
| 4 | +APEI output format | |
| 5 | +================== | |
| 6 | + | |
| 7 | +APEI uses printk as hardware error reporting interface, the output | |
| 8 | +format is as follow:: | |
| 9 | + | |
| 10 | + <error record> := | |
| 11 | + APEI generic hardware error status | |
| 12 | + severity: <integer>, <severity string> | |
| 13 | + section: <integer>, severity: <integer>, <severity string> | |
| 14 | + flags: <integer> | |
| 15 | + <section flags strings> | |
| 16 | + fru_id: <uuid string> | |
| 17 | + fru_text: <string> | |
| 18 | + section_type: <section type string> | |
| 19 | + <section data> | |
| 20 | + | |
| 21 | + <severity string>* := recoverable | fatal | corrected | info | |
| 22 | + | |
| 23 | + <section flags strings># := | |
| 24 | + [primary][, containment warning][, reset][, threshold exceeded]\ | |
| 25 | + [, resource not accessible][, latent error] | |
| 26 | + | |
| 27 | + <section type string> := generic processor error | memory error | \ | |
| 28 | + PCIe error | unknown, <uuid string> | |
| 29 | + | |
| 30 | + <section data> := | |
| 31 | + <generic processor section data> | <memory section data> | \ | |
| 32 | + <pcie section data> | <null> | |
| 33 | + | |
| 34 | + <generic processor section data> := | |
| 35 | + [processor_type: <integer>, <proc type string>] | |
| 36 | + [processor_isa: <integer>, <proc isa string>] | |
| 37 | + [error_type: <integer> | |
| 38 | + <proc error type strings>] | |
| 39 | + [operation: <integer>, <proc operation string>] | |
| 40 | + [flags: <integer> | |
| 41 | + <proc flags strings>] | |
| 42 | + [level: <integer>] | |
| 43 | + [version_info: <integer>] | |
| 44 | + [processor_id: <integer>] | |
| 45 | + [target_address: <integer>] | |
| 46 | + [requestor_id: <integer>] | |
| 47 | + [responder_id: <integer>] | |
| 48 | + [IP: <integer>] | |
| 49 | + | |
| 50 | + <proc type string>* := IA32/X64 | IA64 | |
| 51 | + | |
| 52 | + <proc isa string>* := IA32 | IA64 | X64 | |
| 53 | + | |
| 54 | + <processor error type strings># := | |
| 55 | + [cache error][, TLB error][, bus error][, micro-architectural error] | |
| 56 | + | |
| 57 | + <proc operation string>* := unknown or generic | data read | data write | \ | |
| 58 | + instruction execution | |
| 59 | + | |
| 60 | + <proc flags strings># := | |
| 61 | + [restartable][, precise IP][, overflow][, corrected] | |
| 62 | + | |
| 63 | + <memory section data> := | |
| 64 | + [error_status: <integer>] | |
| 65 | + [physical_address: <integer>] | |
| 66 | + [physical_address_mask: <integer>] | |
| 67 | + [node: <integer>] | |
| 68 | + [card: <integer>] | |
| 69 | + [module: <integer>] | |
| 70 | + [bank: <integer>] | |
| 71 | + [device: <integer>] | |
| 72 | + [row: <integer>] | |
| 73 | + [column: <integer>] | |
| 74 | + [bit_position: <integer>] | |
| 75 | + [requestor_id: <integer>] | |
| 76 | + [responder_id: <integer>] | |
| 77 | + [target_id: <integer>] | |
| 78 | + [error_type: <integer>, <mem error type string>] | |
| 79 | + | |
| 80 | + <mem error type string>* := | |
| 81 | + unknown | no error | single-bit ECC | multi-bit ECC | \ | |
| 82 | + single-symbol chipkill ECC | multi-symbol chipkill ECC | master abort | \ | |
| 83 | + target abort | parity error | watchdog timeout | invalid address | \ | |
| 84 | + mirror Broken | memory sparing | scrub corrected error | \ | |
| 85 | + scrub uncorrected error | |
| 86 | + | |
| 87 | + <pcie section data> := | |
| 88 | + [port_type: <integer>, <pcie port type string>] | |
| 89 | + [version: <integer>.<integer>] | |
| 90 | + [command: <integer>, status: <integer>] | |
| 91 | + [device_id: <integer>:<integer>:<integer>.<integer> | |
| 92 | + slot: <integer> | |
| 93 | + secondary_bus: <integer> | |
| 94 | + vendor_id: <integer>, device_id: <integer> | |
| 95 | + class_code: <integer>] | |
| 96 | + [serial number: <integer>, <integer>] | |
| 97 | + [bridge: secondary_status: <integer>, control: <integer>] | |
| 98 | + [aer_status: <integer>, aer_mask: <integer> | |
| 99 | + <aer status string> | |
| 100 | + [aer_uncor_severity: <integer>] | |
| 101 | + aer_layer=<aer layer string>, aer_agent=<aer agent string> | |
| 102 | + aer_tlp_header: <integer> <integer> <integer> <integer>] | |
| 103 | + | |
| 104 | + <pcie port type string>* := PCIe end point | legacy PCI end point | \ | |
| 105 | + unknown | unknown | root port | upstream switch port | \ | |
| 106 | + downstream switch port | PCIe to PCI/PCI-X bridge | \ | |
| 107 | + PCI/PCI-X to PCIe bridge | root complex integrated endpoint device | \ | |
| 108 | + root complex event collector | |
| 109 | + | |
| 110 | + if section severity is fatal or recoverable | |
| 111 | + <aer status string># := | |
| 112 | + unknown | unknown | unknown | unknown | Data Link Protocol | \ | |
| 113 | + unknown | unknown | unknown | unknown | unknown | unknown | unknown | \ | |
| 114 | + Poisoned TLP | Flow Control Protocol | Completion Timeout | \ | |
| 115 | + Completer Abort | Unexpected Completion | Receiver Overflow | \ | |
| 116 | + Malformed TLP | ECRC | Unsupported Request | |
| 117 | + else | |
| 118 | + <aer status string># := | |
| 119 | + Receiver Error | unknown | unknown | unknown | unknown | unknown | \ | |
| 120 | + Bad TLP | Bad DLLP | RELAY_NUM Rollover | unknown | unknown | unknown | \ | |
| 121 | + Replay Timer Timeout | Advisory Non-Fatal | |
| 122 | + fi | |
| 123 | + | |
| 124 | + <aer layer string> := | |
| 125 | + Physical Layer | Data Link Layer | Transaction Layer | |
| 126 | + | |
| 127 | + <aer agent string> := | |
| 128 | + Receiver ID | Requester ID | Completer ID | Transmitter ID | |
| 129 | + | |
| 130 | +Where, [] designate corresponding content is optional | |
| 131 | + | |
| 132 | +All <field string> description with * has the following format:: | |
| 133 | + | |
| 134 | + field: <integer>, <field string> | |
| 135 | + | |
| 136 | +Where value of <integer> should be the position of "string" in <field | |
| 137 | +string> description. Otherwise, <field string> will be "unknown". | |
| 138 | + | |
| 139 | +All <field strings> description with # has the following format:: | |
| 140 | + | |
| 141 | + field: <integer> | |
| 142 | + <field strings> | |
| 143 | + | |
| 144 | +Where each string in <fields strings> corresponding to one set bit of | |
| 145 | +<integer>. The bit position is the position of "string" in <field | |
| 146 | +strings> description. | |
| 147 | + | |
| 148 | +For more detailed explanation of every field, please refer to UEFI | |
| 149 | +specification version 2.3 or later, section Appendix N: Common | |
| 150 | +Platform Error Record. | |
| @@ -1,18 +1,21 @@ | ||
| 1 | − ACPI Debug Output | |
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | 2 | |
| 3 | +================= | |
| 4 | +ACPI Debug Output | |
| 5 | +================= | |
| 3 | 6 | |
| 4 | 7 | The ACPI CA, the Linux ACPI core, and some ACPI drivers can generate debug |
| 5 | 8 | output. This document describes how to use this facility. |
| 6 | 9 | |
| 7 | 10 | Compile-time configuration |
| 8 | −-------------------------- | |
| 11 | +========================== | |
| 9 | 12 | |
| 10 | 13 | ACPI debug output is globally enabled by CONFIG_ACPI_DEBUG. If this config |
| 11 | 14 | option is turned off, the debug messages are not even built into the |
| 12 | 15 | kernel. |
| 13 | 16 | |
| 14 | 17 | Boot- and run-time configuration |
| 15 | −-------------------------------- | |
| 18 | +================================ | |
| 16 | 19 | |
| 17 | 20 | When CONFIG_ACPI_DEBUG=y, you can select the component and level of messages |
| 18 | 21 | you're interested in. At boot-time, use the acpi.debug_layer and |
| @@ -21,7 +24,7 @@ debug_layer and debug_level files in /sys/module/acpi/parameters/ to control · 2 unmodified lines | ||
| 21 | 24 | the debug messages. |
| 22 | 25 | |
| 23 | 26 | debug_layer (component) |
| 24 | −----------------------- | |
| 27 | +======================= | |
| 25 | 28 | |
| 26 | 29 | The "debug_layer" is a mask that selects components of interest, e.g., a |
| 27 | 30 | specific driver or part of the ACPI interpreter. To build the debug_layer |
| @@ -33,7 +36,7 @@ to /sys/module/acpi/parameters/debug_layer. · 5 unmodified lines | ||
| 33 | 36 | |
| 34 | 37 | The possible components are defined in include/acpi/acoutput.h and |
| 35 | 38 | include/acpi/acpi_drivers.h. Reading /sys/module/acpi/parameters/debug_layer |
| 36 | −shows the supported mask values, currently these: | |
| 39 | +shows the supported mask values, currently these:: | |
| 37 | 40 | |
| 38 | 41 | ACPI_UTILITIES 0x00000001 |
| 39 | 42 | ACPI_HARDWARE 0x00000002 |
| @@ -65,7 +68,7 @@ shows the supported mask values, currently these: · 25 unmodified lines | ||
| 65 | 68 | ACPI_PROCESSOR_COMPONENT 0x20000000 |
| 66 | 69 | |
| 67 | 70 | debug_level |
| 68 | −----------- | |
| 71 | +=========== | |
| 69 | 72 | |
| 70 | 73 | The "debug_level" is a mask that selects different types of messages, e.g., |
| 71 | 74 | those related to initialization, method execution, informational messages, etc. |
| @@ -81,7 +84,7 @@ to /sys/module/acpi/parameters/debug_level. · 9 unmodified lines | ||
| 81 | 84 | |
| 82 | 85 | The possible levels are defined in include/acpi/acoutput.h. Reading |
| 83 | 86 | /sys/module/acpi/parameters/debug_level shows the supported mask values, |
| 84 | −currently these: | |
| 87 | +currently these:: | |
| 85 | 88 | |
| 86 | 89 | ACPI_LV_INIT 0x00000001 |
| 87 | 90 | ACPI_LV_DEBUG_OBJECT 0x00000002 |
| @@ -113,9 +116,9 @@ currently these: · 25 unmodified lines | ||
| 113 | 116 | ACPI_LV_EVENTS 0x80000000 |
| 114 | 117 | |
| 115 | 118 | Examples |
| 116 | −-------- | |
| 119 | +======== | |
| 117 | 120 | |
| 118 | −For example, drivers/acpi/bus.c contains this: | |
| 121 | +For example, drivers/acpi/bus.c contains this:: | |
| 119 | 122 | |
| 120 | 123 | #define _COMPONENT ACPI_BUS_COMPONENT |
| 121 | 124 | ... |
| @@ -127,22 +130,22 @@ statement uses ACPI_DB_INFO, which is macro based on the ACPI_LV_INFO · 5 unmodified lines | ||
| 127 | 130 | definition.) |
| 128 | 131 | |
| 129 | 132 | Enable all AML "Debug" output (stores to the Debug object while interpreting |
| 130 | −AML) during boot: | |
| 133 | +AML) during boot:: | |
| 131 | 134 | |
| 132 | 135 | acpi.debug_layer=0xffffffff acpi.debug_level=0x2 |
| 133 | 136 | |
| 134 | −Enable PCI and PCI interrupt routing debug messages: | |
| 137 | +Enable PCI and PCI interrupt routing debug messages:: | |
| 135 | 138 | |
| 136 | 139 | acpi.debug_layer=0x400000 acpi.debug_level=0x4 |
| 137 | 140 | |
| 138 | −Enable all ACPI hardware-related messages: | |
| 141 | +Enable all ACPI hardware-related messages:: | |
| 139 | 142 | |
| 140 | 143 | acpi.debug_layer=0x2 acpi.debug_level=0xffffffff |
| 141 | 144 | |
| 142 | −Enable all ACPI_DB_INFO messages after boot: | |
| 145 | +Enable all ACPI_DB_INFO messages after boot:: | |
| 143 | 146 | |
| 144 | 147 | # echo 0x4 > /sys/module/acpi/parameters/debug_level |
| 145 | 148 | |
| 146 | −Show all valid component values: | |
| 149 | +Show all valid component values:: | |
| 147 | 150 | |
| 148 | 151 | # cat /sys/module/acpi/parameters/debug_layer |
| @@ -1,9 +1,12 @@ | ||
| 1 | −Copyright (C) 2018 Intel Corporation | |
| 2 | −Author: Sakari Ailus <sakari.ailus@linux.intel.com> | |
| 3 | − | |
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | +.. include:: <isonum.txt> | |
| 4 | 3 | |
| 4 | +=================================== | |
| 5 | 5 | Referencing hierarchical data nodes |
| 6 | −----------------------------------- | |
| 6 | +=================================== | |
| 7 | + | |
| 8 | +:Copyright: |copy| 2018 Intel Corporation | |
| 9 | +:Author: Sakari Ailus <sakari.ailus@linux.intel.com> | |
| 7 | 10 | |
| 8 | 11 | ACPI in general allows referring to device objects in the tree only. |
| 9 | 12 | Hierarchical data extension nodes may not be referred to directly, hence this |
| @@ -28,13 +31,14 @@ extension key. · 18 unmodified lines | ||
| 28 | 31 | |
| 29 | 32 | |
| 30 | 33 | Example |
| 31 | −------- | |
| 34 | +======= | |
| 32 | 35 | |
| 33 | − In the ASL snippet below, the "reference" _DSD property [2] contains a | |
| 34 | − device object reference to DEV0 and under that device object, a | |
| 35 | − hierarchical data extension key "node@1" referring to the NOD1 object | |
| 36 | − and lastly, a hierarchical data extension key "anothernode" referring to | |
| 37 | − the ANOD object which is also the final target node of the reference. | |
| 36 | +In the ASL snippet below, the "reference" _DSD property [2] contains a | |
| 37 | +device object reference to DEV0 and under that device object, a | |
| 38 | +hierarchical data extension key "node@1" referring to the NOD1 object | |
| 39 | +and lastly, a hierarchical data extension key "anothernode" referring to | |
| 40 | +the ANOD object which is also the final target node of the reference. | |
| 41 | +:: | |
| 38 | 42 | |
| 39 | 43 | Device (DEV0) |
| 40 | 44 | { |
| @@ -75,15 +79,15 @@ Example · 34 unmodified lines | ||
| 75 | 79 | }) |
| 76 | 80 | } |
| 77 | 81 | |
| 78 | −Please also see a graph example in graph.txt . | |
| 82 | +Please also see a graph example in :doc:`graph`. | |
| 79 | 83 | |
| 80 | 84 | References |
| 81 | −---------- | |
| 85 | +========== | |
| 82 | 86 | |
| 83 | 87 | [1] Hierarchical Data Extension UUID For _DSD. |
| 84 | − <URL:http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf>, | |
| 85 | − referenced 2018-07-17. | |
| 88 | +<http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf>, | |
| 89 | +referenced 2018-07-17. | |
| 86 | 90 | |
| 87 | 91 | [2] Device Properties UUID For _DSD. |
| 88 | − <URL:http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf>, | |
| 89 | − referenced 2016-10-04. | |
| 92 | +<http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf>, | |
| 93 | +referenced 2016-10-04. | |
| @@ -1,8 +1,11 @@ | ||
| 1 | −Graphs | |
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | 2 | |
| 3 | +====== | |
| 4 | +Graphs | |
| 5 | +====== | |
| 3 | 6 | |
| 4 | 7 | _DSD |
| 5 | −---- | |
| 8 | +==== | |
| 6 | 9 | |
| 7 | 10 | _DSD (Device Specific Data) [7] is a predefined ACPI device |
| 8 | 11 | configuration object that can be used to convey information on |
| @@ -30,7 +33,7 @@ hierarchical data extension array on each depth. · 21 unmodified lines | ||
| 30 | 33 | |
| 31 | 34 | |
| 32 | 35 | Ports and endpoints |
| 33 | −------------------- | |
| 36 | +=================== | |
| 34 | 37 | |
| 35 | 38 | The port and endpoint concepts are very similar to those in Devicetree |
| 36 | 39 | [3]. A port represents an interface in a device, and an endpoint |
| @@ -38,9 +41,9 @@ represents a connection to that interface. · 1 unmodified line | ||
| 38 | 41 | |
| 39 | 42 | All port nodes are located under the device's "_DSD" node in the hierarchical |
| 40 | 43 | data extension tree. The data extension related to each port node must begin |
| 41 | −with "port" and must be followed by the "@" character and the number of the port | |
| 42 | −as its key. The target object it refers to should be called "PRTX", where "X" is | |
| 43 | −the number of the port. An example of such a package would be: | |
| 44 | +with "port" and must be followed by the "@" character and the number of the | |
| 45 | +port as its key. The target object it refers to should be called "PRTX", where | |
| 46 | +"X" is the number of the port. An example of such a package would be:: | |
| 44 | 47 | |
| 45 | 48 | Package() { "port@4", PRT4 } |
| 46 | 49 | |
| @@ -49,7 +52,7 @@ data extension key of the endpoint nodes must begin with · 2 unmodified lines | ||
| 49 | 52 | "endpoint" and must be followed by the "@" character and the number of the |
| 50 | 53 | endpoint. The object it refers to should be called "EPXY", where "X" is the |
| 51 | 54 | number of the port and "Y" is the number of the endpoint. An example of such a |
| 52 | −package would be: | |
| 55 | +package would be:: | |
| 53 | 56 | |
| 54 | 57 | Package() { "endpoint@0", EP40 } |
| 55 | 58 | |
| @@ -62,85 +65,85 @@ of that port shall be zero. Similarly, if a port may only have a single · 6 unmodified lines | ||
| 62 | 65 | endpoint, the number of that endpoint shall be zero. |
| 63 | 66 | |
| 64 | 67 | The endpoint reference uses property extension with "remote-endpoint" property |
| 65 | −name followed by a reference in the same package. Such references consist of the | |
| 68 | +name followed by a reference in the same package. Such references consist of | |
| 66 | 69 | the remote device reference, the first package entry of the port data extension |
| 67 | 70 | reference under the device and finally the first package entry of the endpoint |
| 68 | −data extension reference under the port. Individual references thus appear as: | |
| 71 | +data extension reference under the port. Individual references thus appear as:: | |
| 69 | 72 | |
| 70 | 73 | Package() { device, "port@X", "endpoint@Y" } |
| 71 | 74 | |
| 72 | −In the above example, "X" is the number of the port and "Y" is the number of the | |
| 73 | −endpoint. | |
| 75 | +In the above example, "X" is the number of the port and "Y" is the number of | |
| 76 | +the endpoint. | |
| 74 | 77 | |
| 75 | 78 | The references to endpoints must be always done both ways, to the |
| 76 | 79 | remote endpoint and back from the referred remote endpoint node. |
| 77 | 80 | |
| 78 | −A simple example of this is show below: | |
| 81 | +A simple example of this is show below:: | |
| 79 | 82 | |
| 80 | 83 | Scope (\_SB.PCI0.I2C2) |
| 81 | 84 | { |
| 82 | − Device (CAM0) | |
| 83 | − { | |
| 84 | − Name (_DSD, Package () { | |
| 85 | − ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), | |
| 86 | − Package () { | |
| 87 | − Package () { "compatible", Package () { "nokia,smia" } }, | |
| 88 | − }, | |
| 89 | − ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), | |
| 90 | − Package () { | |
| 91 | − Package () { "port@0", PRT0 }, | |
| 92 | − } | |
| 93 | − }) | |
| 94 | − Name (PRT0, Package() { | |
| 95 | − ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), | |
| 96 | − Package () { | |
| 97 | − Package () { "reg", 0 }, | |
| 98 | − }, | |
| 99 | − ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), | |
| 100 | − Package () { | |
| 101 | − Package () { "endpoint@0", EP00 }, | |
| 102 | − } | |
| 103 | − }) | |
| 104 | − Name (EP00, Package() { | |
| 105 | − ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), | |
| 106 | − Package () { | |
| 107 | − Package () { "reg", 0 }, | |
| 108 | − Package () { "remote-endpoint", Package() { \_SB.PCI0.ISP, "port@4", "endpoint@0" } }, | |
| 109 | − } | |
| 110 | − }) | |
| 111 | − } | |
| 85 | + Device (CAM0) | |
| 86 | + { | |
| 87 | + Name (_DSD, Package () { | |
| 88 | + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), | |
| 89 | + Package () { | |
| 90 | + Package () { "compatible", Package () { "nokia,smia" } }, | |
| 91 | + }, | |
| 92 | + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), | |
| 93 | + Package () { | |
| 94 | + Package () { "port@0", PRT0 }, | |
| 95 | + } | |
| 96 | + }) | |
| 97 | + Name (PRT0, Package() { | |
| 98 | + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), | |
| 99 | + Package () { | |
| 100 | + Package () { "reg", 0 }, | |
| 101 | + }, | |
| 102 | + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), | |
| 103 | + Package () { | |
| 104 | + Package () { "endpoint@0", EP00 }, | |
| 105 | + } | |
| 106 | + }) | |
| 107 | + Name (EP00, Package() { | |
| 108 | + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), | |
| 109 | + Package () { | |
| 110 | + Package () { "reg", 0 }, | |
| 111 | + Package () { "remote-endpoint", Package() { \_SB.PCI0.ISP, "port@4", "endpoint@0" } }, | |
| 112 | + } | |
| 113 | + }) | |
| 114 | + } | |
| 112 | 115 | } |
| 113 | 116 | |
| 114 | 117 | Scope (\_SB.PCI0) |
| 115 | 118 | { |
| 116 | − Device (ISP) | |
| 117 | − { | |
| 118 | − Name (_DSD, Package () { | |
| 119 | − ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), | |
| 120 | − Package () { | |
| 121 | − Package () { "port@4", PRT4 }, | |
| 122 | − } | |
| 123 | − }) | |
| 124 | − | |
| 125 | − Name (PRT4, Package() { | |
| 126 | − ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), | |
| 127 | − Package () { | |
| 128 | − Package () { "reg", 4 }, /* CSI-2 port number */ | |
| 129 | − }, | |
| 130 | − ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), | |
| 131 | − Package () { | |
| 132 | − Package () { "endpoint@0", EP40 }, | |
| 133 | − } | |
| 134 | − }) | |
| 135 | − | |
| 136 | − Name (EP40, Package() { | |
| 137 | − ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), | |
| 138 | − Package () { | |
| 139 | − Package () { "reg", 0 }, | |
| 140 | − Package () { "remote-endpoint", Package () { \_SB.PCI0.I2C2.CAM0, "port@0", "endpoint@0" } }, | |
| 141 | − } | |
| 142 | − }) | |
| 143 | − } | |
| 119 | + Device (ISP) | |
| 120 | + { | |
| 121 | + Name (_DSD, Package () { | |
| 122 | + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), | |
| 123 | + Package () { | |
| 124 | + Package () { "port@4", PRT4 }, | |
| 125 | + } | |
| 126 | + }) | |
| 127 | + | |
| 128 | + Name (PRT4, Package() { | |
| 129 | + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), | |
| 130 | + Package () { | |
| 131 | + Package () { "reg", 4 }, /* CSI-2 port number */ | |
| 132 | + }, | |
| 133 | + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), | |
| 134 | + Package () { | |
| 135 | + Package () { "endpoint@0", EP40 }, | |
| 136 | + } | |
| 137 | + }) | |
| 138 | + | |
| 139 | + Name (EP40, Package() { | |
| 140 | + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), | |
| 141 | + Package () { | |
| 142 | + Package () { "reg", 0 }, | |
| 143 | + Package () { "remote-endpoint", Package () { \_SB.PCI0.I2C2.CAM0, "port@0", "endpoint@0" } }, | |
| 144 | + } | |
| 145 | + }) | |
| 146 | + } | |
| 144 | 147 | } |
| 145 | 148 | |
| 146 | 149 | Here, the port 0 of the "CAM0" device is connected to the port 4 of |
| @@ -148,27 +151,27 @@ the "ISP" device and vice versa. · 1 unmodified line | ||
| 148 | 151 | |
| 149 | 152 | |
| 150 | 153 | References |
| 151 | −---------- | |
| 154 | +========== | |
| 152 | 155 | |
| 153 | 156 | [1] _DSD (Device Specific Data) Implementation Guide. |
| 154 | − <URL:http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_1.htm>, | |
| 157 | + http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_1.htm, | |
| 155 | 158 | referenced 2016-10-03. |
| 156 | 159 | |
| 157 | −[2] Devicetree. <URL:http://www.devicetree.org>, referenced 2016-10-03. | |
| 160 | +[2] Devicetree. http://www.devicetree.org, referenced 2016-10-03. | |
| 158 | 161 | |
| 159 | 162 | [3] Documentation/devicetree/bindings/graph.txt |
| 160 | 163 | |
| 161 | 164 | [4] Device Properties UUID For _DSD. |
| 162 | − <URL:http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf>, | |
| 165 | + http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf, | |
| 163 | 166 | referenced 2016-10-04. |
| 164 | 167 | |
| 165 | 168 | [5] Hierarchical Data Extension UUID For _DSD. |
| 166 | − <URL:http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf>, | |
| 169 | + http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf, | |
| 167 | 170 | referenced 2016-10-04. |
| 168 | 171 | |
| 169 | 172 | [6] Advanced Configuration and Power Interface Specification. |
| 170 | − <URL:http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf>, | |
| 173 | + http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf, | |
| 171 | 174 | referenced 2016-10-04. |
| 172 | 175 | |
| 173 | 176 | [7] _DSD Device Properties Usage Rules. |
| 174 | − Documentation/acpi/DSD-properties-rules.txt | |
| 177 | + :doc:`../DSD-properties-rules` | |
| @@ -1,5 +1,9 @@ | ||
| 1 | −ACPI based device enumeration | |
| 2 | −~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | + | |
| 3 | +============================= | |
| 4 | +ACPI Based Device Enumeration | |
| 5 | +============================= | |
| 6 | + | |
| 3 | 7 | ACPI 5 introduced a set of new resources (UartTSerialBus, I2cSerialBus, |
| 4 | 8 | SpiSerialBus, GpioIo and GpioInt) which can be used in enumerating slave |
| 5 | 9 | devices behind serial bus controllers. |
| @@ -11,12 +15,12 @@ that are accessed through memory-mapped registers. · 5 unmodified lines | ||
| 11 | 15 | In order to support this and re-use the existing drivers as much as |
| 12 | 16 | possible we decided to do following: |
| 13 | 17 | |
| 14 | − o Devices that have no bus connector resource are represented as | |
| 15 | − platform devices. | |
| 18 | + - Devices that have no bus connector resource are represented as | |
| 19 | + platform devices. | |
| 16 | 20 | |
| 17 | − o Devices behind real busses where there is a connector resource | |
| 18 | − are represented as struct spi_device or struct i2c_device | |
| 19 | − (standard UARTs are not busses so there is no struct uart_device). | |
| 21 | + - Devices behind real busses where there is a connector resource | |
| 22 | + are represented as struct spi_device or struct i2c_device | |
| 23 | + (standard UARTs are not busses so there is no struct uart_device). | |
| 20 | 24 | |
| 21 | 25 | As both ACPI and Device Tree represent a tree of devices (and their |
| 22 | 26 | resources) this implementation follows the Device Tree way as much as |
| @@ -31,7 +35,8 @@ enumerated from ACPI namespace. This handle can be used to extract other · 8 unmodified lines | ||
| 31 | 35 | device-specific configuration. There is an example of this below. |
| 32 | 36 | |
| 33 | 37 | Platform bus support |
| 34 | −~~~~~~~~~~~~~~~~~~~~ | |
| 38 | +==================== | |
| 39 | + | |
| 35 | 40 | Since we are using platform devices to represent devices that are not |
| 36 | 41 | connected to any physical bus we only need to implement a platform driver |
| 37 | 42 | for the device and add supported ACPI IDs. If this same IP-block is used on |
| @@ -39,7 +44,7 @@ some other non-ACPI platform, the driver might work out of the box or needs · 1 unmodified line | ||
| 39 | 44 | some minor changes. |
| 40 | 45 | |
| 41 | 46 | Adding ACPI support for an existing driver should be pretty |
| 42 | −straightforward. Here is the simplest example: | |
| 47 | +straightforward. Here is the simplest example:: | |
| 43 | 48 | |
| 44 | 49 | #ifdef CONFIG_ACPI |
| 45 | 50 | static const struct acpi_device_id mydrv_acpi_match[] = { |
| @@ -61,12 +66,13 @@ configuring GPIOs it can get its ACPI handle and extract this information · 15 unmodified lines | ||
| 61 | 66 | from ACPI tables. |
| 62 | 67 | |
| 63 | 68 | DMA support |
| 64 | −~~~~~~~~~~~ | |
| 69 | +=========== | |
| 70 | + | |
| 65 | 71 | DMA controllers enumerated via ACPI should be registered in the system to |
| 66 | 72 | provide generic access to their resources. For example, a driver that would |
| 67 | 73 | like to be accessible to slave devices via generic API call |
| 68 | 74 | dma_request_slave_channel() must register itself at the end of the probe |
| 69 | −function like this: | |
| 75 | +function like this:: | |
| 70 | 76 | |
| 71 | 77 | err = devm_acpi_dma_controller_register(dev, xlate_func, dw); |
| 72 | 78 | /* Handle the error if it's not a case of !CONFIG_ACPI */ |
| @@ -74,7 +80,7 @@ function like this: · 1 unmodified line | ||
| 74 | 80 | and implement custom xlate function if needed (usually acpi_dma_simple_xlate() |
| 75 | 81 | is enough) which converts the FixedDMA resource provided by struct |
| 76 | 82 | acpi_dma_spec into the corresponding DMA channel. A piece of code for that case |
| 77 | −could look like: | |
| 83 | +could look like:: | |
| 78 | 84 | |
| 79 | 85 | #ifdef CONFIG_ACPI |
| 80 | 86 | struct filter_args { |
| @@ -114,7 +120,7 @@ provided by struct acpi_dma. · 33 unmodified lines | ||
| 114 | 120 | Clients must call dma_request_slave_channel() with the string parameter that |
| 115 | 121 | corresponds to a specific FixedDMA resource. By default "tx" means the first |
| 116 | 122 | entry of the FixedDMA resource array, "rx" means the second entry. The table |
| 117 | −below shows a layout: | |
| 123 | +below shows a layout:: | |
| 118 | 124 | |
| 119 | 125 | Device (I2C0) |
| 120 | 126 | { |
| @@ -138,12 +144,13 @@ acpi_dma_request_slave_chan_by_index() directly and therefore choose the · 17 unmodified lines | ||
| 138 | 144 | specific FixedDMA resource by its index. |
| 139 | 145 | |
| 140 | 146 | SPI serial bus support |
| 141 | −~~~~~~~~~~~~~~~~~~~~~~ | |
| 147 | +====================== | |
| 148 | + | |
| 142 | 149 | Slave devices behind SPI bus have SpiSerialBus resource attached to them. |
| 143 | 150 | This is extracted automatically by the SPI core and the slave devices are |
| 144 | 151 | enumerated once spi_register_master() is called by the bus driver. |
| 145 | 152 | |
| 146 | −Here is what the ACPI namespace for a SPI slave might look like: | |
| 153 | +Here is what the ACPI namespace for a SPI slave might look like:: | |
| 147 | 154 | |
| 148 | 155 | Device (EEP0) |
| 149 | 156 | { |
| @@ -163,7 +170,7 @@ Here is what the ACPI namespace for a SPI slave might look like: · 13 unmodified lines | ||
| 163 | 170 | |
| 164 | 171 | The SPI device drivers only need to add ACPI IDs in a similar way than with |
| 165 | 172 | the platform device drivers. Below is an example where we add ACPI support |
| 166 | −to at25 SPI eeprom driver (this is meant for the above ACPI snippet): | |
| 173 | +to at25 SPI eeprom driver (this is meant for the above ACPI snippet):: | |
| 167 | 174 | |
| 168 | 175 | #ifdef CONFIG_ACPI |
| 169 | 176 | static const struct acpi_device_id at25_acpi_match[] = { |
| @@ -182,7 +189,7 @@ to at25 SPI eeprom driver (this is meant for the above ACPI snippet): · 12 unmodified lines | ||
| 182 | 189 | |
| 183 | 190 | Note that this driver actually needs more information like page size of the |
| 184 | 191 | eeprom etc. but at the time writing this there is no standard way of |
| 185 | −passing those. One idea is to return this in _DSM method like: | |
| 192 | +passing those. One idea is to return this in _DSM method like:: | |
| 186 | 193 | |
| 187 | 194 | Device (EEP0) |
| 188 | 195 | { |
| @@ -202,7 +209,7 @@ passing those. One idea is to return this in _DSM method like: · 13 unmodified lines | ||
| 202 | 209 | } |
| 203 | 210 | |
| 204 | 211 | Then the at25 SPI driver can get this configuration by calling _DSM on its |
| 205 | −ACPI handle like: | |
| 212 | +ACPI handle like:: | |
| 206 | 213 | |
| 207 | 214 | struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL }; |
| 208 | 215 | struct acpi_object_list input; |
| @@ -220,14 +227,15 @@ ACPI handle like: · 11 unmodified lines | ||
| 220 | 227 | kfree(output.pointer); |
| 221 | 228 | |
| 222 | 229 | I2C serial bus support |
| 223 | −~~~~~~~~~~~~~~~~~~~~~~ | |
| 230 | +====================== | |
| 231 | + | |
| 224 | 232 | The slaves behind I2C bus controller only need to add the ACPI IDs like |
| 225 | 233 | with the platform and SPI drivers. The I2C core automatically enumerates |
| 226 | 234 | any slave devices behind the controller device once the adapter is |
| 227 | 235 | registered. |
| 228 | 236 | |
| 229 | 237 | Below is an example of how to add ACPI support to the existing mpu3050 |
| 230 | −input driver: | |
| 238 | +input driver:: | |
| 231 | 239 | |
| 232 | 240 | #ifdef CONFIG_ACPI |
| 233 | 241 | static const struct acpi_device_id mpu3050_acpi_match[] = { |
| @@ -251,56 +259,57 @@ input driver: · 17 unmodified lines | ||
| 251 | 259 | }; |
| 252 | 260 | |
| 253 | 261 | GPIO support |
| 254 | −~~~~~~~~~~~~ | |
| 262 | +============ | |
| 263 | + | |
| 255 | 264 | ACPI 5 introduced two new resources to describe GPIO connections: GpioIo |
| 256 | 265 | and GpioInt. These resources can be used to pass GPIO numbers used by |
| 257 | 266 | the device to the driver. ACPI 5.1 extended this with _DSD (Device |
| 258 | 267 | Specific Data) which made it possible to name the GPIOs among other things. |
| 259 | 268 | |
| 260 | −For example: | |
| 269 | +For example:: | |
| 261 | 270 | |
| 262 | −Device (DEV) | |
| 263 | −{ | |
| 264 | − Method (_CRS, 0, NotSerialized) | |
| 271 | + Device (DEV) | |
| 265 | 272 | { |
| 266 | − Name (SBUF, ResourceTemplate() | |
| 273 | + Method (_CRS, 0, NotSerialized) | |
| 267 | 274 | { |
| 268 | − ... | |
| 269 | − // Used to power on/off the device | |
| 270 | − GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, | |
| 271 | − IoRestrictionOutputOnly, "\\_SB.PCI0.GPI0", | |
| 272 | − 0x00, ResourceConsumer,,) | |
| 275 | + Name (SBUF, ResourceTemplate() | |
| 273 | 276 | { |
| 274 | − // Pin List | |
| 275 | − 0x0055 | |
| 276 | − } | |
| 277 | + ... | |
| 278 | + // Used to power on/off the device | |
| 279 | + GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, | |
| 280 | + IoRestrictionOutputOnly, "\\_SB.PCI0.GPI0", | |
| 281 | + 0x00, ResourceConsumer,,) | |
| 282 | + { | |
| 283 | + // Pin List | |
| 284 | + 0x0055 | |
| 285 | + } | |
| 286 | + | |
| 287 | + // Interrupt for the device | |
| 288 | + GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone, | |
| 289 | + 0x0000, "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer,,) | |
| 290 | + { | |
| 291 | + // Pin list | |
| 292 | + 0x0058 | |
| 293 | + } | |
| 294 | + | |
| 295 | + ... | |
| 277 | 296 | |
| 278 | − // Interrupt for the device | |
| 279 | − GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone, | |
| 280 | − 0x0000, "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer,,) | |
| 281 | − { | |
| 282 | − // Pin list | |
| 283 | − 0x0058 | |
| 284 | 297 | } |
| 285 | 298 | |
| 286 | − ... | |
| 287 | − | |
| 299 | + Return (SBUF) | |
| 288 | 300 | } |
| 289 | 301 | |
| 290 | − Return (SBUF) | |
| 291 | − } | |
| 292 | − | |
| 293 | − // ACPI 5.1 _DSD used for naming the GPIOs | |
| 294 | − Name (_DSD, Package () | |
| 295 | − { | |
| 296 | − ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), | |
| 297 | − Package () | |
| 302 | + // ACPI 5.1 _DSD used for naming the GPIOs | |
| 303 | + Name (_DSD, Package () | |
| 298 | 304 | { |
| 299 | − Package () {"power-gpios", Package() {^DEV, 0, 0, 0 }}, | |
| 300 | − Package () {"irq-gpios", Package() {^DEV, 1, 0, 0 }}, | |
| 301 | − } | |
| 302 | − }) | |
| 303 | − ... | |
| 305 | + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), | |
| 306 | + Package () | |
| 307 | + { | |
| 308 | + Package () {"power-gpios", Package() {^DEV, 0, 0, 0 }}, | |
| 309 | + Package () {"irq-gpios", Package() {^DEV, 1, 0, 0 }}, | |
| 310 | + } | |
| 311 | + }) | |
| 312 | + ... | |
| 304 | 313 | |
| 305 | 314 | These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0" |
| 306 | 315 | specifies the path to the controller. In order to use these GPIOs in Linux |
| @@ -310,7 +319,7 @@ There is a standard GPIO API for that and is documented in · 3 unmodified lines | ||
| 310 | 319 | Documentation/gpio/. |
| 311 | 320 | |
| 312 | 321 | In the above example we can get the corresponding two GPIO descriptors with |
| 313 | −a code like this: | |
| 322 | +a code like this:: | |
| 314 | 323 | |
| 315 | 324 | #include <linux/gpio/consumer.h> |
| 316 | 325 | ... |
| @@ -334,21 +343,22 @@ See Documentation/acpi/gpio-properties.txt for more information about the · 17 unmodified lines | ||
| 334 | 343 | _DSD binding related to GPIOs. |
| 335 | 344 | |
| 336 | 345 | MFD devices |
| 337 | −~~~~~~~~~~~ | |
| 346 | +=========== | |
| 347 | + | |
| 338 | 348 | The MFD devices register their children as platform devices. For the child |
| 339 | 349 | devices there needs to be an ACPI handle that they can use to reference |
| 340 | 350 | parts of the ACPI namespace that relate to them. In the Linux MFD subsystem |
| 341 | 351 | we provide two ways: |
| 342 | 352 | |
| 343 | − o The children share the parent ACPI handle. | |
| 344 | − o The MFD cell can specify the ACPI id of the device. | |
| 353 | + - The children share the parent ACPI handle. | |
| 354 | + - The MFD cell can specify the ACPI id of the device. | |
| 345 | 355 | |
| 346 | 356 | For the first case, the MFD drivers do not need to do anything. The |
| 347 | 357 | resulting child platform device will have its ACPI_COMPANION() set to point |
| 348 | 358 | to the parent device. |
| 349 | 359 | |
| 350 | 360 | If the ACPI namespace has a device that we can match using an ACPI id or ACPI |
| 351 | −adr, the cell should be set like: | |
| 361 | +adr, the cell should be set like:: | |
| 352 | 362 | |
| 353 | 363 | static struct mfd_cell_acpi_match my_subdevice_cell_acpi_match = { |
| 354 | 364 | .pnpid = "XYZ0001", |
| @@ -366,7 +376,8 @@ the MFD device and if found, that ACPI companion device is bound to the · 11 unmodified lines | ||
| 366 | 376 | resulting child platform device. |
| 367 | 377 | |
| 368 | 378 | Device Tree namespace link device ID |
| 369 | −~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 379 | +==================================== | |
| 380 | + | |
| 370 | 381 | The Device Tree protocol uses device identification based on the "compatible" |
| 371 | 382 | property whose value is a string or an array of strings recognized as device |
| 372 | 383 | identifiers by drivers and the driver core. The set of all those strings may be |
| @@ -410,6 +421,32 @@ Specifically, the device IDs returned by _HID and preceding PRP0001 in the _CID · 37 unmodified lines | ||
| 410 | 421 | return package will be checked first. Also in that case the bus type the device |
| 411 | 422 | will be enumerated to depends on the device ID returned by _HID. |
| 412 | 423 | |
| 424 | +For example, the following ACPI sample might be used to enumerate an lm75-type | |
| 425 | +I2C temperature sensor and match it to the driver using the Device Tree | |
| 426 | +namespace link: | |
| 427 | + | |
| 428 | + Device (TMP0) | |
| 429 | + { | |
| 430 | + Name (_HID, "PRP0001") | |
| 431 | + Name (_DSD, Package() { | |
| 432 | + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), | |
| 433 | + Package () { | |
| 434 | + Package (2) { "compatible", "ti,tmp75" }, | |
| 435 | + } | |
| 436 | + }) | |
| 437 | + Method (_CRS, 0, Serialized) | |
| 438 | + { | |
| 439 | + Name (SBUF, ResourceTemplate () | |
| 440 | + { | |
| 441 | + I2cSerialBusV2 (0x48, ControllerInitiated, | |
| 442 | + 400000, AddressingMode7Bit, | |
| 443 | + "\\_SB.PCI0.I2C1", 0x00, | |
| 444 | + ResourceConsumer, , Exclusive,) | |
| 445 | + }) | |
| 446 | + Return (SBUF) | |
| 447 | + } | |
| 448 | + } | |
| 449 | + | |
| 413 | 450 | It is valid to define device objects with a _HID returning PRP0001 and without |
| 414 | 451 | the "compatible" property in the _DSD or a _CID as long as one of their |
| 415 | 452 | ancestors provides a _DSD with a valid "compatible" property. Such device |
| @@ -423,4 +460,4 @@ the _DSD of the device object itself or the _DSD of its ancestor in the · 7 unmodified lines | ||
| 423 | 460 | Otherwise, the _DSD itself is regarded as invalid and therefore the "compatible" |
| 424 | 461 | property returned by it is meaningless. |
| 425 | 462 | |
| 426 | −Refer to DSD-properties-rules.txt for more information. | |
| 463 | +Refer to :doc:`DSD-properties-rules` for more information. | |
| @@ -1,5 +1,8 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | + | |
| 3 | +====================================== | |
| 1 | 4 | _DSD Device Properties Related to GPIO |
| 2 | −-------------------------------------- | |
| 5 | +====================================== | |
| 3 | 6 | |
| 4 | 7 | With the release of ACPI 5.1, the _DSD configuration object finally |
| 5 | 8 | allows names to be given to GPIOs (and other things as well) returned |
| @@ -8,7 +11,7 @@ the corresponding GPIO, which is pretty error prone (it depends on · 2 unmodified lines | ||
| 8 | 11 | the _CRS output ordering, for example). |
| 9 | 12 | |
| 10 | 13 | With _DSD we can now query GPIOs using a name instead of an integer |
| 11 | −index, like the ASL example below shows: | |
| 14 | +index, like the ASL example below shows:: | |
| 12 | 15 | |
| 13 | 16 | // Bluetooth device with reset and shutdown GPIOs |
| 14 | 17 | Device (BTH) |
| @@ -34,15 +37,19 @@ index, like the ASL example below shows: · 19 unmodified lines | ||
| 34 | 37 | }) |
| 35 | 38 | } |
| 36 | 39 | |
| 37 | −The format of the supported GPIO property is: | |
| 40 | +The format of the supported GPIO property is:: | |
| 38 | 41 | |
| 39 | 42 | Package () { "name", Package () { ref, index, pin, active_low }} |
| 40 | 43 | |
| 41 | − ref - The device that has _CRS containing GpioIo()/GpioInt() resources, | |
| 42 | − typically this is the device itself (BTH in our case). | |
| 43 | − index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero. | |
| 44 | − pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero. | |
| 45 | − active_low - If 1 the GPIO is marked as active_low. | |
| 44 | +ref | |
| 45 | + The device that has _CRS containing GpioIo()/GpioInt() resources, | |
| 46 | + typically this is the device itself (BTH in our case). | |
| 47 | +index | |
| 48 | + Index of the GpioIo()/GpioInt() resource in _CRS starting from zero. | |
| 49 | +pin | |
| 50 | + Pin in the GpioIo()/GpioInt() resource. Typically this is zero. | |
| 51 | +active_low | |
| 52 | + If 1 the GPIO is marked as active_low. | |
| 46 | 53 | |
| 47 | 54 | Since ACPI GpioIo() resource does not have a field saying whether it is |
| 48 | 55 | active low or high, the "active_low" argument can be used here. Setting |
| @@ -55,7 +62,7 @@ It is possible to leave holes in the array of GPIOs. This is useful in · 6 unmodified lines | ||
| 55 | 62 | cases like with SPI host controllers where some chip selects may be |
| 56 | 63 | implemented as GPIOs and some as native signals. For example a SPI host |
| 57 | 64 | controller can have chip selects 0 and 2 implemented as GPIOs and 1 as |
| 58 | −native: | |
| 65 | +native:: | |
| 59 | 66 | |
| 60 | 67 | Package () { |
| 61 | 68 | "cs-gpios", |
| @@ -67,7 +74,7 @@ native: · 5 unmodified lines | ||
| 67 | 74 | } |
| 68 | 75 | |
| 69 | 76 | Other supported properties |
| 70 | −-------------------------- | |
| 77 | +========================== | |
| 71 | 78 | |
| 72 | 79 | Following Device Tree compatible device properties are also supported by |
| 73 | 80 | _DSD device properties for GPIO controllers: |
| @@ -78,7 +85,7 @@ _DSD device properties for GPIO controllers: · 4 unmodified lines | ||
| 78 | 85 | - input |
| 79 | 86 | - line-name |
| 80 | 87 | |
| 81 | −Example: | |
| 88 | +Example:: | |
| 82 | 89 | |
| 83 | 90 | Name (_DSD, Package () { |
| 84 | 91 | // _DSD Hierarchical Properties Extension UUID |
| @@ -100,7 +107,7 @@ Example: · 15 unmodified lines | ||
| 100 | 107 | |
| 101 | 108 | - gpio-line-names |
| 102 | 109 | |
| 103 | −Example: | |
| 110 | +Example:: | |
| 104 | 111 | |
| 105 | 112 | Package () { |
| 106 | 113 | "gpio-line-names", |
| @@ -114,7 +121,7 @@ See Documentation/devicetree/bindings/gpio/gpio.txt for more information · 7 unmodified lines | ||
| 114 | 121 | about these properties. |
| 115 | 122 | |
| 116 | 123 | ACPI GPIO Mappings Provided by Drivers |
| 117 | −-------------------------------------- | |
| 124 | +====================================== | |
| 118 | 125 | |
| 119 | 126 | There are systems in which the ACPI tables do not contain _DSD but provide _CRS |
| 120 | 127 | with GpioIo()/GpioInt() resources and device drivers still need to work with |
| @@ -139,16 +146,16 @@ line in that resource starting from zero, and the active-low flag for that line, · 18 unmodified lines | ||
| 139 | 146 | respectively, in analogy with the _DSD GPIO property format specified above. |
| 140 | 147 | |
| 141 | 148 | For the example Bluetooth device discussed previously the data structures in |
| 142 | −question would look like this: | |
| 149 | +question would look like this:: | |
| 143 | 150 | |
| 144 | −static const struct acpi_gpio_params reset_gpio = { 1, 1, false }; | |
| 145 | −static const struct acpi_gpio_params shutdown_gpio = { 0, 0, false }; | |
| 151 | + static const struct acpi_gpio_params reset_gpio = { 1, 1, false }; | |
| 152 | + static const struct acpi_gpio_params shutdown_gpio = { 0, 0, false }; | |
| 146 | 153 | |
| 147 | −static const struct acpi_gpio_mapping bluetooth_acpi_gpios[] = { | |
| 148 | − { "reset-gpios", &reset_gpio, 1 }, | |
| 149 | − { "shutdown-gpios", &shutdown_gpio, 1 }, | |
| 150 | − { }, | |
| 151 | −}; | |
| 154 | + static const struct acpi_gpio_mapping bluetooth_acpi_gpios[] = { | |
| 155 | + { "reset-gpios", &reset_gpio, 1 }, | |
| 156 | + { "shutdown-gpios", &shutdown_gpio, 1 }, | |
| 157 | + { }, | |
| 158 | + }; | |
| 152 | 159 | |
| 153 | 160 | Next, the mapping table needs to be passed as the second argument to |
| 154 | 161 | acpi_dev_add_driver_gpios() that will register it with the ACPI device object |
| @@ -158,12 +165,12 @@ calling acpi_dev_remove_driver_gpios() on the ACPI device object where that · 3 unmodified lines | ||
| 158 | 165 | table was previously registered. |
| 159 | 166 | |
| 160 | 167 | Using the _CRS fallback |
| 161 | −----------------------- | |
| 168 | +======================= | |
| 162 | 169 | |
| 163 | 170 | If a device does not have _DSD or the driver does not create ACPI GPIO |
| 164 | 171 | mapping, the Linux GPIO framework refuses to return any GPIOs. This is |
| 165 | 172 | because the driver does not know what it actually gets. For example if we |
| 166 | −have a device like below: | |
| 173 | +have a device like below:: | |
| 167 | 174 | |
| 168 | 175 | Device (BTH) |
| 169 | 176 | { |
| @@ -177,7 +184,7 @@ have a device like below: · 7 unmodified lines | ||
| 177 | 184 | }) |
| 178 | 185 | } |
| 179 | 186 | |
| 180 | −The driver might expect to get the right GPIO when it does: | |
| 187 | +The driver might expect to get the right GPIO when it does:: | |
| 181 | 188 | |
| 182 | 189 | desc = gpiod_get(dev, "reset", GPIOD_OUT_LOW); |
| 183 | 190 | |
| @@ -193,22 +200,25 @@ the ACPI GPIO mapping tables are hardly linked to ACPI ID and certain · 9 unmodified lines | ||
| 193 | 200 | objects, as listed in the above chapter, of the device in question. |
| 194 | 201 | |
| 195 | 202 | Getting GPIO descriptor |
| 196 | −----------------------- | |
| 203 | +======================= | |
| 204 | + | |
| 205 | +There are two main approaches to get GPIO resource from ACPI:: | |
| 197 | 206 | |
| 198 | −There are two main approaches to get GPIO resource from ACPI: | |
| 199 | − desc = gpiod_get(dev, connection_id, flags); | |
| 200 | − desc = gpiod_get_index(dev, connection_id, index, flags); | |
| 207 | + desc = gpiod_get(dev, connection_id, flags); | |
| 208 | + desc = gpiod_get_index(dev, connection_id, index, flags); | |
| 201 | 209 | |
| 202 | 210 | We may consider two different cases here, i.e. when connection ID is |
| 203 | 211 | provided and otherwise. |
| 204 | 212 | |
| 205 | −Case 1: | |
| 206 | − desc = gpiod_get(dev, "non-null-connection-id", flags); | |
| 207 | − desc = gpiod_get_index(dev, "non-null-connection-id", index, flags); | |
| 213 | +Case 1:: | |
| 214 | + | |
| 215 | + desc = gpiod_get(dev, "non-null-connection-id", flags); | |
| 216 | + desc = gpiod_get_index(dev, "non-null-connection-id", index, flags); | |
| 217 | + | |
| 218 | +Case 2:: | |
| 208 | 219 | |
| 209 | −Case 2: | |
| 210 | − desc = gpiod_get(dev, NULL, flags); | |
| 211 | − desc = gpiod_get_index(dev, NULL, index, flags); | |
| 220 | + desc = gpiod_get(dev, NULL, flags); | |
| 221 | + desc = gpiod_get_index(dev, NULL, index, flags); | |
| 212 | 222 | |
| 213 | 223 | Case 1 assumes that corresponding ACPI device description must have |
| 214 | 224 | defined device properties and will prevent to getting any GPIO resources |
| @@ -0,0 +1,61 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | + | |
| 3 | +============== | |
| 4 | +ACPI I2C Muxes | |
| 5 | +============== | |
| 6 | + | |
| 7 | +Describing an I2C device hierarchy that includes I2C muxes requires an ACPI | |
| 8 | +Device () scope per mux channel. | |
| 9 | + | |
| 10 | +Consider this topology:: | |
| 11 | + | |
| 12 | + +------+ +------+ | |
| 13 | + | SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50) | |
| 14 | + | | | 0x70 |--CH01--> i2c client B (0x50) | |
| 15 | + +------+ +------+ | |
| 16 | + | |
| 17 | +which corresponds to the following ASL:: | |
| 18 | + | |
| 19 | + Device (SMB1) | |
| 20 | + { | |
| 21 | + Name (_HID, ...) | |
| 22 | + Device (MUX0) | |
| 23 | + { | |
| 24 | + Name (_HID, ...) | |
| 25 | + Name (_CRS, ResourceTemplate () { | |
| 26 | + I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED, | |
| 27 | + AddressingMode7Bit, "^SMB1", 0x00, | |
| 28 | + ResourceConsumer,,) | |
| 29 | + } | |
| 30 | + | |
| 31 | + Device (CH00) | |
| 32 | + { | |
| 33 | + Name (_ADR, 0) | |
| 34 | + | |
| 35 | + Device (CLIA) | |
| 36 | + { | |
| 37 | + Name (_HID, ...) | |
| 38 | + Name (_CRS, ResourceTemplate () { | |
| 39 | + I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED, | |
| 40 | + AddressingMode7Bit, "^CH00", 0x00, | |
| 41 | + ResourceConsumer,,) | |
| 42 | + } | |
| 43 | + } | |
| 44 | + } | |
| 45 | + | |
| 46 | + Device (CH01) | |
| 47 | + { | |
| 48 | + Name (_ADR, 1) | |
| 49 | + | |
| 50 | + Device (CLIB) | |
| 51 | + { | |
| 52 | + Name (_HID, ...) | |
| 53 | + Name (_CRS, ResourceTemplate () { | |
| 54 | + I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED, | |
| 55 | + AddressingMode7Bit, "^CH01", 0x00, | |
| 56 | + ResourceConsumer,,) | |
| 57 | + } | |
| 58 | + } | |
| 59 | + } | |
| 60 | + } | |
| 61 | + } | |
| @@ -0,0 +1,26 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | + | |
| 3 | +============ | |
| 4 | +ACPI Support | |
| 5 | +============ | |
| 6 | + | |
| 7 | +.. toctree:: | |
| 8 | + :maxdepth: 1 | |
| 9 | + | |
| 10 | + namespace | |
| 11 | + dsd/graph | |
| 12 | + dsd/data-node-references | |
| 13 | + enumeration | |
| 14 | + osi | |
| 15 | + method-customizing | |
| 16 | + method-tracing | |
| 17 | + DSD-properties-rules | |
| 18 | + debug | |
| 19 | + aml-debugger | |
| 20 | + apei/output_format | |
| 21 | + apei/einj | |
| 22 | + gpio-properties | |
| 23 | + i2c-muxes | |
| 24 | + acpi-lid | |
| 25 | + lpit | |
| 26 | + video_extension | |
| @@ -1,3 +1,9 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | + | |
| 3 | +=========================== | |
| 4 | +Low Power Idle Table (LPIT) | |
| 5 | +=========================== | |
| 6 | + | |
| 1 | 7 | To enumerate platform Low Power Idle states, Intel platforms are using |
| 2 | 8 | “Low Power Idle Table” (LPIT). More details about this table can be |
| 3 | 9 | downloaded from: |
| @@ -8,13 +14,15 @@ Residencies for each low power state can be read via FFH · 4 unmodified lines | ||
| 8 | 14 | |
| 9 | 15 | On platforms supporting S0ix sleep states, there can be two types of |
| 10 | 16 | residencies: |
| 11 | −- CPU PKG C10 (Read via FFH interface) | |
| 12 | −- Platform Controller Hub (PCH) SLP_S0 (Read via memory mapped interface) | |
| 17 | + | |
| 18 | + - CPU PKG C10 (Read via FFH interface) | |
| 19 | + - Platform Controller Hub (PCH) SLP_S0 (Read via memory mapped interface) | |
| 13 | 20 | |
| 14 | 21 | The following attributes are added dynamically to the cpuidle |
| 15 | −sysfs attribute group: | |
| 16 | − /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us | |
| 17 | − /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us | |
| 22 | +sysfs attribute group:: | |
| 23 | + | |
| 24 | + /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us | |
| 25 | + /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us | |
| 18 | 26 | |
| 19 | 27 | The "low_power_idle_cpu_residency_us" attribute shows time spent |
| 20 | 28 | by the CPU package in PKG C10 |
| @@ -0,0 +1,89 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | + | |
| 3 | +======================================= | |
| 4 | +Linux ACPI Custom Control Method How To | |
| 5 | +======================================= | |
| 6 | + | |
| 7 | +:Author: Zhang Rui <rui.zhang@intel.com> | |
| 8 | + | |
| 9 | + | |
| 10 | +Linux supports customizing ACPI control methods at runtime. | |
| 11 | + | |
| 12 | +Users can use this to: | |
| 13 | + | |
| 14 | +1. override an existing method which may not work correctly, | |
| 15 | + or just for debugging purposes. | |
| 16 | +2. insert a completely new method in order to create a missing | |
| 17 | + method such as _OFF, _ON, _STA, _INI, etc. | |
| 18 | + | |
| 19 | +For these cases, it is far simpler to dynamically install a single | |
| 20 | +control method rather than override the entire DSDT, because kernel | |
| 21 | +rebuild/reboot is not needed and test result can be got in minutes. | |
| 22 | + | |
| 23 | +.. note:: | |
| 24 | + | |
| 25 | + - Only ACPI METHOD can be overridden, any other object types like | |
| 26 | + "Device", "OperationRegion", are not recognized. Methods | |
| 27 | + declared inside scope operators are also not supported. | |
| 28 | + | |
| 29 | + - The same ACPI control method can be overridden for many times, | |
| 30 | + and it's always the latest one that used by Linux/kernel. | |
| 31 | + | |
| 32 | + - To get the ACPI debug object output (Store (AAAA, Debug)), | |
| 33 | + please run:: | |
| 34 | + | |
| 35 | + echo 1 > /sys/module/acpi/parameters/aml_debug_output | |
| 36 | + | |
| 37 | + | |
| 38 | +1. override an existing method | |
| 39 | +============================== | |
| 40 | +a) get the ACPI table via ACPI sysfs I/F. e.g. to get the DSDT, | |
| 41 | + just run "cat /sys/firmware/acpi/tables/DSDT > /tmp/dsdt.dat" | |
| 42 | +b) disassemble the table by running "iasl -d dsdt.dat". | |
| 43 | +c) rewrite the ASL code of the method and save it in a new file, | |
| 44 | +d) package the new file (psr.asl) to an ACPI table format. | |
| 45 | + Here is an example of a customized \_SB._AC._PSR method:: | |
| 46 | + | |
| 47 | + DefinitionBlock ("", "SSDT", 1, "", "", 0x20080715) | |
| 48 | + { | |
| 49 | + Method (\_SB_.AC._PSR, 0, NotSerialized) | |
| 50 | + { | |
| 51 | + Store ("In AC _PSR", Debug) | |
| 52 | + Return (ACON) | |
| 53 | + } | |
| 54 | + } | |
| 55 | + | |
| 56 | + Note that the full pathname of the method in ACPI namespace | |
| 57 | + should be used. | |
| 58 | +e) assemble the file to generate the AML code of the method. | |
| 59 | + e.g. "iasl -vw 6084 psr.asl" (psr.aml is generated as a result) | |
| 60 | + If parameter "-vw 6084" is not supported by your iASL compiler, | |
| 61 | + please try a newer version. | |
| 62 | +f) mount debugfs by "mount -t debugfs none /sys/kernel/debug" | |
| 63 | +g) override the old method via the debugfs by running | |
| 64 | + "cat /tmp/psr.aml > /sys/kernel/debug/acpi/custom_method" | |
| 65 | + | |
| 66 | +2. insert a new method | |
| 67 | +====================== | |
| 68 | +This is easier than overriding an existing method. | |
| 69 | +We just need to create the ASL code of the method we want to | |
| 70 | +insert and then follow the step c) ~ g) in section 1. | |
| 71 | + | |
| 72 | +3. undo your changes | |
| 73 | +==================== | |
| 74 | +The "undo" operation is not supported for a new inserted method | |
| 75 | +right now, i.e. we can not remove a method currently. | |
| 76 | +For an overridden method, in order to undo your changes, please | |
| 77 | +save a copy of the method original ASL code in step c) section 1, | |
| 78 | +and redo step c) ~ g) to override the method with the original one. | |
| 79 | + | |
| 80 | + | |
| 81 | +.. note:: We can use a kernel with multiple custom ACPI method running, | |
| 82 | + But each individual write to debugfs can implement a SINGLE | |
| 83 | + method override. i.e. if we want to insert/override multiple | |
| 84 | + ACPI methods, we need to redo step c) ~ g) for multiple times. | |
| 85 | + | |
| 86 | +.. note:: Be aware that root can mis-use this driver to modify arbitrary | |
| 87 | + memory and gain additional rights, if root's privileges got | |
| 88 | + restricted (for example if root is not allowed to load additional | |
| 89 | + modules after boot). | |
| @@ -0,0 +1,238 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | +.. include:: <isonum.txt> | |
| 3 | + | |
| 4 | +===================== | |
| 5 | +ACPICA Trace Facility | |
| 6 | +===================== | |
| 7 | + | |
| 8 | +:Copyright: |copy| 2015, Intel Corporation | |
| 9 | +:Author: Lv Zheng <lv.zheng@intel.com> | |
| 10 | + | |
| 11 | + | |
| 12 | +Abstract | |
| 13 | +======== | |
| 14 | +This document describes the functions and the interfaces of the | |
| 15 | +method tracing facility. | |
| 16 | + | |
| 17 | +Functionalities and usage examples | |
| 18 | +================================== | |
| 19 | + | |
| 20 | +ACPICA provides method tracing capability. And two functions are | |
| 21 | +currently implemented using this capability. | |
| 22 | + | |
| 23 | +Log reducer | |
| 24 | +----------- | |
| 25 | + | |
| 26 | +ACPICA subsystem provides debugging outputs when CONFIG_ACPI_DEBUG is | |
| 27 | +enabled. The debugging messages which are deployed via | |
| 28 | +ACPI_DEBUG_PRINT() macro can be reduced at 2 levels - per-component | |
| 29 | +level (known as debug layer, configured via | |
| 30 | +/sys/module/acpi/parameters/debug_layer) and per-type level (known as | |
| 31 | +debug level, configured via /sys/module/acpi/parameters/debug_level). | |
| 32 | + | |
| 33 | +But when the particular layer/level is applied to the control method | |
| 34 | +evaluations, the quantity of the debugging outputs may still be too | |
| 35 | +large to be put into the kernel log buffer. The idea thus is worked out | |
| 36 | +to only enable the particular debug layer/level (normally more detailed) | |
| 37 | +logs when the control method evaluation is started, and disable the | |
| 38 | +detailed logging when the control method evaluation is stopped. | |
| 39 | + | |
| 40 | +The following command examples illustrate the usage of the "log reducer" | |
| 41 | +functionality: | |
| 42 | + | |
| 43 | +a. Filter out the debug layer/level matched logs when control methods | |
| 44 | + are being evaluated:: | |
| 45 | + | |
| 46 | + # cd /sys/module/acpi/parameters | |
| 47 | + # echo "0xXXXXXXXX" > trace_debug_layer | |
| 48 | + # echo "0xYYYYYYYY" > trace_debug_level | |
| 49 | + # echo "enable" > trace_state | |
| 50 | + | |
| 51 | +b. Filter out the debug layer/level matched logs when the specified | |
| 52 | + control method is being evaluated:: | |
| 53 | + | |
| 54 | + # cd /sys/module/acpi/parameters | |
| 55 | + # echo "0xXXXXXXXX" > trace_debug_layer | |
| 56 | + # echo "0xYYYYYYYY" > trace_debug_level | |
| 57 | + # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name | |
| 58 | + # echo "method" > /sys/module/acpi/parameters/trace_state | |
| 59 | + | |
| 60 | +c. Filter out the debug layer/level matched logs when the specified | |
| 61 | + control method is being evaluated for the first time:: | |
| 62 | + | |
| 63 | + # cd /sys/module/acpi/parameters | |
| 64 | + # echo "0xXXXXXXXX" > trace_debug_layer | |
| 65 | + # echo "0xYYYYYYYY" > trace_debug_level | |
| 66 | + # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name | |
| 67 | + # echo "method-once" > /sys/module/acpi/parameters/trace_state | |
| 68 | + | |
| 69 | +Where: | |
| 70 | + 0xXXXXXXXX/0xYYYYYYYY | |
| 71 | + Refer to Documentation/acpi/debug.txt for possible debug layer/level | |
| 72 | + masking values. | |
| 73 | + \PPPP.AAAA.TTTT.HHHH | |
| 74 | + Full path of a control method that can be found in the ACPI namespace. | |
| 75 | + It needn't be an entry of a control method evaluation. | |
| 76 | + | |
| 77 | +AML tracer | |
| 78 | +---------- | |
| 79 | + | |
| 80 | +There are special log entries added by the method tracing facility at | |
| 81 | +the "trace points" the AML interpreter starts/stops to execute a control | |
| 82 | +method, or an AML opcode. Note that the format of the log entries are | |
| 83 | +subject to change:: | |
| 84 | + | |
| 85 | + [ 0.186427] exdebug-0398 ex_trace_point : Method Begin [0xf58394d8:\_SB.PCI0.LPCB.ECOK] execution. | |
| 86 | + [ 0.186630] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905c88:If] execution. | |
| 87 | + [ 0.186820] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905cc0:LEqual] execution. | |
| 88 | + [ 0.187010] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905a20:-NamePath-] execution. | |
| 89 | + [ 0.187214] exdebug-0398 ex_trace_point : Opcode End [0xf5905a20:-NamePath-] execution. | |
| 90 | + [ 0.187407] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905f60:One] execution. | |
| 91 | + [ 0.187594] exdebug-0398 ex_trace_point : Opcode End [0xf5905f60:One] execution. | |
| 92 | + [ 0.187789] exdebug-0398 ex_trace_point : Opcode End [0xf5905cc0:LEqual] execution. | |
| 93 | + [ 0.187980] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905cc0:Return] execution. | |
| 94 | + [ 0.188146] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905f60:One] execution. | |
| 95 | + [ 0.188334] exdebug-0398 ex_trace_point : Opcode End [0xf5905f60:One] execution. | |
| 96 | + [ 0.188524] exdebug-0398 ex_trace_point : Opcode End [0xf5905cc0:Return] execution. | |
| 97 | + [ 0.188712] exdebug-0398 ex_trace_point : Opcode End [0xf5905c88:If] execution. | |
| 98 | + [ 0.188903] exdebug-0398 ex_trace_point : Method End [0xf58394d8:\_SB.PCI0.LPCB.ECOK] execution. | |
| 99 | + | |
| 100 | +Developers can utilize these special log entries to track the AML | |
| 101 | +interpretion, thus can aid issue debugging and performance tuning. Note | |
| 102 | +that, as the "AML tracer" logs are implemented via ACPI_DEBUG_PRINT() | |
| 103 | +macro, CONFIG_ACPI_DEBUG is also required to be enabled for enabling | |
| 104 | +"AML tracer" logs. | |
| 105 | + | |
| 106 | +The following command examples illustrate the usage of the "AML tracer" | |
| 107 | +functionality: | |
| 108 | + | |
| 109 | +a. Filter out the method start/stop "AML tracer" logs when control | |
| 110 | + methods are being evaluated:: | |
| 111 | + | |
| 112 | + # cd /sys/module/acpi/parameters | |
| 113 | + # echo "0x80" > trace_debug_layer | |
| 114 | + # echo "0x10" > trace_debug_level | |
| 115 | + # echo "enable" > trace_state | |
| 116 | + | |
| 117 | +b. Filter out the method start/stop "AML tracer" when the specified | |
| 118 | + control method is being evaluated:: | |
| 119 | + | |
| 120 | + # cd /sys/module/acpi/parameters | |
| 121 | + # echo "0x80" > trace_debug_layer | |
| 122 | + # echo "0x10" > trace_debug_level | |
| 123 | + # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name | |
| 124 | + # echo "method" > trace_state | |
| 125 | + | |
| 126 | +c. Filter out the method start/stop "AML tracer" logs when the specified | |
| 127 | + control method is being evaluated for the first time:: | |
| 128 | + | |
| 129 | + # cd /sys/module/acpi/parameters | |
| 130 | + # echo "0x80" > trace_debug_layer | |
| 131 | + # echo "0x10" > trace_debug_level | |
| 132 | + # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name | |
| 133 | + # echo "method-once" > trace_state | |
| 134 | + | |
| 135 | +d. Filter out the method/opcode start/stop "AML tracer" when the | |
| 136 | + specified control method is being evaluated:: | |
| 137 | + | |
| 138 | + # cd /sys/module/acpi/parameters | |
| 139 | + # echo "0x80" > trace_debug_layer | |
| 140 | + # echo "0x10" > trace_debug_level | |
| 141 | + # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name | |
| 142 | + # echo "opcode" > trace_state | |
| 143 | + | |
| 144 | +e. Filter out the method/opcode start/stop "AML tracer" when the | |
| 145 | + specified control method is being evaluated for the first time:: | |
| 146 | + | |
| 147 | + # cd /sys/module/acpi/parameters | |
| 148 | + # echo "0x80" > trace_debug_layer | |
| 149 | + # echo "0x10" > trace_debug_level | |
| 150 | + # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name | |
| 151 | + # echo "opcode-opcode" > trace_state | |
| 152 | + | |
| 153 | +Note that all above method tracing facility related module parameters can | |
| 154 | +be used as the boot parameters, for example:: | |
| 155 | + | |
| 156 | + acpi.trace_debug_layer=0x80 acpi.trace_debug_level=0x10 \ | |
| 157 | + acpi.trace_method_name=\_SB.LID0._LID acpi.trace_state=opcode-once | |
| 158 | + | |
| 159 | + | |
| 160 | +Interface descriptions | |
| 161 | +====================== | |
| 162 | + | |
| 163 | +All method tracing functions can be configured via ACPI module | |
| 164 | +parameters that are accessible at /sys/module/acpi/parameters/: | |
| 165 | + | |
| 166 | +trace_method_name | |
| 167 | + The full path of the AML method that the user wants to trace. | |
| 168 | + | |
| 169 | + Note that the full path shouldn't contain the trailing "_"s in its | |
| 170 | + name segments but may contain "\" to form an absolute path. | |
| 171 | + | |
| 172 | +trace_debug_layer | |
| 173 | + The temporary debug_layer used when the tracing feature is enabled. | |
| 174 | + | |
| 175 | + Using ACPI_EXECUTER (0x80) by default, which is the debug_layer | |
| 176 | + used to match all "AML tracer" logs. | |
| 177 | + | |
| 178 | +trace_debug_level | |
| 179 | + The temporary debug_level used when the tracing feature is enabled. | |
| 180 | + | |
| 181 | + Using ACPI_LV_TRACE_POINT (0x10) by default, which is the | |
| 182 | + debug_level used to match all "AML tracer" logs. | |
| 183 | + | |
| 184 | +trace_state | |
| 185 | + The status of the tracing feature. | |
| 186 | + | |
| 187 | + Users can enable/disable this debug tracing feature by executing | |
| 188 | + the following command:: | |
| 189 | + | |
| 190 | + # echo string > /sys/module/acpi/parameters/trace_state | |
| 191 | + | |
| 192 | +Where "string" should be one of the following: | |
| 193 | + | |
| 194 | +"disable" | |
| 195 | + Disable the method tracing feature. | |
| 196 | + | |
| 197 | +"enable" | |
| 198 | + Enable the method tracing feature. | |
| 199 | + | |
| 200 | + ACPICA debugging messages matching "trace_debug_layer/trace_debug_level" | |
| 201 | + during any method execution will be logged. | |
| 202 | + | |
| 203 | +"method" | |
| 204 | + Enable the method tracing feature. | |
| 205 | + | |
| 206 | + ACPICA debugging messages matching "trace_debug_layer/trace_debug_level" | |
| 207 | + during method execution of "trace_method_name" will be logged. | |
| 208 | + | |
| 209 | +"method-once" | |
| 210 | + Enable the method tracing feature. | |
| 211 | + | |
| 212 | + ACPICA debugging messages matching "trace_debug_layer/trace_debug_level" | |
| 213 | + during method execution of "trace_method_name" will be logged only once. | |
| 214 | + | |
| 215 | +"opcode" | |
| 216 | + Enable the method tracing feature. | |
| 217 | + | |
| 218 | + ACPICA debugging messages matching "trace_debug_layer/trace_debug_level" | |
| 219 | + during method/opcode execution of "trace_method_name" will be logged. | |
| 220 | + | |
| 221 | +"opcode-once" | |
| 222 | + Enable the method tracing feature. | |
| 223 | + | |
| 224 | + ACPICA debugging messages matching "trace_debug_layer/trace_debug_level" | |
| 225 | + during method/opcode execution of "trace_method_name" will be logged only | |
| 226 | + once. | |
| 227 | + | |
| 228 | +Note that, the difference between the "enable" and other feature | |
| 229 | +enabling options are: | |
| 230 | + | |
| 231 | +1. When "enable" is specified, since | |
| 232 | + "trace_debug_layer/trace_debug_level" shall apply to all control | |
| 233 | + method evaluations, after configuring "trace_state" to "enable", | |
| 234 | + "trace_method_name" will be reset to NULL. | |
| 235 | +2. When "method/opcode" is specified, if | |
| 236 | + "trace_method_name" is NULL when "trace_state" is configured to | |
| 237 | + these options, the "trace_debug_layer/trace_debug_level" will | |
| 238 | + apply to all control method evaluations. | |
| @@ -1,85 +1,90 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | +.. include:: <isonum.txt> | |
| 3 | + | |
| 4 | +=================================================== | |
| 1 | 5 | ACPI Device Tree - Representation of ACPI Namespace |
| 6 | +=================================================== | |
| 2 | 7 | |
| 3 | −Copyright (C) 2013, Intel Corporation | |
| 4 | −Author: Lv Zheng <lv.zheng@intel.com> | |
| 8 | +:Copyright: |copy| 2013, Intel Corporation | |
| 5 | 9 | |
| 10 | +:Author: Lv Zheng <lv.zheng@intel.com> | |
| 6 | 11 | |
| 7 | −Abstract: | |
| 12 | +:Credit: Thanks for the help from Zhang Rui <rui.zhang@intel.com> and | |
| 13 | + Rafael J.Wysocki <rafael.j.wysocki@intel.com>. | |
| 8 | 14 | |
| 15 | +Abstract | |
| 16 | +======== | |
| 9 | 17 | The Linux ACPI subsystem converts ACPI namespace objects into a Linux |
| 10 | 18 | device tree under the /sys/devices/LNXSYSTEM:00 and updates it upon |
| 11 | −receiving ACPI hotplug notification events. For each device object in this | |
| 12 | −hierarchy there is a corresponding symbolic link in the | |
| 19 | +receiving ACPI hotplug notification events. For each device object | |
| 20 | +in this hierarchy there is a corresponding symbolic link in the | |
| 13 | 21 | /sys/bus/acpi/devices. |
| 22 | + | |
| 14 | 23 | This document illustrates the structure of the ACPI device tree. |
| 15 | 24 | |
| 25 | +ACPI Definition Blocks | |
| 26 | +====================== | |
| 27 | + | |
| 28 | +The ACPI firmware sets up RSDP (Root System Description Pointer) in the | |
| 29 | +system memory address space pointing to the XSDT (Extended System | |
| 30 | +Description Table). The XSDT always points to the FADT (Fixed ACPI | |
| 31 | +Description Table) using its first entry, the data within the FADT | |
| 32 | +includes various fixed-length entries that describe fixed ACPI features | |
| 33 | +of the hardware. The FADT contains a pointer to the DSDT | |
| 34 | +(Differentiated System Descripition Table). The XSDT also contains | |
| 35 | +entries pointing to possibly multiple SSDTs (Secondary System | |
| 36 | +Description Table). | |
| 37 | + | |
| 38 | +The DSDT and SSDT data is organized in data structures called definition | |
| 39 | +blocks that contain definitions of various objects, including ACPI | |
| 40 | +control methods, encoded in AML (ACPI Machine Language). The data block | |
| 41 | +of the DSDT along with the contents of SSDTs represents a hierarchical | |
| 42 | +data structure called the ACPI namespace whose topology reflects the | |
| 43 | +structure of the underlying hardware platform. | |
| 44 | + | |
| 45 | +The relationships between ACPI System Definition Tables described above | |
| 46 | +are illustrated in the following diagram:: | |
| 47 | + | |
| 48 | + +---------+ +-------+ +--------+ +------------------------+ | |
| 49 | + | RSDP | +->| XSDT | +->| FADT | | +-------------------+ | | |
| 50 | + +---------+ | +-------+ | +--------+ +-|->| DSDT | | | |
| 51 | + | Pointer | | | Entry |-+ | ...... | | | +-------------------+ | | |
| 52 | + +---------+ | +-------+ | X_DSDT |--+ | | Definition Blocks | | | |
| 53 | + | Pointer |-+ | ..... | | ...... | | +-------------------+ | | |
| 54 | + +---------+ +-------+ +--------+ | +-------------------+ | | |
| 55 | + | Entry |------------------|->| SSDT | | | |
| 56 | + +- - - -+ | +-------------------| | | |
| 57 | + | Entry | - - - - - - - -+ | | Definition Blocks | | | |
| 58 | + +- - - -+ | | +-------------------+ | | |
| 59 | + | | +- - - - - - - - - -+ | | |
| 60 | + +-|->| SSDT | | | |
| 61 | + | +-------------------+ | | |
| 62 | + | | Definition Blocks | | | |
| 63 | + | +- - - - - - - - - -+ | | |
| 64 | + +------------------------+ | |
| 65 | + | | |
| 66 | + OSPM Loading | | |
| 67 | + \|/ | |
| 68 | + +----------------+ | |
| 69 | + | ACPI Namespace | | |
| 70 | + +----------------+ | |
| 71 | + | |
| 72 | + Figure 1. ACPI Definition Blocks | |
| 73 | + | |
| 74 | +.. note:: RSDP can also contain a pointer to the RSDT (Root System | |
| 75 | + Description Table). Platforms provide RSDT to enable | |
| 76 | + compatibility with ACPI 1.0 operating systems. The OS is expected | |
| 77 | + to use XSDT, if present. | |
| 78 | + | |
| 79 | + | |
| 80 | +Example ACPI Namespace | |
| 81 | +====================== | |
| 82 | + | |
| 83 | +All definition blocks are loaded into a single namespace. The namespace | |
| 84 | +is a hierarchy of objects identified by names and paths. | |
| 85 | +The following naming conventions apply to object names in the ACPI | |
| 86 | +namespace: | |
| 16 | 87 | |
| 17 | −Credit: | |
| 18 | − | |
| 19 | −Thanks for the help from Zhang Rui <rui.zhang@intel.com> and Rafael J. | |
| 20 | −Wysocki <rafael.j.wysocki@intel.com>. | |
| 21 | − | |
| 22 | − | |
| 23 | −1. ACPI Definition Blocks | |
| 24 | − | |
| 25 | − The ACPI firmware sets up RSDP (Root System Description Pointer) in the | |
| 26 | − system memory address space pointing to the XSDT (Extended System | |
| 27 | − Description Table). The XSDT always points to the FADT (Fixed ACPI | |
| 28 | − Description Table) using its first entry, the data within the FADT | |
| 29 | − includes various fixed-length entries that describe fixed ACPI features | |
| 30 | − of the hardware. The FADT contains a pointer to the DSDT | |
| 31 | − (Differentiated System Descripition Table). The XSDT also contains | |
| 32 | − entries pointing to possibly multiple SSDTs (Secondary System | |
| 33 | − Description Table). | |
| 34 | − | |
| 35 | − The DSDT and SSDT data is organized in data structures called definition | |
| 36 | − blocks that contain definitions of various objects, including ACPI | |
| 37 | − control methods, encoded in AML (ACPI Machine Language). The data block | |
| 38 | − of the DSDT along with the contents of SSDTs represents a hierarchical | |
| 39 | − data structure called the ACPI namespace whose topology reflects the | |
| 40 | − structure of the underlying hardware platform. | |
| 41 | − | |
| 42 | − The relationships between ACPI System Definition Tables described above | |
| 43 | − are illustrated in the following diagram. | |
| 44 | − | |
| 45 | − +---------+ +-------+ +--------+ +------------------------+ | |
| 46 | − | RSDP | +->| XSDT | +->| FADT | | +-------------------+ | | |
| 47 | − +---------+ | +-------+ | +--------+ +-|->| DSDT | | | |
| 48 | − | Pointer | | | Entry |-+ | ...... | | | +-------------------+ | | |
| 49 | − +---------+ | +-------+ | X_DSDT |--+ | | Definition Blocks | | | |
| 50 | − | Pointer |-+ | ..... | | ...... | | +-------------------+ | | |
| 51 | − +---------+ +-------+ +--------+ | +-------------------+ | | |
| 52 | − | Entry |------------------|->| SSDT | | | |
| 53 | − +- - - -+ | +-------------------| | | |
| 54 | − | Entry | - - - - - - - -+ | | Definition Blocks | | | |
| 55 | − +- - - -+ | | +-------------------+ | | |
| 56 | − | | +- - - - - - - - - -+ | | |
| 57 | − +-|->| SSDT | | | |
| 58 | − | +-------------------+ | | |
| 59 | − | | Definition Blocks | | | |
| 60 | − | +- - - - - - - - - -+ | | |
| 61 | − +------------------------+ | |
| 62 | − | | |
| 63 | − OSPM Loading | | |
| 64 | − \|/ | |
| 65 | − +----------------+ | |
| 66 | − | ACPI Namespace | | |
| 67 | − +----------------+ | |
| 68 | − | |
| 69 | − Figure 1. ACPI Definition Blocks | |
| 70 | − | |
| 71 | − NOTE: RSDP can also contain a pointer to the RSDT (Root System | |
| 72 | − Description Table). Platforms provide RSDT to enable | |
| 73 | − compatibility with ACPI 1.0 operating systems. The OS is expected | |
| 74 | − to use XSDT, if present. | |
| 75 | − | |
| 76 | − | |
| 77 | −2. Example ACPI Namespace | |
| 78 | − | |
| 79 | − All definition blocks are loaded into a single namespace. The namespace | |
| 80 | − is a hierarchy of objects identified by names and paths. | |
| 81 | − The following naming conventions apply to object names in the ACPI | |
| 82 | − namespace: | |
| 83 | 88 | 1. All names are 32 bits long. |
| 84 | 89 | 2. The first byte of a name must be one of 'A' - 'Z', '_'. |
| 85 | 90 | 3. Each of the remaining bytes of a name must be one of 'A' - 'Z', '0' |
| @@ -91,7 +96,7 @@ Wysocki <rafael.j.wysocki@intel.com>. · 5 unmodified lines | ||
| 91 | 96 | (i.e. names prepended with '^' are relative to the parent of the |
| 92 | 97 | current namespace node). |
| 93 | 98 | |
| 94 | − The figure below shows an example ACPI namespace. | |
| 99 | +The figure below shows an example ACPI namespace:: | |
| 95 | 100 | |
| 96 | 101 | +------+ |
| 97 | 102 | | \ | Root |
| @@ -184,19 +189,20 @@ Wysocki <rafael.j.wysocki@intel.com>. · 86 unmodified lines | ||
| 184 | 189 | Figure 2. Example ACPI Namespace |
| 185 | 190 | |
| 186 | 191 | |
| 187 | −3. Linux ACPI Device Objects | |
| 192 | +Linux ACPI Device Objects | |
| 193 | +========================= | |
| 188 | 194 | |
| 189 | − The Linux kernel's core ACPI subsystem creates struct acpi_device | |
| 190 | − objects for ACPI namespace objects representing devices, power resources | |
| 191 | − processors, thermal zones. Those objects are exported to user space via | |
| 192 | − sysfs as directories in the subtree under /sys/devices/LNXSYSTM:00. The | |
| 193 | − format of their names is <bus_id:instance>, where 'bus_id' refers to the | |
| 194 | − ACPI namespace representation of the given object and 'instance' is used | |
| 195 | − for distinguishing different object of the same 'bus_id' (it is | |
| 196 | − two-digit decimal representation of an unsigned integer). | |
| 195 | +The Linux kernel's core ACPI subsystem creates struct acpi_device | |
| 196 | +objects for ACPI namespace objects representing devices, power resources | |
| 197 | +processors, thermal zones. Those objects are exported to user space via | |
| 198 | +sysfs as directories in the subtree under /sys/devices/LNXSYSTM:00. The | |
| 199 | +format of their names is <bus_id:instance>, where 'bus_id' refers to the | |
| 200 | +ACPI namespace representation of the given object and 'instance' is used | |
| 201 | +for distinguishing different object of the same 'bus_id' (it is | |
| 202 | +two-digit decimal representation of an unsigned integer). | |
| 197 | 203 | |
| 198 | − The value of 'bus_id' depends on the type of the object whose name it is | |
| 199 | − part of as listed in the table below. | |
| 204 | +The value of 'bus_id' depends on the type of the object whose name it is | |
| 205 | +part of as listed in the table below:: | |
| 200 | 206 | |
| 201 | 207 | +---+-----------------+-------+----------+ |
| 202 | 208 | | | Object/Feature | Table | bus_id | |
| @@ -226,10 +232,11 @@ Wysocki <rafael.j.wysocki@intel.com>. · 23 unmodified lines | ||
| 226 | 232 | |
| 227 | 233 | Table 1. ACPI Namespace Objects Mapping |
| 228 | 234 | |
| 229 | − The following rules apply when creating struct acpi_device objects on | |
| 230 | − the basis of the contents of ACPI System Description Tables (as | |
| 231 | − indicated by the letter in the first column and the notation in the | |
| 232 | − second column of the table above): | |
| 235 | +The following rules apply when creating struct acpi_device objects on | |
| 236 | +the basis of the contents of ACPI System Description Tables (as | |
| 237 | +indicated by the letter in the first column and the notation in the | |
| 238 | +second column of the table above): | |
| 239 | + | |
| 233 | 240 | N: |
| 234 | 241 | The object's source is an ACPI namespace node (as indicated by the |
| 235 | 242 | named object's type in the second column). In that case the object's |
| @@ -249,13 +256,14 @@ Wysocki <rafael.j.wysocki@intel.com>. · 13 unmodified lines | ||
| 249 | 256 | struct acpi_device object with LNXVIDEO 'bus_id' will be created for |
| 250 | 257 | it. |
| 251 | 258 | |
| 252 | − The third column of the above table indicates which ACPI System | |
| 253 | − Description Tables contain information used for the creation of the | |
| 254 | − struct acpi_device objects represented by the given row (xSDT means DSDT | |
| 255 | − or SSDT). | |
| 259 | +The third column of the above table indicates which ACPI System | |
| 260 | +Description Tables contain information used for the creation of the | |
| 261 | +struct acpi_device objects represented by the given row (xSDT means DSDT | |
| 262 | +or SSDT). | |
| 263 | + | |
| 264 | +The forth column of the above table indicates the 'bus_id' generation | |
| 265 | +rule of the struct acpi_device object: | |
| 256 | 266 | |
| 257 | − The forth column of the above table indicates the 'bus_id' generation | |
| 258 | − rule of the struct acpi_device object: | |
| 259 | 267 | _HID: |
| 260 | 268 | _HID in the last column of the table means that the object's bus_id |
| 261 | 269 | is derived from the _HID/_CID identification objects present under |
| @@ -275,45 +283,47 @@ Wysocki <rafael.j.wysocki@intel.com>. · 13 unmodified lines | ||
| 275 | 283 | object's bus_id. |
| 276 | 284 | |
| 277 | 285 | |
| 278 | −4. Linux ACPI Physical Device Glue | |
| 279 | − | |
| 280 | − ACPI device (i.e. struct acpi_device) objects may be linked to other | |
| 281 | − objects in the Linux' device hierarchy that represent "physical" devices | |
| 282 | − (for example, devices on the PCI bus). If that happens, it means that | |
| 283 | − the ACPI device object is a "companion" of a device otherwise | |
| 284 | − represented in a different way and is used (1) to provide configuration | |
| 285 | − information on that device which cannot be obtained by other means and | |
| 286 | − (2) to do specific things to the device with the help of its ACPI | |
| 287 | − control methods. One ACPI device object may be linked this way to | |
| 288 | − multiple "physical" devices. | |
| 289 | − | |
| 290 | − If an ACPI device object is linked to a "physical" device, its sysfs | |
| 291 | − directory contains the "physical_node" symbolic link to the sysfs | |
| 292 | − directory of the target device object. In turn, the target device's | |
| 293 | − sysfs directory will then contain the "firmware_node" symbolic link to | |
| 294 | − the sysfs directory of the companion ACPI device object. | |
| 295 | − The linking mechanism relies on device identification provided by the | |
| 296 | − ACPI namespace. For example, if there's an ACPI namespace object | |
| 297 | − representing a PCI device (i.e. a device object under an ACPI namespace | |
| 298 | − object representing a PCI bridge) whose _ADR returns 0x00020000 and the | |
| 299 | − bus number of the parent PCI bridge is 0, the sysfs directory | |
| 300 | − representing the struct acpi_device object created for that ACPI | |
| 301 | − namespace object will contain the 'physical_node' symbolic link to the | |
| 302 | − /sys/devices/pci0000:00/0000:00:02:0/ sysfs directory of the | |
| 303 | − corresponding PCI device. | |
| 304 | − | |
| 305 | − The linking mechanism is generally bus-specific. The core of its | |
| 306 | − implementation is located in the drivers/acpi/glue.c file, but there are | |
| 307 | − complementary parts depending on the bus types in question located | |
| 308 | − elsewhere. For example, the PCI-specific part of it is located in | |
| 309 | − drivers/pci/pci-acpi.c. | |
| 310 | − | |
| 311 | − | |
| 312 | −5. Example Linux ACPI Device Tree | |
| 313 | − | |
| 314 | − The sysfs hierarchy of struct acpi_device objects corresponding to the | |
| 315 | − example ACPI namespace illustrated in Figure 2 with the addition of | |
| 316 | − fixed PWR_BUTTON/SLP_BUTTON devices is shown below. | |
| 286 | +Linux ACPI Physical Device Glue | |
| 287 | +=============================== | |
| 288 | + | |
| 289 | +ACPI device (i.e. struct acpi_device) objects may be linked to other | |
| 290 | +objects in the Linux' device hierarchy that represent "physical" devices | |
| 291 | +(for example, devices on the PCI bus). If that happens, it means that | |
| 292 | +the ACPI device object is a "companion" of a device otherwise | |
| 293 | +represented in a different way and is used (1) to provide configuration | |
| 294 | +information on that device which cannot be obtained by other means and | |
| 295 | +(2) to do specific things to the device with the help of its ACPI | |
| 296 | +control methods. One ACPI device object may be linked this way to | |
| 297 | +multiple "physical" devices. | |
| 298 | + | |
| 299 | +If an ACPI device object is linked to a "physical" device, its sysfs | |
| 300 | +directory contains the "physical_node" symbolic link to the sysfs | |
| 301 | +directory of the target device object. In turn, the target device's | |
| 302 | +sysfs directory will then contain the "firmware_node" symbolic link to | |
| 303 | +the sysfs directory of the companion ACPI device object. | |
| 304 | +The linking mechanism relies on device identification provided by the | |
| 305 | +ACPI namespace. For example, if there's an ACPI namespace object | |
| 306 | +representing a PCI device (i.e. a device object under an ACPI namespace | |
| 307 | +object representing a PCI bridge) whose _ADR returns 0x00020000 and the | |
| 308 | +bus number of the parent PCI bridge is 0, the sysfs directory | |
| 309 | +representing the struct acpi_device object created for that ACPI | |
| 310 | +namespace object will contain the 'physical_node' symbolic link to the | |
| 311 | +/sys/devices/pci0000:00/0000:00:02:0/ sysfs directory of the | |
| 312 | +corresponding PCI device. | |
| 313 | + | |
| 314 | +The linking mechanism is generally bus-specific. The core of its | |
| 315 | +implementation is located in the drivers/acpi/glue.c file, but there are | |
| 316 | +complementary parts depending on the bus types in question located | |
| 317 | +elsewhere. For example, the PCI-specific part of it is located in | |
| 318 | +drivers/pci/pci-acpi.c. | |
| 319 | + | |
| 320 | + | |
| 321 | +Example Linux ACPI Device Tree | |
| 322 | +================================= | |
| 323 | + | |
| 324 | +The sysfs hierarchy of struct acpi_device objects corresponding to the | |
| 325 | +example ACPI namespace illustrated in Figure 2 with the addition of | |
| 326 | +fixed PWR_BUTTON/SLP_BUTTON devices is shown below:: | |
| 317 | 327 | |
| 318 | 328 | +--------------+---+-----------------+ |
| 319 | 329 | | LNXSYSTEM:00 | \ | acpi:LNXSYSTEM: | |
| @@ -377,12 +387,14 @@ Wysocki <rafael.j.wysocki@intel.com>. · 57 unmodified lines | ||
| 377 | 387 | |
| 378 | 388 | Figure 3. Example Linux ACPI Device Tree |
| 379 | 389 | |
| 380 | − NOTE: Each node is represented as "object/path/modalias", where: | |
| 381 | − 1. 'object' is the name of the object's directory in sysfs. | |
| 382 | − 2. 'path' is the ACPI namespace path of the corresponding | |
| 383 | − ACPI namespace object, as returned by the object's 'path' | |
| 384 | − sysfs attribute. | |
| 385 | − 3. 'modalias' is the value of the object's 'modalias' sysfs | |
| 386 | − attribute (as described earlier in this document). | |
| 387 | − NOTE: N/A indicates the device object does not have the 'path' or the | |
| 388 | − 'modalias' attribute. | |
| 390 | +.. note:: Each node is represented as "object/path/modalias", where: | |
| 391 | + | |
| 392 | + 1. 'object' is the name of the object's directory in sysfs. | |
| 393 | + 2. 'path' is the ACPI namespace path of the corresponding | |
| 394 | + ACPI namespace object, as returned by the object's 'path' | |
| 395 | + sysfs attribute. | |
| 396 | + 3. 'modalias' is the value of the object's 'modalias' sysfs | |
| 397 | + attribute (as described earlier in this document). | |
| 398 | + | |
| 399 | +.. note:: N/A indicates the device object does not have the 'path' or the | |
| 400 | + 'modalias' attribute. | |
| @@ -1,5 +1,8 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | + | |
| 3 | +========================== | |
| 1 | 4 | ACPI _OSI and _REV methods |
| 2 | −-------------------------- | |
| 5 | +========================== | |
| 3 | 6 | |
| 4 | 7 | An ACPI BIOS can use the "Operating System Interfaces" method (_OSI) |
| 5 | 8 | to find out what the operating system supports. Eg. If BIOS |
| @@ -14,7 +17,7 @@ This document explains how and why the BIOS and Linux should use these methods. · 8 unmodified lines | ||
| 14 | 17 | It also explains how and why they are widely misused. |
| 15 | 18 | |
| 16 | 19 | How to use _OSI |
| 17 | −--------------- | |
| 20 | +=============== | |
| 18 | 21 | |
| 19 | 22 | Linux runs on two groups of machines -- those that are tested by the OEM |
| 20 | 23 | to be compatible with Linux, and those that were never tested with Linux, |
| @@ -62,7 +65,7 @@ the string when that support is added to the kernel. · 41 unmodified lines | ||
| 62 | 65 | That was easy. Read on, to find out how to do it wrong. |
| 63 | 66 | |
| 64 | 67 | Before _OSI, there was _OS |
| 65 | −-------------------------- | |
| 68 | +========================== | |
| 66 | 69 | |
| 67 | 70 | ACPI 1.0 specified "_OS" as an |
| 68 | 71 | "object that evaluates to a string that identifies the operating system." |
| @@ -96,7 +99,7 @@ That is the *only* viable strategy, as that is what modern Windows does, · 27 unmodified lines | ||
| 96 | 99 | and so doing otherwise could steer the BIOS down an untested path. |
| 97 | 100 | |
| 98 | 101 | _OSI is born, and immediately misused |
| 99 | −-------------------------------------- | |
| 102 | +===================================== | |
| 100 | 103 | |
| 101 | 104 | With _OSI, the *BIOS* provides the string describing an interface, |
| 102 | 105 | and asks the OS: "YES/NO, are you compatible with this interface?" |
| @@ -144,7 +147,7 @@ catastrophic failure resulting from the BIOS taking paths that · 41 unmodified lines | ||
| 144 | 147 | were never validated under *any* OS. |
| 145 | 148 | |
| 146 | 149 | Do not use _REV |
| 147 | −--------------- | |
| 150 | +=============== | |
| 148 | 151 | |
| 149 | 152 | Since _OSI("Linux") went away, some BIOS writers used _REV |
| 150 | 153 | to support Linux and Windows differences in the same BIOS. |
| @@ -164,7 +167,7 @@ from mid-2015 onward. The ACPI specification will also be updated · 13 unmodified lines | ||
| 164 | 167 | to reflect that _REV is deprecated, and always returns 2. |
| 165 | 168 | |
| 166 | 169 | Apple Mac and _OSI("Darwin") |
| 167 | −---------------------------- | |
| 170 | +============================ | |
| 168 | 171 | |
| 169 | 172 | On Apple's Mac platforms, the ACPI BIOS invokes _OSI("Darwin") |
| 170 | 173 | to determine if the machine is running Apple OSX. |
| @@ -1,5 +1,8 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | + | |
| 3 | +===================== | |
| 1 | 4 | ACPI video extensions |
| 2 | −~~~~~~~~~~~~~~~~~~~~~ | |
| 5 | +===================== | |
| 3 | 6 | |
| 4 | 7 | This driver implement the ACPI Extensions For Display Adapters for |
| 5 | 8 | integrated graphics devices on motherboard, as specified in ACPI 2.0 |
| @@ -8,9 +11,10 @@ defining the video POST device, retrieving EDID information or to · 2 unmodified lines | ||
| 8 | 11 | setup a video output, etc. Note that this is an ref. implementation |
| 9 | 12 | only. It may or may not work for your integrated video device. |
| 10 | 13 | |
| 11 | −The ACPI video driver does 3 things regarding backlight control: | |
| 14 | +The ACPI video driver does 3 things regarding backlight control. | |
| 12 | 15 | |
| 13 | −1 Export a sysfs interface for user space to control backlight level | |
| 16 | +Export a sysfs interface for user space to control backlight level | |
| 17 | +================================================================== | |
| 14 | 18 | |
| 15 | 19 | If the ACPI table has a video device, and acpi_backlight=vendor kernel |
| 16 | 20 | command line is not present, the driver will register a backlight device |
| @@ -22,36 +26,41 @@ The backlight sysfs interface has a standard definition here: · 5 unmodified lines | ||
| 22 | 26 | Documentation/ABI/stable/sysfs-class-backlight. |
| 23 | 27 | |
| 24 | 28 | And what ACPI video driver does is: |
| 25 | −actual_brightness: on read, control method _BQC will be evaluated to | |
| 26 | −get the brightness level the firmware thinks it is at; | |
| 27 | −bl_power: not implemented, will set the current brightness instead; | |
| 28 | −brightness: on write, control method _BCM will run to set the requested | |
| 29 | −brightness level; | |
| 30 | −max_brightness: Derived from the _BCL package(see below); | |
| 31 | −type: firmware | |
| 29 | + | |
| 30 | +actual_brightness: | |
| 31 | + on read, control method _BQC will be evaluated to | |
| 32 | + get the brightness level the firmware thinks it is at; | |
| 33 | +bl_power: | |
| 34 | + not implemented, will set the current brightness instead; | |
| 35 | +brightness: | |
| 36 | + on write, control method _BCM will run to set the requested brightness level; | |
| 37 | +max_brightness: | |
| 38 | + Derived from the _BCL package(see below); | |
| 39 | +type: | |
| 40 | + firmware | |
| 32 | 41 | |
| 33 | 42 | Note that ACPI video backlight driver will always use index for |
| 34 | 43 | brightness, actual_brightness and max_brightness. So if we have |
| 35 | −the following _BCL package: | |
| 44 | +the following _BCL package:: | |
| 36 | 45 | |
| 37 | −Method (_BCL, 0, NotSerialized) | |
| 38 | −{ | |
| 39 | − Return (Package (0x0C) | |
| 46 | + Method (_BCL, 0, NotSerialized) | |
| 40 | 47 | { |
| 41 | − 0x64, | |
| 42 | − 0x32, | |
| 43 | − 0x0A, | |
| 44 | − 0x14, | |
| 45 | − 0x1E, | |
| 46 | − 0x28, | |
| 47 | − 0x32, | |
| 48 | − 0x3C, | |
| 49 | − 0x46, | |
| 50 | − 0x50, | |
| 51 | − 0x5A, | |
| 52 | − 0x64 | |
| 53 | − }) | |
| 54 | −} | |
| 48 | + Return (Package (0x0C) | |
| 49 | + { | |
| 50 | + 0x64, | |
| 51 | + 0x32, | |
| 52 | + 0x0A, | |
| 53 | + 0x14, | |
| 54 | + 0x1E, | |
| 55 | + 0x28, | |
| 56 | + 0x32, | |
| 57 | + 0x3C, | |
| 58 | + 0x46, | |
| 59 | + 0x50, | |
| 60 | + 0x5A, | |
| 61 | + 0x64 | |
| 62 | + }) | |
| 63 | + } | |
| 55 | 64 | |
| 56 | 65 | The first two levels are for when laptop are on AC or on battery and are |
| 57 | 66 | not used by Linux currently. The remaining 10 levels are supported levels |
| @@ -62,13 +71,15 @@ as a "brightness level" indicator. Thus from the user space perspective · 4 unmodified lines | ||
| 62 | 71 | the range of available brightness levels is from 0 to 9 (max_brightness) |
| 63 | 72 | inclusive. |
| 64 | 73 | |
| 65 | −2 Notify user space about hotkey event | |
| 74 | +Notify user space about hotkey event | |
| 75 | +==================================== | |
| 66 | 76 | |
| 67 | 77 | There are generally two cases for hotkey event reporting: |
| 78 | + | |
| 68 | 79 | i) For some laptops, when user presses the hotkey, a scancode will be |
| 69 | 80 | generated and sent to user space through the input device created by |
| 70 | 81 | the keyboard driver as a key type input event, with proper remap, the |
| 71 | − following key code will appear to user space: | |
| 82 | + following key code will appear to user space:: | |
| 72 | 83 | |
| 73 | 84 | EV_KEY, KEY_BRIGHTNESSUP |
| 74 | 85 | EV_KEY, KEY_BRIGHTNESSDOWN |
| @@ -84,23 +95,27 @@ ii) For some laptops, the press of the hotkey will not generate the · 9 unmodified lines | ||
| 84 | 95 | notify value it received and send the event to user space through the |
| 85 | 96 | input device it created: |
| 86 | 97 | |
| 98 | + ===== ================== | |
| 87 | 99 | event keycode |
| 100 | + ===== ================== | |
| 88 | 101 | 0x86 KEY_BRIGHTNESSUP |
| 89 | 102 | 0x87 KEY_BRIGHTNESSDOWN |
| 90 | 103 | etc. |
| 104 | + ===== ================== | |
| 91 | 105 | |
| 92 | 106 | so this would lead to the same effect as case i) now. |
| 93 | 107 | |
| 94 | 108 | Once user space tool receives this event, it can modify the backlight |
| 95 | 109 | level through the sysfs interface. |
| 96 | 110 | |
| 97 | −3 Change backlight level in the kernel | |
| 111 | +Change backlight level in the kernel | |
| 112 | +==================================== | |
| 98 | 113 | |
| 99 | 114 | This works for machines covered by case ii) in Section 2. Once the driver |
| 100 | 115 | received a notification, it will set the backlight level accordingly. This does |
| 101 | 116 | not affect the sending of event to user space, they are always sent to user |
| 102 | 117 | space regardless of whether or not the video module controls the backlight level |
| 103 | 118 | directly. This behaviour can be controlled through the brightness_switch_enabled |
| 104 | −module parameter as documented in admin-guide/kernel-parameters.rst. It is recommended to | |
| 105 | −disable this behaviour once a GUI environment starts up and wants to have full | |
| 106 | −control of the backlight level. | |
| 119 | +module parameter as documented in admin-guide/kernel-parameters.rst. It is | |
| 120 | +recommended to disable this behaviour once a GUI environment starts up and | |
| 121 | +wants to have full control of the backlight level. | |
| @@ -0,0 +1,13 @@ | ||
| 1 | +.. SPDX-License-Identifier: GPL-2.0 | |
| 2 | + | |
| 3 | +=============================== | |
| 4 | +The Linux kernel firmware guide | |
| 5 | +=============================== | |
| 6 | + | |
| 7 | +This section describes the ACPI subsystem in Linux from firmware perspective. | |
| 8 | + | |
| 9 | +.. toctree:: | |
| 10 | + :maxdepth: 1 | |
| 11 | + | |
| 12 | + acpi/index | |
| 13 | + | |
| @@ -35,6 +35,16 @@ trying to get it to work optimally on a given system. · 34 unmodified lines | ||
| 35 | 35 | |
| 36 | 36 | admin-guide/index |
| 37 | 37 | |
| 38 | +Firmware-related documentation | |
| 39 | +------------------------------ | |
| 40 | +The following holds information on the kernel's expectations regarding the | |
| 41 | +platform firmwares. | |
| 42 | + | |
| 43 | +.. toctree:: | |
| 44 | + :maxdepth: 2 | |
| 45 | + | |
| 46 | + firmware-guide/index | |
| 47 | + | |
| 38 | 48 | Application-developer documentation |
| 39 | 49 | ----------------------------------- |
| 40 | 50 | |
| @@ -6594,7 +6594,7 @@ M: Andy Shevchenko <andriy.shevchenko@linux.intel.com> · 6593 unmodified lines | ||
| 6594 | 6594 | L: linux-gpio@vger.kernel.org |
| 6595 | 6595 | L: linux-acpi@vger.kernel.org |
| 6596 | 6596 | S: Maintained |
| 6597 | −F: Documentation/acpi/gpio-properties.txt | |
| 6597 | +F: Documentation/firmware-guide/acpi/gpio-properties.rst | |
| 6598 | 6598 | F: drivers/gpio/gpiolib-acpi.c |
| 6599 | 6599 | |
| 6600 | 6600 | GPIO IR Transmitter |
| @@ -276,7 +276,7 @@ static unsigned long get_acpi_srat_table(void) · 275 unmodified lines | ||
| 276 | 276 | if (acpi_table) { |
| 277 | 277 | header = (struct acpi_table_header *)acpi_table; |
| 278 | 278 | |
| 279 | − if (ACPI_COMPARE_NAME(header->signature, ACPI_SIG_SRAT)) | |
| 279 | + if (ACPI_COMPARE_NAMESEG(header->signature, ACPI_SIG_SRAT)) | |
| 280 | 280 | return acpi_table; |
| 281 | 281 | } |
| 282 | 282 | entry += size; |
| @@ -109,7 +109,7 @@ static ssize_t acpi_table_signature_show(struct config_item *cfg, char *str) · 108 unmodified lines | ||
| 109 | 109 | if (!h) |
| 110 | 110 | return -EINVAL; |
| 111 | 111 | |
| 112 | − return sprintf(str, "%.*s\n", ACPI_NAME_SIZE, h->signature); | |
| 112 | + return sprintf(str, "%.*s\n", ACPI_NAMESEG_SIZE, h->signature); | |
| 113 | 113 | } |
| 114 | 114 | |
| 115 | 115 | static ssize_t acpi_table_length_show(struct config_item *cfg, char *str) |
| @@ -170,7 +170,7 @@ static ssize_t acpi_table_asl_compiler_id_show(struct config_item *cfg, · 54 unmodified lines | ||
| 170 | 170 | if (!h) |
| 171 | 171 | return -EINVAL; |
| 172 | 172 | |
| 173 | − return sprintf(str, "%.*s\n", ACPI_NAME_SIZE, h->asl_compiler_id); | |
| 173 | + return sprintf(str, "%.*s\n", ACPI_NAMESEG_SIZE, h->asl_compiler_id); | |
| 174 | 174 | } |
| 175 | 175 | |
| 176 | 176 | static ssize_t acpi_table_asl_compiler_revision_show(struct config_item *cfg, |
| @@ -390,7 +390,7 @@ again: · 389 unmodified lines | ||
| 390 | 390 | return size > 0 ? size : ret; |
| 391 | 391 | } |
| 392 | 392 | |
| 393 | −static int acpi_aml_thread(void *unsed) | |
| 393 | +static int acpi_aml_thread(void *unused) | |
| 394 | 394 | { |
| 395 | 395 | acpi_osd_exec_callback function = NULL; |
| 396 | 396 | void *context; |
| @@ -22,7 +22,7 @@ · 21 unmodified lines | ||
| 22 | 22 | * LPAT conversion table |
| 23 | 23 | * |
| 24 | 24 | * @lpat_table: the temperature_raw mapping table structure |
| 25 | − * @raw: the raw value, used as a key to get the temerature from the | |
| 25 | + * @raw: the raw value, used as a key to get the temperature from the | |
| 26 | 26 | * above mapping table |
| 27 | 27 | * |
| 28 | 28 | * A positive converted temperature value will be returned on success, |
| @@ -1142,8 +1142,8 @@ static struct dev_pm_domain acpi_lpss_pm_domain = { · 1141 unmodified lines | ||
| 1142 | 1142 | .thaw_noirq = acpi_subsys_thaw_noirq, |
| 1143 | 1143 | .poweroff = acpi_subsys_suspend, |
| 1144 | 1144 | .poweroff_late = acpi_lpss_suspend_late, |
| 1145 | − .poweroff_noirq = acpi_subsys_suspend_noirq, | |
| 1146 | − .restore_noirq = acpi_subsys_resume_noirq, | |
| 1145 | + .poweroff_noirq = acpi_lpss_suspend_noirq, | |
| 1146 | + .restore_noirq = acpi_lpss_resume_noirq, | |
| 1147 | 1147 | .restore_early = acpi_lpss_resume_early, |
| 1148 | 1148 | #endif |
| 1149 | 1149 | .runtime_suspend = acpi_lpss_runtime_suspend, |
| @@ -293,7 +293,7 @@ acpi_status (*acpi_internal_method) (struct acpi_walk_state * walk_state); · 292 unmodified lines | ||
| 293 | 293 | * expected_return_btypes - Allowed type(s) for the return value |
| 294 | 294 | */ |
| 295 | 295 | struct acpi_name_info { |
| 296 | − char name[ACPI_NAME_SIZE]; | |
| 296 | + char name[ACPI_NAMESEG_SIZE]; | |
| 297 | 297 | u16 argument_list; |
| 298 | 298 | u8 expected_btypes; |
| 299 | 299 | }; |
| @@ -370,7 +370,7 @@ typedef acpi_status (*acpi_object_converter) (struct acpi_namespace_node * · 70 unmodified lines | ||
| 370 | 370 | converted_object); |
| 371 | 371 | |
| 372 | 372 | struct acpi_simple_repair_info { |
| 373 | − char name[ACPI_NAME_SIZE]; | |
| 373 | + char name[ACPI_NAMESEG_SIZE]; | |
| 374 | 374 | u32 unexpected_btypes; |
| 375 | 375 | u32 package_index; |
| 376 | 376 | acpi_object_converter object_converter; |
| @@ -453,7 +453,7 @@ acpi_db_execute(char *name, char **args, acpi_object_type *types, u32 flags) · 452 unmodified lines | ||
| 453 | 453 | |
| 454 | 454 | /* Dump a _PLD buffer if present */ |
| 455 | 455 | |
| 456 | − if (ACPI_COMPARE_NAME | |
| 456 | + if (ACPI_COMPARE_NAMESEG | |
| 457 | 457 | ((ACPI_CAST_PTR |
| 458 | 458 | (struct acpi_namespace_node, |
| 459 | 459 | acpi_gbl_db_method_info.method)->name.ascii), |
| @@ -354,7 +354,7 @@ acpi_status acpi_db_find_name_in_namespace(char *name_arg) · 353 unmodified lines | ||
| 354 | 354 | char acpi_name[5] = "____"; |
| 355 | 355 | char *acpi_name_ptr = acpi_name; |
| 356 | 356 | |
| 357 | − if (strlen(name_arg) > ACPI_NAME_SIZE) { | |
| 357 | + if (strlen(name_arg) > ACPI_NAMESEG_SIZE) { | |
| 358 | 358 | acpi_os_printf("Name must be no longer than 4 characters\n"); |
| 359 | 359 | return (AE_OK); |
| 360 | 360 | } |
| @@ -200,7 +200,7 @@ acpi_ds_initialize_objects(u32 table_index, · 199 unmodified lines | ||
| 200 | 200 | |
| 201 | 201 | /* DSDT is always the first AML table */ |
| 202 | 202 | |
| 203 | − if (ACPI_COMPARE_NAME(table->signature, ACPI_SIG_DSDT)) { | |
| 203 | + if (ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_DSDT)) { | |
| 204 | 204 | ACPI_DEBUG_PRINT_RAW((ACPI_DB_INIT, |
| 205 | 205 | "\nInitializing Namespace objects:\n")); |
| 206 | 206 | } |
| @@ -292,7 +292,7 @@ acpi_ev_match_gpe_method(acpi_handle obj_handle, · 291 unmodified lines | ||
| 292 | 292 | acpi_status status; |
| 293 | 293 | u32 gpe_number; |
| 294 | 294 | u8 temp_gpe_number; |
| 295 | − char name[ACPI_NAME_SIZE + 1]; | |
| 295 | + char name[ACPI_NAMESEG_SIZE + 1]; | |
| 296 | 296 | u8 type; |
| 297 | 297 | |
| 298 | 298 | ACPI_FUNCTION_TRACE(ev_match_gpe_method); |
| @@ -310,7 +310,7 @@ acpi_ev_match_gpe_method(acpi_handle obj_handle, · 11 unmodified lines | ||
| 310 | 310 | * 1) Extract the method name and null terminate it |
| 311 | 311 | */ |
| 312 | 312 | ACPI_MOVE_32_TO_32(name, &method_node->name.integer); |
| 313 | − name[ACPI_NAME_SIZE] = 0; | |
| 313 | + name[ACPI_NAMESEG_SIZE] = 0; | |
| 314 | 314 | |
| 315 | 315 | /* 2) Name must begin with an underscore */ |
| 316 | 316 | |
| @@ -53,10 +53,10 @@ static char *acpi_ex_allocate_name_string(u32 prefix_count, u32 num_name_segs) · 52 unmodified lines | ||
| 53 | 53 | |
| 54 | 54 | /* Special case for root */ |
| 55 | 55 | |
| 56 | − size_needed = 1 + (ACPI_NAME_SIZE * num_name_segs) + 2 + 1; | |
| 56 | + size_needed = 1 + (ACPI_NAMESEG_SIZE * num_name_segs) + 2 + 1; | |
| 57 | 57 | } else { |
| 58 | 58 | size_needed = |
| 59 | − prefix_count + (ACPI_NAME_SIZE * num_name_segs) + 2 + 1; | |
| 59 | + prefix_count + (ACPI_NAMESEG_SIZE * num_name_segs) + 2 + 1; | |
| 60 | 60 | } |
| 61 | 61 | |
| 62 | 62 | /* |
| @@ -141,7 +141,7 @@ static acpi_status acpi_ex_name_segment(u8 ** in_aml_address, char *name_string) · 78 unmodified lines | ||
| 141 | 141 | } |
| 142 | 142 | |
| 143 | 143 | for (index = 0; |
| 144 | − (index < ACPI_NAME_SIZE) | |
| 144 | + (index < ACPI_NAMESEG_SIZE) | |
| 145 | 145 | && (acpi_ut_valid_name_char(*aml_address, 0)); index++) { |
| 146 | 146 | char_buf[index] = *aml_address++; |
| 147 | 147 | } |
| @@ -683,7 +683,7 @@ acpi_ns_lookup(union acpi_generic_state *scope_info, · 682 unmodified lines | ||
| 683 | 683 | |
| 684 | 684 | /* Point to next name segment and make this node current */ |
| 685 | 685 | |
| 686 | − path += ACPI_NAME_SIZE; | |
| 686 | + path += ACPI_NAMESEG_SIZE; | |
| 687 | 687 | current_node = this_node; |
| 688 | 688 | } |
| 689 | 689 | |
| @@ -74,6 +74,10 @@ void acpi_ns_delete_node(struct acpi_namespace_node *node) · 73 unmodified lines | ||
| 74 | 74 | |
| 75 | 75 | ACPI_FUNCTION_NAME(ns_delete_node); |
| 76 | 76 | |
| 77 | + if (!node) { | |
| 78 | + return_VOID; | |
| 79 | + } | |
| 80 | + | |
| 77 | 81 | /* Detach an object if there is one */ |
| 78 | 82 | |
| 79 | 83 | acpi_ns_detach_object(node); |
| @@ -70,7 +70,7 @@ void acpi_ns_print_pathname(u32 num_segments, const char *pathname) · 69 unmodified lines | ||
| 70 | 70 | acpi_os_printf("?"); |
| 71 | 71 | } |
| 72 | 72 | |
| 73 | − pathname += ACPI_NAME_SIZE; | |
| 73 | + pathname += ACPI_NAMESEG_SIZE; | |
| 74 | 74 | num_segments--; |
| 75 | 75 | if (num_segments) { |
| 76 | 76 | acpi_os_printf("."); |
| @@ -478,7 +478,7 @@ acpi_ns_find_ini_methods(acpi_handle obj_handle, · 477 unmodified lines | ||
| 478 | 478 | |
| 479 | 479 | /* We are only looking for methods named _INI */ |
| 480 | 480 | |
| 481 | − if (!ACPI_COMPARE_NAME(node->name.ascii, METHOD_NAME__INI)) { | |
| 481 | + if (!ACPI_COMPARE_NAMESEG(node->name.ascii, METHOD_NAME__INI)) { | |
| 482 | 482 | return (AE_OK); |
| 483 | 483 | } |
| 484 | 484 | |
| @@ -641,7 +641,7 @@ acpi_ns_init_one_device(acpi_handle obj_handle, · 156 unmodified lines | ||
| 641 | 641 | * Note: We know there is an _INI within this subtree, but it may not be |
| 642 | 642 | * under this particular device, it may be lower in the branch. |
| 643 | 643 | */ |
| 644 | − if (!ACPI_COMPARE_NAME(device_node->name.ascii, "_SB_") || | |
| 644 | + if (!ACPI_COMPARE_NAMESEG(device_node->name.ascii, "_SB_") || | |
| 645 | 645 | device_node->parent != acpi_gbl_root_node) { |
| 646 | 646 | ACPI_DEBUG_EXEC(acpi_ut_display_init_pathname |
| 647 | 647 | (ACPI_TYPE_METHOD, device_node, |
| @@ -108,8 +108,8 @@ acpi_ns_handle_to_name(acpi_handle target_handle, struct acpi_buffer *buffer) · 107 unmodified lines | ||
| 108 | 108 | /* Just copy the ACPI name from the Node and zero terminate it */ |
| 109 | 109 | |
| 110 | 110 | node_name = acpi_ut_get_node_name(node); |
| 111 | − ACPI_MOVE_NAME(buffer->pointer, node_name); | |
| 112 | − ((char *)buffer->pointer)[ACPI_NAME_SIZE] = 0; | |
| 111 | + ACPI_COPY_NAMESEG(buffer->pointer, node_name); | |
| 112 | + ((char *)buffer->pointer)[ACPI_NAMESEG_SIZE] = 0; | |
| 113 | 113 | |
| 114 | 114 | ACPI_DEBUG_PRINT((ACPI_DB_EXEC, "%4.4s\n", (char *)buffer->pointer)); |
| 115 | 115 | return_ACPI_STATUS(AE_OK); |
| @@ -198,7 +198,7 @@ acpi_ns_build_normalized_path(struct acpi_namespace_node *node, · 82 unmodified lines | ||
| 198 | 198 | char *full_path, u32 path_size, u8 no_trailing) |
| 199 | 199 | { |
| 200 | 200 | u32 length = 0, i; |
| 201 | − char name[ACPI_NAME_SIZE]; | |
| 201 | + char name[ACPI_NAMESEG_SIZE]; | |
| 202 | 202 | u8 do_no_trailing; |
| 203 | 203 | char c, *left, *right; |
| 204 | 204 | struct acpi_namespace_node *next_node; |
| @@ -446,7 +446,7 @@ static void acpi_ns_normalize_pathname(char *original_path) · 241 unmodified lines | ||
| 446 | 446 | |
| 447 | 447 | /* Do one nameseg at a time */ |
| 448 | 448 | |
| 449 | − for (i = 0; (i < ACPI_NAME_SIZE) && *input_path; i++) { | |
| 449 | + for (i = 0; (i < ACPI_NAMESEG_SIZE) && *input_path; i++) { | |
| 450 | 450 | if ((i == 0) || (*input_path != '_')) { /* First char is allowed to be underscore */ |
| 451 | 451 | *new_path = *input_path; |
| 452 | 452 | new_path++; |
| @@ -203,7 +203,7 @@ acpi_ns_one_complete_parse(u32 pass_number, · 202 unmodified lines | ||
| 203 | 203 | |
| 204 | 204 | /* Found OSDT table, enable the namespace override feature */ |
| 205 | 205 | |
| 206 | − if (ACPI_COMPARE_NAME(table->signature, ACPI_SIG_OSDT) && | |
| 206 | + if (ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_OSDT) && | |
| 207 | 207 | pass_number == ACPI_IMODE_LOAD_PASS1) { |
| 208 | 208 | walk_state->namespace_override = TRUE; |
| 209 | 209 | } |
| @@ -316,7 +316,7 @@ static const struct acpi_simple_repair_info *acpi_ns_match_simple_repair(struct · 315 unmodified lines | ||
| 316 | 316 | |
| 317 | 317 | this_name = acpi_object_repair_info; |
| 318 | 318 | while (this_name->object_converter) { |
| 319 | − if (ACPI_COMPARE_NAME(node->name.ascii, this_name->name)) { | |
| 319 | + if (ACPI_COMPARE_NAMESEG(node->name.ascii, this_name->name)) { | |
| 320 | 320 | |
| 321 | 321 | /* Check if we can actually repair this name/type combination */ |
| 322 | 322 | |
| @@ -25,7 +25,7 @@ acpi_status (*acpi_repair_function) (struct acpi_evaluate_info * info, · 24 unmodified lines | ||
| 25 | 25 | return_object_ptr); |
| 26 | 26 | |
| 27 | 27 | typedef struct acpi_repair_info { |
| 28 | − char name[ACPI_NAME_SIZE]; | |
| 28 | + char name[ACPI_NAMESEG_SIZE]; | |
| 29 | 29 | acpi_repair_function repair_function; |
| 30 | 30 | |
| 31 | 31 | } acpi_repair_info; |
| @@ -188,7 +188,7 @@ static const struct acpi_repair_info *acpi_ns_match_complex_repair(struct · 156 unmodified lines | ||
| 188 | 188 | |
| 189 | 189 | this_name = acpi_ns_repairable_names; |
| 190 | 190 | while (this_name->repair_function) { |
| 191 | − if (ACPI_COMPARE_NAME(node->name.ascii, this_name->name)) { | |
| 191 | + if (ACPI_COMPARE_NAMESEG(node->name.ascii, this_name->name)) { | |
| 192 | 192 | return (this_name); |
| 193 | 193 | } |
| 194 | 194 | |
| @@ -178,7 +178,7 @@ void acpi_ns_get_internal_name_length(struct acpi_namestring_info *info) · 177 unmodified lines | ||
| 178 | 178 | } |
| 179 | 179 | } |
| 180 | 180 | |
| 181 | − info->length = (ACPI_NAME_SIZE * info->num_segments) + | |
| 181 | + info->length = (ACPI_NAMESEG_SIZE * info->num_segments) + | |
| 182 | 182 | 4 + info->num_carats; |
| 183 | 183 | |
| 184 | 184 | info->next_external_char = next_external_char; |
| @@ -249,7 +249,7 @@ acpi_status acpi_ns_build_internal_name(struct acpi_namestring_info *info) · 64 unmodified lines | ||
| 249 | 249 | /* Build the name (minus path separators) */ |
| 250 | 250 | |
| 251 | 251 | for (; num_segments; num_segments--) { |
| 252 | − for (i = 0; i < ACPI_NAME_SIZE; i++) { | |
| 252 | + for (i = 0; i < ACPI_NAMESEG_SIZE; i++) { | |
| 253 | 253 | if (ACPI_IS_PATH_SEPARATOR(*external_name) || |
| 254 | 254 | (*external_name == 0)) { |
| 255 | 255 | |
| @@ -274,7 +274,7 @@ acpi_status acpi_ns_build_internal_name(struct acpi_namestring_info *info) · 18 unmodified lines | ||
| 274 | 274 | /* Move on the next segment */ |
| 275 | 275 | |
| 276 | 276 | external_name++; |
| 277 | − result += ACPI_NAME_SIZE; | |
| 277 | + result += ACPI_NAMESEG_SIZE; | |
| 278 | 278 | } |
| 279 | 279 | |
| 280 | 280 | /* Terminate the string */ |
| @@ -489,12 +489,12 @@ acpi_ns_externalize_name(u32 internal_name_length, · 208 unmodified lines | ||
| 489 | 489 | |
| 490 | 490 | /* Copy and validate the 4-char name segment */ |
| 491 | 491 | |
| 492 | − ACPI_MOVE_NAME(&(*converted_name)[j], | |
| 493 | − &internal_name[names_index]); | |
| 492 | + ACPI_COPY_NAMESEG(&(*converted_name)[j], | |
| 493 | + &internal_name[names_index]); | |
| 494 | 494 | acpi_ut_repair_name(&(*converted_name)[j]); |
| 495 | 495 | |
| 496 | − j += ACPI_NAME_SIZE; | |
| 497 | − names_index += ACPI_NAME_SIZE; | |
| 496 | + j += ACPI_NAMESEG_SIZE; | |
| 497 | + names_index += ACPI_NAMESEG_SIZE; | |
| 498 | 498 | } |
| 499 | 499 | } |
| 500 | 500 | |
| @@ -495,8 +495,8 @@ acpi_status acpi_install_method(u8 *buffer) · 494 unmodified lines | ||
| 495 | 495 | |
| 496 | 496 | /* Table must be a DSDT or SSDT */ |
| 497 | 497 | |
| 498 | − if (!ACPI_COMPARE_NAME(table->signature, ACPI_SIG_DSDT) && | |
| 499 | − !ACPI_COMPARE_NAME(table->signature, ACPI_SIG_SSDT)) { | |
| 498 | + if (!ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_DSDT) && | |
| 499 | + !ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_SSDT)) { | |
| 500 | 500 | return (AE_BAD_HEADER); |
| 501 | 501 | } |
| 502 | 502 | |
| @@ -150,21 +150,21 @@ char *acpi_ps_get_next_namestring(struct acpi_parse_state *parser_state) · 149 unmodified lines | ||
| 150 | 150 | |
| 151 | 151 | /* Two name segments */ |
| 152 | 152 | |
| 153 | − end += 1 + (2 * ACPI_NAME_SIZE); | |
| 153 | + end += 1 + (2 * ACPI_NAMESEG_SIZE); | |
| 154 | 154 | break; |
| 155 | 155 | |
| 156 | 156 | case AML_MULTI_NAME_PREFIX: |
| 157 | 157 | |
| 158 | 158 | /* Multiple name segments, 4 chars each, count in next byte */ |
| 159 | 159 | |
| 160 | − end += 2 + (*(end + 1) * ACPI_NAME_SIZE); | |
| 160 | + end += 2 + (*(end + 1) * ACPI_NAMESEG_SIZE); | |
| 161 | 161 | break; |
| 162 | 162 | |
| 163 | 163 | default: |
| 164 | 164 | |
| 165 | 165 | /* Single name segment */ |
| 166 | 166 | |
| 167 | − end += ACPI_NAME_SIZE; | |
| 167 | + end += ACPI_NAMESEG_SIZE; | |
| 168 | 168 | break; |
| 169 | 169 | } |
| 170 | 170 | |
| @@ -522,7 +522,7 @@ static union acpi_parse_object *acpi_ps_get_next_field(struct acpi_parse_state · 351 unmodified lines | ||
| 522 | 522 | |
| 523 | 523 | ACPI_MOVE_32_TO_32(&name, parser_state->aml); |
| 524 | 524 | acpi_ps_set_name(field, name); |
| 525 | − parser_state->aml += ACPI_NAME_SIZE; | |
| 525 | + parser_state->aml += ACPI_NAMESEG_SIZE; | |
| 526 | 526 | |
| 527 | 527 | ASL_CV_CAPTURE_COMMENTS_ONLY(parser_state); |
| 528 | 528 | |
| @@ -603,10 +603,10 @@ acpi_walk_resources(acpi_handle device_handle, · 602 unmodified lines | ||
| 603 | 603 | /* Parameter validation */ |
| 604 | 604 | |
| 605 | 605 | if (!device_handle || !user_function || !name || |
| 606 | − (!ACPI_COMPARE_NAME(name, METHOD_NAME__CRS) && | |
| 607 | − !ACPI_COMPARE_NAME(name, METHOD_NAME__PRS) && | |
| 608 | − !ACPI_COMPARE_NAME(name, METHOD_NAME__AEI) && | |
| 609 | − !ACPI_COMPARE_NAME(name, METHOD_NAME__DMA))) { | |
| 606 | + (!ACPI_COMPARE_NAMESEG(name, METHOD_NAME__CRS) && | |
| 607 | + !ACPI_COMPARE_NAMESEG(name, METHOD_NAME__PRS) && | |
| 608 | + !ACPI_COMPARE_NAMESEG(name, METHOD_NAME__AEI) && | |
| 609 | + !ACPI_COMPARE_NAMESEG(name, METHOD_NAME__DMA))) { | |
| 610 | 610 | return_ACPI_STATUS(AE_BAD_PARAMETER); |
| 611 | 611 | } |
| 612 | 612 | |
| @@ -480,7 +480,8 @@ acpi_tb_verify_temp_table(struct acpi_table_desc *table_desc, · 479 unmodified lines | ||
| 480 | 480 | |
| 481 | 481 | /* If a particular signature is expected (DSDT/FACS), it must match */ |
| 482 | 482 | |
| 483 | − if (signature && !ACPI_COMPARE_NAME(&table_desc->signature, signature)) { | |
| 483 | + if (signature && | |
| 484 | + !ACPI_COMPARE_NAMESEG(&table_desc->signature, signature)) { | |
| 484 | 485 | ACPI_BIOS_ERROR((AE_INFO, |
| 485 | 486 | "Invalid signature 0x%X for ACPI table, expected [%s]", |
| 486 | 487 | table_desc->signature.integer, signature)); |
| @@ -56,7 +56,7 @@ acpi_tb_find_table(char *signature, · 55 unmodified lines | ||
| 56 | 56 | /* Normalize the input strings */ |
| 57 | 57 | |
| 58 | 58 | memset(&header, 0, sizeof(struct acpi_table_header)); |
| 59 | − ACPI_MOVE_NAME(header.signature, signature); | |
| 59 | + ACPI_COPY_NAMESEG(header.signature, signature); | |
| 60 | 60 | strncpy(header.oem_id, oem_id, ACPI_OEM_ID_SIZE); |
| 61 | 61 | strncpy(header.oem_table_id, oem_table_id, ACPI_OEM_TABLE_ID_SIZE); |
| 62 | 62 | |
| @@ -65,7 +65,7 @@ acpi_tb_find_table(char *signature, · 2 unmodified lines | ||
| 65 | 65 | (void)acpi_ut_acquire_mutex(ACPI_MTX_TABLES); |
| 66 | 66 | for (i = 0; i < acpi_gbl_root_table_list.current_table_count; ++i) { |
| 67 | 67 | if (memcmp(&(acpi_gbl_root_table_list.tables[i].signature), |
| 68 | − header.signature, ACPI_NAME_SIZE)) { | |
| 68 | + header.signature, ACPI_NAMESEG_SIZE)) { | |
| 69 | 69 | |
| 70 | 70 | /* Not the requested table */ |
| 71 | 71 | |
| @@ -94,14 +94,14 @@ acpi_tb_find_table(char *signature, · 22 unmodified lines | ||
| 94 | 94 | |
| 95 | 95 | if (!memcmp |
| 96 | 96 | (acpi_gbl_root_table_list.tables[i].pointer->signature, |
| 97 | − header.signature, ACPI_NAME_SIZE) && (!oem_id[0] | |
| 98 | − || | |
| 99 | − !memcmp | |
| 100 | − (acpi_gbl_root_table_list. | |
| 101 | − tables[i].pointer-> | |
| 102 | − oem_id, | |
| 103 | − header.oem_id, | |
| 104 | − ACPI_OEM_ID_SIZE)) | |
| 97 | + header.signature, ACPI_NAMESEG_SIZE) && (!oem_id[0] | |
| 98 | + || | |
| 99 | + !memcmp | |
| 100 | + (acpi_gbl_root_table_list. | |
| 101 | + tables[i]. | |
| 102 | + pointer->oem_id, | |
| 103 | + header.oem_id, | |
| 104 | + ACPI_OEM_ID_SIZE)) | |
| 105 | 105 | && (!oem_table_id[0] |
| 106 | 106 | || !memcmp(acpi_gbl_root_table_list.tables[i].pointer-> |
| 107 | 107 | oem_table_id, header.oem_table_id, |
| @@ -120,7 +120,7 @@ acpi_tb_install_standard_table(acpi_physical_address address, · 119 unmodified lines | ||
| 120 | 120 | */ |
| 121 | 121 | if (!reload && |
| 122 | 122 | acpi_gbl_disable_ssdt_table_install && |
| 123 | − ACPI_COMPARE_NAME(&new_table_desc.signature, ACPI_SIG_SSDT)) { | |
| 123 | + ACPI_COMPARE_NAMESEG(&new_table_desc.signature, ACPI_SIG_SSDT)) { | |
| 124 | 124 | ACPI_INFO(("Ignoring installation of %4.4s at %8.8X%8.8X", |
| 125 | 125 | new_table_desc.signature.ascii, |
| 126 | 126 | ACPI_FORMAT_UINT64(address))); |
| @@ -69,10 +69,10 @@ acpi_tb_cleanup_table_header(struct acpi_table_header *out_header, · 68 unmodified lines | ||
| 69 | 69 | |
| 70 | 70 | memcpy(out_header, header, sizeof(struct acpi_table_header)); |
| 71 | 71 | |
| 72 | − acpi_tb_fix_string(out_header->signature, ACPI_NAME_SIZE); | |
| 72 | + acpi_tb_fix_string(out_header->signature, ACPI_NAMESEG_SIZE); | |
| 73 | 73 | acpi_tb_fix_string(out_header->oem_id, ACPI_OEM_ID_SIZE); |
| 74 | 74 | acpi_tb_fix_string(out_header->oem_table_id, ACPI_OEM_TABLE_ID_SIZE); |
| 75 | − acpi_tb_fix_string(out_header->asl_compiler_id, ACPI_NAME_SIZE); | |
| 75 | + acpi_tb_fix_string(out_header->asl_compiler_id, ACPI_NAMESEG_SIZE); | |
| 76 | 76 | } |
| 77 | 77 | |
| 78 | 78 | /******************************************************************************* |
| @@ -94,7 +94,7 @@ acpi_tb_print_table_header(acpi_physical_address address, · 15 unmodified lines | ||
| 94 | 94 | { |
| 95 | 95 | struct acpi_table_header local_header; |
| 96 | 96 | |
| 97 | − if (ACPI_COMPARE_NAME(header->signature, ACPI_SIG_FACS)) { | |
| 97 | + if (ACPI_COMPARE_NAMESEG(header->signature, ACPI_SIG_FACS)) { | |
| 98 | 98 | |
| 99 | 99 | /* FACS only has signature and length fields */ |
| 100 | 100 | |
| @@ -158,8 +158,8 @@ acpi_status acpi_tb_verify_checksum(struct acpi_table_header *table, u32 length) · 57 unmodified lines | ||
| 158 | 158 | * They are the odd tables, have no standard ACPI header and no checksum |
| 159 | 159 | */ |
| 160 | 160 | |
| 161 | − if (ACPI_COMPARE_NAME(table->signature, ACPI_SIG_S3PT) || | |
| 162 | − ACPI_COMPARE_NAME(table->signature, ACPI_SIG_FACS)) { | |
| 161 | + if (ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_S3PT) || | |
| 162 | + ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_FACS)) { | |
| 163 | 163 | return (AE_OK); |
| 164 | 164 | } |
| 165 | 165 | |
| @@ -332,9 +332,9 @@ acpi_tb_parse_root_table(acpi_physical_address rsdp_address) · 331 unmodified lines | ||
| 332 | 332 | &table_index); |
| 333 | 333 | |
| 334 | 334 | if (ACPI_SUCCESS(status) && |
| 335 | − ACPI_COMPARE_NAME(&acpi_gbl_root_table_list. | |
| 336 | − tables[table_index].signature, | |
| 337 | − ACPI_SIG_FADT)) { | |
| 335 | + ACPI_COMPARE_NAMESEG(&acpi_gbl_root_table_list. | |
| 336 | + tables[table_index].signature, | |
| 337 | + ACPI_SIG_FADT)) { | |
| 338 | 338 | acpi_gbl_fadt_index = table_index; |
| 339 | 339 | acpi_tb_parse_fadt(); |
| 340 | 340 | } |
| @@ -230,7 +230,7 @@ acpi_get_table_header(char *signature, · 229 unmodified lines | ||
| 230 | 230 | |
| 231 | 231 | for (i = 0, j = 0; i < acpi_gbl_root_table_list.current_table_count; |
| 232 | 232 | i++) { |
| 233 | − if (!ACPI_COMPARE_NAME | |
| 233 | + if (!ACPI_COMPARE_NAMESEG | |
| 234 | 234 | (&(acpi_gbl_root_table_list.tables[i].signature), |
| 235 | 235 | signature)) { |
| 236 | 236 | continue; |
| @@ -323,7 +323,7 @@ acpi_get_table(char *signature, · 86 unmodified lines | ||
| 323 | 323 | i++) { |
| 324 | 324 | table_desc = &acpi_gbl_root_table_list.tables[i]; |
| 325 | 325 | |
| 326 | − if (!ACPI_COMPARE_NAME(&table_desc->signature, signature)) { | |
| 326 | + if (!ACPI_COMPARE_NAMESEG(&table_desc->signature, signature)) { | |
| 327 | 327 | continue; |
| 328 | 328 | } |
| 329 | 329 | |
| @@ -118,7 +118,7 @@ acpi_status acpi_tb_load_namespace(void) · 117 unmodified lines | ||
| 118 | 118 | table = &acpi_gbl_root_table_list.tables[acpi_gbl_dsdt_index]; |
| 119 | 119 | |
| 120 | 120 | if (!acpi_gbl_root_table_list.current_table_count || |
| 121 | − !ACPI_COMPARE_NAME(table->signature.ascii, ACPI_SIG_DSDT) || | |
| 121 | + !ACPI_COMPARE_NAMESEG(table->signature.ascii, ACPI_SIG_DSDT) || | |
| 122 | 122 | ACPI_FAILURE(acpi_tb_validate_table(table))) { |
| 123 | 123 | status = AE_NO_ACPI_TABLES; |
| 124 | 124 | goto unlock_and_exit; |
| @@ -170,11 +170,12 @@ acpi_status acpi_tb_load_namespace(void) · 45 unmodified lines | ||
| 170 | 170 | table = &acpi_gbl_root_table_list.tables[i]; |
| 171 | 171 | |
| 172 | 172 | if (!table->address || |
| 173 | − (!ACPI_COMPARE_NAME(table->signature.ascii, ACPI_SIG_SSDT) | |
| 174 | − && !ACPI_COMPARE_NAME(table->signature.ascii, | |
| 175 | − ACPI_SIG_PSDT) | |
| 176 | − && !ACPI_COMPARE_NAME(table->signature.ascii, | |
| 177 | − ACPI_SIG_OSDT)) | |
| 173 | + (!ACPI_COMPARE_NAMESEG | |
| 174 | + (table->signature.ascii, ACPI_SIG_SSDT) | |
| 175 | + && !ACPI_COMPARE_NAMESEG(table->signature.ascii, | |
| 176 | + ACPI_SIG_PSDT) | |
| 177 | + && !ACPI_COMPARE_NAMESEG(table->signature.ascii, | |
| 178 | + ACPI_SIG_OSDT)) | |
| 178 | 179 | || ACPI_FAILURE(acpi_tb_validate_table(table))) { |
| 179 | 180 | continue; |
| 180 | 181 | } |
| @@ -364,7 +365,7 @@ acpi_status acpi_unload_parent_table(acpi_handle object) · 183 unmodified lines | ||
| 364 | 365 | * only these types can contain AML and thus are the only types |
| 365 | 366 | * that can create namespace objects. |
| 366 | 367 | */ |
| 367 | − if (ACPI_COMPARE_NAME | |
| 368 | + if (ACPI_COMPARE_NAMESEG | |
| 368 | 369 | (acpi_gbl_root_table_list.tables[i].signature.ascii, |
| 369 | 370 | ACPI_SIG_DSDT)) { |
| 370 | 371 | status = AE_TYPE; |
| @@ -30,7 +30,7 @@ u8 acpi_ut_valid_nameseg(char *name) · 29 unmodified lines | ||
| 30 | 30 | |
| 31 | 31 | /* Validate each character in the signature */ |
| 32 | 32 | |
| 33 | − for (i = 0; i < ACPI_NAME_SIZE; i++) { | |
| 33 | + for (i = 0; i < ACPI_NAMESEG_SIZE; i++) { | |
| 34 | 34 | if (!acpi_ut_valid_name_char(name[i], i)) { |
| 35 | 35 | return (FALSE); |
| 36 | 36 | } |
| @@ -78,7 +78,7 @@ const char *acpi_gbl_region_types[ACPI_NUM_PREDEFINED_REGIONS] = { · 77 unmodified lines | ||
| 78 | 78 | "IPMI", /* 0x07 */ |
| 79 | 79 | "GeneralPurposeIo", /* 0x08 */ |
| 80 | 80 | "GenericSerialBus", /* 0x09 */ |
| 81 | − "PCC" /* 0x0A */ | |
| 81 | + "PlatformCommChannel" /* 0x0A */ | |
| 82 | 82 | }; |
| 83 | 83 | |
| 84 | 84 | const char *acpi_ut_get_region_name(u8 space_id) |
| @@ -239,7 +239,7 @@ const char *acpi_ut_get_node_name(void *object) · 154 unmodified lines | ||
| 239 | 239 | { |
| 240 | 240 | struct acpi_namespace_node *node = (struct acpi_namespace_node *)object; |
| 241 | 241 | |
| 242 | − /* Must return a string of exactly 4 characters == ACPI_NAME_SIZE */ | |
| 242 | + /* Must return a string of exactly 4 characters == ACPI_NAMESEG_SIZE */ | |
| 243 | 243 | |
| 244 | 244 | if (!object) { |
| 245 | 245 | return ("NULL"); |
| @@ -59,10 +59,10 @@ u8 acpi_ut_is_aml_table(struct acpi_table_header *table) · 58 unmodified lines | ||
| 59 | 59 | |
| 60 | 60 | /* These are the only tables that contain executable AML */ |
| 61 | 61 | |
| 62 | − if (ACPI_COMPARE_NAME(table->signature, ACPI_SIG_DSDT) || | |
| 63 | − ACPI_COMPARE_NAME(table->signature, ACPI_SIG_PSDT) || | |
| 64 | − ACPI_COMPARE_NAME(table->signature, ACPI_SIG_SSDT) || | |
| 65 | − ACPI_COMPARE_NAME(table->signature, ACPI_SIG_OSDT) || | |
| 62 | + if (ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_DSDT) || | |
| 63 | + ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_PSDT) || | |
| 64 | + ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_SSDT) || | |
| 65 | + ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_OSDT) || | |
| 66 | 66 | ACPI_IS_OEM_SIG(table->signature)) { |
| 67 | 67 | return (TRUE); |
| 68 | 68 | } |
| @@ -84,7 +84,7 @@ const union acpi_predefined_info *acpi_ut_match_predefined_method(char *name) · 83 unmodified lines | ||
| 84 | 84 | |
| 85 | 85 | this_name = acpi_gbl_predefined_methods; |
| 86 | 86 | while (this_name->info.name[0]) { |
| 87 | − if (ACPI_COMPARE_NAME(name, this_name->info.name)) { | |
| 87 | + if (ACPI_COMPARE_NAMESEG(name, this_name->info.name)) { | |
| 88 | 88 | return (this_name); |
| 89 | 89 | } |
| 90 | 90 | |
| @@ -201,7 +201,7 @@ const union acpi_predefined_info *acpi_ut_match_resource_name(char *name) · 110 unmodified lines | ||
| 201 | 201 | |
| 202 | 202 | this_name = acpi_gbl_resource_names; |
| 203 | 203 | while (this_name->info.name[0]) { |
| 204 | − if (ACPI_COMPARE_NAME(name, this_name->info.name)) { | |
| 204 | + if (ACPI_COMPARE_NAMESEG(name, this_name->info.name)) { | |
| 205 | 205 | return (this_name); |
| 206 | 206 | } |
| 207 | 207 | |
| @@ -141,15 +141,15 @@ void acpi_ut_repair_name(char *name) · 140 unmodified lines | ||
| 141 | 141 | * Special case for the root node. This can happen if we get an |
| 142 | 142 | * error during the execution of module-level code. |
| 143 | 143 | */ |
| 144 | − if (ACPI_COMPARE_NAME(name, ACPI_ROOT_PATHNAME)) { | |
| 144 | + if (ACPI_COMPARE_NAMESEG(name, ACPI_ROOT_PATHNAME)) { | |
| 145 | 145 | return; |
| 146 | 146 | } |
| 147 | 147 | |
| 148 | − ACPI_MOVE_NAME(&original_name, name); | |
| 148 | + ACPI_COPY_NAMESEG(&original_name, name); | |
| 149 | 149 | |
| 150 | 150 | /* Check each character in the name */ |
| 151 | 151 | |
| 152 | − for (i = 0; i < ACPI_NAME_SIZE; i++) { | |
| 152 | + for (i = 0; i < ACPI_NAMESEG_SIZE; i++) { | |
| 153 | 153 | if (acpi_ut_valid_name_char(name[i], i)) { |
| 154 | 154 | continue; |
| 155 | 155 | } |
| @@ -456,8 +456,11 @@ static int acpi_button_resume(struct device *dev) · 455 unmodified lines | ||
| 456 | 456 | struct acpi_button *button = acpi_driver_data(device); |
| 457 | 457 | |
| 458 | 458 | button->suspended = false; |
| 459 | − if (button->type == ACPI_BUTTON_TYPE_LID && button->input->users) | |
| 459 | + if (button->type == ACPI_BUTTON_TYPE_LID && button->input->users) { | |
| 460 | + button->last_state = !!acpi_lid_evaluate_state(device); | |
| 461 | + button->last_time = ktime_get(); | |
| 460 | 462 | acpi_lid_initialize_state(device); |
| 463 | + } | |
| 461 | 464 | return 0; |
| 462 | 465 | } |
| 463 | 466 | #endif |
| @@ -81,9 +81,9 @@ struct cppc_pcc_data { · 80 unmodified lines | ||
| 81 | 81 | int refcount; |
| 82 | 82 | }; |
| 83 | 83 | |
| 84 | −/* Array to represent the PCC channel per subspace id */ | |
| 84 | +/* Array to represent the PCC channel per subspace ID */ | |
| 85 | 85 | static struct cppc_pcc_data *pcc_data[MAX_PCC_SUBSPACES]; |
| 86 | −/* The cpu_pcc_subspace_idx containsper CPU subspace id */ | |
| 86 | +/* The cpu_pcc_subspace_idx contains per CPU subspace ID */ | |
| 87 | 87 | static DEFINE_PER_CPU(int, cpu_pcc_subspace_idx); |
| 88 | 88 | |
| 89 | 89 | /* |
| @@ -436,7 +436,7 @@ int acpi_get_psd_map(struct cppc_cpudata **all_cpu_data) · 346 unmodified lines | ||
| 436 | 436 | return -ENOMEM; |
| 437 | 437 | |
| 438 | 438 | /* |
| 439 | − * Now that we have _PSD data from all CPUs, lets setup P-state | |
| 439 | + * Now that we have _PSD data from all CPUs, let's setup P-state | |
| 440 | 440 | * domain info. |
| 441 | 441 | */ |
| 442 | 442 | for_each_possible_cpu(i) { |
| @@ -588,7 +588,7 @@ static int register_pcc_channel(int pcc_ss_idx) · 145 unmodified lines | ||
| 588 | 588 | return -ENOMEM; |
| 589 | 589 | } |
| 590 | 590 | |
| 591 | − /* Set flag so that we dont come here for each CPU. */ | |
| 591 | + /* Set flag so that we don't come here for each CPU. */ | |
| 592 | 592 | pcc_data[pcc_ss_idx]->pcc_channel_acquired = true; |
| 593 | 593 | } |
| 594 | 594 | |
| @@ -613,7 +613,7 @@ bool __weak cpc_ffh_supported(void) · 18 unmodified lines | ||
| 613 | 613 | * |
| 614 | 614 | * Check and allocate the cppc_pcc_data memory. |
| 615 | 615 | * In some processor configurations it is possible that same subspace |
| 616 | − * is shared between multiple CPU's. This is seen especially in CPU's | |
| 616 | + * is shared between multiple CPUs. This is seen especially in CPUs | |
| 617 | 617 | * with hardware multi-threading support. |
| 618 | 618 | * |
| 619 | 619 | * Return: 0 for success, errno for failure |
| @@ -711,7 +711,7 @@ static bool is_cppc_supported(int revision, int num_ent) · 91 unmodified lines | ||
| 711 | 711 | |
| 712 | 712 | /** |
| 713 | 713 | * acpi_cppc_processor_probe - Search for per CPU _CPC objects. |
| 714 | − * @pr: Ptr to acpi_processor containing this CPUs logical Id. | |
| 714 | + * @pr: Ptr to acpi_processor containing this CPU's logical ID. | |
| 715 | 715 | * |
| 716 | 716 | * Return: 0 for success or negative value for err. |
| 717 | 717 | */ |
| @@ -728,7 +728,7 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) · 10 unmodified lines | ||
| 728 | 728 | acpi_status status; |
| 729 | 729 | int ret = -EFAULT; |
| 730 | 730 | |
| 731 | − /* Parse the ACPI _CPC table for this cpu. */ | |
| 731 | + /* Parse the ACPI _CPC table for this CPU. */ | |
| 732 | 732 | status = acpi_evaluate_object_typed(handle, "_CPC", NULL, &output, |
| 733 | 733 | ACPI_TYPE_PACKAGE); |
| 734 | 734 | if (ACPI_FAILURE(status)) { |
| @@ -840,7 +840,7 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) · 105 unmodified lines | ||
| 840 | 840 | if (ret) |
| 841 | 841 | goto out_free; |
| 842 | 842 | |
| 843 | − /* Register PCC channel once for all PCC subspace id. */ | |
| 843 | + /* Register PCC channel once for all PCC subspace ID. */ | |
| 844 | 844 | if (pcc_subspace_id >= 0 && !pcc_data[pcc_subspace_id]->pcc_channel_acquired) { |
| 845 | 845 | ret = register_pcc_channel(pcc_subspace_id); |
| 846 | 846 | if (ret) |
| @@ -860,7 +860,7 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) · 13 unmodified lines | ||
| 860 | 860 | goto out_free; |
| 861 | 861 | } |
| 862 | 862 | |
| 863 | − /* Plug PSD data into this CPUs CPC descriptor. */ | |
| 863 | + /* Plug PSD data into this CPU's CPC descriptor. */ | |
| 864 | 864 | per_cpu(cpc_desc_ptr, pr->id) = cpc_ptr; |
| 865 | 865 | |
| 866 | 866 | ret = kobject_init_and_add(&cpc_ptr->kobj, &cppc_ktype, &cpu_dev->kobj, |
| @@ -891,7 +891,7 @@ EXPORT_SYMBOL_GPL(acpi_cppc_processor_probe); · 24 unmodified lines | ||
| 891 | 891 | |
| 892 | 892 | /** |
| 893 | 893 | * acpi_cppc_processor_exit - Cleanup CPC structs. |
| 894 | − * @pr: Ptr to acpi_processor containing this CPUs logical Id. | |
| 894 | + * @pr: Ptr to acpi_processor containing this CPU's logical ID. | |
| 895 | 895 | * |
| 896 | 896 | * Return: Void |
| 897 | 897 | */ |
| @@ -931,7 +931,7 @@ EXPORT_SYMBOL_GPL(acpi_cppc_processor_exit); · 33 unmodified lines | ||
| 931 | 931 | |
| 932 | 932 | /** |
| 933 | 933 | * cpc_read_ffh() - Read FFH register |
| 934 | − * @cpunum: cpu number to read | |
| 934 | + * @cpunum: CPU number to read | |
| 935 | 935 | * @reg: cppc register information |
| 936 | 936 | * @val: place holder for return value |
| 937 | 937 | * |
| @@ -946,7 +946,7 @@ int __weak cpc_read_ffh(int cpunum, struct cpc_reg *reg, u64 *val) · 8 unmodified lines | ||
| 946 | 946 | |
| 947 | 947 | /** |
| 948 | 948 | * cpc_write_ffh() - Write FFH register |
| 949 | − * @cpunum: cpu number to write | |
| 949 | + * @cpunum: CPU number to write | |
| 950 | 950 | * @reg: cppc register information |
| 951 | 951 | * @val: value to write |
| 952 | 952 | * |
| @@ -1093,7 +1093,7 @@ int cppc_get_desired_perf(int cpunum, u64 *desired_perf) · 140 unmodified lines | ||
| 1093 | 1093 | EXPORT_SYMBOL_GPL(cppc_get_desired_perf); |
| 1094 | 1094 | |
| 1095 | 1095 | /** |
| 1096 | − * cppc_get_perf_caps - Get a CPUs performance capabilities. | |
| 1096 | + * cppc_get_perf_caps - Get a CPU's performance capabilities. | |
| 1097 | 1097 | * @cpunum: CPU from which to get capabilities info. |
| 1098 | 1098 | * @perf_caps: ptr to cppc_perf_caps. See cppc_acpi.h |
| 1099 | 1099 | * |
| @@ -1183,7 +1183,7 @@ out_err: · 83 unmodified lines | ||
| 1183 | 1183 | EXPORT_SYMBOL_GPL(cppc_get_perf_caps); |
| 1184 | 1184 | |
| 1185 | 1185 | /** |
| 1186 | − * cppc_get_perf_ctrs - Read a CPUs performance feedback counters. | |
| 1186 | + * cppc_get_perf_ctrs - Read a CPU's performance feedback counters. | |
| 1187 | 1187 | * @cpunum: CPU from which to read counters. |
| 1188 | 1188 | * @perf_fb_ctrs: ptr to cppc_perf_fb_ctrs. See cppc_acpi.h |
| 1189 | 1189 | * |
| @@ -1210,7 +1210,7 @@ int cppc_get_perf_ctrs(int cpunum, struct cppc_perf_fb_ctrs *perf_fb_ctrs) · 20 unmodified lines | ||
| 1210 | 1210 | ctr_wrap_reg = &cpc_desc->cpc_regs[CTR_WRAP_TIME]; |
| 1211 | 1211 | |
| 1212 | 1212 | /* |
| 1213 | − * If refernce perf register is not supported then we should | |
| 1213 | + * If reference perf register is not supported then we should | |
| 1214 | 1214 | * use the nominal perf value |
| 1215 | 1215 | */ |
| 1216 | 1216 | if (!CPC_SUPPORTED(ref_perf_reg)) |
| @@ -1263,7 +1263,7 @@ out_err: · 46 unmodified lines | ||
| 1263 | 1263 | EXPORT_SYMBOL_GPL(cppc_get_perf_ctrs); |
| 1264 | 1264 | |
| 1265 | 1265 | /** |
| 1266 | − * cppc_set_perf - Set a CPUs performance controls. | |
| 1266 | + * cppc_set_perf - Set a CPU's performance controls. | |
| 1267 | 1267 | * @cpu: CPU for which to set performance controls. |
| 1268 | 1268 | * @perf_ctrls: ptr to cppc_perf_ctrls. See cppc_acpi.h |
| 1269 | 1269 | * |
| @@ -1344,7 +1344,7 @@ int cppc_set_perf(int cpu, struct cppc_perf_ctrls *perf_ctrls) · 74 unmodified lines | ||
| 1344 | 1344 | * executing the Phase-II. |
| 1345 | 1345 | * 2. Some other CPU has beaten this CPU to successfully execute the |
| 1346 | 1346 | * write_trylock and has already acquired the write_lock. We know for a |
| 1347 | − * fact it(other CPU acquiring the write_lock) couldn't have happened | |
| 1347 | + * fact it (other CPU acquiring the write_lock) couldn't have happened | |
| 1348 | 1348 | * before this CPU's Phase-I as we held the read_lock. |
| 1349 | 1349 | * 3. Some other CPU executing pcc CMD_READ has stolen the |
| 1350 | 1350 | * down_write, in which case, send_pcc_cmd will check for pending |
| @@ -728,6 +728,9 @@ static int __acpi_device_wakeup_enable(struct acpi_device *adev, · 727 unmodified lines | ||
| 728 | 728 | goto out; |
| 729 | 729 | } |
| 730 | 730 | |
| 731 | + acpi_handle_debug(adev->handle, "GPE%2X enabled for wakeup\n", | |
| 732 | + (unsigned int)wakeup->gpe_number); | |
| 733 | + | |
| 731 | 734 | inc: |
| 732 | 735 | wakeup->enable_count++; |
| 733 | 736 | |
| @@ -31,8 +31,7 @@ static ssize_t name##_show(struct device *dev,\ · 30 unmodified lines | ||
| 31 | 31 | struct device_attribute *attr,\ |
| 32 | 32 | char *buf)\ |
| 33 | 33 | {\ |
| 34 | − struct platform_device *pdev = to_platform_device(dev);\ | |
| 35 | − struct acpi_device *acpi_dev = platform_get_drvdata(pdev);\ | |
| 34 | + struct acpi_device *acpi_dev = dev_get_drvdata(dev);\ | |
| 36 | 35 | unsigned long long val;\ |
| 37 | 36 | acpi_status status;\ |
| 38 | 37 | \ |
| @@ -131,8 +131,8 @@ int acpi_bus_generate_netlink_event(const char *device_class, · 130 unmodified lines | ||
| 131 | 131 | event = nla_data(attr); |
| 132 | 132 | memset(event, 0, sizeof(struct acpi_genl_event)); |
| 133 | 133 | |
| 134 | − strcpy(event->device_class, device_class); | |
| 135 | − strcpy(event->bus_id, bus_id); | |
| 134 | + strscpy(event->device_class, device_class, sizeof(event->device_class)); | |
| 135 | + strscpy(event->bus_id, bus_id, sizeof(event->bus_id)); | |
| 136 | 136 | event->type = type; |
| 137 | 137 | event->data = data; |
| 138 | 138 | |
| @@ -535,12 +535,12 @@ int acpi_device_sleep_wake(struct acpi_device *dev, · 534 unmodified lines | ||
| 535 | 535 | /* |
| 536 | 536 | * Try to execute _DSW first. |
| 537 | 537 | * |
| 538 | − * Three agruments are needed for the _DSW object: | |
| 538 | + * Three arguments are needed for the _DSW object: | |
| 539 | 539 | * Argument 0: enable/disable the wake capabilities |
| 540 | 540 | * Argument 1: target system state |
| 541 | 541 | * Argument 2: target device state |
| 542 | 542 | * When _DSW object is called to disable the wake capabilities, maybe |
| 543 | − * the first argument is filled. The values of the other two agruments | |
| 543 | + * the first argument is filled. The values of the other two arguments | |
| 544 | 544 | * are meaningless. |
| 545 | 545 | */ |
| 546 | 546 | in_arg[0].type = ACPI_TYPE_INTEGER; |
| @@ -164,7 +164,7 @@ static struct acpi_pptt_cache *acpi_find_cache_level(struct acpi_table_header *t · 163 unmodified lines | ||
| 164 | 164 | } |
| 165 | 165 | |
| 166 | 166 | /** |
| 167 | − * acpi_count_levels() - Given a PPTT table, and a cpu node, count the caches | |
| 167 | + * acpi_count_levels() - Given a PPTT table, and a CPU node, count the caches | |
| 168 | 168 | * @table_hdr: Pointer to the head of the PPTT table |
| 169 | 169 | * @cpu_node: processor node we wish to count caches for |
| 170 | 170 | * |
| @@ -235,7 +235,7 @@ static int acpi_pptt_leaf_node(struct acpi_table_header *table_hdr, · 64 unmodified lines | ||
| 235 | 235 | /** |
| 236 | 236 | * acpi_find_processor_node() - Given a PPTT table find the requested processor |
| 237 | 237 | * @table_hdr: Pointer to the head of the PPTT table |
| 238 | − * @acpi_cpu_id: cpu we are searching for | |
| 238 | + * @acpi_cpu_id: CPU we are searching for | |
| 239 | 239 | * |
| 240 | 240 | * Find the subtable entry describing the provided processor. |
| 241 | 241 | * This is done by iterating the PPTT table looking for processor nodes |
| @@ -456,21 +456,21 @@ static struct acpi_pptt_processor *acpi_find_processor_package_id(struct acpi_ta · 214 unmodified lines | ||
| 456 | 456 | |
| 457 | 457 | static void acpi_pptt_warn_missing(void) |
| 458 | 458 | { |
| 459 | − pr_warn_once("No PPTT table found, cpu and cache topology may be inaccurate\n"); | |
| 459 | + pr_warn_once("No PPTT table found, CPU and cache topology may be inaccurate\n"); | |
| 460 | 460 | } |
| 461 | 461 | |
| 462 | 462 | /** |
| 463 | 463 | * topology_get_acpi_cpu_tag() - Find a unique topology value for a feature |
| 464 | 464 | * @table: Pointer to the head of the PPTT table |
| 465 | − * @cpu: Kernel logical cpu number | |
| 465 | + * @cpu: Kernel logical CPU number | |
| 466 | 466 | * @level: A level that terminates the search |
| 467 | 467 | * @flag: A flag which terminates the search |
| 468 | 468 | * |
| 469 | − * Get a unique value given a cpu, and a topology level, that can be | |
| 469 | + * Get a unique value given a CPU, and a topology level, that can be | |
| 470 | 470 | * matched to determine which cpus share common topological features |
| 471 | 471 | * at that level. |
| 472 | 472 | * |
| 473 | − * Return: Unique value, or -ENOENT if unable to locate cpu | |
| 473 | + * Return: Unique value, or -ENOENT if unable to locate CPU | |
| 474 | 474 | */ |
| 475 | 475 | static int topology_get_acpi_cpu_tag(struct acpi_table_header *table, |
| 476 | 476 | unsigned int cpu, int level, int flag) |
| @@ -510,7 +510,7 @@ static int find_acpi_cpu_topology_tag(unsigned int cpu, int level, int flag) · 33 unmodified lines | ||
| 510 | 510 | return -ENOENT; |
| 511 | 511 | } |
| 512 | 512 | retval = topology_get_acpi_cpu_tag(table, cpu, level, flag); |
| 513 | − pr_debug("Topology Setup ACPI cpu %d, level %d ret = %d\n", | |
| 513 | + pr_debug("Topology Setup ACPI CPU %d, level %d ret = %d\n", | |
| 514 | 514 | cpu, level, retval); |
| 515 | 515 | acpi_put_table(table); |
| 516 | 516 | |
| @@ -519,9 +519,9 @@ static int find_acpi_cpu_topology_tag(unsigned int cpu, int level, int flag) · 2 unmodified lines | ||
| 519 | 519 | |
| 520 | 520 | /** |
| 521 | 521 | * acpi_find_last_cache_level() - Determines the number of cache levels for a PE |
| 522 | − * @cpu: Kernel logical cpu number | |
| 522 | + * @cpu: Kernel logical CPU number | |
| 523 | 523 | * |
| 524 | − * Given a logical cpu number, returns the number of levels of cache represented | |
| 524 | + * Given a logical CPU number, returns the number of levels of cache represented | |
| 525 | 525 | * in the PPTT. Errors caused by lack of a PPTT table, or otherwise, return 0 |
| 526 | 526 | * indicating we didn't find any cache levels. |
| 527 | 527 | * |
| @@ -534,7 +534,7 @@ int acpi_find_last_cache_level(unsigned int cpu) · 6 unmodified lines | ||
| 534 | 534 | int number_of_levels = 0; |
| 535 | 535 | acpi_status status; |
| 536 | 536 | |
| 537 | − pr_debug("Cache Setup find last level cpu=%d\n", cpu); | |
| 537 | + pr_debug("Cache Setup find last level CPU=%d\n", cpu); | |
| 538 | 538 | |
| 539 | 539 | acpi_cpu_id = get_acpi_id_for_cpu(cpu); |
| 540 | 540 | status = acpi_get_table(ACPI_SIG_PPTT, 0, &table); |
| @@ -551,14 +551,14 @@ int acpi_find_last_cache_level(unsigned int cpu) · 10 unmodified lines | ||
| 551 | 551 | |
| 552 | 552 | /** |
| 553 | 553 | * cache_setup_acpi() - Override CPU cache topology with data from the PPTT |
| 554 | − * @cpu: Kernel logical cpu number | |
| 554 | + * @cpu: Kernel logical CPU number | |
| 555 | 555 | * |
| 556 | 556 | * Updates the global cache info provided by cpu_get_cacheinfo() |
| 557 | 557 | * when there are valid properties in the acpi_pptt_cache nodes. A |
| 558 | 558 | * successful parse may not result in any updates if none of the |
| 559 | − * cache levels have any valid flags set. Futher, a unique value is | |
| 559 | + * cache levels have any valid flags set. Further, a unique value is | |
| 560 | 560 | * associated with each known CPU cache entry. This unique value |
| 561 | − * can be used to determine whether caches are shared between cpus. | |
| 561 | + * can be used to determine whether caches are shared between CPUs. | |
| 562 | 562 | * |
| 563 | 563 | * Return: -ENOENT on failure to find table, or 0 on success |
| 564 | 564 | */ |
| @@ -567,7 +567,7 @@ int cache_setup_acpi(unsigned int cpu) · 2 unmodified lines | ||
| 567 | 567 | struct acpi_table_header *table; |
| 568 | 568 | acpi_status status; |
| 569 | 569 | |
| 570 | − pr_debug("Cache Setup ACPI cpu %d\n", cpu); | |
| 570 | + pr_debug("Cache Setup ACPI CPU %d\n", cpu); | |
| 571 | 571 | |
| 572 | 572 | status = acpi_get_table(ACPI_SIG_PPTT, 0, &table); |
| 573 | 573 | if (ACPI_FAILURE(status)) { |
| @@ -582,8 +582,8 @@ int cache_setup_acpi(unsigned int cpu) · 8 unmodified lines | ||
| 582 | 582 | } |
| 583 | 583 | |
| 584 | 584 | /** |
| 585 | − * find_acpi_cpu_topology() - Determine a unique topology value for a given cpu | |
| 586 | − * @cpu: Kernel logical cpu number | |
| 585 | + * find_acpi_cpu_topology() - Determine a unique topology value for a given CPU | |
| 586 | + * @cpu: Kernel logical CPU number | |
| 587 | 587 | * @level: The topological level for which we would like a unique ID |
| 588 | 588 | * |
| 589 | 589 | * Determine a topology unique ID for each thread/core/cluster/mc_grouping |
| @@ -596,7 +596,7 @@ int cache_setup_acpi(unsigned int cpu) · 6 unmodified lines | ||
| 596 | 596 | * other levels beyond this use a generated value to uniquely identify |
| 597 | 597 | * a topological feature. |
| 598 | 598 | * |
| 599 | − * Return: -ENOENT if the PPTT doesn't exist, or the cpu cannot be found. | |
| 599 | + * Return: -ENOENT if the PPTT doesn't exist, or the CPU cannot be found. | |
| 600 | 600 | * Otherwise returns a value which represents a unique topological feature. |
| 601 | 601 | */ |
| 602 | 602 | int find_acpi_cpu_topology(unsigned int cpu, int level) |
| @@ -606,12 +606,12 @@ int find_acpi_cpu_topology(unsigned int cpu, int level) · 3 unmodified lines | ||
| 606 | 606 | |
| 607 | 607 | /** |
| 608 | 608 | * find_acpi_cpu_cache_topology() - Determine a unique cache topology value |
| 609 | − * @cpu: Kernel logical cpu number | |
| 609 | + * @cpu: Kernel logical CPU number | |
| 610 | 610 | * @level: The cache level for which we would like a unique ID |
| 611 | 611 | * |
| 612 | 612 | * Determine a unique ID for each unified cache in the system |
| 613 | 613 | * |
| 614 | − * Return: -ENOENT if the PPTT doesn't exist, or the cpu cannot be found. | |
| 614 | + * Return: -ENOENT if the PPTT doesn't exist, or the CPU cannot be found. | |
| 615 | 615 | * Otherwise returns a value which represents a unique topological feature. |
| 616 | 616 | */ |
| 617 | 617 | int find_acpi_cpu_cache_topology(unsigned int cpu, int level) |
| @@ -643,17 +643,17 @@ int find_acpi_cpu_cache_topology(unsigned int cpu, int level) · 25 unmodified lines | ||
| 643 | 643 | |
| 644 | 644 | |
| 645 | 645 | /** |
| 646 | − * find_acpi_cpu_topology_package() - Determine a unique cpu package value | |
| 647 | − * @cpu: Kernel logical cpu number | |
| 646 | + * find_acpi_cpu_topology_package() - Determine a unique CPU package value | |
| 647 | + * @cpu: Kernel logical CPU number | |
| 648 | 648 | * |
| 649 | − * Determine a topology unique package ID for the given cpu. | |
| 649 | + * Determine a topology unique package ID for the given CPU. | |
| 650 | 650 | * This ID can then be used to group peers, which will have matching ids. |
| 651 | 651 | * |
| 652 | 652 | * The search terminates when either a level is found with the PHYSICAL_PACKAGE |
| 653 | 653 | * flag set or we reach a root node. |
| 654 | 654 | * |
| 655 | − * Return: -ENOENT if the PPTT doesn't exist, or the cpu cannot be found. | |
| 656 | − * Otherwise returns a value which represents the package for this cpu. | |
| 655 | + * Return: -ENOENT if the PPTT doesn't exist, or the CPU cannot be found. | |
| 656 | + * Otherwise returns a value which represents the package for this CPU. | |
| 657 | 657 | */ |
| 658 | 658 | int find_acpi_cpu_topology_package(unsigned int cpu) |
| 659 | 659 | { |
| @@ -763,18 +763,16 @@ acpi_bus_get_ejd(acpi_handle handle, acpi_handle *ejd) · 762 unmodified lines | ||
| 763 | 763 | } |
| 764 | 764 | EXPORT_SYMBOL_GPL(acpi_bus_get_ejd); |
| 765 | 765 | |
| 766 | −static int acpi_bus_extract_wakeup_device_power_package(acpi_handle handle, | |
| 767 | − struct acpi_device_wakeup *wakeup) | |
| 766 | +static int acpi_bus_extract_wakeup_device_power_package(struct acpi_device *dev) | |
| 768 | 767 | { |
| 768 | + acpi_handle handle = dev->handle; | |
| 769 | + struct acpi_device_wakeup *wakeup = &dev->wakeup; | |
| 769 | 770 | struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL }; |
| 770 | 771 | union acpi_object *package = NULL; |
| 771 | 772 | union acpi_object *element = NULL; |
| 772 | 773 | acpi_status status; |
| 773 | 774 | int err = -ENODATA; |
| 774 | 775 | |
| 775 | − if (!wakeup) | |
| 776 | − return -EINVAL; | |
| 777 | − | |
| 778 | 776 | INIT_LIST_HEAD(&wakeup->resources); |
| 779 | 777 | |
| 780 | 778 | /* _PRW */ |
| @@ -848,9 +846,9 @@ static int acpi_bus_extract_wakeup_device_power_package(acpi_handle handle, · 67 unmodified lines | ||
| 848 | 846 | static bool acpi_wakeup_gpe_init(struct acpi_device *device) |
| 849 | 847 | { |
| 850 | 848 | static const struct acpi_device_id button_device_ids[] = { |
| 851 | − {"PNP0C0C", 0}, | |
| 852 | − {"PNP0C0D", 0}, | |
| 853 | − {"PNP0C0E", 0}, | |
| 849 | + {"PNP0C0C", 0}, /* Power button */ | |
| 850 | + {"PNP0C0D", 0}, /* Lid */ | |
| 851 | + {"PNP0C0E", 0}, /* Sleep button */ | |
| 854 | 852 | {"", 0}, |
| 855 | 853 | }; |
| 856 | 854 | struct acpi_device_wakeup *wakeup = &device->wakeup; |
| @@ -883,8 +881,7 @@ static void acpi_bus_get_wakeup_device_flags(struct acpi_device *device) · 26 unmodified lines | ||
| 883 | 881 | if (!acpi_has_method(device->handle, "_PRW")) |
| 884 | 882 | return; |
| 885 | 883 | |
| 886 | − err = acpi_bus_extract_wakeup_device_power_package(device->handle, | |
| 887 | − &device->wakeup); | |
| 884 | + err = acpi_bus_extract_wakeup_device_power_package(device); | |
| 888 | 885 | if (err) { |
| 889 | 886 | dev_err(&device->dev, "_PRW evaluation error: %d\n", err); |
| 890 | 887 | return; |
| @@ -895,7 +892,7 @@ static void acpi_bus_get_wakeup_device_flags(struct acpi_device *device) · 4 unmodified lines | ||
| 895 | 892 | /* |
| 896 | 893 | * Call _PSW/_DSW object to disable its ability to wake the sleeping |
| 897 | 894 | * system for the ACPI device with the _PRW object. |
| 898 | − * The _PSW object is depreciated in ACPI 3.0 and is replaced by _DSW. | |
| 895 | + * The _PSW object is deprecated in ACPI 3.0 and is replaced by _DSW. | |
| 899 | 896 | * So it is necessary to call _DSW object first. Only when it is not |
| 900 | 897 | * present will the _PSW object used. |
| 901 | 898 | */ |
| @@ -2260,7 +2257,7 @@ int __init __acpi_probe_device_table(struct acpi_probe_entry *ap_head, int nr) · 1358 unmodified lines | ||
| 2260 | 2257 | |
| 2261 | 2258 | mutex_lock(&acpi_probe_mutex); |
| 2262 | 2259 | for (ape = ap_head; nr; ape++, nr--) { |
| 2263 | − if (ACPI_COMPARE_NAME(ACPI_SIG_MADT, ape->id)) { | |
| 2260 | + if (ACPI_COMPARE_NAMESEG(ACPI_SIG_MADT, ape->id)) { | |
| 2264 | 2261 | acpi_probe_count = 0; |
| 2265 | 2262 | acpi_table_parse_madt(ape->type, acpi_match_madt, 0); |
| 2266 | 2263 | count += acpi_probe_count; |
| @@ -28,7 +28,7 @@ EXPORT_SYMBOL(qdf2400_e44_present); · 27 unmodified lines | ||
| 28 | 28 | |
| 29 | 29 | /* |
| 30 | 30 | * Some Qualcomm Datacenter Technologies SoCs have a defective UART BUSY bit. |
| 31 | − * Detect them by examining the OEM fields in the SPCR header, similiar to PCI | |
| 31 | + * Detect them by examining the OEM fields in the SPCR header, similar to PCI | |
| 32 | 32 | * quirk detection in pci_mcfg.c. |
| 33 | 33 | */ |
| 34 | 34 | static bool qdf2400_erratum_44_present(struct acpi_table_header *h) |
| @@ -327,9 +327,9 @@ static struct kobject *hotplug_kobj; · 326 unmodified lines | ||
| 327 | 327 | |
| 328 | 328 | struct acpi_table_attr { |
| 329 | 329 | struct bin_attribute attr; |
| 330 | − char name[ACPI_NAME_SIZE]; | |
| 330 | + char name[ACPI_NAMESEG_SIZE]; | |
| 331 | 331 | int instance; |
| 332 | − char filename[ACPI_NAME_SIZE+ACPI_INST_SIZE]; | |
| 332 | + char filename[ACPI_NAMESEG_SIZE+ACPI_INST_SIZE]; | |
| 333 | 333 | struct list_head node; |
| 334 | 334 | }; |
| 335 | 335 | |
| @@ -368,10 +368,10 @@ static int acpi_table_attr_init(struct kobject *tables_obj, · 32 unmodified lines | ||
| 368 | 368 | char instance_str[ACPI_INST_SIZE]; |
| 369 | 369 | |
| 370 | 370 | sysfs_attr_init(&table_attr->attr.attr); |
| 371 | − ACPI_MOVE_NAME(table_attr->name, table_header->signature); | |
| 371 | + ACPI_COPY_NAMESEG(table_attr->name, table_header->signature); | |
| 372 | 372 | |
| 373 | 373 | list_for_each_entry(attr, &acpi_table_attr_list, node) { |
| 374 | − if (ACPI_COMPARE_NAME(table_attr->name, attr->name)) | |
| 374 | + if (ACPI_COMPARE_NAMESEG(table_attr->name, attr->name)) | |
| 375 | 375 | if (table_attr->instance < attr->instance) |
| 376 | 376 | table_attr->instance = attr->instance; |
| 377 | 377 | } |
| @@ -382,8 +382,8 @@ static int acpi_table_attr_init(struct kobject *tables_obj, · 4 unmodified lines | ||
| 382 | 382 | return -ERANGE; |
| 383 | 383 | } |
| 384 | 384 | |
| 385 | − ACPI_MOVE_NAME(table_attr->filename, table_header->signature); | |
| 386 | − table_attr->filename[ACPI_NAME_SIZE] = '\0'; | |
| 385 | + ACPI_COPY_NAMESEG(table_attr->filename, table_header->signature); | |
| 386 | + table_attr->filename[ACPI_NAMESEG_SIZE] = '\0'; | |
| 387 | 387 | if (table_attr->instance > 1 || (table_attr->instance == 1 && |
| 388 | 388 | !acpi_get_table |
| 389 | 389 | (table_header->signature, 2, &header))) { |
| @@ -484,7 +484,7 @@ static int acpi_table_data_init(struct acpi_table_header *th) · 94 unmodified lines | ||
| 484 | 484 | int i; |
| 485 | 485 | |
| 486 | 486 | for (i = 0; i < NUM_ACPI_DATA_OBJS; i++) { |
| 487 | − if (ACPI_COMPARE_NAME(th->signature, acpi_data_objs[i].name)) { | |
| 487 | + if (ACPI_COMPARE_NAMESEG(th->signature, acpi_data_objs[i].name)) { | |
| 488 | 488 | data_attr = kzalloc(sizeof(*data_attr), GFP_KERNEL); |
| 489 | 489 | if (!data_attr) |
| 490 | 490 | return -ENOMEM; |
| @@ -240,8 +240,7 @@ void acpi_table_print_madt_entry(struct acpi_subtable_header *header) · 239 unmodified lines | ||
| 240 | 240 | * On success returns sum of all matching entries for all proc handlers. |
| 241 | 241 | * Otherwise, -ENODEV or -EINVAL is returned. |
| 242 | 242 | */ |
| 243 | −static int __init | |
| 244 | −acpi_parse_entries_array(char *id, unsigned long table_size, | |
| 243 | +static int __init acpi_parse_entries_array(char *id, unsigned long table_size, | |
| 245 | 244 | struct acpi_table_header *table_header, |
| 246 | 245 | struct acpi_subtable_proc *proc, int proc_num, |
| 247 | 246 | unsigned int max_entries) |
| @@ -314,8 +313,7 @@ acpi_parse_entries_array(char *id, unsigned long table_size, · 66 unmodified lines | ||
| 314 | 313 | return errs ? -EINVAL : count; |
| 315 | 314 | } |
| 316 | 315 | |
| 317 | −int __init | |
| 318 | −acpi_table_parse_entries_array(char *id, | |
| 316 | +int __init acpi_table_parse_entries_array(char *id, | |
| 319 | 317 | unsigned long table_size, |
| 320 | 318 | struct acpi_subtable_proc *proc, int proc_num, |
| 321 | 319 | unsigned int max_entries) |
| @@ -346,8 +344,7 @@ acpi_table_parse_entries_array(char *id, · 24 unmodified lines | ||
| 346 | 344 | return count; |
| 347 | 345 | } |
| 348 | 346 | |
| 349 | −int __init | |
| 350 | −acpi_table_parse_entries(char *id, | |
| 347 | +int __init acpi_table_parse_entries(char *id, | |
| 351 | 348 | unsigned long table_size, |
| 352 | 349 | int entry_id, |
| 353 | 350 | acpi_tbl_entry_handler handler, |
| @@ -362,8 +359,7 @@ acpi_table_parse_entries(char *id, · 8 unmodified lines | ||
| 362 | 359 | max_entries); |
| 363 | 360 | } |
| 364 | 361 | |
| 365 | −int __init | |
| 366 | −acpi_table_parse_madt(enum acpi_madt_type id, | |
| 362 | +int __init acpi_table_parse_madt(enum acpi_madt_type id, | |
| 367 | 363 | acpi_tbl_entry_handler handler, unsigned int max_entries) |
| 368 | 364 | { |
| 369 | 365 | return acpi_table_parse_entries(ACPI_SIG_MADT, |
| @@ -670,8 +666,8 @@ static void __init acpi_table_initrd_scan(void) · 300 unmodified lines | ||
| 670 | 666 | table_length = table->length; |
| 671 | 667 | |
| 672 | 668 | /* Skip RSDT/XSDT which should only be used for override */ |
| 673 | − if (ACPI_COMPARE_NAME(table->signature, ACPI_SIG_RSDT) || | |
| 674 | − ACPI_COMPARE_NAME(table->signature, ACPI_SIG_XSDT)) { | |
| 669 | + if (ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_RSDT) || | |
| 670 | + ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_XSDT)) { | |
| 675 | 671 | acpi_os_unmap_memory(table, ACPI_HEADER_SIZE); |
| 676 | 672 | goto next_table; |
| 677 | 673 | } |
| @@ -725,8 +721,7 @@ static void *amlcode __attribute__ ((weakref("AmlCode"))); · 47 unmodified lines | ||
| 725 | 721 | static void *dsdt_amlcode __attribute__ ((weakref("dsdt_aml_code"))); |
| 726 | 722 | #endif |
| 727 | 723 | |
| 728 | −acpi_status | |
| 729 | −acpi_os_table_override(struct acpi_table_header *existing_table, | |
| 724 | +acpi_status acpi_os_table_override(struct acpi_table_header *existing_table, | |
| 730 | 725 | struct acpi_table_header **new_table) |
| 731 | 726 | { |
| 732 | 727 | if (!existing_table || !new_table) |
| @@ -788,7 +783,6 @@ static int __init acpi_parse_apic_instance(char *str) · 55 unmodified lines | ||
| 788 | 783 | |
| 789 | 784 | return 0; |
| 790 | 785 | } |
| 791 | − | |
| 792 | 786 | early_param("acpi_apic_instance", acpi_parse_apic_instance); |
| 793 | 787 | |
| 794 | 788 | static int __init acpi_force_table_verification_setup(char *s) |
| @@ -797,7 +791,6 @@ static int __init acpi_force_table_verification_setup(char *s) · 2 unmodified lines | ||
| 797 | 791 | |
| 798 | 792 | return 0; |
| 799 | 793 | } |
| 800 | − | |
| 801 | 794 | early_param("acpi_force_table_verification", acpi_force_table_verification_setup); |
| 802 | 795 | |
| 803 | 796 | static int __init acpi_force_32bit_fadt_addr(char *s) |
| @@ -807,5 +800,4 @@ static int __init acpi_force_32bit_fadt_addr(char *s) · 3 unmodified lines | ||
| 807 | 800 | |
| 808 | 801 | return 0; |
| 809 | 802 | } |
| 810 | − | |
| 811 | 803 | early_param("acpi_force_32bit_fadt_addr", acpi_force_32bit_fadt_addr); |
| @@ -739,6 +739,7 @@ EXPORT_SYMBOL(acpi_dev_found); · 738 unmodified lines | ||
| 739 | 739 | |
| 740 | 740 | struct acpi_dev_match_info { |
| 741 | 741 | const char *dev_name; |
| 742 | + struct acpi_device *adev; | |
| 742 | 743 | struct acpi_device_id hid[2]; |
| 743 | 744 | const char *uid; |
| 744 | 745 | s64 hrv; |
| @@ -759,6 +760,7 @@ static int acpi_dev_match_cb(struct device *dev, void *data) · 14 unmodified lines | ||
| 759 | 760 | return 0; |
| 760 | 761 | |
| 761 | 762 | match->dev_name = acpi_dev_name(adev); |
| 763 | + match->adev = adev; | |
| 762 | 764 | |
| 763 | 765 | if (match->hrv == -1) |
| 764 | 766 | return 1; |
| @@ -806,18 +808,20 @@ bool acpi_dev_present(const char *hid, const char *uid, s64 hrv) · 41 unmodified lines | ||
| 806 | 808 | EXPORT_SYMBOL(acpi_dev_present); |
| 807 | 809 | |
| 808 | 810 | /** |
| 809 | − * acpi_dev_get_first_match_name - Return name of first match of ACPI device | |
| 811 | + * acpi_dev_get_first_match_dev - Return the first match of ACPI device | |
| 810 | 812 | * @hid: Hardware ID of the device. |
| 811 | 813 | * @uid: Unique ID of the device, pass NULL to not check _UID |
| 812 | 814 | * @hrv: Hardware Revision of the device, pass -1 to not check _HRV |
| 813 | 815 | * |
| 814 | − * Return device name if a matching device was present | |
| 816 | + * Return the first match of ACPI device if a matching device was present | |
| 815 | 817 | * at the moment of invocation, or NULL otherwise. |
| 816 | 818 | * |
| 819 | + * The caller is responsible to call put_device() on the returned device. | |
| 820 | + * | |
| 817 | 821 | * See additional information in acpi_dev_present() as well. |
| 818 | 822 | */ |
| 819 | −const char * | |
| 820 | −acpi_dev_get_first_match_name(const char *hid, const char *uid, s64 hrv) | |
| 823 | +struct acpi_device * | |
| 824 | +acpi_dev_get_first_match_dev(const char *hid, const char *uid, s64 hrv) | |
| 821 | 825 | { |
| 822 | 826 | struct acpi_dev_match_info match = {}; |
| 823 | 827 | struct device *dev; |
| @@ -827,9 +831,9 @@ acpi_dev_get_first_match_name(const char *hid, const char *uid, s64 hrv) · 3 unmodified lines | ||
| 827 | 831 | match.hrv = hrv; |
| 828 | 832 | |
| 829 | 833 | dev = bus_find_device(&acpi_bus_type, NULL, &match, acpi_dev_match_cb); |
| 830 | − return dev ? match.dev_name : NULL; | |
| 834 | + return dev ? match.adev : NULL; | |
| 831 | 835 | } |
| 832 | −EXPORT_SYMBOL(acpi_dev_get_first_match_name); | |
| 836 | +EXPORT_SYMBOL(acpi_dev_get_first_match_dev); | |
| 833 | 837 | |
| 834 | 838 | /* |
| 835 | 839 | * acpi_backlight= handling, this is done here rather then in video_detect.c |
| @@ -112,7 +112,7 @@ static int video_detect_force_none(const struct dmi_system_id *d) · 111 unmodified lines | ||
| 112 | 112 | static const struct dmi_system_id video_detect_dmi_table[] = { |
| 113 | 113 | /* On Samsung X360, the BIOS will set a flag (VDRV) if generic |
| 114 | 114 | * ACPI backlight device is used. This flag will definitively break |
| 115 | − * the backlight interface (even the vendor interface) untill next | |
| 115 | + * the backlight interface (even the vendor interface) until next | |
| 116 | 116 | * reboot. It's why we should prevent video.ko from being used here |
| 117 | 117 | * and we can't rely on a later call to acpi_video_unregister(). |
| 118 | 118 | */ |
| @@ -141,6 +141,14 @@ static const struct dmi_system_id video_detect_dmi_table[] = { · 22 unmodified lines | ||
| 141 | 141 | DMI_MATCH(DMI_PRODUCT_NAME, "UL30A"), |
| 142 | 142 | }, |
| 143 | 143 | }, |
| 144 | + { | |
| 145 | + .callback = video_detect_force_vendor, | |
| 146 | + .ident = "Sony VPCEH3U1E", | |
| 147 | + .matches = { | |
| 148 | + DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"), | |
| 149 | + DMI_MATCH(DMI_PRODUCT_NAME, "VPCEH3U1E"), | |
| 150 | + }, | |
| 151 | + }, | |
| 144 | 152 | |
| 145 | 153 | /* |
| 146 | 154 | * These models have a working acpi_video backlight control, and using |
| @@ -333,7 +333,7 @@ static int axp288_extcon_probe(struct platform_device *pdev) · 332 unmodified lines | ||
| 333 | 333 | struct axp288_extcon_info *info; |
| 334 | 334 | struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent); |
| 335 | 335 | struct device *dev = &pdev->dev; |
| 336 | − const char *name; | |
| 336 | + struct acpi_device *adev; | |
| 337 | 337 | int ret, i, pirq; |
| 338 | 338 | |
| 339 | 339 | info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL); |
| @@ -357,9 +357,10 @@ static int axp288_extcon_probe(struct platform_device *pdev) · 17 unmodified lines | ||
| 357 | 357 | if (ret) |
| 358 | 358 | return ret; |
| 359 | 359 | |
| 360 | − name = acpi_dev_get_first_match_name("INT3496", NULL, -1); | |
| 361 | − if (name) { | |
| 362 | − info->id_extcon = extcon_get_extcon_dev(name); | |
| 360 | + adev = acpi_dev_get_first_match_dev("INT3496", NULL, -1); | |
| 361 | + if (adev) { | |
| 362 | + info->id_extcon = extcon_get_extcon_dev(acpi_dev_name(adev)); | |
| 363 | + put_device(&adev->dev); | |
| 363 | 364 | if (!info->id_extcon) |
| 364 | 365 | return -EPROBE_DEFER; |
| 365 | 366 | |
| @@ -425,7 +425,7 @@ static ssize_t ibft_attr_show_acpitbl(void *data, int type, char *buf) · 424 unmodified lines | ||
| 425 | 425 | |
| 426 | 426 | switch (type) { |
| 427 | 427 | case ISCSI_BOOT_ACPITBL_SIGNATURE: |
| 428 | − str += sprintf_string(str, ACPI_NAME_SIZE, | |
| 428 | + str += sprintf_string(str, ACPI_NAMESEG_SIZE, | |
| 429 | 429 | entry->header->header.signature); |
| 430 | 430 | break; |
| 431 | 431 | case ISCSI_BOOT_ACPITBL_OEM_ID: |
| @@ -377,10 +377,20 @@ static void mrfld_irq_init_hw(struct mrfld_gpio *priv) · 376 unmodified lines | ||
| 377 | 377 | } |
| 378 | 378 | } |
| 379 | 379 | |
| 380 | −static const char *mrfld_gpio_get_pinctrl_dev_name(void) | |
| 380 | +static const char *mrfld_gpio_get_pinctrl_dev_name(struct mrfld_gpio *priv) | |
| 381 | 381 | { |
| 382 | − const char *dev_name = acpi_dev_get_first_match_name("INTC1002", NULL, -1); | |
| 383 | − return dev_name ? dev_name : "pinctrl-merrifield"; | |
| 382 | + struct acpi_device *adev; | |
| 383 | + const char *name; | |
| 384 | + | |
| 385 | + adev = acpi_dev_get_first_match_dev("INTC1002", NULL, -1); | |
| 386 | + if (adev) { | |
| 387 | + name = devm_kstrdup(priv->dev, acpi_dev_name(adev), GFP_KERNEL); | |
| 388 | + acpi_dev_put(adev); | |
| 389 | + } else { | |
| 390 | + name = "pinctrl-merrifield"; | |
| 391 | + } | |
| 392 | + | |
| 393 | + return name; | |
| 384 | 394 | } |
| 385 | 395 | |
| 386 | 396 | static int mrfld_gpio_probe(struct pci_dev *pdev, const struct pci_device_id *id) |
| @@ -441,7 +451,7 @@ static int mrfld_gpio_probe(struct pci_dev *pdev, const struct pci_device_id *id · 54 unmodified lines | ||
| 441 | 451 | return retval; |
| 442 | 452 | } |
| 443 | 453 | |
| 444 | − pinctrl_dev_name = mrfld_gpio_get_pinctrl_dev_name(); | |
| 454 | + pinctrl_dev_name = mrfld_gpio_get_pinctrl_dev_name(priv); | |
| 445 | 455 | for (i = 0; i < ARRAY_SIZE(mrfld_gpio_ranges); i++) { |
| 446 | 456 | range = &mrfld_gpio_ranges[i]; |
| 447 | 457 | retval = gpiochip_add_pin_range(&priv->chip, |
| @@ -230,7 +230,7 @@ static void get_single_name(acpi_handle handle, char *name) · 229 unmodified lines | ||
| 230 | 230 | if (ACPI_FAILURE(acpi_get_name(handle, ACPI_SINGLE_NAME, &buffer))) |
| 231 | 231 | pr_warn("Failed to get device name from acpi handle\n"); |
| 232 | 232 | else { |
| 233 | − memcpy(name, buffer.pointer, ACPI_NAME_SIZE); | |
| 233 | + memcpy(name, buffer.pointer, ACPI_NAMESEG_SIZE); | |
| 234 | 234 | kfree(buffer.pointer); |
| 235 | 235 | } |
| 236 | 236 | } |
| @@ -91,8 +91,8 @@ acpi_evaluate_dsm_typed(acpi_handle handle, const guid_t *guid, u64 rev, · 90 unmodified lines | ||
| 91 | 91 | bool acpi_dev_found(const char *hid); |
| 92 | 92 | bool acpi_dev_present(const char *hid, const char *uid, s64 hrv); |
| 93 | 93 | |
| 94 | −const char * | |
| 95 | −acpi_dev_get_first_match_name(const char *hid, const char *uid, s64 hrv); | |
| 94 | +struct acpi_device * | |
| 95 | +acpi_dev_get_first_match_dev(const char *hid, const char *uid, s64 hrv); | |
| 96 | 96 | |
| 97 | 97 | #ifdef CONFIG_ACPI |
| 98 | 98 | |
| @@ -687,6 +687,10 @@ static inline bool acpi_device_can_poweroff(struct acpi_device *adev) · 588 unmodified lines | ||
| 687 | 687 | adev->power.states[ACPI_STATE_D3_HOT].flags.explicit_set); |
| 688 | 688 | } |
| 689 | 689 | |
| 690 | +static inline void acpi_dev_put(struct acpi_device *adev) | |
| 691 | +{ | |
| 692 | + put_device(&adev->dev); | |
| 693 | +} | |
| 690 | 694 | #else /* CONFIG_ACPI */ |
| 691 | 695 | |
| 692 | 696 | static inline int register_acpi_bus_type(void *bus) { return 0; } |
| @@ -12,7 +12,7 @@ · 11 unmodified lines | ||
| 12 | 12 | |
| 13 | 13 | /* Current ACPICA subsystem version in YYYYMMDD format */ |
| 14 | 14 | |
| 15 | −#define ACPI_CA_VERSION 0x20190215 | |
| 15 | +#define ACPI_CA_VERSION 0x20190405 | |
| 16 | 16 | |
| 17 | 17 | #include <acpi/acconfig.h> |
| 18 | 18 | #include <acpi/actypes.h> |
| @@ -66,14 +66,14 @@ · 65 unmodified lines | ||
| 66 | 66 | ******************************************************************************/ |
| 67 | 67 | |
| 68 | 68 | struct acpi_table_header { |
| 69 | − char signature[ACPI_NAME_SIZE]; /* ASCII table signature */ | |
| 69 | + char signature[ACPI_NAMESEG_SIZE]; /* ASCII table signature */ | |
| 70 | 70 | u32 length; /* Length of table in bytes, including this header */ |
| 71 | 71 | u8 revision; /* ACPI Specification minor version number */ |
| 72 | 72 | u8 checksum; /* To make sum of entire table == 0 */ |
| 73 | 73 | char oem_id[ACPI_OEM_ID_SIZE]; /* ASCII OEM identification */ |
| 74 | 74 | char oem_table_id[ACPI_OEM_TABLE_ID_SIZE]; /* ASCII OEM table identification */ |
| 75 | 75 | u32 oem_revision; /* OEM revision number */ |
| 76 | − char asl_compiler_id[ACPI_NAME_SIZE]; /* ASCII ASL compiler vendor ID */ | |
| 76 | + char asl_compiler_id[ACPI_NAMESEG_SIZE]; /* ASCII ASL compiler vendor ID */ | |
| 77 | 77 | u32 asl_compiler_revision; /* ASL compiler version */ |
| 78 | 78 | }; |
| 79 | 79 | |
| @@ -375,7 +375,7 @@ typedef u64 acpi_physical_address; · 374 unmodified lines | ||
| 375 | 375 | |
| 376 | 376 | /* Names within the namespace are 4 bytes long */ |
| 377 | 377 | |
| 378 | −#define ACPI_NAME_SIZE 4 | |
| 378 | +#define ACPI_NAMESEG_SIZE 4 /* Fixed by ACPI spec */ | |
| 379 | 379 | #define ACPI_PATH_SEGMENT_LENGTH 5 /* 4 chars for name + 1 char for separator */ |
| 380 | 380 | #define ACPI_PATH_SEPARATOR '.' |
| 381 | 381 | |
| @@ -515,11 +515,11 @@ typedef u64 acpi_integer; · 133 unmodified lines | ||
| 515 | 515 | /* Optimizations for 4-character (32-bit) acpi_name manipulation */ |
| 516 | 516 | |
| 517 | 517 | #ifndef ACPI_MISALIGNMENT_NOT_SUPPORTED |
| 518 | −#define ACPI_COMPARE_NAME(a,b) (*ACPI_CAST_PTR (u32, (a)) == *ACPI_CAST_PTR (u32, (b))) | |
| 519 | −#define ACPI_MOVE_NAME(dest,src) (*ACPI_CAST_PTR (u32, (dest)) = *ACPI_CAST_PTR (u32, (src))) | |
| 518 | +#define ACPI_COMPARE_NAMESEG(a,b) (*ACPI_CAST_PTR (u32, (a)) == *ACPI_CAST_PTR (u32, (b))) | |
| 519 | +#define ACPI_COPY_NAMESEG(dest,src) (*ACPI_CAST_PTR (u32, (dest)) = *ACPI_CAST_PTR (u32, (src))) | |
| 520 | 520 | #else |
| 521 | −#define ACPI_COMPARE_NAME(a,b) (!strncmp (ACPI_CAST_PTR (char, (a)), ACPI_CAST_PTR (char, (b)), ACPI_NAME_SIZE)) | |
| 522 | −#define ACPI_MOVE_NAME(dest,src) (strncpy (ACPI_CAST_PTR (char, (dest)), ACPI_CAST_PTR (char, (src)), ACPI_NAME_SIZE)) | |
| 521 | +#define ACPI_COMPARE_NAMESEG(a,b) (!strncmp (ACPI_CAST_PTR (char, (a)), ACPI_CAST_PTR (char, (b)), ACPI_NAMESEG_SIZE)) | |
| 522 | +#define ACPI_COPY_NAMESEG(dest,src) (strncpy (ACPI_CAST_PTR (char, (dest)), ACPI_CAST_PTR (char, (src)), ACPI_NAMESEG_SIZE)) | |
| 523 | 523 | #endif |
| 524 | 524 | |
| 525 | 525 | /* Support for the special RSDP signature (8 characters) */ |
| @@ -529,7 +529,7 @@ typedef u64 acpi_integer; · 3 unmodified lines | ||
| 529 | 529 | |
| 530 | 530 | /* Support for OEMx signature (x can be any character) */ |
| 531 | 531 | #define ACPI_IS_OEM_SIG(a) (!strncmp (ACPI_CAST_PTR (char, (a)), ACPI_OEM_NAME, 3) &&\ |
| 532 | − strnlen (a, ACPI_NAME_SIZE) == ACPI_NAME_SIZE) | |
| 532 | + strnlen (a, ACPI_NAMESEG_SIZE) == ACPI_NAMESEG_SIZE) | |
| 533 | 533 | |
| 534 | 534 | /* |
| 535 | 535 | * Algorithm to obtain access bit width. |
| @@ -669,12 +669,14 @@ static inline bool acpi_dev_present(const char *hid, const char *uid, s64 hrv) · 668 unmodified lines | ||
| 669 | 669 | return false; |
| 670 | 670 | } |
| 671 | 671 | |
| 672 | −static inline const char * | |
| 673 | −acpi_dev_get_first_match_name(const char *hid, const char *uid, s64 hrv) | |
| 672 | +static inline struct acpi_device * | |
| 673 | +acpi_dev_get_first_match_dev(const char *hid, const char *uid, s64 hrv) | |
| 674 | 674 | { |
| 675 | 675 | return NULL; |
| 676 | 676 | } |
| 677 | 677 | |
| 678 | +static inline void acpi_dev_put(struct acpi_device *adev) {} | |
| 679 | + | |
| 678 | 680 | static inline bool is_acpi_node(struct fwnode_handle *fwnode) |
| 679 | 681 | { |
| 680 | 682 | return false; |
| @@ -226,7 +226,7 @@ static int bytcht_da7213_probe(struct platform_device *pdev) · 225 unmodified lines | ||
| 226 | 226 | struct snd_soc_card *card; |
| 227 | 227 | struct snd_soc_acpi_mach *mach; |
| 228 | 228 | const char *platform_name; |
| 229 | − const char *i2c_name = NULL; | |
| 229 | + struct acpi_device *adev; | |
| 230 | 230 | int dai_index = 0; |
| 231 | 231 | int ret_val = 0; |
| 232 | 232 | int i; |
| @@ -244,10 +244,11 @@ static int bytcht_da7213_probe(struct platform_device *pdev) · 11 unmodified lines | ||
| 244 | 244 | } |
| 245 | 245 | |
| 246 | 246 | /* fixup codec name based on HID */ |
| 247 | − i2c_name = acpi_dev_get_first_match_name(mach->id, NULL, -1); | |
| 248 | − if (i2c_name) { | |
| 247 | + adev = acpi_dev_get_first_match_dev(mach->id, NULL, -1); | |
| 248 | + if (adev) { | |
| 249 | 249 | snprintf(codec_name, sizeof(codec_name), |
| 250 | − "%s%s", "i2c-", i2c_name); | |
| 250 | + "i2c-%s", acpi_dev_name(adev)); | |
| 251 | + put_device(&adev->dev); | |
| 251 | 252 | dailink[dai_index].codec_name = codec_name; |
| 252 | 253 | } |
| 253 | 254 | |
| @@ -442,7 +442,7 @@ static int snd_byt_cht_es8316_mc_probe(struct platform_device *pdev) · 441 unmodified lines | ||
| 442 | 442 | struct device *dev = &pdev->dev; |
| 443 | 443 | struct snd_soc_acpi_mach *mach; |
| 444 | 444 | const char *platform_name; |
| 445 | − const char *i2c_name = NULL; | |
| 445 | + struct acpi_device *adev; | |
| 446 | 446 | struct device *codec_dev; |
| 447 | 447 | int dai_index = 0; |
| 448 | 448 | int i; |
| @@ -463,10 +463,11 @@ static int snd_byt_cht_es8316_mc_probe(struct platform_device *pdev) · 14 unmodified lines | ||
| 463 | 463 | } |
| 464 | 464 | |
| 465 | 465 | /* fixup codec name based on HID */ |
| 466 | − i2c_name = acpi_dev_get_first_match_name(mach->id, NULL, -1); | |
| 467 | − if (i2c_name) { | |
| 466 | + adev = acpi_dev_get_first_match_dev(mach->id, NULL, -1); | |
| 467 | + if (adev) { | |
| 468 | 468 | snprintf(codec_name, sizeof(codec_name), |
| 469 | − "%s%s", "i2c-", i2c_name); | |
| 469 | + "i2c-%s", acpi_dev_name(adev)); | |
| 470 | + put_device(&adev->dev); | |
| 470 | 471 | byt_cht_es8316_dais[dai_index].codec_name = codec_name; |
| 471 | 472 | } |
| 472 | 473 | |
| @@ -1154,7 +1154,7 @@ static int snd_byt_rt5640_mc_probe(struct platform_device *pdev) · 1153 unmodified lines | ||
| 1154 | 1154 | struct byt_rt5640_private *priv; |
| 1155 | 1155 | struct snd_soc_acpi_mach *mach; |
| 1156 | 1156 | const char *platform_name; |
| 1157 | − const char *i2c_name = NULL; | |
| 1157 | + struct acpi_device *adev; | |
| 1158 | 1158 | int ret_val = 0; |
| 1159 | 1159 | int dai_index = 0; |
| 1160 | 1160 | int i; |
| @@ -1178,11 +1178,11 @@ static int snd_byt_rt5640_mc_probe(struct platform_device *pdev) · 17 unmodified lines | ||
| 1178 | 1178 | } |
| 1179 | 1179 | |
| 1180 | 1180 | /* fixup codec name based on HID */ |
| 1181 | − i2c_name = acpi_dev_get_first_match_name(mach->id, NULL, -1); | |
| 1182 | − if (i2c_name) { | |
| 1181 | + adev = acpi_dev_get_first_match_dev(mach->id, NULL, -1); | |
| 1182 | + if (adev) { | |
| 1183 | 1183 | snprintf(byt_rt5640_codec_name, sizeof(byt_rt5640_codec_name), |
| 1184 | − "%s%s", "i2c-", i2c_name); | |
| 1185 | − | |
| 1184 | + "i2c-%s", acpi_dev_name(adev)); | |
| 1185 | + put_device(&adev->dev); | |
| 1186 | 1186 | byt_rt5640_dais[dai_index].codec_name = byt_rt5640_codec_name; |
| 1187 | 1187 | } |
| 1188 | 1188 | |
| @@ -867,8 +867,8 @@ static int snd_byt_rt5651_mc_probe(struct platform_device *pdev) · 866 unmodified lines | ||
| 867 | 867 | struct byt_rt5651_private *priv; |
| 868 | 868 | struct snd_soc_acpi_mach *mach; |
| 869 | 869 | const char *platform_name; |
| 870 | + struct acpi_device *adev; | |
| 870 | 871 | struct device *codec_dev; |
| 871 | − const char *i2c_name = NULL; | |
| 872 | 872 | const char *hp_swapped; |
| 873 | 873 | bool is_bytcr = false; |
| 874 | 874 | int ret_val = 0; |
| @@ -894,14 +894,16 @@ static int snd_byt_rt5651_mc_probe(struct platform_device *pdev) · 19 unmodified lines | ||
| 894 | 894 | } |
| 895 | 895 | |
| 896 | 896 | /* fixup codec name based on HID */ |
| 897 | − i2c_name = acpi_dev_get_first_match_name(mach->id, NULL, -1); | |
| 898 | − if (!i2c_name) { | |
| 897 | + adev = acpi_dev_get_first_match_dev(mach->id, NULL, -1); | |
| 898 | + if (adev) { | |
| 899 | + snprintf(byt_rt5651_codec_name, sizeof(byt_rt5651_codec_name), | |
| 900 | + "i2c-%s", acpi_dev_name(adev)); | |
| 901 | + put_device(&adev->dev); | |
| 902 | + byt_rt5651_dais[dai_index].codec_name = byt_rt5651_codec_name; | |
| 903 | + } else { | |
| 899 | 904 | dev_err(&pdev->dev, "Error cannot find '%s' dev\n", mach->id); |
| 900 | 905 | return -ENODEV; |
| 901 | 906 | } |
| 902 | − snprintf(byt_rt5651_codec_name, sizeof(byt_rt5651_codec_name), | |
| 903 | − "%s%s", "i2c-", i2c_name); | |
| 904 | − byt_rt5651_dais[dai_index].codec_name = byt_rt5651_codec_name; | |
| 905 | 907 | |
| 906 | 908 | codec_dev = bus_find_device_by_name(&i2c_bus_type, NULL, |
| 907 | 909 | byt_rt5651_codec_name); |
| @@ -532,7 +532,7 @@ static int snd_cht_mc_probe(struct platform_device *pdev) · 531 unmodified lines | ||
| 532 | 532 | struct snd_soc_acpi_mach *mach; |
| 533 | 533 | const char *platform_name; |
| 534 | 534 | struct cht_mc_private *drv; |
| 535 | − const char *i2c_name = NULL; | |
| 535 | + struct acpi_device *adev; | |
| 536 | 536 | bool found = false; |
| 537 | 537 | bool is_bytcr = false; |
| 538 | 538 | int dai_index = 0; |
| @@ -573,10 +573,11 @@ static int snd_cht_mc_probe(struct platform_device *pdev) · 34 unmodified lines | ||
| 573 | 573 | } |
| 574 | 574 | |
| 575 | 575 | /* fixup codec name based on HID */ |
| 576 | − i2c_name = acpi_dev_get_first_match_name(mach->id, NULL, -1); | |
| 577 | − if (i2c_name) { | |
| 576 | + adev = acpi_dev_get_first_match_dev(mach->id, NULL, -1); | |
| 577 | + if (adev) { | |
| 578 | 578 | snprintf(cht_rt5645_codec_name, sizeof(cht_rt5645_codec_name), |
| 579 | − "%s%s", "i2c-", i2c_name); | |
| 579 | + "i2c-%s", acpi_dev_name(adev)); | |
| 580 | + put_device(&adev->dev); | |
| 580 | 581 | cht_dailink[dai_index].codec_name = cht_rt5645_codec_name; |
| 581 | 582 | } |
| 582 | 583 | |
| @@ -401,7 +401,7 @@ static int snd_cht_mc_probe(struct platform_device *pdev) · 400 unmodified lines | ||
| 401 | 401 | struct cht_mc_private *drv; |
| 402 | 402 | struct snd_soc_acpi_mach *mach = pdev->dev.platform_data; |
| 403 | 403 | const char *platform_name; |
| 404 | − const char *i2c_name; | |
| 404 | + struct acpi_device *adev; | |
| 405 | 405 | int i; |
| 406 | 406 | |
| 407 | 407 | drv = devm_kzalloc(&pdev->dev, sizeof(*drv), GFP_KERNEL); |
| @@ -411,10 +411,11 @@ static int snd_cht_mc_probe(struct platform_device *pdev) · 3 unmodified lines | ||
| 411 | 411 | strcpy(drv->codec_name, RT5672_I2C_DEFAULT); |
| 412 | 412 | |
| 413 | 413 | /* fixup codec name based on HID */ |
| 414 | − i2c_name = acpi_dev_get_first_match_name(mach->id, NULL, -1); | |
| 415 | − if (i2c_name) { | |
| 414 | + adev = acpi_dev_get_first_match_dev(mach->id, NULL, -1); | |
| 415 | + if (adev) { | |
| 416 | 416 | snprintf(drv->codec_name, sizeof(drv->codec_name), |
| 417 | − "i2c-%s", i2c_name); | |
| 417 | + "i2c-%s", acpi_dev_name(adev)); | |
| 418 | + put_device(&adev->dev); | |
| 418 | 419 | for (i = 0; i < ARRAY_SIZE(cht_dailink); i++) { |
| 419 | 420 | if (!strcmp(cht_dailink[i].codec_name, |
| 420 | 421 | RT5672_I2C_DEFAULT)) { |
| @@ -19,7 +19,7 @@ ACPI_MODULE_NAME("oslinuxtbl") · 18 unmodified lines | ||
| 19 | 19 | typedef struct osl_table_info { |
| 20 | 20 | struct osl_table_info *next; |
| 21 | 21 | u32 instance; |
| 22 | − char signature[ACPI_NAME_SIZE]; | |
| 22 | + char signature[ACPI_NAMESEG_SIZE]; | |
| 23 | 23 | |
| 24 | 24 | } osl_table_info; |
| 25 | 25 | |
| @@ -286,14 +286,14 @@ static acpi_status osl_add_table_to_list(char *signature, u32 instance) · 260 unmodified lines | ||
| 286 | 286 | return (AE_NO_MEMORY); |
| 287 | 287 | } |
| 288 | 288 | |
| 289 | − ACPI_MOVE_NAME(new_info->signature, signature); | |
| 289 | + ACPI_COPY_NAMESEG(new_info->signature, signature); | |
| 290 | 290 | |
| 291 | 291 | if (!gbl_table_list_head) { |
| 292 | 292 | gbl_table_list_head = new_info; |
| 293 | 293 | } else { |
| 294 | 294 | next = gbl_table_list_head; |
| 295 | 295 | while (1) { |
| 296 | − if (ACPI_COMPARE_NAME(next->signature, signature)) { | |
| 296 | + if (ACPI_COMPARE_NAMESEG(next->signature, signature)) { | |
| 297 | 297 | if (next->instance == instance) { |
| 298 | 298 | found = TRUE; |
| 299 | 299 | } |
| @@ -782,11 +782,11 @@ osl_get_bios_table(char *signature, · 482 unmodified lines | ||
| 782 | 782 | |
| 783 | 783 | /* Handle special tables whose addresses are not in RSDT/XSDT */ |
| 784 | 784 | |
| 785 | − if (ACPI_COMPARE_NAME(signature, ACPI_RSDP_NAME) || | |
| 786 | − ACPI_COMPARE_NAME(signature, ACPI_SIG_RSDT) || | |
| 787 | − ACPI_COMPARE_NAME(signature, ACPI_SIG_XSDT) || | |
| 788 | − ACPI_COMPARE_NAME(signature, ACPI_SIG_DSDT) || | |
| 789 | − ACPI_COMPARE_NAME(signature, ACPI_SIG_FACS)) { | |
| 785 | + if (ACPI_COMPARE_NAMESEG(signature, ACPI_RSDP_NAME) || | |
| 786 | + ACPI_COMPARE_NAMESEG(signature, ACPI_SIG_RSDT) || | |
| 787 | + ACPI_COMPARE_NAMESEG(signature, ACPI_SIG_XSDT) || | |
| 788 | + ACPI_COMPARE_NAMESEG(signature, ACPI_SIG_DSDT) || | |
| 789 | + ACPI_COMPARE_NAMESEG(signature, ACPI_SIG_FACS)) { | |
| 790 | 790 | |
| 791 | 791 | find_next_instance: |
| 792 | 792 | |
| @@ -797,7 +797,7 @@ find_next_instance: · 4 unmodified lines | ||
| 797 | 797 | * careful about the FADT length and validate table addresses. |
| 798 | 798 | * Note: The 64-bit addresses have priority. |
| 799 | 799 | */ |
| 800 | − if (ACPI_COMPARE_NAME(signature, ACPI_SIG_DSDT)) { | |
| 800 | + if (ACPI_COMPARE_NAMESEG(signature, ACPI_SIG_DSDT)) { | |
| 801 | 801 | if (current_instance < 2) { |
| 802 | 802 | if ((gbl_fadt->header.length >= |
| 803 | 803 | MIN_FADT_FOR_XDSDT) && gbl_fadt->Xdsdt |
| @@ -815,7 +815,7 @@ find_next_instance: · 11 unmodified lines | ||
| 815 | 815 | dsdt; |
| 816 | 816 | } |
| 817 | 817 | } |
| 818 | − } else if (ACPI_COMPARE_NAME(signature, ACPI_SIG_FACS)) { | |
| 818 | + } else if (ACPI_COMPARE_NAMESEG(signature, ACPI_SIG_FACS)) { | |
| 819 | 819 | if (current_instance < 2) { |
| 820 | 820 | if ((gbl_fadt->header.length >= |
| 821 | 821 | MIN_FADT_FOR_XFACS) && gbl_fadt->Xfacs |
| @@ -833,7 +833,7 @@ find_next_instance: · 11 unmodified lines | ||
| 833 | 833 | facs; |
| 834 | 834 | } |
| 835 | 835 | } |
| 836 | − } else if (ACPI_COMPARE_NAME(signature, ACPI_SIG_XSDT)) { | |
| 836 | + } else if (ACPI_COMPARE_NAMESEG(signature, ACPI_SIG_XSDT)) { | |
| 837 | 837 | if (!gbl_revision) { |
| 838 | 838 | return (AE_BAD_SIGNATURE); |
| 839 | 839 | } |
| @@ -842,7 +842,7 @@ find_next_instance: · 2 unmodified lines | ||
| 842 | 842 | (acpi_physical_address)gbl_rsdp. |
| 843 | 843 | xsdt_physical_address; |
| 844 | 844 | } |
| 845 | − } else if (ACPI_COMPARE_NAME(signature, ACPI_SIG_RSDT)) { | |
| 845 | + } else if (ACPI_COMPARE_NAMESEG(signature, ACPI_SIG_RSDT)) { | |
| 846 | 846 | if (current_instance == 0) { |
| 847 | 847 | table_address = |
| 848 | 848 | (acpi_physical_address)gbl_rsdp. |
| @@ -931,7 +931,7 @@ find_next_instance: · 82 unmodified lines | ||
| 931 | 931 | |
| 932 | 932 | /* Does this table match the requested signature? */ |
| 933 | 933 | |
| 934 | − if (!ACPI_COMPARE_NAME | |
| 934 | + if (!ACPI_COMPARE_NAMESEG | |
| 935 | 935 | (mapped_table->signature, signature)) { |
| 936 | 936 | osl_unmap_table(mapped_table); |
| 937 | 937 | mapped_table = NULL; |
| @@ -995,7 +995,7 @@ static acpi_status osl_list_customized_tables(char *directory) · 57 unmodified lines | ||
| 995 | 995 | { |
| 996 | 996 | void *table_dir; |
| 997 | 997 | u32 instance; |
| 998 | − char temp_name[ACPI_NAME_SIZE]; | |
| 998 | + char temp_name[ACPI_NAMESEG_SIZE]; | |
| 999 | 999 | char *filename; |
| 1000 | 1000 | acpi_status status = AE_OK; |
| 1001 | 1001 | |
| @@ -1086,8 +1086,8 @@ osl_map_table(acpi_size address, · 84 unmodified lines | ||
| 1086 | 1086 | return (AE_BAD_SIGNATURE); |
| 1087 | 1087 | } |
| 1088 | 1088 | } else |
| 1089 | − if (!ACPI_COMPARE_NAME(signature, mapped_table->signature)) | |
| 1090 | − { | |
| 1089 | + if (!ACPI_COMPARE_NAMESEG | |
| 1090 | + (signature, mapped_table->signature)) { | |
| 1091 | 1091 | acpi_os_unmap_memory(mapped_table, |
| 1092 | 1092 | sizeof(struct acpi_table_header)); |
| 1093 | 1093 | return (AE_BAD_SIGNATURE); |
| @@ -1158,15 +1158,15 @@ osl_table_name_from_file(char *filename, char *signature, u32 *instance) · 64 unmodified lines | ||
| 1158 | 1158 | |
| 1159 | 1159 | /* Ignore meaningless files */ |
| 1160 | 1160 | |
| 1161 | − if (strlen(filename) < ACPI_NAME_SIZE) { | |
| 1161 | + if (strlen(filename) < ACPI_NAMESEG_SIZE) { | |
| 1162 | 1162 | return (AE_BAD_SIGNATURE); |
| 1163 | 1163 | } |
| 1164 | 1164 | |
| 1165 | 1165 | /* Extract instance number */ |
| 1166 | 1166 | |
| 1167 | − if (isdigit((int)filename[ACPI_NAME_SIZE])) { | |
| 1168 | − sscanf(&filename[ACPI_NAME_SIZE], "%u", instance); | |
| 1169 | − } else if (strlen(filename) != ACPI_NAME_SIZE) { | |
| 1167 | + if (isdigit((int)filename[ACPI_NAMESEG_SIZE])) { | |
| 1168 | + sscanf(&filename[ACPI_NAMESEG_SIZE], "%u", instance); | |
| 1169 | + } else if (strlen(filename) != ACPI_NAMESEG_SIZE) { | |
| 1170 | 1170 | return (AE_BAD_SIGNATURE); |
| 1171 | 1171 | } else { |
| 1172 | 1172 | *instance = 0; |
| @@ -1174,7 +1174,7 @@ osl_table_name_from_file(char *filename, char *signature, u32 *instance) · 1 unmodified line | ||
| 1174 | 1174 | |
| 1175 | 1175 | /* Extract signature */ |
| 1176 | 1176 | |
| 1177 | − ACPI_MOVE_NAME(signature, filename); | |
| 1177 | + ACPI_COPY_NAMESEG(signature, filename); | |
| 1178 | 1178 | return (AE_OK); |
| 1179 | 1179 | } |
| 1180 | 1180 | |
| @@ -1236,7 +1236,7 @@ osl_read_table_from_file(char *filename, · 55 unmodified lines | ||
| 1236 | 1236 | status = AE_BAD_SIGNATURE; |
| 1237 | 1237 | goto exit; |
| 1238 | 1238 | } |
| 1239 | − } else if (!ACPI_COMPARE_NAME(signature, header.signature)) { | |
| 1239 | + } else if (!ACPI_COMPARE_NAMESEG(signature, header.signature)) { | |
| 1240 | 1240 | fprintf(stderr, |
| 1241 | 1241 | "Incorrect signature: Expecting %4.4s, found %4.4s\n", |
| 1242 | 1242 | signature, header.signature); |
| @@ -1311,7 +1311,7 @@ osl_get_customized_table(char *pathname, · 68 unmodified lines | ||
| 1311 | 1311 | { |
| 1312 | 1312 | void *table_dir; |
| 1313 | 1313 | u32 current_instance = 0; |
| 1314 | − char temp_name[ACPI_NAME_SIZE]; | |
| 1314 | + char temp_name[ACPI_NAMESEG_SIZE]; | |
| 1315 | 1315 | char table_filename[PATH_MAX]; |
| 1316 | 1316 | char *filename; |
| 1317 | 1317 | acpi_status status; |
| @@ -1329,7 +1329,7 @@ osl_get_customized_table(char *pathname, · 11 unmodified lines | ||
| 1329 | 1329 | |
| 1330 | 1330 | /* Ignore meaningless files */ |
| 1331 | 1331 | |
| 1332 | − if (!ACPI_COMPARE_NAME(filename, signature)) { | |
| 1332 | + if (!ACPI_COMPARE_NAMESEG(filename, signature)) { | |
| 1333 | 1333 | continue; |
| 1334 | 1334 | } |
| 1335 | 1335 | |
| @@ -289,14 +289,14 @@ int ap_dump_table_by_address(char *ascii_address) · 288 unmodified lines | ||
| 289 | 289 | |
| 290 | 290 | int ap_dump_table_by_name(char *signature) |
| 291 | 291 | { |
| 292 | − char local_signature[ACPI_NAME_SIZE + 1]; | |
| 292 | + char local_signature[ACPI_NAMESEG_SIZE + 1]; | |
| 293 | 293 | u32 instance; |
| 294 | 294 | struct acpi_table_header *table; |
| 295 | 295 | acpi_physical_address address; |
| 296 | 296 | acpi_status status; |
| 297 | 297 | int table_status; |
| 298 | 298 | |
| 299 | − if (strlen(signature) != ACPI_NAME_SIZE) { | |
| 299 | + if (strlen(signature) != ACPI_NAMESEG_SIZE) { | |
| 300 | 300 | fprintf(stderr, |
| 301 | 301 | "Invalid table signature [%s]: must be exactly 4 characters\n", |
| 302 | 302 | signature); |
| @@ -310,9 +310,9 @@ int ap_dump_table_by_name(char *signature) · 7 unmodified lines | ||
| 310 | 310 | |
| 311 | 311 | /* To be friendly, handle tables whose signatures do not match the name */ |
| 312 | 312 | |
| 313 | − if (ACPI_COMPARE_NAME(local_signature, "FADT")) { | |
| 313 | + if (ACPI_COMPARE_NAMESEG(local_signature, "FADT")) { | |
| 314 | 314 | strcpy(local_signature, ACPI_SIG_FADT); |
| 315 | − } else if (ACPI_COMPARE_NAME(local_signature, "MADT")) { | |
| 315 | + } else if (ACPI_COMPARE_NAMESEG(local_signature, "MADT")) { | |
| 316 | 316 | strcpy(local_signature, ACPI_SIG_MADT); |
| 317 | 317 | } |
| 318 | 318 | |
| @@ -97,7 +97,7 @@ int ap_open_output_file(char *pathname) · 96 unmodified lines | ||
| 97 | 97 | |
| 98 | 98 | int ap_write_to_binary_file(struct acpi_table_header *table, u32 instance) |
| 99 | 99 | { |
| 100 | − char filename[ACPI_NAME_SIZE + 16]; | |
| 100 | + char filename[ACPI_NAMESEG_SIZE + 16]; | |
| 101 | 101 | char instance_str[16]; |
| 102 | 102 | ACPI_FILE file; |
| 103 | 103 | acpi_size actual; |
| @@ -110,16 +110,16 @@ int ap_write_to_binary_file(struct acpi_table_header *table, u32 instance) · 6 unmodified lines | ||
| 110 | 110 | /* Construct lower-case filename from the table local signature */ |
| 111 | 111 | |
| 112 | 112 | if (ACPI_VALIDATE_RSDP_SIG(table->signature)) { |
| 113 | − ACPI_MOVE_NAME(filename, ACPI_RSDP_NAME); | |
| 113 | + ACPI_COPY_NAMESEG(filename, ACPI_RSDP_NAME); | |
| 114 | 114 | } else { |
| 115 | − ACPI_MOVE_NAME(filename, table->signature); | |
| 115 | + ACPI_COPY_NAMESEG(filename, table->signature); | |
| 116 | 116 | } |
| 117 | 117 | |
| 118 | 118 | filename[0] = (char)tolower((int)filename[0]); |
| 119 | 119 | filename[1] = (char)tolower((int)filename[1]); |
| 120 | 120 | filename[2] = (char)tolower((int)filename[2]); |
| 121 | 121 | filename[3] = (char)tolower((int)filename[3]); |
| 122 | − filename[ACPI_NAME_SIZE] = 0; | |
| 122 | + filename[ACPI_NAMESEG_SIZE] = 0; | |
| 123 | 123 | |
| 124 | 124 | /* Handle multiple SSDts - create different filenames for each */ |
| 125 | 125 | |