linux.git/include/acpi/platform, branch v6.12.80 Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git ACPICA: haiku: Fix invalid value used for semaphores 2024-08-29T15:26:51+00:00 Adrien Destugues adrien.destugues@opensource.viveris.fr 2023-12-12T11:28:17+00:00 7afea7bc49c5482ac11fc4488230827edc51e28a 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> 
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>
mm: add comments for allocation helpers explaining why they are macros 2024-07-12T22:52:20+00:00 Suren Baghdasaryan surenb@google.com 2024-07-03T17:42:25+00:00 3b0ba54d5f8ff60553c01d3ec3c607ab7bb3b452 A number of allocation helper functions were converted into macros to account them at the call sites. Add a comment for each converted allocation helper explaining why it has to be a macro and why we typecast the return value wherever required. The patch also moves acpi_os_acquire_object() closer to other allocation helpers to group them together under the same comment. The patch has no functional changes. Link: https://lkml.kernel.org/r/20240703174225.3891393-1-surenb@google.com Fixes: 2c321f3f70bc ("mm: change inlined allocation helpers to account at the call site") Signed-off-by: Suren Baghdasaryan <surenb@google.com> Suggested-by: Andrew Morton <akpm@linux-foundation.org> Cc: Christian König <christian.koenig@amd.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Jan Kara <jack@suse.cz> Cc: Kent Overstreet <kent.overstreet@linux.dev> Cc: Thorsten Blum <thorsten.blum@toblux.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> 
A number of allocation helper functions were converted into macros to
account them at the call sites.  Add a comment for each converted
allocation helper explaining why it has to be a macro and why we typecast
the return value wherever required.  The patch also moves
acpi_os_acquire_object() closer to other allocation helpers to group them
together under the same comment.  The patch has no functional changes.

Link: https://lkml.kernel.org/r/20240703174225.3891393-1-surenb@google.com
Fixes: 2c321f3f70bc ("mm: change inlined allocation helpers to account at the call site")
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Suggested-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Christian König <christian.koenig@amd.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Jan Kara <jack@suse.cz>
Cc: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Thorsten Blum <thorsten.blum@toblux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
mm: change inlined allocation helpers to account at the call site 2024-04-26T03:55:59+00:00 Suren Baghdasaryan surenb@google.com 2024-04-15T02:07:31+00:00 2c321f3f70bc284510598f712b702ce8d60c4d14 Main goal of memory allocation profiling patchset is to provide accounting that is cheap enough to run in production. To achieve that we inject counters using codetags at the allocation call sites to account every time allocation is made. This injection allows us to perform accounting efficiently because injected counters are immediately available as opposed to the alternative methods, such as using _RET_IP_, which would require counter lookup and appropriate locking that makes accounting much more expensive. This method requires all allocation functions to inject separate counters at their call sites so that their callers can be individually accounted. Counter injection is implemented by allocation hooks which should wrap all allocation functions. Inlined functions which perform allocations but do not use allocation hooks are directly charged for the allocations they perform. In most cases these functions are just specialized allocation wrappers used from multiple places to allocate objects of a specific type. It would be more useful to do the accounting at their call sites instead. Instrument these helpers to do accounting at the call site. Simple inlined allocation wrappers are converted directly into macros. More complex allocators or allocators with documentation are converted into _noprof versions and allocation hooks are added. This allows memory allocation profiling mechanism to charge allocations to the callers of these functions. Link: https://lkml.kernel.org/r/20240415020731.1152108-1-surenb@google.com Signed-off-by: Suren Baghdasaryan <surenb@google.com> Acked-by: Jan Kara <jack@suse.cz> [jbd2] Cc: Anna Schumaker <anna@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: Christoph Lameter <cl@linux.com> Cc: David Rientjes <rientjes@google.com> Cc: David S. Miller <davem@davemloft.net> Cc: Dennis Zhou <dennis@kernel.org> Cc: Eric Dumazet <edumazet@google.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Jakub Sitnicki <jakub@cloudflare.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: Joerg Roedel <joro@8bytes.org> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Kent Overstreet <kent.overstreet@linux.dev> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: Tejun Heo <tj@kernel.org> Cc: Theodore Ts'o <tytso@mit.edu> Cc: Trond Myklebust <trond.myklebust@hammerspace.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> 
Main goal of memory allocation profiling patchset is to provide accounting
that is cheap enough to run in production.  To achieve that we inject
counters using codetags at the allocation call sites to account every time
allocation is made.  This injection allows us to perform accounting
efficiently because injected counters are immediately available as opposed
to the alternative methods, such as using _RET_IP_, which would require
counter lookup and appropriate locking that makes accounting much more
expensive.  This method requires all allocation functions to inject
separate counters at their call sites so that their callers can be
individually accounted.  Counter injection is implemented by allocation
hooks which should wrap all allocation functions.

