kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-10 20:48:12 +00:00
Code Issues Releases Packages Activity
linux/include/acpi/platform/aclinuxex.h

141 lines
3.3 KiB
Raw Normal View History

ACPICA: adding SPDX headers Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-14 16:13:07 -07:00
ACPICA: Linux headers: Add <acpi/platform/aclinuxex.h> From ACPICA's perspective, <acpi/actypes.h> should be included after inclusion of <acpi/platform/acenv.h>. But currently in Linux, <acpi/platform/aclinux.h> included by <acpi/platform/acenv.h> has included <acpi/actypes.h> to find ACPICA types for inline functions. This causes the following problem: 1. Redundant code in <asm/acpi.h> and <acpi/platform/aclinux.h>: Linux must be careful to keep conditions for <acpi/actypes.h> inclusion consistent with the conditions for <acpi/platform/aclinux.h> inclusion. Which finally leads to the issue that we have to keep many useless macro definitions in <acpi/platform/aclinux.h> or <asm/acpi.h>. Such conditions include: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_INT64 ACPI_INLINE ACPI_SYSTEM_XFACE ACPI_EXTERNAL_XFACE ACPI_INTERNAL_XFACE ACPI_INTERNAL_VAR_XFACE ACPI_MUTEX_TYPE DEBUGGER_THREADING ACPI_ACQUIRE_GLOBAL_LOCK ACPI_RELEASE_GLOBAL_LOCK ACPI_FLUSH_CPU_CACHE They have default implementations in <include/acpi/platform/acenv.h> while Linux need to keep a copy in <asm/acpi.h> to avoid build errors. This patch introduces <acpi/platform/aclinuxex.h> to fix this issue by splitting conditions and declarations (most of them are inline functions) into 2 header files so that the wrong inclusion of <acpi/actypes.h> can be removed from <acpi/platform/aclinux.h>. This patch also removes old ACPI_NATIVE_INTERFACE_HEADER mechanism which is not preferred by Linux and adds the platform/acenvex.h to be the solution to solve this issue. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-12 15:46:32 +08:00
ACPICA: Update the copyright year to 2026 Update copyright notices in all ACPICA files. Link: https://github.com/acpica/acpica/commit/9def02549a9c Signed-off-by: Pawel Chmielewski <pawel.chmielewski@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/4379132.1IzOArtZ34@rafael.j.wysocki
2026-05-27 20:08:02 +02:00
ACPICA: Linux headers: Add <acpi/platform/aclinuxex.h> From ACPICA's perspective, <acpi/actypes.h> should be included after inclusion of <acpi/platform/acenv.h>. But currently in Linux, <acpi/platform/aclinux.h> included by <acpi/platform/acenv.h> has included <acpi/actypes.h> to find ACPICA types for inline functions. This causes the following problem: 1. Redundant code in <asm/acpi.h> and <acpi/platform/aclinux.h>: Linux must be careful to keep conditions for <acpi/actypes.h> inclusion consistent with the conditions for <acpi/platform/aclinux.h> inclusion. Which finally leads to the issue that we have to keep many useless macro definitions in <acpi/platform/aclinux.h> or <asm/acpi.h>. Such conditions include: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_INT64 ACPI_INLINE ACPI_SYSTEM_XFACE ACPI_EXTERNAL_XFACE ACPI_INTERNAL_XFACE ACPI_INTERNAL_VAR_XFACE ACPI_MUTEX_TYPE DEBUGGER_THREADING ACPI_ACQUIRE_GLOBAL_LOCK ACPI_RELEASE_GLOBAL_LOCK ACPI_FLUSH_CPU_CACHE They have default implementations in <include/acpi/platform/acenv.h> while Linux need to keep a copy in <asm/acpi.h> to avoid build errors. This patch introduces <acpi/platform/aclinuxex.h> to fix this issue by splitting conditions and declarations (most of them are inline functions) into 2 header files so that the wrong inclusion of <acpi/actypes.h> can be removed from <acpi/platform/aclinux.h>. This patch also removes old ACPI_NATIVE_INTERFACE_HEADER mechanism which is not preferred by Linux and adds the platform/acenvex.h to be the solution to solve this issue. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-12 15:46:32 +08:00
ACPICA: adding SPDX headers Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-14 16:13:07 -07:00
ACPICA: Linux headers: Add <acpi/platform/aclinuxex.h> From ACPICA's perspective, <acpi/actypes.h> should be included after inclusion of <acpi/platform/acenv.h>. But currently in Linux, <acpi/platform/aclinux.h> included by <acpi/platform/acenv.h> has included <acpi/actypes.h> to find ACPICA types for inline functions. This causes the following problem: 1. Redundant code in <asm/acpi.h> and <acpi/platform/aclinux.h>: Linux must be careful to keep conditions for <acpi/actypes.h> inclusion consistent with the conditions for <acpi/platform/aclinux.h> inclusion. Which finally leads to the issue that we have to keep many useless macro definitions in <acpi/platform/aclinux.h> or <asm/acpi.h>. Such conditions include: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_INT64 ACPI_INLINE ACPI_SYSTEM_XFACE ACPI_EXTERNAL_XFACE ACPI_INTERNAL_XFACE ACPI_INTERNAL_VAR_XFACE ACPI_MUTEX_TYPE DEBUGGER_THREADING ACPI_ACQUIRE_GLOBAL_LOCK ACPI_RELEASE_GLOBAL_LOCK ACPI_FLUSH_CPU_CACHE They have default implementations in <include/acpi/platform/acenv.h> while Linux need to keep a copy in <asm/acpi.h> to avoid build errors. This patch introduces <acpi/platform/aclinuxex.h> to fix this issue by splitting conditions and declarations (most of them are inline functions) into 2 header files so that the wrong inclusion of <acpi/actypes.h> can be removed from <acpi/platform/aclinux.h>. This patch also removes old ACPI_NATIVE_INTERFACE_HEADER mechanism which is not preferred by Linux and adds the platform/acenvex.h to be the solution to solve this issue. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-12 15:46:32 +08:00
ACPICA: Linux: Add stub implementation of ACPICA 64-bit mathematics. This patch adds default 64-bit mathematics in aclinux.h using do_div(). As do_div() can be used for all Linux architectures, this can also be used as stub macros for ACPICA 64-bit mathematics. These macros are required by drivers/acpi/utmath.c when ACPI_USE_NATIVE_DIVIDE is not defined. It is used by ACPICA, so currently this is only meaningful to CONFIG_ACPI builds. So the kernel will not use these macros unless CONFIG_ACPI is defined and ACPI_USE_DIVIDE is not defined. For 64-bit kernels: In include/acpi/actypes.h, for ACPI_MACHINE_WIDTH=64, ACPI_USE_NATIVE_DIVIDE will be defined, thus these macros are not used. In include/acpi/platform/aclinux.h, for __KERNEL__ surrounded code, ACPI_MACHINE_WIDTH is defined to be BITS_PER_LONG. So all 64-bit kernels do not use these macros. For 32-bit kernels: As mentioned above, these macros will be used when BITS_PER_LONG is 32. Thus currently the i328 kernels are the only users for these macros. But they won't use this default implementation provided by this patch, because in arch/x86/include/asm/acenv.h, there are already overrides implemented. So these default macros are not used by 32-bit x86 (i386) kernels. These macros will only be used by future non x86 32-bit architectures that try to support ACPI in Linux kernel. During the period they do not have arch specific implementations of such macros, we can avoid build errors for them. And since they can see ACPICA functioning without implementing any arch specific environment tunings, we can also avoid function errors for them. As this implementation is not performance friendly, those architectures still need to implement real support in the end. Signed-off-by: Lv Zheng <lv.zheng@intel.com> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-07-16 16:58:00 +08:00
ACPICA: Linux headers: Add <acpi/platform/aclinuxex.h> From ACPICA's perspective, <acpi/actypes.h> should be included after inclusion of <acpi/platform/acenv.h>. But currently in Linux, <acpi/platform/aclinux.h> included by <acpi/platform/acenv.h> has included <acpi/actypes.h> to find ACPICA types for inline functions. This causes the following problem: 1. Redundant code in <asm/acpi.h> and <acpi/platform/aclinux.h>: Linux must be careful to keep conditions for <acpi/actypes.h> inclusion consistent with the conditions for <acpi/platform/aclinux.h> inclusion. Which finally leads to the issue that we have to keep many useless macro definitions in <acpi/platform/aclinux.h> or <asm/acpi.h>. Such conditions include: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_INT64 ACPI_INLINE ACPI_SYSTEM_XFACE ACPI_EXTERNAL_XFACE ACPI_INTERNAL_XFACE ACPI_INTERNAL_VAR_XFACE ACPI_MUTEX_TYPE DEBUGGER_THREADING ACPI_ACQUIRE_GLOBAL_LOCK ACPI_RELEASE_GLOBAL_LOCK ACPI_FLUSH_CPU_CACHE They have default implementations in <include/acpi/platform/acenv.h> while Linux need to keep a copy in <asm/acpi.h> to avoid build errors. This patch introduces <acpi/platform/aclinuxex.h> to fix this issue by splitting conditions and declarations (most of them are inline functions) into 2 header files so that the wrong inclusion of <acpi/actypes.h> can be removed from <acpi/platform/aclinux.h>. This patch also removes old ACPI_NATIVE_INTERFACE_HEADER mechanism which is not preferred by Linux and adds the platform/acenvex.h to be the solution to solve this issue. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-12 15:46:32 +08:00
ACPICA: Divergence: Port declarators back to ACPICA ACPICA commit c160cae765412f5736cf88a9ebcc6138aa761a48 Linux uses asmlinkage and sparse macros to mark function symbols. This leads to the divergences between the Linux and the ACPICA. This patch ports such declarators back to ACPICA. Lv Zheng. Link: https://github.com/acpica/acpica/commit/c160cae7 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-04 16:43:19 +08:00
ACPICA: Linux headers: Add <acpi/platform/aclinuxex.h> From ACPICA's perspective, <acpi/actypes.h> should be included after inclusion of <acpi/platform/acenv.h>. But currently in Linux, <acpi/platform/aclinux.h> included by <acpi/platform/acenv.h> has included <acpi/actypes.h> to find ACPICA types for inline functions. This causes the following problem: 1. Redundant code in <asm/acpi.h> and <acpi/platform/aclinux.h>: Linux must be careful to keep conditions for <acpi/actypes.h> inclusion consistent with the conditions for <acpi/platform/aclinux.h> inclusion. Which finally leads to the issue that we have to keep many useless macro definitions in <acpi/platform/aclinux.h> or <asm/acpi.h>. Such conditions include: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_INT64 ACPI_INLINE ACPI_SYSTEM_XFACE ACPI_EXTERNAL_XFACE ACPI_INTERNAL_XFACE ACPI_INTERNAL_VAR_XFACE ACPI_MUTEX_TYPE DEBUGGER_THREADING ACPI_ACQUIRE_GLOBAL_LOCK ACPI_RELEASE_GLOBAL_LOCK ACPI_FLUSH_CPU_CACHE They have default implementations in <include/acpi/platform/acenv.h> while Linux need to keep a copy in <asm/acpi.h> to avoid build errors. This patch introduces <acpi/platform/aclinuxex.h> to fix this issue by splitting conditions and declarations (most of them are inline functions) into 2 header files so that the wrong inclusion of <acpi/actypes.h> can be removed from <acpi/platform/aclinux.h>. This patch also removes old ACPI_NATIVE_INTERFACE_HEADER mechanism which is not preferred by Linux and adds the platform/acenvex.h to be the solution to solve this issue. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-12 15:46:32 +08:00
mm: add comments for allocation helpers explaining why they are macros 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>
2024-07-03 10:42:25 -07:00
ACPICA: Linux headers: Add <acpi/platform/aclinuxex.h> From ACPICA's perspective, <acpi/actypes.h> should be included after inclusion of <acpi/platform/acenv.h>. But currently in Linux, <acpi/platform/aclinux.h> included by <acpi/platform/acenv.h> has included <acpi/actypes.h> to find ACPICA types for inline functions. This causes the following problem: 1. Redundant code in <asm/acpi.h> and <acpi/platform/aclinux.h>: Linux must be careful to keep conditions for <acpi/actypes.h> inclusion consistent with the conditions for <acpi/platform/aclinux.h> inclusion. Which finally leads to the issue that we have to keep many useless macro definitions in <acpi/platform/aclinux.h> or <asm/acpi.h>. Such conditions include: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_INT64 ACPI_INLINE ACPI_SYSTEM_XFACE ACPI_EXTERNAL_XFACE ACPI_INTERNAL_XFACE ACPI_INTERNAL_VAR_XFACE ACPI_MUTEX_TYPE DEBUGGER_THREADING ACPI_ACQUIRE_GLOBAL_LOCK ACPI_RELEASE_GLOBAL_LOCK ACPI_FLUSH_CPU_CACHE They have default implementations in <include/acpi/platform/acenv.h> while Linux need to keep a copy in <asm/acpi.h> to avoid build errors. This patch introduces <acpi/platform/aclinuxex.h> to fix this issue by splitting conditions and declarations (most of them are inline functions) into 2 header files so that the wrong inclusion of <acpi/actypes.h> can be removed from <acpi/platform/aclinux.h>. This patch also removes old ACPI_NATIVE_INTERFACE_HEADER mechanism which is not preferred by Linux and adds the platform/acenvex.h to be the solution to solve this issue. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-12 15:46:32 +08:00
mm: change inlined allocation helpers to account at the call site 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>
2024-04-14 19:07:31 -07:00
ACPICA: Linux headers: Add <acpi/platform/aclinuxex.h> From ACPICA's perspective, <acpi/actypes.h> should be included after inclusion of <acpi/platform/acenv.h>. But currently in Linux, <acpi/platform/aclinux.h> included by <acpi/platform/acenv.h> has included <acpi/actypes.h> to find ACPICA types for inline functions. This causes the following problem: 1. Redundant code in <asm/acpi.h> and <acpi/platform/aclinux.h>: Linux must be careful to keep conditions for <acpi/actypes.h> inclusion consistent with the conditions for <acpi/platform/aclinux.h> inclusion. Which finally leads to the issue that we have to keep many useless macro definitions in <acpi/platform/aclinux.h> or <asm/acpi.h>. Such conditions include: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_INT64 ACPI_INLINE ACPI_SYSTEM_XFACE ACPI_EXTERNAL_XFACE ACPI_INTERNAL_XFACE ACPI_INTERNAL_VAR_XFACE ACPI_MUTEX_TYPE DEBUGGER_THREADING ACPI_ACQUIRE_GLOBAL_LOCK ACPI_RELEASE_GLOBAL_LOCK ACPI_FLUSH_CPU_CACHE They have default implementations in <include/acpi/platform/acenv.h> while Linux need to keep a copy in <asm/acpi.h> to avoid build errors. This patch introduces <acpi/platform/aclinuxex.h> to fix this issue by splitting conditions and declarations (most of them are inline functions) into 2 header files so that the wrong inclusion of <acpi/actypes.h> can be removed from <acpi/platform/aclinux.h>. This patch also removes old ACPI_NATIVE_INTERFACE_HEADER mechanism which is not preferred by Linux and adds the platform/acenvex.h to be the solution to solve this issue. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-12 15:46:32 +08:00
mm: change inlined allocation helpers to account at the call site 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>
2024-04-14 19:07:31 -07:00
ACPICA: Linux headers: Add <acpi/platform/aclinuxex.h> From ACPICA's perspective, <acpi/actypes.h> should be included after inclusion of <acpi/platform/acenv.h>. But currently in Linux, <acpi/platform/aclinux.h> included by <acpi/platform/acenv.h> has included <acpi/actypes.h> to find ACPICA types for inline functions. This causes the following problem: 1. Redundant code in <asm/acpi.h> and <acpi/platform/aclinux.h>: Linux must be careful to keep conditions for <acpi/actypes.h> inclusion consistent with the conditions for <acpi/platform/aclinux.h> inclusion. Which finally leads to the issue that we have to keep many useless macro definitions in <acpi/platform/aclinux.h> or <asm/acpi.h>. Such conditions include: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_INT64 ACPI_INLINE ACPI_SYSTEM_XFACE ACPI_EXTERNAL_XFACE ACPI_INTERNAL_XFACE ACPI_INTERNAL_VAR_XFACE ACPI_MUTEX_TYPE DEBUGGER_THREADING ACPI_ACQUIRE_GLOBAL_LOCK ACPI_RELEASE_GLOBAL_LOCK ACPI_FLUSH_CPU_CACHE They have default implementations in <include/acpi/platform/acenv.h> while Linux need to keep a copy in <asm/acpi.h> to avoid build errors. This patch introduces <acpi/platform/aclinuxex.h> to fix this issue by splitting conditions and declarations (most of them are inline functions) into 2 header files so that the wrong inclusion of <acpi/actypes.h> can be removed from <acpi/platform/aclinux.h>. This patch also removes old ACPI_NATIVE_INTERFACE_HEADER mechanism which is not preferred by Linux and adds the platform/acenvex.h to be the solution to solve this issue. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-12 15:46:32 +08:00
mm: add comments for allocation helpers explaining why they are macros 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>
2024-07-03 10:42:25 -07:00
ACPICA: Linux headers: Add <acpi/platform/aclinuxex.h> From ACPICA's perspective, <acpi/actypes.h> should be included after inclusion of <acpi/platform/acenv.h>. But currently in Linux, <acpi/platform/aclinux.h> included by <acpi/platform/acenv.h> has included <acpi/actypes.h> to find ACPICA types for inline functions. This causes the following problem: 1. Redundant code in <asm/acpi.h> and <acpi/platform/aclinux.h>: Linux must be careful to keep conditions for <acpi/actypes.h> inclusion consistent with the conditions for <acpi/platform/aclinux.h> inclusion. Which finally leads to the issue that we have to keep many useless macro definitions in <acpi/platform/aclinux.h> or <asm/acpi.h>. Such conditions include: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_INT64 ACPI_INLINE ACPI_SYSTEM_XFACE ACPI_EXTERNAL_XFACE ACPI_INTERNAL_XFACE ACPI_INTERNAL_VAR_XFACE ACPI_MUTEX_TYPE DEBUGGER_THREADING ACPI_ACQUIRE_GLOBAL_LOCK ACPI_RELEASE_GLOBAL_LOCK ACPI_FLUSH_CPU_CACHE They have default implementations in <include/acpi/platform/acenv.h> while Linux need to keep a copy in <asm/acpi.h> to avoid build errors. This patch introduces <acpi/platform/aclinuxex.h> to fix this issue by splitting conditions and declarations (most of them are inline functions) into 2 header files so that the wrong inclusion of <acpi/actypes.h> can be removed from <acpi/platform/aclinux.h>. This patch also removes old ACPI_NATIVE_INTERFACE_HEADER mechanism which is not preferred by Linux and adds the platform/acenvex.h to be the solution to solve this issue. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-12 15:46:32 +08:00
ACPICA: provide abstraction for raw_spinlock_t Provide a new lock type acpi_raw_spinlock which is implemented as raw_spinlock_t on Linux. This type should be used in code which covers small areas of code and disables interrupts only for short time even on a realtime OS. There is a fallback to spinlock_t if an OS does not provide an implementation for acpi_raw_spinlock. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-04-25 16:28:26 +02:00
ACPI: Enable build of AML interpreter debugger This patch enables ACPICA debugger files using a configurable CONFIG_ACPI_DEBUGGER configuration item. Those debugger related code that was originally masked as ACPI_FUTURE_USAGE now gets unmasked. Necessary OSL stubs are also added in this patch: 1. acpi_os_readable(): This should be arch specific in Linux, while this patch doesn't introduce real implementation and a complex mechanism to allow architecture specific acpi_os_readable() to be implemented to validate the address. It may be done by future commits. 2. acpi_os_get_line(): This is used to obtain debugger command input. This patch only introduces a simple KDB concept example in it and the example should be co-working with the code implemented in acpi_os_printf(). Since this KDB example won't be compiled unless ENABLE_DEBUGGER is defined and it seems Linux has already stopped to use ENABLE_DEBUGGER, thus do not expect it can work properly. This patch also cleans up all other ACPI_FUTURE_USAGE surroundings accordingly. 1. Since linkage error can be automatically detected, declaration in the headers needn't be surrounded by ACPI_FUTURE_USAGE. So only the following separate exported fuction bodies are masked by this macro (other exported fucntions may have already been masked at entire module level via drivers/acpi/acpica/Makefile): acpi_install_exception_handler() acpi_subsystem_status() acpi_get_system_info() acpi_get_statistics() acpi_install_initialization_handler() 2. Since strip can automatically zap the no-user functions, functions that are not marked with ACPI_EXPORT_SYMBOL() needn't get surrounded by ACPI_FUTURE_USAGE. So the following function which is not used by Linux kernel now won't get surrounded by this macro: acpi_ps_get_name() Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-10-19 10:25:56 +08:00
ACPICA: Debugger: Rename debugger OSL names ACPICA commit e76eb8b36ace880e4d475880db1128a206e57b6f This linuxized ACPICA commit is a back port result of the following linux commit: Commit: f8d31489629c125806ce4bf587c0c5c284d6d113 Subject: ACPICA: Debugger: Convert some mechanisms to OSPM specific During the back porting, it is requested by ACPICA to use expected OSL names. Suggested by Bob Moore, Fixed by Lv Zheng. Linux is not affected by this patch. Link: https://github.com/acpica/acpica/commit/e76eb8b3 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-28 15:28:07 +08:00
ACPICA: Debugger: Convert some mechanisms to OSPM specific The following mechanisms are OSPM specific: 1. Redirect output destination to console: no file redirection will be needed by an in-kernel debugger, there is even no file can be accessed when the debugger is running in the kernel mode. 2. Output command prompts: programs other than acpiexec can have different prompt characters and the prompt characters may be implemented as a special character sequence to form a char device IO protocol. 3. Command ready/complete handshake: OSPM debugger may wait more conditions to implement OSPM specific semantics (for example, FIFO full/empty conditions for O_NONBLOCK or IO open/close conditions). Leaving such OSPM specific stuffs in the ACPICA debugger core blocks Linux debugger IO driver implementation. Several new OSL APIs are provided by this patch: 1. acpi_os_initialize_command_signals: initialize command handshake mechanism or any other OSPM specific stuffs. 2. acpi_os_terminate_command_signals: reversal of acpi_os_initialize_command_signals. 3. acpi_os_wait_command_ready: putting debugger task into wait state when a command is not ready. OSPMs can terminate command loop by returning AE_CTRL_TERMINATE from this API. Normally, wait_event() or wait_for_multiple_object() may be used to implement this API. 4. acpi_os_notify_command_complete: putting user task into running state when a command has been completed. OSPMs can terminate command loop by returning AE_CTRL_TERMINATE from this API. Normally, wake_up() or set_event() may be used to implement this API. This patch also converts current command signaling implementation into a generic debugger layer (osgendbg.c) to be used by the existing OSPMs or acpiexec, in return, Linux can have chance to implement its own command handshake mechanism. This patch also implements acpiexec batch mode in a multi-threading mode comaptible style as a demo (this can be confirmed by configuring acpiexec into DEBUGGER_MULTI_THREADED mode where the batch mode is still working). Lv Zheng. Note that the OSPM specific command handshake mechanism is required by Linux kernel because: 1. Linux kernel trends to use wait queue to synchronize two threads, using mutexes to achieve that will cause false "dead lock" warnings. 2. The command handshake mechanism implemented by ACPICA is implemented in this way because of a design issue in debugger IO streaming. Debugger IO outputs are simply cached using a giant buffer, this should be tuned by Linux in the future. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-03 10:42:46 +08:00
ACPICA: Debugger: Rename debugger OSL names ACPICA commit e76eb8b36ace880e4d475880db1128a206e57b6f This linuxized ACPICA commit is a back port result of the following linux commit: Commit: f8d31489629c125806ce4bf587c0c5c284d6d113 Subject: ACPICA: Debugger: Convert some mechanisms to OSPM specific During the back porting, it is requested by ACPICA to use expected OSL names. Suggested by Bob Moore, Fixed by Lv Zheng. Linux is not affected by this patch. Link: https://github.com/acpica/acpica/commit/e76eb8b3 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-28 15:28:07 +08:00
ACPICA: Debugger: Convert some mechanisms to OSPM specific The following mechanisms are OSPM specific: 1. Redirect output destination to console: no file redirection will be needed by an in-kernel debugger, there is even no file can be accessed when the debugger is running in the kernel mode. 2. Output command prompts: programs other than acpiexec can have different prompt characters and the prompt characters may be implemented as a special character sequence to form a char device IO protocol. 3. Command ready/complete handshake: OSPM debugger may wait more conditions to implement OSPM specific semantics (for example, FIFO full/empty conditions for O_NONBLOCK or IO open/close conditions). Leaving such OSPM specific stuffs in the ACPICA debugger core blocks Linux debugger IO driver implementation. Several new OSL APIs are provided by this patch: 1. acpi_os_initialize_command_signals: initialize command handshake mechanism or any other OSPM specific stuffs. 2. acpi_os_terminate_command_signals: reversal of acpi_os_initialize_command_signals. 3. acpi_os_wait_command_ready: putting debugger task into wait state when a command is not ready. OSPMs can terminate command loop by returning AE_CTRL_TERMINATE from this API. Normally, wait_event() or wait_for_multiple_object() may be used to implement this API. 4. acpi_os_notify_command_complete: putting user task into running state when a command has been completed. OSPMs can terminate command loop by returning AE_CTRL_TERMINATE from this API. Normally, wake_up() or set_event() may be used to implement this API. This patch also converts current command signaling implementation into a generic debugger layer (osgendbg.c) to be used by the existing OSPMs or acpiexec, in return, Linux can have chance to implement its own command handshake mechanism. This patch also implements acpiexec batch mode in a multi-threading mode comaptible style as a demo (this can be confirmed by configuring acpiexec into DEBUGGER_MULTI_THREADED mode where the batch mode is still working). Lv Zheng. Note that the OSPM specific command handshake mechanism is required by Linux kernel because: 1. Linux kernel trends to use wait queue to synchronize two threads, using mutexes to achieve that will cause false "dead lock" warnings. 2. The command handshake mechanism implemented by ACPICA is implemented in this way because of a design issue in debugger IO streaming. Debugger IO outputs are simply cached using a giant buffer, this should be tuned by Linux in the future. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-03 10:42:46 +08:00
ACPICA: Linuxize: reduce divergences for 20151218 release The patch reduces source code differences between the Linux kernel and the ACPICA upstream so that the linuxized ACPICA 20151218 release can be applied with reduced human intervention. The pscode.c has already been out of sync for months, and it becomes more and more difficult to merge pscode.c changes, so instead of update the affected lines of pscode.c, this patch synchronizes entire pscode.c file. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-29 13:52:32 +08:00
ACPICA: Debugger: Convert some mechanisms to OSPM specific The following mechanisms are OSPM specific: 1. Redirect output destination to console: no file redirection will be needed by an in-kernel debugger, there is even no file can be accessed when the debugger is running in the kernel mode. 2. Output command prompts: programs other than acpiexec can have different prompt characters and the prompt characters may be implemented as a special character sequence to form a char device IO protocol. 3. Command ready/complete handshake: OSPM debugger may wait more conditions to implement OSPM specific semantics (for example, FIFO full/empty conditions for O_NONBLOCK or IO open/close conditions). Leaving such OSPM specific stuffs in the ACPICA debugger core blocks Linux debugger IO driver implementation. Several new OSL APIs are provided by this patch: 1. acpi_os_initialize_command_signals: initialize command handshake mechanism or any other OSPM specific stuffs. 2. acpi_os_terminate_command_signals: reversal of acpi_os_initialize_command_signals. 3. acpi_os_wait_command_ready: putting debugger task into wait state when a command is not ready. OSPMs can terminate command loop by returning AE_CTRL_TERMINATE from this API. Normally, wait_event() or wait_for_multiple_object() may be used to implement this API. 4. acpi_os_notify_command_complete: putting user task into running state when a command has been completed. OSPMs can terminate command loop by returning AE_CTRL_TERMINATE from this API. Normally, wake_up() or set_event() may be used to implement this API. This patch also converts current command signaling implementation into a generic debugger layer (osgendbg.c) to be used by the existing OSPMs or acpiexec, in return, Linux can have chance to implement its own command handshake mechanism. This patch also implements acpiexec batch mode in a multi-threading mode comaptible style as a demo (this can be confirmed by configuring acpiexec into DEBUGGER_MULTI_THREADED mode where the batch mode is still working). Lv Zheng. Note that the OSPM specific command handshake mechanism is required by Linux kernel because: 1. Linux kernel trends to use wait queue to synchronize two threads, using mutexes to achieve that will cause false "dead lock" warnings. 2. The command handshake mechanism implemented by ACPICA is implemented in this way because of a design issue in debugger IO streaming. Debugger IO outputs are simply cached using a giant buffer, this should be tuned by Linux in the future. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-03 10:42:46 +08:00
ACPICA: Linux headers: Add <acpi/platform/aclinuxex.h> From ACPICA's perspective, <acpi/actypes.h> should be included after inclusion of <acpi/platform/acenv.h>. But currently in Linux, <acpi/platform/aclinux.h> included by <acpi/platform/acenv.h> has included <acpi/actypes.h> to find ACPICA types for inline functions. This causes the following problem: 1. Redundant code in <asm/acpi.h> and <acpi/platform/aclinux.h>: Linux must be careful to keep conditions for <acpi/actypes.h> inclusion consistent with the conditions for <acpi/platform/aclinux.h> inclusion. Which finally leads to the issue that we have to keep many useless macro definitions in <acpi/platform/aclinux.h> or <asm/acpi.h>. Such conditions include: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_INT64 ACPI_INLINE ACPI_SYSTEM_XFACE ACPI_EXTERNAL_XFACE ACPI_INTERNAL_XFACE ACPI_INTERNAL_VAR_XFACE ACPI_MUTEX_TYPE DEBUGGER_THREADING ACPI_ACQUIRE_GLOBAL_LOCK ACPI_RELEASE_GLOBAL_LOCK ACPI_FLUSH_CPU_CACHE They have default implementations in <include/acpi/platform/acenv.h> while Linux need to keep a copy in <asm/acpi.h> to avoid build errors. This patch introduces <acpi/platform/aclinuxex.h> to fix this issue by splitting conditions and declarations (most of them are inline functions) into 2 header files so that the wrong inclusion of <acpi/actypes.h> can be removed from <acpi/platform/aclinux.h>. This patch also removes old ACPI_NATIVE_INTERFACE_HEADER mechanism which is not preferred by Linux and adds the platform/acenvex.h to be the solution to solve this issue. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-12 15:46:32 +08:00
ACPICA: Define acpi_ut_safe_strncpy() as strscpy_pad() alias Commit 292db66afd20 ("ACPICA: Unbreak tools build after switching over to strscpy_pad()") added an #ifdef based on a __KERNEL__ check which is sort of nasty to the acpi_ut_safe_strncpy() definition to unbreak ACPICA tools builds broken by commit 97f7d3f9c9ac ("ACPICA: Replace strncpy() with strscpy_pad() in acpi_ut_safe_strncpy()"). However, that #ifdef effectively produces dead code when tools are built because they don't call acpi_ut_safe_strncpy(). Accordingly, drop the existing definition of acpi_ut_safe_strncpy() and define it as a strscpy_pad() alias. Fixes: 292db66afd20 ("ACPICA: Unbreak tools build after switching over to strscpy_pad()") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [ rjw: Tweak the changelog ] Link: https://patch.msgid.link/12941764.O9o76ZdvQC@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-06-30 18:03:03 +02:00
ACPICA: Linux headers: Add <acpi/platform/aclinuxex.h> From ACPICA's perspective, <acpi/actypes.h> should be included after inclusion of <acpi/platform/acenv.h>. But currently in Linux, <acpi/platform/aclinux.h> included by <acpi/platform/acenv.h> has included <acpi/actypes.h> to find ACPICA types for inline functions. This causes the following problem: 1. Redundant code in <asm/acpi.h> and <acpi/platform/aclinux.h>: Linux must be careful to keep conditions for <acpi/actypes.h> inclusion consistent with the conditions for <acpi/platform/aclinux.h> inclusion. Which finally leads to the issue that we have to keep many useless macro definitions in <acpi/platform/aclinux.h> or <asm/acpi.h>. Such conditions include: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_INT64 ACPI_INLINE ACPI_SYSTEM_XFACE ACPI_EXTERNAL_XFACE ACPI_INTERNAL_XFACE ACPI_INTERNAL_VAR_XFACE ACPI_MUTEX_TYPE DEBUGGER_THREADING ACPI_ACQUIRE_GLOBAL_LOCK ACPI_RELEASE_GLOBAL_LOCK ACPI_FLUSH_CPU_CACHE They have default implementations in <include/acpi/platform/acenv.h> while Linux need to keep a copy in <asm/acpi.h> to avoid build errors. This patch introduces <acpi/platform/aclinuxex.h> to fix this issue by splitting conditions and declarations (most of them are inline functions) into 2 header files so that the wrong inclusion of <acpi/actypes.h> can be removed from <acpi/platform/aclinux.h>. This patch also removes old ACPI_NATIVE_INTERFACE_HEADER mechanism which is not preferred by Linux and adds the platform/acenvex.h to be the solution to solve this issue. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-12 15:46:32 +08:00