linux-dev/drivers/acpi/acpica/acobject.h, branch linus/master

ACPICA: Update copyright notices to the year 2022

2022-04-13T18:24:57Z

ACPICA commit 738d7b0726e6c0458ef93c0a01c0377490888d1e Affects all source modules and utility signons. Link: https://github.com/acpica/acpica/commit/738d7b07 Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki

ACPICA: Use original data_table_region pointer for accesses

2021-12-27T16:01:28Z

ACPICA commit d9eb82bd7515989f0b29d79deeeb758db4d6529c Currently the pointer to the table is cast to acpi_physical_address and later cast back to a pointer to be dereferenced. Whether or not this is supported is implementation-defined. On CHERI, and thus Arm's experimental Morello prototype architecture, pointers are represented as capabilities, which are unforgeable bounded pointers, providing always-on fine-grained spatial memory safety. This means that any pointer cast to a plain integer will lose all its associated metadata, and when cast back to a pointer it will give a null-derived pointer (one that has the same metadata as null but an address equal to the integer) that will trap on any dereference. As a result, this is an implementation where acpi_physical_address cannot be used as a hack to store real pointers. Thus, add a new field to struct acpi_object_region to store the pointer for table regions, and propagate it to acpi_ex_data_table_space_handler via the region context, to use a more portable implementation that supports CHERI. Link: https://github.com/acpica/acpica/commit/d9eb82bd Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki

ACPICA: Fix race in generic_serial_bus (I2C) and GPIO op_region parameter handling

2021-02-19T15:03:25Z

ACPICA commit c9e0116952363b0fa815143dca7e9a2eb4fefa61 The handling of the generic_serial_bus (I2C) and GPIO op_regions in acpi_ev_address_space_dispatch() passes a number of extra parameters to the address-space handler through the address-space Context pointer (instead of using more function parameters). The Context is shared between threads, so if multiple threads try to call the handler for the same address-space at the same time, then a second thread could change the parameters of a first thread while the handler is running for the first thread. An example of this race hitting is the Lenovo Yoga Tablet2 1015L, where there are both attrib_bytes accesses and attrib_byte accesses to the same address-space. The attrib_bytes access stores the number of bytes to transfer in Context->access_length. Where as for the attrib_byte access the number of bytes to transfer is always 1 and field_obj->Field.access_length is unused (so 0). Both types of accesses racing from different threads leads to the following problem: 1. Thread a. starts an attrib_bytes access, stores a non 0 value from field_obj->Field.access_length in Context->access_length 2. Thread b. starts an attrib_byte access, stores 0 in Context->access_length 3. Thread a. calls i2c_acpi_space_handler() (under Linux). Which sees that the access-type is ACPI_GSB_ACCESS_ATTRIB_MULTIBYTE and calls acpi_gsb_i2c_read_bytes(..., Context->access_length) 4. At this point Context->access_length is 0 (set by thread b.) rather then the field_obj->Field.access_length value from thread a. This 0 length reads leads to the following errors being logged: i2c i2c-0: adapter quirk: no zero length (addr 0x0078, size 0, read) i2c i2c-0: i2c read 0 bytes from client@0x78 starting at reg 0x0 failed, error: -95 Note this is just an example of the problems which this race can cause. There are likely many more (sporadic) problems caused by this race. This commit adds a new context_mutex to struct acpi_object_addr_handler and makes acpi_ev_address_space_dispatch() take that mutex when using the shared Context to pass extra parameters to an address-space handler, fixing this race. Note the new mutex must be taken *after* exiting the interpreter, therefor the existing acpi_ex_exit_interpreter() call is moved to above the code which stores the extra parameters in the Context. Link: https://github.com/acpica/acpica/commit/c9e01169 Signed-off-by: Hans de Goede Signed-off-by: Bob Moore Signed-off-by: Erik Kaneda Signed-off-by: Rafael J. Wysocki

ACPICA: Updated all copyrights to 2021

2021-01-22T14:51:53Z

This affects all ACPICA source code modules. ACPICA commit c570953c914437e621dd5f160f26ddf352e0d2f4 Link: https://github.com/acpica/acpica/commit/c570953c Signed-off-by: Bob Moore Signed-off-by: Erik Kaneda Signed-off-by: Rafael J. Wysocki

ACPICA: All acpica: Update copyrights to 2020 Including tool signons.

2020-01-13T10:52:48Z

ACPICA commit 8b9c69d0984067051ffbe8526f871448ead6a26b Link: https://github.com/acpica/acpica/commit/8b9c69d0 Signed-off-by: Bob Moore Signed-off-by: Erik Kaneda Signed-off-by: Rafael J. Wysocki