Inlined functions which perform allocations but do not use allocation
hooks are directly charged for the allocations they perform.  In most
cases these functions are just specialized allocation wrappers used from
multiple places to allocate objects of a specific type.  It would be more
useful to do the accounting at their call sites instead.  Instrument these
helpers to do accounting at the call site.  Simple inlined allocation
wrappers are converted directly into macros.  More complex allocators or
allocators with documentation are converted into _noprof versions and
allocation hooks are added.  This allows memory allocation profiling
mechanism to charge allocations to the callers of these functions.

Link: https://lkml.kernel.org/r/20240415020731.1152108-1-surenb@google.com
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Acked-by: Jan Kara <jack@suse.cz>		[jbd2]
Cc: Anna Schumaker <anna@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: David Rientjes <rientjes@google.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Dennis Zhou <dennis@kernel.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Jakub Sitnicki <jakub@cloudflare.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Trond Myklebust <trond.myklebust@hammerspace.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ACPICA: fix for conflict macro definition on zephyr interface 2023-07-10T13:21:04+00:00 Najumon B.A najumon.ba@intel.com 2023-04-27T01:32:10+00:00 9558c2a2425077d5c8c761c16a7bfad867a24f65 ACPICA commit c71a12dfc66593fa9730c62a519161c4a7fca9f6 remove SEEK_SET/SEEK_END duplicate macro on zephyr header which through error while run zephyr CI jobs. Link: https://github.com/acpica/acpica/commit/c71a12df Signed-off-by: Najumon B.A <najumon.ba@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
ACPICA commit c71a12dfc66593fa9730c62a519161c4a7fca9f6

remove SEEK_SET/SEEK_END duplicate macro on zephyr header which through
 error while run zephyr CI jobs.

Link: https://github.com/acpica/acpica/commit/c71a12df
Signed-off-by: Najumon B.A <najumon.ba@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA: Fix GCC 12 dangling-pointer warning 2023-07-10T13:21:03+00:00 Philip Prindeville philipp@redfish-solutions.com 2023-04-12T16:18:20+00:00 7c94858ec17dae9071fa3bdf6b005967b9f146f4 ACPICA commit aea0a5cfce262ce2ab16fd96d87c12cf5e756380 We're storing a persistent pointer to an ephemeral local variable which technically is a dangling pointer and the compiler is correct. However, since we never indirect the pointer, this is a safe operation and we can suppress the warning. Also, some C run-times (like MUSL) aren't including <stdint.h> indirectly so we must include it explicitly or we won't have the type definition for uintptr_t. Fixes issue #867. Link: https://github.com/acpica/acpica/commit/aea0a5cf Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
ACPICA commit aea0a5cfce262ce2ab16fd96d87c12cf5e756380

We're storing a persistent pointer to an ephemeral local variable
which technically is a dangling pointer and the compiler is correct.
However, since we never indirect the pointer, this is a safe
operation and we can suppress the warning.

Also, some C run-times (like MUSL) aren't including <stdint.h>
indirectly so we must include it explicitly or we won't have the
type definition for uintptr_t.

Fixes issue #867.

Link: https://github.com/acpica/acpica/commit/aea0a5cf
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA: add os specific support for Zephyr RTOS 2023-04-06T18:29:12+00:00 Najumon najumon.ba@intel.com 2023-04-05T13:59:00+00:00 beadd51f74f606105b558ec69bbbe2305066d0ea ACPICA commit 463d30f0a8edc5dccad20c2d189dc55111d51aae The acpica will be integrated as module into Zephyr project for enable acpi bus driver. This patch is for enable os specific support layer for Zephyr. Link: https://github.com/acpica/acpica/commit/463d30f0 Signed-off-by: Najumon <najumon.ba@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
ACPICA commit 463d30f0a8edc5dccad20c2d189dc55111d51aae

