summaryrefslogtreecommitdiff
path: root/drivers/acpi/acpica
AgeCommit message (Collapse)Author
2025-09-15ACPICA: ACPI_TYPE_ANY does not include the package typeSaket Dumbre
So add it to the list of acceptable Arg3 types for _DSM. Link: https://github.com/acpica/acpica/commit/6eb81e7c Signed-off-by: Saket Dumbre <saket.dumbre@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-15ACPICA: Fix largest possible resource descriptor indexDmitry Antipov
ACPI_RESOURCE_NAME_LARGE_MAX should be equal to the last actually used resource descriptor index (ACPI_RESOURCE_NAME_CLOCK_INPUT). Otherwise 'resource_index' in 'acpi_ut_validate_resource()' may be clamped incorrectly and resulting value may issue an out-of-bounds access for 'acpi_gbl_resource_types' array. Compile tested only. Fixes: 520d4a0ee5b6 ("ACPICA: add support for ClockInput resource (v6.5)") Link: https://github.com/acpica/acpica/commit/cf00116c Link: https://marc.info/?l=linux-acpi&m=175449676131260&w=2 Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-15ACPICA: Print error messages for too few or too many argumentsSaket Dumbre
Fix Issue #1027 by displaying error messages when there are too few or too many arguments in the caller vs the definition of an ASL/AML method. Link: https://github.com/acpica/acpica/commit/cbc243e4 Reported-by: Peter Williams <peter@newton.cx> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Saket Dumbre <saket.dumbre@intel.com>
2025-09-15ACPICA: Update dsmethod.c to get rid of unused variable warningSaket Dumbre
All the 3 major C compilers (MSVC, GCC, LLVM/Clang) warn about the unused variable i after the removal of its usage by PR #1031 addressing Issue #1027 Link: https://github.com/acpica/acpica/commit/6d235320 Signed-off-by: Saket Dumbre <saket.dumbre@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-15ACPICA: dispatcher: Use acpi_ds_clear_operands() in ↵Hans de Goede
acpi_ds_call_control_method() When deleting the previous walkstate operand stack acpi_ds_call_control_method() was deleting obj_desc->Method.param_count operands. But Method.param_count does not necessarily match this_walk_state->num_operands, it may be either less or more. After correcting the for loop to check `i < this_walk_state->num_operands` the code is identical to acpi_ds_clear_operands(), so just outright replace the code with acpi_ds_clear_operands() to fix this. Link: https://github.com/acpica/acpica/commit/53fc0220 Signed-off-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-15ACPICA: Debugger: drop ACPI_NONSTRING attribute from name_segAhmed Salem
ACPICA commit 4623b3369f3aa1ec5229d461e91c514510a96912 Partially revert commit 70662db73d54 ("ACPICA: Apply ACPI_NONSTRING in more places") as I've yet again incorrectly applied the ACPI_NONSTRING attribute where it is not needed. A warning was initially reported by Collin Funk [1], and further review by Jiri Slaby [2] highlighted another issue related to the same commit. Drop the ACPI_NONSTRING attribute to fix the issue. Fixes: 70662db73d54 ("ACPICA: Apply ACPI_NONSTRING in more places") Link: https://lore.kernel.org/all/87ecvpcypw.fsf@gmail.com [1] Link: https://lore.kernel.org/all/5c210121-c9b8-4458-b1ad-0da24732ac72@kernel.org [2] Link: https://github.com/acpica/acpica/commit/4623b336 Reported-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Ahmed Salem <x0rw3ll@gmail.com> Cc: 6.16+ <stable@vger.kernel.org> # 6.16+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-15ACPICA: iASL: Fix printing CDAT table headerAhmed Salem
When disassembling CDAT AML, the lack of CDAT's common ACPI table header should be taken into consideration when printing the table's actual header. As the table header lacks fields like Signature, header information is mangled and incorrect: # $ iasl -d -ds CDAT cdat.aml # Input file cdat.aml, Length 0xE4 (228) bytes # ACPI: ? 0x0000000000000000 000C01 (v00 ? 00180000 ?? 23456789) Both Signature and Length are printed incorrectly, and the remaining fields are not applicable for this special table. To fix this, verify acpi_gbl_CDAT is set (<-ds CDAT> via command line) and Header->Signature is an invalid nameseg (due to the presence of non-ASCII char(s)), then print only the explicitly-passed signature (ACPI_SIG_CDAT) and the table length as cast with a pointer to the struct acpi_table_cdat structure. Link: https://github.com/acpica/acpica/commit/2b5586b4 Signed-off-by: Ahmed Salem <x0rw3ll@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-15ACPICA: Allow to skip Global Lock initializationHuacai Chen
Introduce acpi_gbl_use_global_lock, which allows to skip the Global Lock initialization. This is useful for systems without Global Lock (such as loong_arch), so as to avoid error messages during boot phase: ACPI Error: Could not enable global_lock event (20240827/evxfevnt-182) ACPI Error: No response from Global Lock hardware, disabling lock (20240827/evglock-59) Link: https://github.com/acpica/acpica/commit/463cb0fe Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-15ACPICA: Change the compilation conditionsZhe Qiao
To prevent the risk of undefined variables. Link: https://github.com/acpica/acpica/commit/9f86d4c9 Signed-off-by: Zhe Qiao <qiaozhe@iscas.ac.cn> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-15ACPICA: Remove redundant "#ifdef" definitionsZhe Qiao
Link: https://github.com/acpica/acpica/commit/204776a3 Signed-off-by: Zhe Qiao <qiaozhe@iscas.ac.cn> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-15ACPICA: Modify variable definition positionZhe Qiao
To prevent potential undefined risks. Link: https://github.com/acpica/acpica/commit/efc4d8ab Signed-off-by: Zhe Qiao <qiaozhe@iscas.ac.cn> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-06-26ACPICA: Decrease `AcpiExTracePoint` verbosityMario Limonciello
Early in kernel boot pointers can't be used and so %p shows up incorrectly: ``` extrace-0138 ex_trace_point : Method Begin [0x(____ptrval____):\M460] execution. ``` Later in the boot %p works, but it's not really actually useful when the pathname can resolve properly. Adjust the debug print so that if the Pathname resolves that the pointer isn't also printed: ``` extrace-0138 ex_trace_point : Method Begin [\M460] execution. ``` Link: https://github.com/acpica/acpica/pull/1013 Link: https://github.com/acpica/acpica/commit/bdc2a4e646f097b693aa60f1f2c4228d1e31b0d1 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/20250609032839.525087-1-superm1@kernel.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-06-18ACPICA: Refuse to evaluate a method if arguments are missingRafael J. Wysocki
As reported in [1], a platform firmware update that increased the number of method parameters and forgot to update a least one of its callers, caused ACPICA to crash due to use-after-free. Since this a result of a clear AML issue that arguably cannot be fixed up by the interpreter (it cannot produce missing data out of thin air), address it by making ACPICA refuse to evaluate a method if the caller attempts to pass fewer arguments than expected to it. Closes: https://github.com/acpica/acpica/issues/1027 [1] Reported-by: Peter Williams <peter@newton.cx> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hans de Goede <hansg@kernel.org> Tested-by: Hans de Goede <hansg@kernel.org> # Dell XPS 9640 with BIOS 1.12.0 Link: https://patch.msgid.link/5909446.DvuYhMxLoT@rjwysocki.net Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-05-29ACPICA: Switch back to using strncpy() in acpi_ut_safe_strncpy()Ahmed Salem
ACPICA commit b90d0d65ec97ff8279ad826f4102e0d31c5f662a I mistakenly replaced strncpy() with memcpy() in commit ebf27765421c ("ACPICA: Replace strncpy() with memcpy()"), not realizing the entire context behind *why* strncpy() was used. In this safer implementation of strncpy(), it does not make sense to use memcpy() only to null-terminate strings passed to acpi_ut_safe_strncpy() one byte early. The consequences of doing so are understandably *bad*, as was evident by the kernel test bot reporting problems [1]. Fixes: ebf27765421c ("ACPICA: Replace strncpy() with memcpy()") Link: https://lore.kernel.org/all/202505081033.50e45ff4-lkp@intel.com [1] Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202505081033.50e45ff4-lkp@intel.com Link: https://github.com/acpica/acpica/commit/b90d0d65 Signed-off-by: Ahmed Salem <x0rw3ll@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/12685690.O9o76ZdvQC@rjwysocki.net
2025-05-12ACPICA: Update copyright yearSaket Dumbre
ACPICA commit 45253be18b3f37d46cd0072aa3f8a0a21a70e0a4 Changes needed by acpisrc to update copyright year when building for release. Link: https://github.com/acpica/acpica/commit/45253be1 Signed-off-by: Saket Dumbre <saket.dumbre@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-05-12ACPICA: Replace strncpy() with memcpy()Ahmed Salem
ACPICA commit 83019b471e1902151e67c588014ba2d09fa099a3 strncpy() is deprecated for NUL-terminated destination buffers[1]. Use memcpy() for length-bounded destinations. Link: https://github.com/KSPP/linux/issues/90 [1] Link: https://github.com/acpica/acpica/commit/83019b47 Signed-off-by: Ahmed Salem <x0rw3ll@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/1910878.atdPhlSkOF@rjwysocki.net
2025-05-12ACPICA: Apply ACPI_NONSTRING in more placesAhmed Salem
ACPICA commit 1035a3d453f7dd49a235a59ee84ebda9d2d2f41b Add ACPI_NONSTRING for destination char arrays without a terminating NUL character. This is a follow-up to commit 35ad99236f3a ("ACPICA: Apply ACPI_NONSTRING") where not all instances received the same treatment, in preparation for replacing strncpy() calls with memcpy() Link: https://github.com/acpica/acpica/commit/1035a3d4 Signed-off-by: Ahmed Salem <x0rw3ll@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/3833065.MHq7AAxBmi@rjwysocki.net
2025-05-12ACPICA: Adjust the position of code linesZhe Qiao
ACPICA commit 5da6daf5691169d2bf2e5c9e55baf093757312ca In the acpica/utcache.c file, adjust the position of the "ACPI_MEM_TRACKING(cache->total_allocated++);" code line to ensure that the increment operation on total_allocated is included within the ACPI_DBG_TRACK_ALLOCATIONS configuration. Link: https://github.com/acpica/acpica/commit/5da6daf5 Signed-off-by: Zhe Qiao <qiaozhe@iscas.ac.cn> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2670567.Lt9SDvczpP@rjwysocki.net
2025-05-12ACPICA: Apply ACPI_NONSTRINGKees Cook
ACPICA commit ed68cb8e082e3bfbba02814af4fd5a61247f491b Add ACPI_NONSTRING annotations for places found that are using char arrays without a terminating NUL character. These were found during Linux kernel builds and after looking for instances of arrays of size ACPI_NAMESEG_SIZE. Link: https://github.com/acpica/acpica/commit/ed68cb8e Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2039736.usQuhbGJ8B@rjwysocki.net
2025-05-12ACPICA: Utilities: Fix spelling mistake "Incremement" -> "Increment"Colin Ian King
ACPICA commit 0faa6e20cfe56fdaefc37a38f8fd04e3137fcdad There is a spelling mistake in a literal string. Fix it. Fixes: ff5340f8ac94 ("ACPICA: Reference count: add additional debugging details") Link: https://github.com/acpica/acpica/commit/0faa6e20 Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/7814589.EvYhyI6sBW@rjwysocki.net [ rjw: Fix up the Fixes: tag ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-05-12ACPICA: utilities: Fix overflow check in vsnprintf()gldrk
ACPICA commit d9d59b7918514ae55063b93f3ec041b1a569bf49 The old version breaks sprintf on 64-bit systems for buffers outside [0..UINT32_MAX]. Link: https://github.com/acpica/acpica/commit/d9d59b79 Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/4994935.GXAFRqVoOG@rjwysocki.net Signed-off-by: gldrk <me@rarity.fan> [ rjw: Added the tag from gldrk ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-05-06ACPICA: Apply pack(1) to union aml_resourceTamir Duberstein
ACPICA commit 1c28da2242783579d59767617121035dafba18c3 This was originally done in NetBSD: https://github.com/NetBSD/src/commit/b69d1ac3f7702f67edfe412e4392f77d09804910 and is the correct alternative to the smattering of `memcpy`s I previously contributed to this repository. This also sidesteps the newly strict checks added in UBSAN: https://github.com/llvm/llvm-project/commit/792674400f6f04a074a3827349ed0e2ac10067f6 Before this change we see the following UBSAN stack trace in Fuchsia: #0 0x000021afcfdeca5e in acpi_rs_get_address_common(struct acpi_resource*, union aml_resource*) ../../third_party/acpica/source/components/resources/rsaddr.c:329 <platform-bus-x86.so>+0x6aca5e #1.2 0x000021982bc4af3c in ubsan_get_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 <libclang_rt.asan.so>+0x41f3c #1.1 0x000021982bc4af3c in maybe_print_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 <libclang_rt.asan.so>+0x41f3c #1 0x000021982bc4af3c in ~scoped_report() compiler-rt/lib/ubsan/ubsan_diag.cpp:395 <libclang_rt.asan.so>+0x41f3c #2 0x000021982bc4bb6f in handletype_mismatch_impl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:137 <libclang_rt.asan.so>+0x42b6f #3 0x000021982bc4b723 in __ubsan_handle_type_mismatch_v1 compiler-rt/lib/ubsan/ubsan_handlers.cpp:142 <libclang_rt.asan.so>+0x42723 #4 0x000021afcfdeca5e in acpi_rs_get_address_common(struct acpi_resource*, union aml_resource*) ../../third_party/acpica/source/components/resources/rsaddr.c:329 <platform-bus-x86.so>+0x6aca5e #5 0x000021afcfdf2089 in acpi_rs_convert_aml_to_resource(struct acpi_resource*, union aml_resource*, struct acpi_rsconvert_info*) ../../third_party/acpica/source/components/resources/rsmisc.c:355 <platform-bus-x86.so>+0x6b2089 #6 0x000021afcfded169 in acpi_rs_convert_aml_to_resources(u8*, u32, u32, u8, void**) ../../third_party/acpica/source/components/resources/rslist.c:137 <platform-bus-x86.so>+0x6ad169 #7 0x000021afcfe2d24a in acpi_ut_walk_aml_resources(struct acpi_walk_state*, u8*, acpi_size, acpi_walk_aml_callback, void**) ../../third_party/acpica/source/components/utilities/utresrc.c:237 <platform-bus-x86.so>+0x6ed24a #8 0x000021afcfde66b7 in acpi_rs_create_resource_list(union acpi_operand_object*, struct acpi_buffer*) ../../third_party/acpica/source/components/resources/rscreate.c:199 <platform-bus-x86.so>+0x6a66b7 #9 0x000021afcfdf6979 in acpi_rs_get_method_data(acpi_handle, const char*, struct acpi_buffer*) ../../third_party/acpica/source/components/resources/rsutils.c:770 <platform-bus-x86.so>+0x6b6979 #10 0x000021afcfdf708f in acpi_walk_resources(acpi_handle, char*, acpi_walk_resource_callback, void*) ../../third_party/acpica/source/components/resources/rsxface.c:731 <platform-bus-x86.so>+0x6b708f #11 0x000021afcfa95dcf in acpi::acpi_impl::walk_resources(acpi::acpi_impl*, acpi_handle, const char*, acpi::Acpi::resources_callable) ../../src/devices/board/lib/acpi/acpi-impl.cc:41 <platform-bus-x86.so>+0x355dcf #12 0x000021afcfaa8278 in acpi::device_builder::gather_resources(acpi::device_builder*, acpi::Acpi*, fidl::any_arena&, acpi::Manager*, acpi::device_builder::gather_resources_callback) ../../src/devices/board/lib/acpi/device-builder.cc:84 <platform-bus-x86.so>+0x368278 #13 0x000021afcfbddb87 in acpi::Manager::configure_discovered_devices(acpi::Manager*) ../../src/devices/board/lib/acpi/manager.cc:75 <platform-bus-x86.so>+0x49db87 #14 0x000021afcf99091d in publish_acpi_devices(acpi::Manager*, zx_device_t*, zx_device_t*) ../../src/devices/board/drivers/x86/acpi-nswalk.cc:95 <platform-bus-x86.so>+0x25091d #15 0x000021afcf9c1d4e in x86::X86::do_init(x86::X86*) ../../src/devices/board/drivers/x86/x86.cc:60 <platform-bus-x86.so>+0x281d4e #16 0x000021afcf9e33ad in λ(x86::X86::ddk_init::(anon class)*) ../../src/devices/board/drivers/x86/x86.cc:77 <platform-bus-x86.so>+0x2a33ad #17 0x000021afcf9e313e in fit::internal::target<(lambda at../../src/devices/board/drivers/x86/x86.cc:76:19), false, false, std::__2::allocator<std::byte>, void>::invoke(void*) ../../sdk/lib/fit/include/lib/fit/internal/function.h:183 <platform-bus-x86.so>+0x2a313e #18 0x000021afcfbab4c7 in fit::internal::function_base<16UL, false, void(), std::__2::allocator<std::byte>>::invoke(const fit::internal::function_base<16UL, false, void (), std::__2::allocator<std::byte> >*) ../../sdk/lib/fit/include/lib/fit/internal/function.h:522 <platform-bus-x86.so>+0x46b4c7 #19 0x000021afcfbab342 in fit::function_impl<16UL, false, void(), std::__2::allocator<std::byte>>::operator()(const fit::function_impl<16UL, false, void (), std::__2::allocator<std::byte> >*) ../../sdk/lib/fit/include/lib/fit/function.h:315 <platform-bus-x86.so>+0x46b342 #20 0x000021afcfcd98c3 in async::internal::retained_task::Handler(async_dispatcher_t*, async_task_t*, zx_status_t) ../../sdk/lib/async/task.cc:24 <platform-bus-x86.so>+0x5998c3 #21 0x00002290f9924616 in λ(const driver_runtime::Dispatcher::post_task::(anon class)*, std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request> >, zx_status_t) ../../src/devices/bin/driver_runtime/dispatcher.cc:789 <libdriver_runtime.so>+0x10a616 #22 0x00002290f9924323 in fit::internal::target<(lambda at../../src/devices/bin/driver_runtime/dispatcher.cc:788:7), true, false, std::__2::allocator<std::byte>, void, std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request>>, int>::invoke(void*, std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request> >, int) ../../sdk/lib/fit/include/lib/fit/internal/function.h:128 <libdriver_runtime.so>+0x10a323 #23 0x00002290f9904b76 in fit::internal::function_base<24UL, true, void(std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request>>, int), std::__2::allocator<std::byte>>::invoke(const fit::internal::function_base<24UL, true, void (std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request> >, int), std::__2::allocator<std::byte> >*, std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request> >, int) ../../sdk/lib/fit/include/lib/fit/internal/function.h:522 <libdriver_runtime.so>+0xeab76 #24 0x00002290f9904831 in fit::callback_impl<24UL, true, void(std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request>>, int), std::__2::allocator<std::byte>>::operator()(fit::callback_impl<24UL, true, void (std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request> >, int), std::__2::allocator<std::byte> >*, std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request> >, int) ../../sdk/lib/fit/include/lib/fit/function.h:471 <libdriver_runtime.so>+0xea831 #25 0x00002290f98d5adc in driver_runtime::callback_request::Call(driver_runtime::callback_request*, std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request> >, zx_status_t) ../../src/devices/bin/driver_runtime/callback_request.h:74 <libdriver_runtime.so>+0xbbadc #26 0x00002290f98e1e58 in driver_runtime::Dispatcher::dispatch_callback(driver_runtime::Dispatcher*, std::__2::unique_ptr<driver_runtime::callback_request, std::__2::default_delete<driver_runtime::callback_request> >) ../../src/devices/bin/driver_runtime/dispatcher.cc:1248 <libdriver_runtime.so>+0xc7e58 #27 0x00002290f98e4159 in driver_runtime::Dispatcher::dispatch_callbacks(driver_runtime::Dispatcher*, std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter> >, fbl::ref_ptr<driver_runtime::Dispatcher>) ../../src/devices/bin/driver_runtime/dispatcher.cc:1308 <libdriver_runtime.so>+0xca159 #28 0x00002290f9918414 in λ(const driver_runtime::Dispatcher::create_with_adder::(anon class)*, std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter> >, fbl::ref_ptr<driver_runtime::Dispatcher>) ../../src/devices/bin/driver_runtime/dispatcher.cc:353 <libdriver_runtime.so>+0xfe414 #29 0x00002290f991812d in fit::internal::target<(lambda at../../src/devices/bin/driver_runtime/dispatcher.cc:351:7), true, false, std::__2::allocator<std::byte>, void, std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter>>, fbl::ref_ptr<driver_runtime::Dispatcher>>::invoke(void*, std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter> >, fbl::ref_ptr<driver_runtime::Dispatcher>) ../../sdk/lib/fit/include/lib/fit/internal/function.h:128 <libdriver_runtime.so>+0xfe12d #30 0x00002290f9906fc7 in fit::internal::function_base<8UL, true, void(std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter>>, fbl::ref_ptr<driver_runtime::Dispatcher>), std::__2::allocator<std::byte>>::invoke(const fit::internal::function_base<8UL, true, void (std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter> >, fbl::ref_ptr<driver_runtime::Dispatcher>), std::__2::allocator<std::byte> >*, std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter> >, fbl::ref_ptr<driver_runtime::Dispatcher>) ../../sdk/lib/fit/include/lib/fit/internal/function.h:522 <libdriver_runtime.so>+0xecfc7 #31 0x00002290f9906c66 in fit::function_impl<8UL, true, void(std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter>>, fbl::ref_ptr<driver_runtime::Dispatcher>), std::__2::allocator<std::byte>>::operator()(const fit::function_impl<8UL, true, void (std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter> >, fbl::ref_ptr<driver_runtime::Dispatcher>), std::__2::allocator<std::byte> >*, std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter> >, fbl::ref_ptr<driver_runtime::Dispatcher>) ../../sdk/lib/fit/include/lib/fit/function.h:315 <libdriver_runtime.so>+0xecc66 #32 0x00002290f98e73d9 in driver_runtime::Dispatcher::event_waiter::invoke_callback(driver_runtime::Dispatcher::event_waiter*, std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter> >, fbl::ref_ptr<driver_runtime::Dispatcher>) ../../src/devices/bin/driver_runtime/dispatcher.h:543 <libdriver_runtime.so>+0xcd3d9 #33 0x00002290f98e700d in driver_runtime::Dispatcher::event_waiter::handle_event(std::__2::unique_ptr<driver_runtime::Dispatcher::event_waiter, std::__2::default_delete<driver_runtime::Dispatcher::event_waiter> >, async_dispatcher_t*, async::wait_base*, zx_status_t, zx_packet_signal_t const*) ../../src/devices/bin/driver_runtime/dispatcher.cc:1442 <libdriver_runtime.so>+0xcd00d #34 0x00002290f9918983 in async_loop_owned_event_handler<driver_runtime::Dispatcher::event_waiter>::handle_event(async_loop_owned_event_handler<driver_runtime::Dispatcher::event_waiter>*, async_dispatcher_t*, async::wait_base*, zx_status_t, zx_packet_signal_t const*) ../../src/devices/bin/driver_runtime/async_loop_owned_event_handler.h:59 <libdriver_runtime.so>+0xfe983 #35 0x00002290f9918b9e in async::wait_method<async_loop_owned_event_handler<driver_runtime::Dispatcher::event_waiter>, &async_loop_owned_event_handler<driver_runtime::Dispatcher::event_waiter>::handle_event>::call_handler(async_dispatcher_t*, async_wait_t*, zx_status_t, zx_packet_signal_t const*) ../../sdk/lib/async/include/lib/async/cpp/wait.h:201 <libdriver_runtime.so>+0xfeb9e #36 0x00002290f99bf509 in async_loop_dispatch_wait(async_loop_t*, async_wait_t*, zx_status_t, zx_packet_signal_t const*) ../../sdk/lib/async-loop/loop.c:394 <libdriver_runtime.so>+0x1a5509 #37 0x00002290f99b9958 in async_loop_run_once(async_loop_t*, zx_time_t) ../../sdk/lib/async-loop/loop.c:343 <libdriver_runtime.so>+0x19f958 #38 0x00002290f99b9247 in async_loop_run(async_loop_t*, zx_time_t, _Bool) ../../sdk/lib/async-loop/loop.c:301 <libdriver_runtime.so>+0x19f247 #39 0x00002290f99ba962 in async_loop_run_thread(void*) ../../sdk/lib/async-loop/loop.c:860 <libdriver_runtime.so>+0x1a0962 #40 0x000041afd176ef30 in start_c11(void*) ../../zircon/third_party/ulib/musl/pthread/pthread_create.c:63 <libc.so>+0x84f30 #41 0x000041afd18a448d in thread_trampoline(uintptr_t, uintptr_t) ../../zircon/system/ulib/runtime/thread.cc:100 <libc.so>+0x1ba48d Link: https://github.com/acpica/acpica/commit/1c28da22 Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/4664267.LvFx2qVVIh@rjwysocki.net Signed-off-by: Tamir Duberstein <tamird@gmail.com> [ rjw: Pick up the tag from Tamir ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-04-25Merge back earlier ACPICA material for 6.16Rafael J. Wysocki
2025-04-24ACPICA: Add support for printing AML arguments when trace point enabledMario Limonciello
When debug level is set to `ACPI_LV_TRACE_POINT` method start and exit are emitted into the debug logs. This can be useful to understand call paths, however none of the arguments for the method calls are populated even when turning up other debug levels. This can be useful for BIOSes that contain debug strings to see those strings. When `ACPI_LV_TRACE_POINT` is set also output all of the arguments for a given method call. This enables this type of debugging: ``` extrace-0138 ex_trace_point : Method Begin [0x0000000096b240c4:\M460] execution. extrace-0173 ex_trace_args : " POST CODE: %X ACPI TIMER: %X TIME: %d.%d ms\n", b0003f53, 1a26a8b2, 0, 15e, 0, 0 extrace-0138 ex_trace_point : Method End [0x0000000096b240c4:\M460] execution. ``` Link: https://github.com/acpica/acpica/commit/08219d91b5678ae2fae6e4f208df790a4e108c1c Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/20250417031040.514460-1-superm1@kernel.org Link: https://github.com/acpica/acpica/pull/1012 Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-04-20gcc-15: acpi: sprinkle random '__nonstring' crumbles aroundLinus Torvalds
This is not great: I'd much rather introduce a typedef that is a "ACPI name byte buffer", and use that to mark these special 4-byte ACPI names that do not use NUL termination. But as noted in the previous commit ("gcc-15: make 'unterminated string initialization' just a warning") gcc doesn't actually seem to support that notion, so instead you have to just mark every single array declaration individually. So this is not pretty, but this gets rid of the bulk of the annoying warnings during an allmodconfig build for me. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2025-04-09ACPICA: exserial: don't forget to handle FFixedHW opregions for readingDaniil Tatianin
The initial commit that introduced support for FFixedHW operation regions did add a special case in the AcpiExReadSerialBus If, but forgot to actually handle it inside the switch, so add the missing case to prevent reads from failing with AE_AML_INVALID_SPACE_ID. Link: https://github.com/acpica/acpica/pull/998 Fixes: ee64b827a9a ("ACPICA: Add support for FFH Opregion special context data") Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Link: https://patch.msgid.link/20250401184312.599962-1-d-tatianin@yandex-team.ru Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-03-27ACPICA: Fix warnings from PR #295 mergeSaket Dumbre
Possible loss of data from u32 to u8 conversions. ACPICA commit 1d7a0aa04793ff731da13f2070877ec7a9498571 Link: https://github.com/acpica/acpica/commit/1d7a0aa0 Signed-off-by: Saket Dumbre <saket.dumbre@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2304653.iZASKD2KPV@rjwysocki.net
2025-03-27ACPICA: fix acpi parse and parseext cache leaksSeunghun Han
ACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5 I'm Seunghun Han, and I work for National Security Research Institute of South Korea. I have been doing a research on ACPI and found an ACPI cache leak in ACPI early abort cases. Boot log of ACPI cache leak is as follows: [ 0.352414] ACPI: Added _OSI(Module Device) [ 0.353182] ACPI: Added _OSI(Processor Device) [ 0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.353182] ACPI: Added _OSI(Processor Aggregator Device) [ 0.356028] ACPI: Unable to start the ACPI Interpreter [ 0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects [ 0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #10 [ 0.361273] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.361873] Call Trace: [ 0.362243] ? dump_stack+0x5c/0x81 [ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.362944] ? acpi_sleep_proc_init+0x27/0x27 [ 0.363296] ? acpi_os_delete_cache+0xa/0x10 [ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.364000] ? acpi_terminate+0xa/0x14 [ 0.364000] ? acpi_init+0x2af/0x34f [ 0.364000] ? __class_create+0x4c/0x80 [ 0.364000] ? video_setup+0x7f/0x7f [ 0.364000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.364000] ? do_one_initcall+0x4e/0x1a0 [ 0.364000] ? kernel_init_freeable+0x189/0x20a [ 0.364000] ? rest_init+0xc0/0xc0 [ 0.364000] ? kernel_init+0xa/0x100 [ 0.364000] ? ret_from_fork+0x25/0x30 I analyzed this memory leak in detail. I found that “Acpi-State” cache and “Acpi-Parse” cache were merged because the size of cache objects was same slab cache size. I finally found “Acpi-Parse” cache and “Acpi-parse_ext” cache were leaked using SLAB_NEVER_MERGE flag in kmem_cache_create() function. Real ACPI cache leak point is as follows: [ 0.360101] ACPI: Added _OSI(Module Device) [ 0.360101] ACPI: Added _OSI(Processor Device) [ 0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.361043] ACPI: Added _OSI(Processor Aggregator Device) [ 0.364016] ACPI: Unable to start the ACPI Interpreter [ 0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects [ 0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.371256] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.372000] Call Trace: [ 0.372000] ? dump_stack+0x5c/0x81 [ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? acpi_os_delete_cache+0xa/0x10 [ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b [ 0.372000] ? acpi_terminate+0xa/0x14 [ 0.372000] ? acpi_init+0x2af/0x34f [ 0.372000] ? __class_create+0x4c/0x80 [ 0.372000] ? video_setup+0x7f/0x7f [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? do_one_initcall+0x4e/0x1a0 [ 0.372000] ? kernel_init_freeable+0x189/0x20a [ 0.372000] ? rest_init+0xc0/0xc0 [ 0.372000] ? kernel_init+0xa/0x100 [ 0.372000] ? ret_from_fork+0x25/0x30 [ 0.388039] kmem_cache_destroy Acpi-parse_ext: Slab cache still has objects [ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.390557] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.392000] Call Trace: [ 0.392000] ? dump_stack+0x5c/0x81 [ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.392000] ? acpi_os_delete_cache+0xa/0x10 [ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.392000] ? acpi_terminate+0xa/0x14 [ 0.392000] ? acpi_init+0x2af/0x34f [ 0.392000] ? __class_create+0x4c/0x80 [ 0.392000] ? video_setup+0x7f/0x7f [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.392000] ? do_one_initcall+0x4e/0x1a0 [ 0.392000] ? kernel_init_freeable+0x189/0x20a [ 0.392000] ? rest_init+0xc0/0xc0 [ 0.392000] ? kernel_init+0xa/0x100 [ 0.392000] ? ret_from_fork+0x25/0x30 When early abort is occurred due to invalid ACPI information, Linux kernel terminates ACPI by calling acpi_terminate() function. The function calls acpi_ut_delete_caches() function to delete local caches (acpi_gbl_namespace_ cache, state_cache, operand_cache, ps_node_cache, ps_node_ext_cache). But the deletion codes in acpi_ut_delete_caches() function only delete slab caches using kmem_cache_destroy() function, therefore the cache objects should be flushed before acpi_ut_delete_caches() function. "Acpi-Parse" cache and "Acpi-ParseExt" cache are used in an AML parse function, acpi_ps_parse_loop(). The function should complete all ops using acpi_ps_complete_final_op() when an error occurs due to invalid AML codes. However, the current implementation of acpi_ps_complete_final_op() does not complete all ops when it meets some errors and this cause cache leak. This cache leak has a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. To fix ACPI cache leak for enhancing security, I made a patch to complete all ops unconditionally for acpi_ps_complete_final_op() function. I hope that this patch improves the security of Linux kernel. Thank you. Link: https://github.com/acpica/acpica/commit/8829e70e Signed-off-by: Seunghun Han <kkamagui@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2363774.ElGaqSPkdT@rjwysocki.net
2025-03-27ACPICA: fix acpi operand cache leak in dswstate.cSeunghun Han
ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak. Link: https://github.com/acpica/acpica/commit/987a3b5c Signed-off-by: Seunghun Han <kkamagui@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/4999480.31r3eYUQgx@rjwysocki.net
2025-01-26LoongArch: Fix warnings during S3 suspendHuacai Chen
The enable_gpe_wakeup() function calls acpi_enable_all_wakeup_gpes(), and the later one may call the preempt_schedule_common() function, resulting in a thread switch and causing the CPU to be in an interrupt enabled state after the enable_gpe_wakeup() function returns, leading to the warnings as follow. [ C0] WARNING: ... at kernel/time/timekeeping.c:845 ktime_get+0xbc/0xc8 [ C0] ... [ C0] Call Trace: [ C0] [<90000000002243b4>] show_stack+0x64/0x188 [ C0] [<900000000164673c>] dump_stack_lvl+0x60/0x88 [ C0] [<90000000002687e4>] __warn+0x8c/0x148 [ C0] [<90000000015e9978>] report_bug+0x1c0/0x2b0 [ C0] [<90000000016478e4>] do_bp+0x204/0x3b8 [ C0] [<90000000025b1924>] exception_handlers+0x1924/0x10000 [ C0] [<9000000000343bbc>] ktime_get+0xbc/0xc8 [ C0] [<9000000000354c08>] tick_sched_timer+0x30/0xb0 [ C0] [<90000000003408e0>] __hrtimer_run_queues+0x160/0x378 [ C0] [<9000000000341f14>] hrtimer_interrupt+0x144/0x388 [ C0] [<9000000000228348>] constant_timer_interrupt+0x38/0x48 [ C0] [<90000000002feba4>] __handle_irq_event_percpu+0x64/0x1e8 [ C0] [<90000000002fed48>] handle_irq_event_percpu+0x20/0x80 [ C0] [<9000000000306b9c>] handle_percpu_irq+0x5c/0x98 [ C0] [<90000000002fd4a0>] generic_handle_domain_irq+0x30/0x48 [ C0] [<9000000000d0c7b0>] handle_cpu_irq+0x70/0xa8 [ C0] [<9000000001646b30>] handle_loongarch_irq+0x30/0x48 [ C0] [<9000000001646bc8>] do_vint+0x80/0xe0 [ C0] [<90000000002aea1c>] finish_task_switch.isra.0+0x8c/0x2a8 [ C0] [<900000000164e34c>] __schedule+0x314/0xa48 [ C0] [<900000000164ead8>] schedule+0x58/0xf0 [ C0] [<9000000000294a2c>] worker_thread+0x224/0x498 [ C0] [<900000000029d2f0>] kthread+0xf8/0x108 [ C0] [<9000000000221f28>] ret_from_kernel_thread+0xc/0xa4 [ C0] [ C0] ---[ end trace 0000000000000000 ]--- The root cause is acpi_enable_all_wakeup_gpes() uses a mutex to protect acpi_hw_enable_all_wakeup_gpes(), and acpi_ut_acquire_mutex() may cause a thread switch. Since there is no longer concurrent execution during loongarch_acpi_suspend(), we can call acpi_hw_enable_all_wakeup_gpes() directly in enable_gpe_wakeup(). The solution is similar to commit 22db06337f590d01 ("ACPI: sleep: Avoid breaking S3 wakeup due to might_sleep()"). Fixes: 366bb35a8e48 ("LoongArch: Add suspend (ACPI S3) support") Signed-off-by: Qunqin Zhao <zhaoqunqin@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2024-12-12ACPICA: events/evxfregn: don't release the ContextMutex that was never acquiredDaniil Tatianin
This bug was first introduced in c27f3d011b08, where the author of the patch probably meant to do DeleteMutex instead of ReleaseMutex. The mutex leak was noticed later on and fixed in e4dfe108371, but the bogus MutexRelease line was never removed, so do it now. Link: https://github.com/acpica/acpica/pull/982 Fixes: c27f3d011b08 ("ACPICA: Fix race in generic_serial_bus (I2C) and GPIO op_region parameter handling") Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Link: https://patch.msgid.link/20241122082954.658356-1-d-tatianin@yandex-team.ru Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-09-11Merge branch 'acpica'Rafael J. Wysocki
Merge ACPICA updates for 6.12-rc1: - Check return value in acpi_db_convert_to_package() (Pei Xiao). - Detect FACS and allow setting the waking vector on reduced-hardware ACPI platforms (Jiaqing Zhao). - Allow ACPICA to represent semaphores as integers (Adrien Destugues). - Complete CXL 3.0 CXIMS structures support in ACPICA (Zhang Rui). - Make ACPICA support SPCR version 4 and add RISC-V SBI Subtype to DBG2 (Sia Jee Heng). - Implement the Dword_PCC Resource Descriptor Macro in ACPICA (Jose Marinho). - Correct the typo in struct acpi_mpam_msc_node member (Punit Agrawal). - Implement ACPI_WARNING_ONCE() and ACPI_ERROR_ONCE() and use them to prevent a Stall() violation warning from being printed every time this takes place (Vasily Khoruzhick). - Allow PCC Data Type in MCTP resource (Adam Young). - Fix memory leaks on acpi_ps_get_next_namepath() and acpi_ps_get_next_field() failures (Armin Wolf). - Add support for supressing leading zeros in hex strings when converting them to integers and update integer-to-hex-string conversions in ACPICA (Armin Wolf). - Add support for Windows 11 22H2 _OSI string (Armin Wolf). - Avoid warning for Dump Functions in ACPICA (Adam Lackorzynski). - Add extended linear address mode to HMAT MSCIS in ACPICA (Dave Jiang). - Handle empty connection_node in iasl (Aleksandrs Vinarskis). - Allow for more flexibility in _DSM args (Saket Dumbre). - Setup for ACPICA release 20240827 (Saket Dumbre). * acpica: (23 commits) ACPICA: Setup for ACPICA release 20240827 ACPICA: Allow for more flexibility in _DSM args ACPICA: iasl: handle empty connection_node ACPICA: HMAT: Add extended linear address mode to MSCIS ACPICA: Avoid warning for Dump Functions ACPICA: Add support for Windows 11 22H2 _OSI string ACPICA: Update integer-to-hex-string conversions ACPICA: Add support for supressing leading zeros in hex strings ACPICA: Allow for supressing leading zeros when using acpi_ex_convert_to_ascii() ACPICA: Fix memory leak if acpi_ps_get_next_field() fails ACPICA: Fix memory leak if acpi_ps_get_next_namepath() fails ACPICA: Allow PCC Data Type in MCTP resource. ACPICA: executer/exsystem: Don't nag user about every Stall() violating the spec ACPICA: Implement ACPI_WARNING_ONCE and ACPI_ERROR_ONCE ACPICA: MPAM: Correct the typo in struct acpi_mpam_msc_node member ACPICA: Implement the Dword_PCC Resource Descriptor Macro ACPICA: Headers: Add RISC-V SBI Subtype to DBG2 ACPICA: SPCR: Update the SPCR table to version 4 ACPICA: Complete CXL 3.0 CXIMS structures ACPICA: haiku: Fix invalid value used for semaphores ...
2024-08-29ACPICA: Allow for more flexibility in _DSM argsSaket Dumbre
ACPICA commit fbb651249ced5e19cc9c4452fec1408f595aa702 To eliminate annoying driver-side warnings. ASWG ECR to follow soon. Link: https://github.com/acpica/acpica/commit/fbb65124 Signed-off-by: Saket Dumbre <saket.dumbre@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-08-29ACPICA: iasl: handle empty connection_nodeAleksandrs Vinarskis
ACPICA commit 6c551e2c9487067d4b085333e7fe97e965a11625 Link: https://github.com/acpica/acpica/commit/6c551e2c Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-08-29ACPICA: Avoid warning for Dump FunctionsAdam Lackorzynski
ACPICA commit 6031b34b5dbabfaaebe80e57e8e415790b51d285 Only include the functions acpi_rs_dump_resource_list and acpi_rs_dump_irq_list() if ACPI_DEBUGGER is defined, as specified in the header. This avoids the compiler warning by adding the ifdef for ACPI_DEBUGGER. Link: https://github.com/acpica/acpica/commit/6031b34b Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-08-29ACPICA: Add support for Windows 11 22H2 _OSI stringArmin Wolf
ACPICA commit f56218c4e4dc1d1f699662d0726ad9e7a0d58548 See: https://github.com/microsoft_docs/windows-driver-docs/commit/be9d1c211adf8fabe5a43de71c034b1b6d7372de Link: https://github.com/acpica/acpica/commit/f56218c4 Signed-off-by: Armin Wolf <W_Armin@gmx.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-08-29ACPICA: Update integer-to-hex-string conversionsArmin Wolf
ACPICA commit f2cb44f6deb6325a6b348b225fc82f565a870899 Add "0x" prefix for explicitly converted integers and suppress leading zeros in such a case. Provides compatibility with other ACPI implementations. Link: https://github.com/acpica/acpica/commit/f2cb44f6 Signed-off-by: Armin Wolf <W_Armin@gmx.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-08-29ACPICA: Add support for supressing leading zeros in hex stringsArmin Wolf
ACPICA commit 86289439d9f8b9eda28c249da66ae230d6439491 Currently the leading_zeros argument has no effect when converting hex integers. Fix that. Link: https://github.com/acpica/acpica/commit/86289439 Signed-off-by: Armin Wolf <W_Armin@gmx.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-08-29ACPICA: Allow for supressing leading zeros when using acpi_ex_convert_to_ascii()Armin Wolf
ACPICA commit 792a337104ce2c1729d33d76241b42b3214aa60f Allow to specifiy wether leading zeros should be supressed ot not when using acpi_ex_convert_to_ascii(). Link: https://github.com/acpica/acpica/commit/792a3371 Signed-off-by: Armin Wolf <W_Armin@gmx.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-08-29ACPICA: Fix memory leak if acpi_ps_get_next_field() failsArmin Wolf
ACPICA commit 1280045754264841b119a5ede96cd005bc09b5a7 If acpi_ps_get_next_field() fails, the previously created field list needs to be properly disposed before returning the status code. Link: https://github.com/acpica/acpica/commit/12800457 Signed-off-by: Armin Wolf <W_Armin@gmx.de> [ rjw: Rename local variable to avoid compiler confusion ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-08-29ACPICA: Fix memory leak if acpi_ps_get_next_namepath() failsArmin Wolf
ACPICA commit 2802af722bbde7bf1a7ac68df68e179e2555d361 If acpi_ps_get_next_namepath() fails, the previously allocated union acpi_parse_object needs to be freed before returning the status code. The issue was first being reported on the Linux ACPI mailing list: Link: https://lore.kernel.org/linux-acpi/56f94776-484f-48c0-8855-dba8e6a7793b@yandex.ru/T/ Link: https://github.com/acpica/acpica/commit/2802af72 Signed-off-by: Armin Wolf <W_Armin@gmx.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-08-29ACPICA: Allow PCC Data Type in MCTP resource.Adam Young
ACPICA commit f0776a465cc2c20393bec534c16bdee4a78f7bb7 explicitly allow QWord address space description type to be 0xA to indicate it refers to a Platform Communication channel IAW ACPI_ECR_PCC_DESCRIPTORS_CF_V2 https://bugzilla.tianocore.org/show_bug.cgi?id=4594 An entity in a DSDT or in SSDTs that requires a platform communication channel table (PCCT) entry to communicate with a remote service will have a single value that is the index of the entry in the PCCT. This data type with have a resource_type value of 0xA. This value indicates that the type shares the same footprint as a Dword_space section. Link: https://github.com/acpica/acpica/commit/f0776a46 Signed-off-by: Adam Young <ayoung@amperecomputing.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-08-29ACPICA: executer/exsystem: Don't nag user about every Stall() violating the specVasily Khoruzhick
ACPICA commit 129b75516fc49fe1fd6b8c5798f86c13854630b3 Stop nagging user about every Stall() that violates the spec On my Dell XPS 15 7590 I get hundreds of these warnings after few hours of uptime: $ dmesg | grep "fix the firmware" | wc -l 261 I cannot fix the firmware and I doubt that Dell cares about 4 year old laptop either Fixes: ace8f1c54a02 ("ACPICA: executer/exsystem: Inform users about ACPI spec violation") Link: https://github.com/acpica/acpica/commit/129b7551 Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-08-29ACPICA: Implement the Dword_PCC Resource Descriptor MacroJose Marinho
ACPICA commit 1209ecf682e03d9ef0c22f4986a2e53b03bd2985 The Dword_pcc (alongside word_pcc and Qword_pcc) were accepted to ACPI inclusion via a code-first process. This patch implements support in iASL for Dword_pcc. Link: https://bugzilla.tianocore.org/show_bug.cgi?id=4594 Link: https://github.com/acpica/acpica/commit/1209ecf6 Signed-off-by: Jose Marinho <jose.marinho@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-08-29ACPICA: haiku: Fix invalid value used for semaphoresAdrien Destugues
ACPICA commit 49fe4f25483feec2f685b204ef19e28d92979e95 In Haiku, semaphores are represented by integers, not pointers. So, we can't use NULL as the invalid/destroyed value, the correct value is -1. Introduce a platform overridable define to allow this. Fixes #162 (which was closed after coming to the conclusion that this should be done, but the change was never done). Link: https://github.com/acpica/acpica/commit/49fe4f25 Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-08-29ACPICA: Allow setting waking vector on reduced hardware platformsJiaqing Zhao
Allow setting waking vector in FACS table on reduced hardware platforms to support S3 wakeup. Link: https://github.com/acpica/acpica/commit/ee53ed6b5452612bb44af542b68d605f8b2b1104 Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com> Link: https://patch.msgid.link/20240827025821.2099068-3-jiaqing.zhao@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-08-29ACPICA: Detect FACS in reduced hardware buildJiaqing Zhao
According to Section 5.2.10 of ACPI Specification, FACS is optional in reduced hardware model. Enable the detection for "Hardware-reduced ACPI support only" build (CONFIG_ACPI_REDUCED_HARDWARE_ONLY=y) also. Link: https://github.com/acpica/acpica/commit/ee53ed6b5452612bb44af542b68d605f8b2b1104 Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com> Link: https://patch.msgid.link/20240827025821.2099068-2-jiaqing.zhao@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-08-13ACPICA: Add a depth argument to acpi_execute_reg_methods()Rafael J. Wysocki
A subsequent change will need to pass a depth argument to acpi_execute_reg_methods(), so prepare that function for it. No intentional functional changes. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Cc: All applicable <stable@vger.kernel.org> Link: https://patch.msgid.link/8451567.NyiUUSuA9g@rjwysocki.net
2024-08-13Revert "ACPI: EC: Evaluate orphan _REG under EC device"Rafael J. Wysocki
This reverts commit 0e6b6dedf168 ("Revert "ACPI: EC: Evaluate orphan _REG under EC device") because the problem addressed by it will be addressed differently in what follows. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Cc: All applicable <stable@vger.kernel.org> Link: https://patch.msgid.link/3236716.5fSG56mABF@rjwysocki.net
2024-08-02ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in ↵Pei Xiao
acpi_db_convert_to_package() ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause NULL pointer dereference later. Link: https://github.com/acpica/acpica/commit/4d4547cf Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Link: https://patch.msgid.link/tencent_4A21A2865B8B0A0D12CAEBEB84708EDDB505@qq.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
generated by cgit v1.2.3 (git 2.0.4) at 2025-10-16 11:40:15 +0000