aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/acpi/acpica
AgeCommit message (Collapse)Author
13 daysACPI: disable -Wstringop-truncationArnd Bergmann
[ Upstream commit a3403d304708f60565582d60af4316289d0316a0 ] gcc -Wstringop-truncation warns about copying a string that results in a missing nul termination: drivers/acpi/acpica/tbfind.c: In function 'acpi_tb_find_table': drivers/acpi/acpica/tbfind.c:60:9: error: 'strncpy' specified bound 6 equals destination size [-Werror=stringop-truncation] 60 | strncpy(header.oem_id, oem_id, ACPI_OEM_ID_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/acpi/acpica/tbfind.c:61:9: error: 'strncpy' specified bound 8 equals destination size [-Werror=stringop-truncation] 61 | strncpy(header.oem_table_id, oem_table_id, ACPI_OEM_TABLE_ID_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The code works as intended, and the warning could be addressed by using a memcpy(), but turning the warning off for this file works equally well and may be easier to merge. Fixes: 47c08729bf1c ("ACPICA: Fix for LoadTable operator, input strings") Link: https://lore.kernel.org/lkml/CAJZ5v0hoUfv54KW7y4223Mn9E7D4xvR7whRFNLTBqCZMUxT50Q@mail.gmail.com/#t Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-23ACPICA: Add AML_NO_OPERAND_RESOLVE flag to TimerAbhishek Mainkar
[ Upstream commit 3a21ffdbc825e0919db9da0e27ee5ff2cc8a863e ] ACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5 According to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode. When ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed. ============================================================= UBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type 'union acpi_operand_object *[9]' CPU: 37 PID: 1678 Comm: cat Not tainted 6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k HW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace: dump_backtrace+0xe0/0x130 show_stack+0x20/0x60 dump_stack_lvl+0x68/0x84 dump_stack+0x18/0x34 ubsan_epilogue+0x10/0x50 __ubsan_handle_out_of_bounds+0x80/0x90 acpi_ds_exec_end_op+0x1bc/0x6d8 acpi_ps_parse_loop+0x57c/0x618 acpi_ps_parse_aml+0x1e0/0x4b4 acpi_ps_execute_method+0x24c/0x2b8 acpi_ns_evaluate+0x3a8/0x4bc acpi_evaluate_object+0x15c/0x37c acpi_evaluate_integer+0x54/0x15c show_power+0x8c/0x12c [acpi_power_meter] Link: https://github.com/acpica/acpica/commit/90310989 Signed-off-by: Abhishek Mainkar <abmainkar@nvidia.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-30ACPICA: ACPICA: check null return of ACPI_ALLOCATE_ZEROED in ↵void0red
acpi_db_display_objects [ Upstream commit ae5a0eccc85fc960834dd66e3befc2728284b86c ] ACPICA commit 0d5f467d6a0ba852ea3aad68663cbcbd43300fd4 ACPI_ALLOCATE_ZEROED may fails, object_info might be null and will cause null pointer dereference later. Link: https://github.com/acpica/acpica/commit/0d5f467d Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-30ACPICA: Avoid undefined behavior: applying zero offset to null pointerTamir Duberstein
[ Upstream commit 05bb0167c80b8f93c6a4e0451b7da9b96db990c2 ] ACPICA commit 770653e3ba67c30a629ca7d12e352d83c2541b1e Before this change we see the following UBSAN stack trace in Fuchsia: #0 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302 #1.2 0x000020d0f660777f in ubsan_get_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 <libclang_rt.asan.so>+0x3d77f #1.1 0x000020d0f660777f in maybe_print_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 <libclang_rt.asan.so>+0x3d77f #1 0x000020d0f660777f in ~scoped_report() compiler-rt/lib/ubsan/ubsan_diag.cpp:387 <libclang_rt.asan.so>+0x3d77f #2 0x000020d0f660b96d in handlepointer_overflow_impl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 <libclang_rt.asan.so>+0x4196d #3 0x000020d0f660b50d in compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 <libclang_rt.asan.so>+0x4150d #4 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302 #5 0x000021e4213e2369 in acpi_ds_call_control_method(struct acpi_thread_state*, struct acpi_walk_state*, union acpi_parse_object*) ../../third_party/acpica/source/components/dispatcher/dsmethod.c:605 <platform-bus-x86.so>+0x262369 #6 0x000021e421437fac in acpi_ps_parse_aml(struct acpi_walk_state*) ../../third_party/acpica/source/components/parser/psparse.c:550 <platform-bus-x86.so>+0x2b7fac #7 0x000021e4214464d2 in acpi_ps_execute_method(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/parser/psxface.c:244 <platform-bus-x86.so>+0x2c64d2 #8 0x000021e4213aa052 in acpi_ns_evaluate(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/namespace/nseval.c:250 <platform-bus-x86.so>+0x22a052 #9 0x000021e421413dd8 in acpi_ns_init_one_device(acpi_handle, u32, void*, void**) ../../third_party/acpica/source/components/namespace/nsinit.c:735 <platform-bus-x86.so>+0x293dd8 #10 0x000021e421429e98 in acpi_ns_walk_namespace(acpi_object_type, acpi_handle, u32, u32, acpi_walk_callback, acpi_walk_callback, void*, void**) ../../third_party/acpica/source/components/namespace/nswalk.c:298 <platform-bus-x86.so>+0x2a9e98 #11 0x000021e4214131ac in acpi_ns_initialize_devices(u32) ../../third_party/acpica/source/components/namespace/nsinit.c:268 <platform-bus-x86.so>+0x2931ac #12 0x000021e42147c40d in acpi_initialize_objects(u32) ../../third_party/acpica/source/components/utilities/utxfinit.c:304 <platform-bus-x86.so>+0x2fc40d #13 0x000021e42126d603 in acpi::acpi_impl::initialize_acpi(acpi::acpi_impl*) ../../src/devices/board/lib/acpi/acpi-impl.cc:224 <platform-bus-x86.so>+0xed603 Add a simple check that avoids incrementing a pointer by zero, but otherwise behaves as before. Note that our findings are against ACPICA 20221020, but the same code exists on master. Link: https://github.com/acpica/acpica/commit/770653e3 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-11ACPI: Don't build ACPICA with '-Os'Mark Rutland
[ Upstream commit 8f9e0a52810dd83406c768972d022c37e7a18f1f ] The ACPICA code has been built with '-Os' since the beginning of git history, though there's no explanatory comment as to why. This is unfortunate as GCC drops the alignment specificed by '-falign-functions=N' when '-Os' is used, as reported in GCC bug 88345: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345 This prevents CONFIG_FUNCTION_ALIGNMENT and CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B from having their expected effect on the ACPICA code. This is doubly unfortunate as in subsequent patches arm64 will depend upon CONFIG_FUNCTION_ALIGNMENT for its ftrace implementation. Drop the '-Os' flag when building the ACPICA code. With this removed, the code builds cleanly and works correctly in testing so far. I've tested this by selecting CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B=y, building and booting a kernel using ACPI, and looking for misaligned text symbols: * arm64: Before, v6.2-rc3: # uname -rm 6.2.0-rc3 aarch64 # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l 5009 Before, v6.2-rc3 + fixed __cold: # uname -rm 6.2.0-rc3-00001-g2a2bedf8bfa9 aarch64 # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l 919 After: # uname -rm 6.2.0-rc3-00002-g267bddc38572 aarch64 # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l 323 # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | grep acpi | wc -l 0 * x86_64: Before, v6.2-rc3: # uname -rm 6.2.0-rc3 x86_64 # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l 11537 Before, v6.2-rc3 + fixed __cold: # uname -rm 6.2.0-rc3-00001-g2a2bedf8bfa9 x86_64 # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l 2805 After: # uname -rm 6.2.0-rc3-00002-g267bddc38572 x86_64 # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l 1357 # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | grep acpi | wc -l 0 With the patch applied, the remaining unaligned text labels are a combination of static call trampolines and labels in assembly, which can be dealt with in subsequent patches. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Florent Revest <revest@chromium.org> Cc: Len Brown <lenb@kernel.org> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Robert Moore <robert.moore@intel.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Will Deacon <will@kernel.org> Cc: linux-acpi@vger.kernel.org Link: https://lore.kernel.org/r/20230123134603.1064407-4-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-11ACPICA: nsrepair: handle cases without a return value correctlyDaniil Tatianin
[ Upstream commit ca843a4c79486e99a19b859ef0b9887854afe146 ] Previously acpi_ns_simple_repair() would crash if expected_btypes contained any combination of ACPI_RTYPE_NONE with a different type, e.g | ACPI_RTYPE_INTEGER because of slightly incorrect logic in the !return_object branch, which wouldn't return AE_AML_NO_RETURN_VALUE for such cases. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Link: https://github.com/acpica/acpica/pull/811 Fixes: 61db45ca2163 ("ACPICA: Restore code that repairs NULL package elements in return values.") Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-11ACPICA: Drop port I/O validation for some regionsMario Limonciello
[ Upstream commit e1d9148582ab2c3dada5c5cf8ca7531ca269fee5 ] Microsoft introduced support in Windows XP for blocking port I/O to various regions. For Windows compatibility ACPICA has adopted the same protections and will disallow writes to those (presumably) the same regions. On some systems the AML included with the firmware will issue 4 byte long writes to 0x80. These writes aren't making it over because of this blockage. The first 4 byte write attempt is rejected, and then subsequently 1 byte at a time each offset is tried. The first at 0x80 works, but then the next 3 bytes are rejected. This manifests in bizarre failures for devices that expected the AML to write all 4 bytes. Trying the same AML on Windows 10 or 11 doesn't hit this failure and all 4 bytes are written. Either some of these regions were wrong or some point after Windows XP some of these regions blocks have been lifted. In the last 15 years there doesn't seem to be any reports popping up of this error in the Windows event viewer anymore. There is no documentation at Microsoft's developer site indicating that Windows ACPI interpreter blocks these regions. Between the lack of documentation and the fact that the writes actually do work in Windows 10 and 11, it's quite likely Windows doesn't actually enforce this anymore. So to help the issue, only enforce Windows XP specific entries if the latest _OSI supported is Windows XP. Continue to enforce the ALWAYS_ILLEGAL entries. Link: https://github.com/acpica/acpica/pull/817 Fixes: 7f0719039085 ("ACPICA: New: I/O port protection") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-01-18ACPICA: Fix error code path in acpi_ds_call_control_method()Rafael J. Wysocki
[ Upstream commit 404ec60438add1afadaffaed34bb5fe4ddcadd40 ] A use-after-free in acpi_ps_parse_aml() after a failing invocaion of acpi_ds_call_control_method() is reported by KASAN [1] and code inspection reveals that next_walk_state pushed to the thread by acpi_ds_create_walk_state() is freed on errors, but it is not popped from the thread beforehand. Thus acpi_ds_get_current_walk_state() called by acpi_ps_parse_aml() subsequently returns it as the new walk state which is incorrect. To address this, make acpi_ds_call_control_method() call acpi_ds_pop_walk_state() to pop next_walk_state from the thread before returning an error. Link: https://lore.kernel.org/linux-acpi/20221019073443.248215-1-chenzhongjin@huawei.com/ # [1] Reported-by: Chen Zhongjin <chenzhongjin@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Chen Zhongjin <chenzhongjin@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-01-18ACPICA: Fix use-after-free in acpi_ut_copy_ipackage_to_ipackage()Li Zetao
[ Upstream commit 470188b09e92d83c5a997f25f0e8fb8cd2bc3469 ] There is an use-after-free reported by KASAN: BUG: KASAN: use-after-free in acpi_ut_remove_reference+0x3b/0x82 Read of size 1 at addr ffff888112afc460 by task modprobe/2111 CPU: 0 PID: 2111 Comm: modprobe Not tainted 6.1.0-rc7-dirty Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), Call Trace: <TASK> kasan_report+0xae/0xe0 acpi_ut_remove_reference+0x3b/0x82 acpi_ut_copy_iobject_to_iobject+0x3be/0x3d5 acpi_ds_store_object_to_local+0x15d/0x3a0 acpi_ex_store+0x78d/0x7fd acpi_ex_opcode_1A_1T_1R+0xbe4/0xf9b acpi_ps_parse_aml+0x217/0x8d5 ... </TASK> The root cause of the problem is that the acpi_operand_object is freed when acpi_ut_walk_package_tree() fails in acpi_ut_copy_ipackage_to_ipackage(), lead to repeated release in acpi_ut_copy_iobject_to_iobject(). The problem was introduced by "8aa5e56eeb61" commit, this commit is to fix memory leak in acpi_ut_copy_iobject_to_iobject(), repeatedly adding remove operation, lead to "acpi_operand_object" used after free. Fix it by removing acpi_ut_remove_reference() in acpi_ut_copy_ipackage_to_ipackage(). acpi_ut_copy_ipackage_to_ipackage() is called to copy an internal package object into another internal package object, when it fails, the memory of acpi_operand_object should be freed by the caller. Fixes: 8aa5e56eeb61 ("ACPICA: Utilities: Fix memory leak in acpi_ut_copy_iobject_to_iobject") Signed-off-by: Li Zetao <lizetao1@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-05-12ACPICA: Always create namespace nodes using acpi_ns_create_node()Vegard Nossum
commit 25928deeb1e4e2cdae1dccff349320c6841eb5f8 upstream. ACPICA commit 29da9a2a3f5b2c60420893e5c6309a0586d7a329 ACPI is allocating an object using kmalloc(), but then frees it using kmem_cache_free(<"Acpi-Namespace" kmem_cache>). This is wrong and can lead to boot failures manifesting like this: hpet0: 3 comparators, 64-bit 100.000000 MHz counter clocksource: Switched to clocksource tsc-early BUG: unable to handle page fault for address: 000000003ffe0018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.6.0+ #211 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 RIP: 0010:kmem_cache_alloc+0x70/0x1d0 Code: 00 00 4c 8b 45 00 65 49 8b 50 08 65 4c 03 05 6f cc e7 7e 4d 8b 20 4d 85 e4 0f 84 3d 01 00 00 8b 45 20 48 8b 7d 00 48 8d 4a 01 <49> 8b 1c 04 4c 89 e0 65 48 0f c7 0f 0f 94 c0 84 c0 74 c5 8b 45 20 RSP: 0000:ffffc90000013df8 EFLAGS: 00010206 RAX: 0000000000000018 RBX: ffffffff81c49200 RCX: 0000000000000002 RDX: 0000000000000001 RSI: 0000000000000dc0 RDI: 000000000002b300 RBP: ffff88803e403d00 R08: ffff88803ec2b300 R09: 0000000000000001 R10: 0000000000000dc0 R11: 0000000000000006 R12: 000000003ffe0000 R13: ffffffff8110a583 R14: 0000000000000dc0 R15: ffffffff81c49a80 FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000003ffe0018 CR3: 0000000001c0a001 CR4: 00000000003606f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __trace_define_field+0x33/0xa0 event_trace_init+0xeb/0x2b4 tracer_init_tracefs+0x60/0x195 ? register_tracer+0x1e7/0x1e7 do_one_initcall+0x74/0x160 kernel_init_freeable+0x190/0x1f0 ? rest_init+0x9a/0x9a kernel_init+0x5/0xf6 ret_from_fork+0x35/0x40 CR2: 000000003ffe0018 ---[ end trace 707efa023f2ee960 ]--- RIP: 0010:kmem_cache_alloc+0x70/0x1d0 Bisection leads to unrelated changes in slab; Vlastimil Babka suggests an unrelated layout or slab merge change merely exposed the underlying bug. Link: https://lore.kernel.org/lkml/4dc93ff8-f86e-f4c9-ebeb-6d3153a78d03@oracle.com/ Link: https://lore.kernel.org/r/a1461e21-c744-767d-6dfc-6641fd3e3ce2@siemens.com Link: https://github.com/acpica/acpica/commit/29da9a2a Fixes: f79c8e4136ea ("ACPICA: Namespace: simplify creation of the initial/default namespace") Reported-by: Jan Kiszka <jan.kiszka@siemens.com> Diagnosed-by: Vlastimil Babka <vbabka@suse.cz> Diagnosed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Kaneda <erik.kaneda@intel.com> Cc: 5.10+ <stable@vger.kernel.org> # 5.10+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-15ACPICA: Avoid walking the ACPI Namespace if it is not thereRafael J. Wysocki
[ Upstream commit 0c9992315e738e7d6e927ef36839a466b080dba6 ] ACPICA commit b1c3656ef4950098e530be68d4b589584f06cddc Prevent acpi_ns_walk_namespace() from crashing when called with start_node equal to ACPI_ROOT_OBJECT if the Namespace has not been instantiated yet and acpi_gbl_root_node is NULL. For instance, this can happen if the kernel is run with "acpi=off" in the command line. Link: https://github.com/acpica/acpica/commit/b1c3656ef4950098e530be68d4b589584f06cddc Link: https://lore.kernel.org/linux-acpi/CAJZ5v0hJWW_vZ3wwajE7xT38aWjY7cZyvqMJpXHzUL98-SiCVQ@mail.gmail.com/ Reported-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27ACPICA: Hardware: Do not flush CPU cache when entering S4 and S5Kirill A. Shutemov
[ Upstream commit 1d4e0b3abb168b2ee1eca99c527cffa1b80b6161 ] ACPICA commit 3dd7e1f3996456ef81bfe14cba29860e8d42949e According to ACPI 6.4, Section 16.2, the CPU cache flushing is required on entering to S1, S2, and S3, but the ACPICA code flushes the CPU cache regardless of the sleep state. Blind cache flush on entering S5 causes problems for TDX. Flushing happens with WBINVD that is not supported in the TDX environment. TDX only supports S5 and adjusting ACPICA code to conform to the spec more strictly fixes the issue. Link: https://github.com/acpica/acpica/commit/3dd7e1f3 Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27ACPICA: Fix wrong interpretation of PCC addressSudeep Holla
[ Upstream commit 9a3b8655db1ada31c82189ae13f40eb25da48c35 ] ACPICA commit 41be6afacfdaec2dba3a5ed368736babc2a7aa5c With the PCC Opregion in the firmware and we are hitting below kernel crash: -->8 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Workqueue: pm pm_runtime_work pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __memcpy+0x54/0x260 lr : acpi_ex_write_data_to_field+0xb8/0x194 Call trace: __memcpy+0x54/0x260 acpi_ex_store_object_to_node+0xa4/0x1d4 acpi_ex_store+0x44/0x164 acpi_ex_opcode_1A_1T_1R+0x25c/0x508 acpi_ds_exec_end_op+0x1b4/0x44c acpi_ps_parse_loop+0x3a8/0x614 acpi_ps_parse_aml+0x90/0x2f4 acpi_ps_execute_method+0x11c/0x19c acpi_ns_evaluate+0x1ec/0x2b0 acpi_evaluate_object+0x170/0x2b0 acpi_device_set_power+0x118/0x310 acpi_dev_suspend+0xd4/0x180 acpi_subsys_runtime_suspend+0x28/0x38 __rpm_callback+0x74/0x328 rpm_suspend+0x2d8/0x624 pm_runtime_work+0xa4/0xb8 process_one_work+0x194/0x25c worker_thread+0x260/0x49c kthread+0x14c/0x30c ret_from_fork+0x10/0x20 Code: f9000006 f81f80a7 d65f03c0 361000c2 (b9400026) ---[ end trace 24d8a032fa77b68a ]--- The reason for the crash is that the PCC channel index passed via region.address in acpi_ex_store_object_to_node is interpreted as the channel subtype incorrectly. Assuming the PCC op_region support is not used by any other type, let us remove the subtype check as the AML has no access to the subtype information. Once we remove it, the kernel crash disappears and correctly complains about missing PCC Opregion handler. ACPI Error: No handler for Region [PFRM] ((____ptrval____)) [PCC] (20210730/evregion-130) ACPI Error: Region PCC (ID=10) has no handler (20210730/exfldio-261) ACPI Error: Aborting method \_SB.ETH0._PS3 due to previous error (AE_NOT_EXIST) (20210730/psparse-531) Link: https://github.com/acpica/acpica/commit/41be6afa Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27ACPICA: Executer: Fix the REFCLASS_REFOF case in acpi_ex_opcode_1A_0T_1R()Rafael J. Wysocki
[ Upstream commit 24ea5f90ec9548044a6209685c5010edd66ffe8f ] ACPICA commit d984f12041392fa4156b52e2f7e5c5e7bc38ad9e If Operand[0] is a reference of the ACPI_REFCLASS_REFOF class, acpi_ex_opcode_1A_0T_1R () calls acpi_ns_get_attached_object () to obtain return_desc which may require additional resolution with the help of acpi_ex_read_data_from_field (). If the latter fails, the reference counter of the original return_desc is decremented which is incorrect, because acpi_ns_get_attached_object () does not increment the reference counter of the object returned by it. This issue may lead to premature deletion of the attached object while it is still attached and a use-after-free and crash in the host OS. For example, this may happen when on evaluation of ref_of() a local region field where there is no registered handler for the given Operation Region. Fix it by making acpi_ex_opcode_1A_0T_1R () return Status right away after a acpi_ex_read_data_from_field () failure. Link: https://github.com/acpica/acpica/commit/d984f120 Link: https://github.com/acpica/acpica/pull/685 Reported-by: Lenny Szubowicz <lszubowi@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27ACPICA: Utilities: Avoid deleting the same object twice in a rowRafael J. Wysocki
[ Upstream commit 1cdfe9e346b4c5509ffe19ccde880fd259d9f7a3 ] ACPICA commit c11af67d8f7e3d381068ce7771322f2b5324d687 If original_count is 0 in acpi_ut_update_ref_count (), acpi_ut_delete_internal_obj () is invoked for the target object, which is incorrect, because that object has been deleted once already and the memory allocated to store it may have been reclaimed and allocated for a different purpose by the host OS. Moreover, a confusing debug message following the "Reference Count is already zero, cannot decrement" warning is printed in that case. To fix this issue, make acpi_ut_update_ref_count () return after finding that original_count is 0 and printing the above warning. Link: https://github.com/acpica/acpica/commit/c11af67d Link: https://github.com/acpica/acpica/pull/652 Reported-by: Mark Asselstine <mark.asselstine@windriver.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-17ACPICA: Avoid evaluating methods too early during system resumeRafael J. Wysocki
[ Upstream commit d3c4b6f64ad356c0d9ddbcf73fa471e6a841cc5c ] ACPICA commit 0762982923f95eb652cf7ded27356b247c9774de During wakeup from system-wide sleep states, acpi_get_sleep_type_data() is called and it tries to get memory from the slab allocator in order to evaluate a control method, but if KFENCE is enabled in the kernel, the memory allocation attempt causes an IRQ work to be queued and a self-IPI to be sent to the CPU running the code which requires the memory controller to be ready, so if that happens too early in the wakeup path, it doesn't work. Prevent that from taking place by calling acpi_get_sleep_type_data() for S0 upfront, when preparing to enter a given sleep state, and saving the data obtained by it for later use during system wakeup. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214271 Reported-by: Reik Keutterling <spielkind@gmail.com> Tested-by: Reik Keutterling <spielkind@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-08-12Revert "ACPICA: Fix memory leak caused by _CID repair function"Rafael J. Wysocki
commit 6511a8b5b7a65037340cd8ee91a377811effbc83 upstream. Revert commit c27bac0314131 ("ACPICA: Fix memory leak caused by _CID repair function") which is reported to cause a boot issue on Acer Swift 3 (SF314-51). Reported-by: Adrien Precigout <dev@asdrip.fr> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-14ACPICA: Fix memory leak caused by _CID repair functionErik Kaneda
[ Upstream commit c27bac0314131b11bccd735f7e8415ac6444b667 ] ACPICA commit 180cb53963aa876c782a6f52cc155d951b26051a According to the ACPI spec, _CID returns a package containing hardware ID's. Each element of an ASL package contains a reference count from the parent package as well as the element itself. Name (TEST, Package() { "String object" // this package element has a reference count of 2 }) A memory leak was caused in the _CID repair function because it did not decrement the reference count created by the package. Fix the memory leak by calling acpi_ut_remove_reference on _CID package elements that represent a hardware ID (_HID). Link: https://github.com/acpica/acpica/commit/180cb539 Tested-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Erik Kaneda <erik.kaneda@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-06-10ACPICA: Clean up context mutex during object deletionErik Kaneda
[ Upstream commit e4dfe108371214500ee10c2cf19268f53acaa803 ] ACPICA commit bc43c878fd4ff27ba75b1d111b97ee90d4a82707 Fixes: c27f3d011b08 ("Fix race in GenericSerialBus (I2C) and GPIO OpRegion parameter handling") Link: https://github.com/acpica/acpica/commit/bc43c878 Reported-by: John Garry <john.garry@huawei.com> Reported-by: Xiang Chen <chenxiang66@hisilicon.com> Tested-by: Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by: Erik Kaneda <erik.kaneda@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-11ACPICA: Fix race in generic_serial_bus (I2C) and GPIO op_region parameter ↵Hans de Goede
handling commit c27f3d011b08540e68233cf56274fdc34bebb9b5 upstream. 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 <hdegoede@redhat.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Kaneda <erik.kaneda@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-19ACPICA: Do not increment operation_region reference counts for field unitsErik Kaneda
[ Upstream commit 6a54ebae6d047c988a31f5ac5a64ab5cf83797a2 ] ACPICA commit e17b28cfcc31918d0db9547b6b274b09c413eb70 Object reference counts are used as a part of ACPICA's garbage collection mechanism. This mechanism keeps track of references to heap-allocated structures such as the ACPI operand objects. Recent server firmware has revealed that this reference count can overflow on large servers that declare many field units under the same operation_region. This occurs because each field unit declaration will add a reference count to the source operation_region. This change solves the reference count overflow for operation_regions objects by preventing fieldunits from incrementing their operation_region's reference count. Each operation_region's reference count will not be changed by named objects declared under the Field operator. During namespace deletion, the operation_region namespace node will be deleted and each fieldunit will be deleted without touching the deleted operation_region object. Link: https://github.com/acpica/acpica/commit/e17b28cf Signed-off-by: Erik Kaneda <erik.kaneda@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-22ACPICA: Dispatcher: add status checksErik Kaneda
[ Upstream commit 6bfe5344b2956d0bee116f1c640aef05e5cddd76 ] ACPICA commit 3244c1eeba9f9fb9ccedb875f7923a3d85e0c6aa The status chekcs are used to to avoid NULL pointer dereference on field objects Link: https://github.com/acpica/acpica/commit/3244c1ee Reported-by: Kurt Kennett <kurt_kennett@hotmail.com> Signed-off-by: Erik Kaneda <erik.kaneda@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23ACPICA: Fixes for acpiExec namespace init fileBob Moore
[ Upstream commit 9a1ae80412dcaa67a29eecf19de44f32b5f1c357 ] This is the result of squashing the following ACPICA commit ID's: 6803997e5b4f3635cea6610b51ff69e29d251de3 f31cdf8bfda22fe265c1a176d0e33d311c82a7f7 This change fixes several problems with the support for the acpi_exec namespace init file (-fi option). Specifically, it fixes AE_ALREADY_EXISTS errors, as well as various seg faults. Link: https://github.com/acpica/acpica/commit/f31cdf8b Link: https://github.com/acpica/acpica/commit/6803997e Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Kaneda <erik.kaneda@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-17ACPICA: Allow acpi_any_gpe_status_set() to skip one GPERafael J. Wysocki
commit 0ce792d660bda990c675eaf14ce09594a9b85cbf upstream. The check carried out by acpi_any_gpe_status_set() is not precise enough for the suspend-to-idle implementation in Linux and in some cases it is necessary make it skip one GPE (specifically, the EC GPE) from the check to prevent a race condition leading to a premature system resume from occurring. For this reason, redefine acpi_any_gpe_status_set() to take the number of a GPE to skip as an argument. Link: https://bugzilla.kernel.org/show_bug.cgi?id=206629 Tested-by: Ondřej Caletka <ondrej@caletka.cz> Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-28ACPI: PM: s2idle: Check fixed wakeup events in acpi_s2idle_wake()Rafael J. Wysocki
commit 63fb9623427fbb44e3782233b6e4714057b76ff2 upstream. Commit fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system") overlooked the fact that fixed events can wake up the system too and broke RTC wakeup from suspend-to-idle as a result. Fix this issue by checking the fixed events in acpi_s2idle_wake() in addition to checking wakeup GPEs and break out of the suspend-to-idle loop if the status bits of any enabled fixed events are set then. Fixes: fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system") Reported-and-tested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-24ACPICA: Disassembler: create buffer fields in ACPI_PARSE_LOAD_PASS1Erik Kaneda
[ Upstream commit 5ddbd77181dfca61b16d2e2222382ea65637f1b9 ] 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 <elia.f.geretto@gmail.com> Tested-by: Elia Geretto <elia.f.geretto@gmail.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Kaneda <erik.kaneda@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-02-19ACPICA: Introduce acpi_any_gpe_status_set()Rafael J. Wysocki
commit ea128834dd76f9a72a35d011c651fa96658f06a7 upstream. 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+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-17Merge tag 'acpi-5.4-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI updates from Rafael Wysocki: "These include an ACPICA update (to upstream revision 20190816), improvements of support for memory hot-add in the HMAT handling code and some assorted fixes and cleanups. Specifics: - Update the ACPICA code in the kernel to upstream revision 20190816 including: * Internal limits change to support larger systems (Bob Moore). * Macros clean up (Bob Moore). * printf format string fixes (Bob Moore). * Full deployment of the ACPI_PRINTF_LIKE macro (Bob Moore). * Tools improvements (Bob Moore, Colin Ian King). * Windows _OSI support fixes (Jung-uk Kim). - Improve memory hot-add support in the ACPI HMAT handling code (Dan Williams, Keith Busch). - Fix the ACPI LPSS (Low-Power Subsystem) driver for Intel SoCs to save and restore private registers during system-wide suspend and resume on systems with the Lynxpoint PCH (Jarkko Nikula). - Convert the ACPI documentation related to LEDs to ReST (Sakari Ailus). - Fix assorted issues and make assorted minor improvements in the ACPI-related code (Al Stone, Andy Shevchenko, Jiri Slaby, Kelsey Skunberg, Krzysztof Wilczynski, Liguang Zhang, Wenwen Wang, YueHaibing)" * tag 'acpi-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (23 commits) ACPI / PCI: fix acpi_pci_irq_enable() memory leak ACPI: custom_method: fix memory leaks ACPI: thermal: Remove redundant acpi_has_method() calls ACPI / CPPC: do not require the _PSD method ACPI: SBS: remove unused const variable 'SMBUS_PEC' ACPI / LPSS: Save/restore LPSS private registers also on Lynxpoint ACPI/PCI: Remove surplus parentheses from a return statement ACPICA: Update version to 20190816. ACPICA: Add "Windows 2019" string to _OSI support. ACPICA: Differentiate Windows 8.1 from Windows 8. ACPICA: Fully deploy ACPI_PRINTF_LIKE macro ACPICA: iASL,acpi_dump: Improve y/n query ACPICA: Fix issues with arg types within printf format strings ACPICA: Macros: remove pointer math on a null pointer ACPICA: Increase total number of possible Owner IDs ACPICA: Debugger: remove redundant assignment on obj_desc Documentation: ACPI: DSD: Convert LED documentation to ReST ACPI / APEI: Release resources if gen_pool_add() fails HMAT: Skip publishing target info for nodes with no online memory HMAT: Register attributes for memory hot add ...
2019-08-21ACPICA: Add "Windows 2019" string to _OSI support.Jung-uk Kim
ACPICA commit 32fffb242800b0202986e86d9b0e16f88a23de66 Link: https://github.com/acpica/acpica/commit/32fffb24 Signed-off-by: Jung-uk Kim <jkim@free_BSD.org> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-08-21ACPICA: Differentiate Windows 8.1 from Windows 8.Jung-uk Kim
ACPICA commit 66db7b38f61e63f11e48a0ea993d92b12e0a17ca Link: https://github.com/acpica/acpica/commit/66db7b38 Signed-off-by: Jung-uk Kim <jkim@free_BSD.org> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-08-21ACPICA: Fully deploy ACPI_PRINTF_LIKE macroBob Moore
ACPICA commit d06def132a8852d02c9c7fee60f17b2011066e8e Macro was not being used across all "printf-like" functions. Also, clean up all calls to such functions now that they are analyzed by the compiler (gcc). Both in 32-bit mode and 64-bit mode. Link: https://github.com/acpica/acpica/commit/d06def13 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-08-21ACPICA: Fix issues with arg types within printf format stringsBob Moore
ACPICA commit db2638ccaac84b61e92f34d60c3630ff5217f852 Link: https://github.com/acpica/acpica/commit/db2638cc Link: https://github.com/acpica/acpica/commit/634c3085 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-08-21ACPICA: Increase total number of possible Owner IDsBob Moore
ACPICA commit 1f1652dad88b9d767767bc1f7eb4f7d99e6b5324 From 255 to 4095 possible IDs. Link: https://github.com/acpica/acpica/commit/1f1652da Reported-by: Hedi Berriche <hedi.berriche @hpe.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-08-21ACPICA: Debugger: remove redundant assignment on obj_descColin Ian King
ACPICA commit f530f1acb3128136ad97c715fdaebbbeff283ee2 Pointer obj_desc is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Link: https://github.com/acpica/acpica/commit/f530f1ac Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-07-23ACPICA: Return u32 from acpi_dispatch_gpe()Rafael J. Wysocki
In some cases it is useful to know whether or not the acpi_ev_detect_gpe() called by acpi_dispatch_gpe() has found the GPE to be active, so return the return value of it (whose data type is u32) from latter. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Thomas Gleixner <tglx@linutronix.de>
2019-07-11ACPICA: Update table load object initializationErik Schmauss
ACPICA commit c7ef9f3526765bed8930825dda1eed1a274b9668 Use the common internal "initialize objects" interface Affects: Load() load_table() acpi_load_table Link: https://github.com/acpica/acpica/commit/c7ef9f35 Tested-by: Rong Chen <rong.a.chen@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-07-10Revert "ACPICA: Update table load object initialization"Rafael J. Wysocki
Revert commit c522ad0637ca ("ACPICA: Update table load object initialization") as it causes systems to hang on attempts to load OEM ACPI tables. Reported-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-07-04ACPICA: Update table load object initializationErik Schmauss
ACPICA commit c7ef9f3526765bed8930825dda1eed1a274b9668 Use the common internal "initialize objects" interface Affects: Load() load_table() acpi_load_table Link: https://github.com/acpica/acpica/commit/c7ef9f35 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-07-04ACPICA: Update for object initialization sequenceBob Moore
ACPICA commit 106c72a97f5ca972f29956e5e9a0429b8c4a2723 1) Do not allow the objects to be initialized twice 2) Only package objects require a deferred initialization 3) Cleanup initialization output Link: https://github.com/acpica/acpica/commit/106c72a9 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-07-04ACPICA: remove legacy module-level code due to deprecationErik Schmauss
ACPICA commit 1ca34b1a7b960ef321eae5dcddfff77707c88aef There have been several places that have been calling functions regarding module level code blocks. This change removes all old vestiges in the codebase. This is dead code. Link: https://github.com/acpica/acpica/commit/1ca34b1a Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-07-04ACPICA: Namespace: simplify creation of the initial/default namespaceBob Moore
ACPICA commit 76658f55d8cc498a763bdb92f8e0d934822a129c For the objects that are created by default (_GPE, _SB_, etc) there is no need to use the heavyweight ns_lookup function. Instead, simply create each object and link it in as the namespace is built. Link: https://github.com/acpica/acpica/commit/76658f55 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-07-04Merge ACPI tables handling changes for v5.3.Rafael J. Wysocki
2019-06-19ACPICA: Clear status of GPEs on first direct enableRafael J. Wysocki
ACPI GPEs (other than the EC one) can be enabled in two situations. First, the GPEs with existing _Lxx and _Exx methods are enabled implicitly by ACPICA during system initialization. Second, the GPEs without these methods (like GPEs listed by _PRW objects for wakeup devices) need to be enabled directly by the code that is going to use them (e.g. ACPI power management or device drivers). In the former case, if the status of a given GPE is set to start with, its handler method (either _Lxx or _Exx) needs to be invoked to take care of the events (possibly) signaled before the GPE was enabled. In the latter case, however, the first caller of acpi_enable_gpe() for a given GPE should not be expected to care about any events that might be signaled through it earlier. In that case, it is better to clear the status of the GPE before enabling it, to prevent stale events from triggering unwanted actions (like spurious system resume, for example). For this reason, modify acpi_ev_add_gpe_reference() to take an additional boolean argument indicating whether or not the GPE status needs to be cleared when its reference counter changes from zero to one and make acpi_enable_gpe() pass TRUE to it through that new argument. Fixes: 18996f2db918 ("ACPICA: Events: Stop unconditionally clearing ACPI IRQs during suspend/resume") Reported-by: Furquan Shaikh <furquan@google.com> Tested-by: Furquan Shaikh <furquan@google.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-06-14ACPI: configfs: Resolve objects on host-directed table loadsNikolaus Voss
If an ACPI SSDT overlay is loaded after built-in tables have been loaded e.g. via configfs or efivar_ssdt_load() it is necessary to rewalk the namespace to resolve references. Without this, relative and absolute paths like ^PCI0.SBUS or \_SB.PCI0.SBUS are not resolved correctly. Make configfs loads use the same method as efivar_ssdt_load(). Signed-off-by: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-05-06Merge branch 'acpica'Rafael J. Wysocki
* acpica: ACPICA: Update version to 20190405 ACPICA: Namespace: add check to avoid null pointer dereference ACPICA: Update version to 20190329 ACPICA: utilities: fix spelling of PCC to platform_comm_channel ACPICA: Rename nameseg length macro/define for clarity ACPICA: Rename nameseg compare macro for clarity ACPICA: Rename nameseg copy macro for clarity
2019-04-30Revert "ACPICA: Clear status of GPEs before enabling them"Rafael J. Wysocki
Revert commit c8b1917c8987 ("ACPICA: Clear status of GPEs before enabling them") that causes problems with Thunderbolt controllers to occur if a dock device is connected at init time (the xhci_hcd and thunderbolt modules crash which prevents peripherals connected through them from working). Commit c8b1917c8987 effectively causes commit ecc1165b8b74 ("ACPICA: Dispatch active GPEs at init time") to get undone, so the problem addressed by commit ecc1165b8b74 appears again as a result of it. Fixes: c8b1917c8987 ("ACPICA: Clear status of GPEs before enabling them") Link: https://lore.kernel.org/lkml/s5hy33siofw.wl-tiwai@suse.de/T/#u Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1132943 Reported-by: Michael Hirmke <opensuse@mike.franken.de> Reported-by: Takashi Iwai <tiwai@suse.de> Cc: 4.17+ <stable@vger.kernel.org> # 4.17+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-04-12Merge back ACPICA changes for v5.2.Rafael J. Wysocki
2019-04-09ACPICA: Namespace: add check to avoid null pointer dereferenceErik Schmauss
ACPICA commit 7586a625f9c34c3169efd88470192bf63119e31a Some ACPICA userspace tools call acpi_ut_subsystem_shutdown() during cleanup and dereference a null pointer when cleaning up the namespace. Link: https://github.com/acpica/acpica/commit/7586a625 Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-04-09ACPICA: utilities: fix spelling of PCC to platform_comm_channelErik Schmauss
ACPICA commit 5e5c349e73982aea5d9f74416c0b2eea1b0767a1 Link: https://github.com/acpica/acpica/commit/5e5c349e Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-04-09ACPICA: Rename nameseg length macro/define for clarityBob Moore
ACPICA commit 24870bd9e73d71e2a1ff0a1e94519f8f8409e57d ACPI_NAME_SIZE changed to ACPI_NAMESEG_SIZE This clarifies that this is the length of an individual nameseg, not the length of a generic namestring/namepath. Improves understanding of the code. Link: https://github.com/acpica/acpica/commit/24870bd9 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
generated by cgit 1.2.3-korg (git 2.39.0) at 2024-06-29 02:26:50 +0000