The acpica will be integrated as module into Zephyr project for
enable acpi bus driver. This patch is for enable os specific
support layer for Zephyr.

Link: https://github.com/acpica/acpica/commit/463d30f0
Signed-off-by: Najumon <najumon.ba@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA: Introduce ACPI_FLEX_ARRAY 2023-04-06T18:29:12+00:00 Kees Cook kees@outflux.net 2023-04-05T13:52:23+00:00 11132ad0176e9a6a847a9bfca77c39c2857cf85b ACPICA commit e73b227e8e475c20cc394f237ea35d592fdf9ec3 In order to enable using -fstrict-flex-arrays with GCC and Clang in the Linux kernel, each trailing dynamically sized array must be defined as proper C99 "flexible array members" (FAM). Unfortunately, ACPICA has a bunch of technical debt, dating back to before even the GNU extension of 0-length arrays, meaning the code base has many 1-element and 0-length arrays defined at the end of structures that should actually be FAMs. One limitation of the C99 FAM specification is the accidental requirement that they cannot be in unions or alone in structs. There is no real-world reason for this, though, and, actually, the existing GNU extension permits this for 0-length arrays (which get treated as FAMs). Add the ACPI_FLEX_ARRAY() helper macro to work around this requirement so that FAMs can be defined in unions or alone in structs. Since this behavior still depends on GNU extensions, keep the macro specific to GCC (and Clang) builds. In this way, MSVC will continue to use 0-length arrays (since it does not support the union work-around). When MSVC grows support for this in the future, the macro can be updated. Link: https://github.com/acpica/acpica/commit/e73b227e Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
ACPICA commit e73b227e8e475c20cc394f237ea35d592fdf9ec3

In order to enable using -fstrict-flex-arrays with GCC and Clang in the
Linux kernel, each trailing dynamically sized array must be defined as
proper C99 "flexible array members" (FAM). Unfortunately, ACPICA has a
bunch of technical debt, dating back to before even the GNU extension of
0-length arrays, meaning the code base has many 1-element and 0-length
arrays defined at the end of structures that should actually be FAMs.

One limitation of the C99 FAM specification is the accidental requirement
that they cannot be in unions or alone in structs. There is no real-world
reason for this, though, and, actually, the existing GNU extension
permits this for 0-length arrays (which get treated as FAMs).

Add the ACPI_FLEX_ARRAY() helper macro to work around this requirement
so that FAMs can be defined in unions or alone in structs. Since this
behavior still depends on GNU extensions, keep the macro specific to GCC
(and Clang) builds. In this way, MSVC will continue to use 0-length
arrays (since it does not support the union work-around). When MSVC
grows support for this in the future, the macro can be updated.