ACPICA: Dispatcher: always generate buffer objects for ASL create_field() operator

2019-12-19T22:04:21Z

ACPICA commit 79a466b64e6af36cc83102f05915e56cb7dd89ab According to table 19-419 of the ACPI 6.3 specification, buffer_fields created using the ASL create_field() Operator have been treated as integers if the buffer_field is small enough to fit inside of an ASL integer (32-bits or 64-bits depending on the definition block revision). If they are larger, buffer fields are treated as ASL Buffer objects. However, this is not true for other AML interpreter implementations. It has been discovered that other AML interpreters always treat buffer fields created by create_field() as a buffer regardless of the length of the buffer field. More specifically, the Microsoft AML interpreter always treats buffer fields created by the create_field() operator as buffer. ACPICA currently does this only when the field size is larger than the maximum integer width. This causes problems with AML code shipped in Microsoft Surface devices. More details: The control methods in these devices determine the success of an ASL control method execution by examining the type resulting from storing a buffer field created by a create_field() operator. On success, a Buffer object is expected, on failure an Integer containing an error code. This buffer object is created with a dynamic size via the create_field() operator. Due to the difference in behavior, Buffer values of small size are however converted to Integers and thus interpreted by the control method as having failed, whereas in reality it succeeded. Below is an example of a control method called TEST that illustrates this behavior. Method (CBUF) // Create a Buffer field { /* * Depending on the value of RAND, ACPICA interpreter will treat * BF00 as an integer or buffer. */ create_field (BUFF, 0, RAND, BF00) return (BF00) } Method (TEST) { /* * Storing the value returned by CBUF to local0 will result in * implicit type conversion outlined in the ACPI specification. * * ACPICA will treat local0 like an ASL integer if RAND is less * than or equal to 64 or 32 (depending on the definition_block * revision). If RAND is greater, it will be treated like an ASL * buffer. Other implementations treat local0 like an ASL buffer * regardless of the value of RAND. */ local0 = CBUF() /* * object_type of 0x03 represents an ASL Buffer */ if (object_type (Local0) != 0x03) { // Error on ACPICA if RAND is small enough } else { /* * Success on APICA if RAND is large enough * Other implementations always take this path because local0 * is always treated as a buffer. */ } } This change prohibits the previously mentioned integer conversion to match other AML interpreter implementations (Microsoft) that do not conform to the ACPI specification. Link: https://github.com/acpica/acpica/commit/79a466b6 Signed-off-by: Maximilian Luz Signed-off-by: Bob Moore Signed-off-by: Erik Kaneda Signed-off-by: Rafael J. Wysocki

ACPICA: Increase total number of possible Owner IDs

2019-08-20T22:00:36Z

ACPICA commit 1f1652dad88b9d767767bc1f7eb4f7d99e6b5324 From 255 to 4095 possible IDs. Link: https://github.com/acpica/acpica/commit/1f1652da Reported-by: Hedi Berriche Signed-off-by: Bob Moore Signed-off-by: Erik Schmauss Signed-off-by: Rafael J. Wysocki

ACPICA: ACPI 6.3: add PCC operation region support for AML interpreter

2019-02-24T20:11:20Z

ACPICA commit a4849944e80f97970e99843f4975850753584a4e This change adds PCC operation region support in the AML interpreter and a default handler for acpiexec. According to the specification, the PCC operation region performs a transaction when the COMD field is written. This allows ASL to write data to other fields before sending the data. In order to accommodate this protocol, a temorary buffer is added to the regionfield object to accumulate writes. If any offset that spans COMD is written, the temporary buffer is sent to the PCC operation region handler to be processed. This change also renames the PCC keyword to platform_comm_channel. Link: https://github.com/acpica/acpica/commit/a4849944 Reviewed-by: Kyle Pelton Signed-off-by: Erik Schmauss Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki

ACPICA: All acpica: Update copyrights to 2019

2019-01-15T17:04:02Z

ACPICA commit 62f4f98e941d86e41969bf2ab5a93b8dc94dc49e The update includes userspace tool signons. Link: https://github.com/acpica/acpica/commit/62f4f98e Signed-off-by: Bob Moore Signed-off-by: Erik Schmauss Signed-off-by: Rafael J. Wysocki

ACPICA: adding SPDX headers

2018-03-18T18:08:05Z

Signed-off-by: Erik Schmauss Signed-off-by: Rafael J. Wysocki