talos-op-linux/drivers/acpi/acpica, branch master

ACPICA: Introduce acpi_any_gpe_status_set()

2020-02-11T22:26:15+00:00

Introduce a new helper function, acpi_any_gpe_status_set(), for checking the status bits of all enabled GPEs in one go. It is needed to distinguish spurious SCIs from genuine ones when deciding whether or not to wake up the system from suspend-to-idle. Cc: 5.4+ # 5.4+ Signed-off-by: Rafael J. Wysocki

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

2020-01-13T10:52:48+00:00

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:21+00:00

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: Disassembler: create buffer fields in ACPI_PARSE_LOAD_PASS1

2019-12-19T22:04:21+00:00

ACPICA commit 29cc8dbc5463a93625bed87d7550a8bed8913bf4 create_buffer_field is a deferred op that is typically processed in load pass 2. However, disassembly of control method contents walk the parse tree with ACPI_PARSE_LOAD_PASS1 and AML_CREATE operators are processed in a later walk. This is a problem when there is a control method that has the same name as the AML_CREATE object. In this case, any use of the name segment will be detected as a method call rather than a reference to a buffer field. If this is detected as a method call, it can result in a mal-formed parse tree if the control methods have parameters. This change in processing AML_CREATE ops earlier solves this issue by inserting the named object in the ACPI namespace so that references to this name would be detected as a name string rather than a method call. Link: https://github.com/acpica/acpica/commit/29cc8dbc Reported-by: Elia Geretto Tested-by: Elia Geretto Signed-off-by: Bob Moore Signed-off-by: Erik Kaneda Signed-off-by: Rafael J. Wysocki

ACPICA: debugger: fix spelling mistake "adress" -> "address"

2019-12-19T22:04:21+00:00

ACPICA commit 7aa72c5fdf75c5b80adf758980e06bcafb7f8670 There is a spelling mistake in an error message. Fix it. Link: https://github.com/acpica/acpica/commit/7aa72c5f Signed-off-by: Colin Ian King Signed-off-by: Bob Moore Signed-off-by: Erik Kaneda Signed-off-by: Rafael J. Wysocki

ACPICA: debugger: remove leading whitespaces when converting a string to a buffer

2019-10-28T21:12:46+00:00

ACPICA commit 1b7228072f254a5b02625586ff7d561757b7fc2d By removing leading whitespaces, the conversion computes the correct number of elements in a given buffer or field encoding that contains leading whitespaces. Link: https://github.com/acpica/acpica/commit/1b722807 Signed-off-by: Erik Schmauss Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki

ACPICA: acpiexec: initialize all simple types and field units from user input

2019-10-28T21:12:46+00:00

ACPICA commit 367b363edc5fa1f93bbc14e4a1e05f34fef765a2 acpiexec allows a user to provide a file that indicates values to initialize named objects during table load with the -fi option. This can provide more accurate simulation by setting named objects to values found during OS runtime. Previously, this option only supported integer objects. This change adds user initialization support for field units, strings, buffers, and packages. Link: https://github.com/acpica/acpica/commit/367b363e Signed-off-by: Erik Schmauss Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki

ACPICA: debugger: add field unit support for acpi_db_get_next_token

2019-10-28T21:12:46+00:00

ACPICA commit d509afa88e9415f13a3283c38ce9ee034634ae24 Since field unit data output from the debugger are now surrounded by braces '{', support has been added to acpi_db_get_next_token to recognize strings beginning with this character as a ACPI_TYPE_FIELD_UNIT. Link: https://github.com/acpica/acpica/commit/d509afa8 Signed-off-by: Erik Schmauss Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki

ACPICA: debugger: surround field unit output with braces '{'

2019-10-28T21:12:46+00:00

ACPICA commit 76ca57291d007d33087982a4b28cd1ee9bcd37a6 This helps differentiate the type of named objects between field units and buffers. In other words, without this symbol, it would be difficult to tell whether a particular named object is a buffer or a field unit. Link: https://github.com/acpica/acpica/commit/76ca5729 Signed-off-by: Erik Schmauss Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki

ACPICA: debugger: add command to dump all fields of particular subtype

2019-10-28T21:12:46+00:00

In acpiexec, this can be invoked by typing "fields" followed by a number representing the address space ID of that field. Signed-off-by: Erik Schmauss Signed-off-by: Rafael J. Wysocki