Link: https://github.com/acpica/acpica/commit/e73b227e
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA: Avoid undefined behavior: member access within null pointer 2023-04-06T18:29:11+00:00 Tamir Duberstein tamird@google.com 2023-04-05T13:43:28+00:00 4cf8a60602f724d07e0c8d4bb639dfd38b36aaa4 ACPICA commit 2411e11ef88f42b08f33c38ed9c0d40282780e8c 84449c1eef1c0d092b037dc4c2c60cec5d5cc6c4 fixed this for Linux kernel builds, but not Linux userspace builds. Before this change we see the following UBSAN stack trace in Fuchsia: ../../third_party/acpica/source/components/tables/tbfadt.c:536:39: runtime error: member access within null pointer of type 'struct acpi_table_fadt' (aka 'struct acpi_table_fadt') #0 0x564860b5ee9b in acpi_tb_convert_fadt ../../third_party/acpica/source/components/tables/tbfadt.c:536:39 #1 0x564860b5edb4 in acpi_tb_create_local_fadt ../../third_party/acpica/source/components/tables/tbfadt.c:461:5 #2 0x564860b5e5c6 in acpi_tb_parse_fadt ../../third_party/acpica/source/components/tables/tbfadt.c:371:5 #3 0x564860b5c485 in acpi_tb_parse_root_table ../../third_party/acpica/source/components/tables/tbutils.c:407:13 #4 0x564860b6401a in acpi_initialize_tables ../../third_party/acpica/source/components/tables/tbxface.c:160:14 #5 0x5648608fb417 in acpi_host_test::acpi_host_test::init_acpi_with_tables(char const*) ../../src/devices/board/tests/acpi-host-tests/acpi-host-test.cc:36:5 #6 0x5648608f9095 in acpi_host_test::acpi_host_test_device_is_child_of_scope_test_Test::test_body() ../../src/devices/board/tests/acpi-host-tests/acpi-host-test.cc:85:3 #7 0x564860c6007e in void testing::internal::handle_seh_exceptions_in_method_if_supported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) ../../third_party/googletest/src/googletest/src/gtest.cc:2609:10 #8 0x564860bbd5df in void testing::internal::handle_exceptions_in_method_if_supported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) ../../third_party/googletest/src/googletest/src/gtest.cc:2664:12 #9 0x564860bbd141 in testing::Test::Run() ../../third_party/googletest/src/googletest/src/gtest.cc:2684:5 #10 0x564860bbff0a in testing::test_info::Run() ../../third_party/googletest/src/googletest/src/gtest.cc:2864:11 #11 0x564860bc40f1 in testing::test_suite::Run() ../../third_party/googletest/src/googletest/src/gtest.cc:3023:30 #12 0x564860beba40 in testing::internal::unit_test_impl::run_all_tests() ../../third_party/googletest/src/googletest/src/gtest.cc:5882:44 #13 0x564860c7db6e in bool testing::internal::handle_seh_exceptions_in_method_if_supported<testing::internal::unit_test_impl, bool>(testing::internal::unit_test_impl*, bool (testing::internal::unit_test_impl::*)(), char const*) ../../third_party/googletest/src/googletest/src/gtest.cc:2609:10 #14 0x564860bea71f in bool testing::internal::handle_exceptions_in_method_if_supported<testing::internal::unit_test_impl, bool>(testing::internal::unit_test_impl*, bool (testing::internal::unit_test_impl::*)(), char const*) ../../third_party/googletest/src/googletest/src/gtest.cc:2664:12 #15 0x564860bea1c5 in testing::unit_test::Run() ../../third_party/googletest/src/googletest/src/gtest.cc:5456:10 #16 0x5648608fccc0 in RUN_ALL_TESTS() ../../third_party/googletest/src/googletest/include/gtest/gtest.h:2304:73 #17 0x5648608fcb7e in main ../../src/devices/board/tests/acpi-host-tests/acpi-host-test.cc:121:10 #18 0x7f6defa2d189 (/lib/x86_64-linux-gnu/libc.so.6+0x27189) (build_id: c4f6727c560b1c33527ff9e0ca0cef13a7db64d2) #19 0x7f6defa2d244 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x27244) (build_id: c4f6727c560b1c33527ff9e0ca0cef13a7db64d2) #20 0x56486082e598 (/usr/local/google/home/tamird/src/fuchsia/out/core.x64/host_x64/acpi-host-test-bin+0x359598) (build_id: 851423b0e664df6a) Link: https://github.com/acpica/acpica/commit/2411e11e Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
ACPICA commit 2411e11ef88f42b08f33c38ed9c0d40282780e8c

84449c1eef1c0d092b037dc4c2c60cec5d5cc6c4 fixed this for Linux kernel
builds, but not Linux userspace builds.

Before this change we see the following UBSAN stack trace in Fuchsia:

  ../../third_party/acpica/source/components/tables/tbfadt.c:536:39: runtime error: member access within null pointer of type 'struct acpi_table_fadt' (aka 'struct acpi_table_fadt')
      #0 0x564860b5ee9b in acpi_tb_convert_fadt ../../third_party/acpica/source/components/tables/tbfadt.c:536:39
      #1 0x564860b5edb4 in acpi_tb_create_local_fadt ../../third_party/acpica/source/components/tables/tbfadt.c:461:5
      #2 0x564860b5e5c6 in acpi_tb_parse_fadt ../../third_party/acpica/source/components/tables/tbfadt.c:371:5
      #3 0x564860b5c485 in acpi_tb_parse_root_table ../../third_party/acpica/source/components/tables/tbutils.c:407:13
      #4 0x564860b6401a in acpi_initialize_tables ../../third_party/acpica/source/components/tables/tbxface.c:160:14
      #5 0x5648608fb417 in acpi_host_test::acpi_host_test::init_acpi_with_tables(char const*) ../../src/devices/board/tests/acpi-host-tests/acpi-host-test.cc:36:5
      #6 0x5648608f9095 in acpi_host_test::acpi_host_test_device_is_child_of_scope_test_Test::test_body() ../../src/devices/board/tests/acpi-host-tests/acpi-host-test.cc:85:3
      #7 0x564860c6007e in void testing::internal::handle_seh_exceptions_in_method_if_supported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) ../../third_party/googletest/src/googletest/src/gtest.cc:2609:10
      #8 0x564860bbd5df in void testing::internal::handle_exceptions_in_method_if_supported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) ../../third_party/googletest/src/googletest/src/gtest.cc:2664:12 #9 0x564860bbd141 in testing::Test::Run() ../../third_party/googletest/src/googletest/src/gtest.cc:2684:5  #10 0x564860bbff0a in testing::test_info::Run() ../../third_party/googletest/src/googletest/src/gtest.cc:2864:11   #11 0x564860bc40f1 in testing::test_suite::Run() ../../third_party/googletest/src/googletest/src/gtest.cc:3023:30   #12 0x564860beba40 in testing::internal::unit_test_impl::run_all_tests() ../../third_party/googletest/src/googletest/src/gtest.cc:5882:44
      #13 0x564860c7db6e in bool testing::internal::handle_seh_exceptions_in_method_if_supported<testing::internal::unit_test_impl, bool>(testing::internal::unit_test_impl*, bool (testing::internal::unit_test_impl::*)(), char const*) ../../third_party/googletest/src/googletest/src/gtest.cc:2609:10
      #14 0x564860bea71f in bool testing::internal::handle_exceptions_in_method_if_supported<testing::internal::unit_test_impl, bool>(testing::internal::unit_test_impl*, bool (testing::internal::unit_test_impl::*)(), char const*) ../../third_party/googletest/src/googletest/src/gtest.cc:2664:12 #15 0x564860bea1c5 in testing::unit_test::Run() ../../third_party/googletest/src/googletest/src/gtest.cc:5456:10 #16 0x5648608fccc0 in RUN_ALL_TESTS() ../../third_party/googletest/src/googletest/include/gtest/gtest.h:2304:73 #17 0x5648608fcb7e in main ../../src/devices/board/tests/acpi-host-tests/acpi-host-test.cc:121:10 #18 0x7f6defa2d189  (/lib/x86_64-linux-gnu/libc.so.6+0x27189) (build_id: c4f6727c560b1c33527ff9e0ca0cef13a7db64d2)
      #19 0x7f6defa2d244 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x27244) (build_id: c4f6727c560b1c33527ff9e0ca0cef13a7db64d2)
      #20 0x56486082e598  (/usr/local/google/home/tamird/src/fuchsia/out/core.x64/host_x64/acpi-host-test-bin+0x359598) (build_id: 851423b0e664df6a)

Link: https://github.com/acpica/acpica/commit/2411e11e
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA: Update all copyrights/signons to 2023 2023-04-06T18:29:11+00:00 Bob Moore robert.moore@intel.com 2023-04-05T13:38:21+00:00 612c29328466bdc1454ce76959fc03a1e2f7087a ACPICA commit 25bddd1824b1e450829468a64bbdcb38074ba3d2 Copyright updates to 2023. Link: https://github.com/acpica/acpica/commit/25bddd18 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
ACPICA commit 25bddd1824b1e450829468a64bbdcb38074ba3d2

Copyright updates to 2023.

Link: https://github.com/acpica/acpica/commit/25bddd18
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA: Add support for 64 bit loong_arch compilation 2023-04-06T18:29:10+00:00 Huacai Chen chenhuacai@loongson.cn 2023-04-05T13:36:09+00:00 a47a0c2a1fe1e4975c7214e1efeabc68171dc5c5 ACPICA commit d809b69cf43c632c8fe5b42372a891216fdd9223 Add 64 bit loong_arch architecture by defining ACPI_MACHINE_WIDTH to 64. Useful for acpica tools and incorporating ACPICA into the Firmware Test Suite. Link: https://github.com/acpica/acpica/commit/d809b69c Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
ACPICA commit d809b69cf43c632c8fe5b42372a891216fdd9223

Add 64 bit loong_arch architecture by defining ACPI_MACHINE_WIDTH to 64.
Useful for acpica tools and incorporating ACPICA into the Firmware Test
Suite.

Link: https://github.com/acpica/acpica/commit/d809b69c
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>