Kernel/linux
1
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git synced 2024-12-29 09:13:38 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
fd0584d220
linux/drivers/acpi/Kconfig

616 lines
19 KiB
Plaintext
Raw Normal View History

License cleanup: add SPDX GPL-2.0 license identifier to files with no license Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 14:07:57 +00:00
# SPDX-License-Identifier: GPL-2.0
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
#
# ACPI Configuration
#
ACPI: fix menuconfig presentation of ACPI submenu My fix for a recursive Kconfig dependency caused another issue where the ACPI specific options end up in the top-level menu in 'menuconfig'. This was an unintended side-effect of having a silent option between 'menuconfig ACPI' and 'if ACPI'. Moving the ARCH_SUPPORTS_ACPI symbol ahead of the ACPI menu solves that problem and restores the previous presentation. Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Fixes: 2c870e61132c (arm64: fix ACPI dependencies) Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-08-21 20:37:33 +00:00
config ARCH_SUPPORTS_ACPI
bool
ACPI: Use menuconfig objects Use menuconfigs instead of menus, so the whole menu can be disabled at once instead of going through all options. Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
2007-07-03 05:40:59 +00:00
menuconfig ACPI
acpi: remove double mention of Support for ACPI option Current description for CONFIG_ACPI includes the word "Support" twice. One effect of this is that in menuconfig the "--->" that indicates the presence of sub-options will not show up unless you have a very wide console. Signed-off-by: Frans Pop <elendil@planet.nl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
2007-10-29 21:20:38 +00:00
bool "ACPI (Advanced Configuration and Power Interface) Support"
arm64: fix ACPI dependencies Kconfig reports a warning on x86 builds after the ARM64 dependency was added. drivers/acpi/Kconfig:6:error: recursive dependency detected! drivers/acpi/Kconfig:6: symbol ACPI depends on EFI This rephrases the dependency to keep the ARM64 details out of the shared Kconfig file, so Kconfig no longer gets confused by it. For consistency, all three architectures that support ACPI now select ARCH_SUPPORTS_ACPI in exactly the configuration in which they allow it. We still need the 'default x86', as each one wants a different default: default-y on x86, default-n on arm64, and always-y on ia64. Fixes: 5bcd44083a08 ("drivers: acpi: add dependency of EFI for arm64") Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-07-24 09:48:45 +00:00
depends on ARCH_SUPPORTS_ACPI
ACPI: always enable CONFIG_PNPACPI on CONFIG_ACPI kernels We removed the ACPI motherboard driver which handled the ACPI=y, PNP=n case, so now we need to enforce that PNP & PNPACPI are always enabled for ACPI kernels. Most major distros ship this way this already. Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2007-02-16 03:34:36 +00:00
select PNP
ACPI: Fix build failure when CONFIG_NLS is set to 'n' Observing link failure as follows when CONFIG_ACPI is set but both CONFIG_NLS and CONFIG_PCI are no set: drivers/acpi/device_sysfs.o: In function `description_show': device_sysfs.c:(.text+0x48a): undefined reference to `utf16s_to_utf8s' This issue was previously addressed implicitly by commit 8a226e00eeed (PCI: pci-label: Fix build failure when CONFIG_NLS is set to 'm' by allmodconfig) causing PCI_LABEL to be selected when ACPI was set which caused NLS to be selected too in that case. However, after commit 5d32a66541c46 (PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set) it is possible to build ACPI support without PCI, so make ACPI select NLS directly to cover that case. Fixes: 5d32a66541c46 (PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set) Signed-off-by: Sinan Kaya <okaya@kernel.org> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-12-30 20:40:05 +00:00
select NLS
ACPI: require CRC32 to build ACPI core now requires crc32() but the kernel build can fail when CRC32 is not set/enabled, so select it in the ACPI Kconfig entry. Fixes this build error: ia64-linux-ld: drivers/acpi/scan.o: in function `acpi_store_pld_crc': include/acpi/platform/aclinuxex.h:62: undefined reference to `crc32_le' Fixes: 882c982dada4 ("acpi: Store CRC-32 hash of the _PLD in struct acpi_device") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-01-30 22:38:18 +00:00
select CRC32
acpi: Move common tables helper functions to common lib Some of the routines in ACPI driver/acpi/tables.c can be shared with parsing CDAT. CDAT is a device-provided data structure that is formatted similar to a platform provided ACPI table. CDAT is used by CXL and can exist on platforms that do not use ACPI. Split out the common routine from ACPI to accommodate platforms that do not support ACPI and move that to /lib. The common routines can be built outside of ACPI if FIRMWARE_TABLES is selected. Link: https://lore.kernel.org/linux-cxl/CAJZ5v0jipbtTNnsA0-o5ozOk8ZgWnOg34m34a9pPenTyRLj=6A@mail.gmail.com/ Suggested-by: "Rafael J. Wysocki" <rafael@kernel.org> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Acked-by: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/169713683430.2205276.17899451119920103445.stgit@djiang5-mobl3 Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-10-12 18:53:54 +00:00
select FIRMWARE_TABLE
arm64: fix ACPI dependencies Kconfig reports a warning on x86 builds after the ARM64 dependency was added. drivers/acpi/Kconfig:6:error: recursive dependency detected! drivers/acpi/Kconfig:6: symbol ACPI depends on EFI This rephrases the dependency to keep the ARM64 details out of the shared Kconfig file, so Kconfig no longer gets confused by it. For consistency, all three architectures that support ACPI now select ARCH_SUPPORTS_ACPI in exactly the configuration in which they allow it. We still need the 'default x86', as each one wants a different default: default-y on x86, default-n on arm64, and always-y on ia64. Fixes: 5bcd44083a08 ("drivers: acpi: add dependency of EFI for arm64") Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-07-24 09:48:45 +00:00
default y if X86
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
help
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
Advanced Configuration and Power Interface (ACPI) support for
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
Linux requires an ACPI-compliant platform (hardware/firmware),
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
and assumes the presence of OS-directed configuration and power
management (OSPM) software. This option will enlarge your
kernel by about 70K.
Linux ACPI provides a robust functional replacement for several
legacy configuration and power management interfaces, including
the Plug-and-Play BIOS specification (PnP BIOS), the
MultiProcessor Specification (MPS), and the Advanced Power
Management (APM) specification. If both ACPI and APM support
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
are configured, ACPI is used.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
Linux support for ACPI is based on Intel Corporation's ACPI
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
Component Architecture (ACPI CA). For more information on the
ACPI CA, see:
ACPI: Replace HTTP links with HTTPS ones Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Acked-by: Vishal Verma <vishal.l.verma@intel.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-17 18:24:36 +00:00
<https://acpica.org/>
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
ACPI: Update the ACPI spec information in Kconfig The UEFI Forum included the ACPI spec in its portfolio in October 2013 and will host future spec iterations, following the ACPI v5.0a release. A UEFI Forum working group named ACPI Specification Working Group (ASWG) has been established to handle future ACPI developments, any UEFI member can join the group and contribute to ACPI specification. So update the ownership and developers for ACPI in Kconfig accordingly, and add another website link to ACPI specification too. Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-08 12:59:48 +00:00
ACPI is an open industry specification originally co-developed by
Hewlett-Packard, Intel, Microsoft, Phoenix, and Toshiba. Currently,
it is developed by the ACPI Specification Working Group (ASWG) under
the UEFI Forum and any UEFI member can join the ASWG and contribute
to the ACPI specification.
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
The specification is available at:
ACPI: Use valid link to the ACPI specification Currently, acpi.info is an invalid link to access ACPI specification, the new valid link is https://uefi.org/specifications. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-27 09:29:38 +00:00
<https://uefi.org/specifications>
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
[PATCH] ACPI build fix Fix 2.6.12 CONFIG_ACPI=n build regression. CONFIG_ACPI_BOOT shall be set only if CONFIG_ACPI. Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-27 08:53:27 +00:00
if ACPI
ACPI: add config for BIOS table scan With the addition of ARM64 that does not have a traditional BIOS to scan, add a config option which is selected on x86 (ia64 doesn't need it either, it is EFI/UEFI based system) to do the traditional BIOS scanning for tables. Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-07-18 10:02:52 +00:00
config ACPI_LEGACY_TABLES_LOOKUP
bool
ACPI / processor: Introduce ARCH_MIGHT_HAVE_ACPI_PDC The use of _PDC is deprecated in ACPI 3.0 in favor of _OSC, as ARM platform is supported only in ACPI 5.0 or higher version, _PDC will not be used in ARM platform, so make Make _PDC only for platforms with Intel CPUs. Introduce ARCH_MIGHT_HAVE_ACPI_PDC and move _PDC related code in ACPI processor driver into a single file processor_pdc.c, make x86 and ia64 select it when ACPI is enabled. This patch also use pr_* to replace printk to fix the checkpatch warning and factor acpi_processor_alloc_pdc() a little bit to avoid duplicate pr_err() code. Suggested-by: Robert Richter <rric@kernel.org> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-07-18 10:02:54 +00:00
config ARCH_MIGHT_HAVE_ACPI_PDC
bool
ACPI: move arm64 GSI IRQ model to generic GSI IRQ layer The code deployed to implement GSI linux IRQ numbers mapping on arm64 turns out to be generic enough so that it can be moved to ACPI core code along with its respective config option ACPI_GENERIC_GSI selectable on architectures that can reuse the same code. Current ACPI IRQ mapping code is not integrated in the kernel IRQ domain infrastructure, in particular there is no way to look-up the IRQ domain associated with a particular interrupt controller, so this first version of GSI generic code carries out the GSI<->IRQ mapping relying on the IRQ default domain which is supposed to be always set on a specific architecture in case the domain structure passed to irq_create/find_mapping() functions is missing. This patch moves the arm64 acpi functions that implement the gsi mappings: acpi_gsi_to_irq() acpi_register_gsi() acpi_unregister_gsi() to ACPI core code. Since the generic GSI<->domain mapping is based on IRQ domains, it can be extended as soon as a way to map an interrupt controller to an IRQ domain is implemented for ACPI in the IRQ domain layer. x86 and ia64 code for GSI mappings cannot rely on the generic GSI layer at present for legacy reasons, so they do not select the ACPI_GENERIC_GSI config options and keep relying on their arch specific GSI mapping layer. Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Acked-by: Hanjun Guo <hanjun.guo@linaro.org> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2015-03-24 17:58:51 +00:00
config ACPI_GENERIC_GSI
bool
ACPI / sleep: Introduce CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT ACPI 5.1 does not currently support S states for ARM64 hardware but ACPI code will call acpi_target_system_state() and acpi_sleep_init() for device power management, so introduce CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT and select it for x86 and ia64 only to make sleep functions available, and also introduce stub function to allow other drivers to function until S states are defined for ARM64. It will be no functional change for x86 and IA64. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
2015-03-24 14:02:39 +00:00
config ACPI_SYSTEM_POWER_STATES_SUPPORT
bool
ACPI / scan: Parse _CCA and setup device coherency This patch implements support for ACPI _CCA object, which is introduced in ACPIv5.1, can be used for specifying device DMA coherency attribute. The parsing logic traverses device namespace to parse coherency information, and stores it in acpi_device_flags. Then uses it to call arch_setup_dma_ops() when creating each device enumerated in DSDT during ACPI scan. This patch also introduces acpi_dma_is_coherent(), which provides an interface for device drivers to check the coherency information similarly to the of_dma_is_coherent(). Signed-off-by: Mark Salter <msalter@redhat.com> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-10 16:08:52 +00:00
config ACPI_CCA_REQUIRED
bool
ACPI: Keep sub-table parsing infrastructure available for modules The NFIT driver and now the CXL ACPI driver have both open-coded ACPI table parsing. Before another instance is added arrange for the core ACPI sub-table parsing to be optionally available to drivers via the CONFIG_ACPI_TABLE_LIB symbol. If no drivers select the symbol then the infrastructure reverts back to being tagged __init via the __init_or_acpilib annotation. For now, only tag the core sub-table routines and data that the CEDT parsing in the cxl_acpi driver would want to reuse, a CEDT parsing helper is added in a later change. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Len Brown <lenb@kernel.org> Cc: Alison Schofield <alison.schofield@intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/163553709227.2509508.8215196520233473814.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-10-29 19:51:32 +00:00
config ACPI_TABLE_LIB
bool
thermal: ACPI: Move the ACPI thermal library to drivers/acpi/ The ACPI thermal library contains functions that can be used to retrieve trip point temperature values through the platform firmware for various types of trip points. Each of these functions basically evaluates a specific ACPI object, checks if the value produced by it is reasonable and returns it (or THERMAL_TEMP_INVALID if anything fails). It made sense to hold it in drivers/thermal/ so long as it was only used by the code in that directory, but since it is also going to be used by the ACPI thermal driver located in drivers/acpi/, move it to the latter in order to keep the code related to evaluating ACPI objects defined in the specification proper together. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-10-17 20:05:23 +00:00
config ACPI_THERMAL_LIB
depends on THERMAL
bool
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 02:25:56 +00:00
config ACPI_DEBUGGER
ACPI / debugger: Add IO interface to access debugger functionalities This patch adds /sys/kernel/debug/acpi/acpidbg, which can be used by userspace programs to access ACPICA debugger functionalities. Known issue: 1. IO flush support acpi_os_notify_command_complete() and acpi_os_wait_command_ready() can be used by acpi_dbg module to implement .flush() filesystem operation. While this patch doesn't go that far. It then becomes userspace tool's duty now to flush old commands before executing new batch mode commands. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-03 02:43:00 +00:00
bool "AML debugger interface"
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 02:25:56 +00:00
select ACPI_DEBUG
help
ACPI / debugger: Add module support for ACPI debugger This patch converts AML debugger into a loadable module. Note that, it implements driver unloading at the level dependent on the module reference count. Which means if ACPI debugger is being used by a userspace program, "rmmod acpi_dbg" should result in failure. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-03 02:43:14 +00:00
Enable in-kernel debugging of AML facilities: statistics,
internal object dump, single step control method execution.
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 02:25:56 +00:00
This is still under development, currently enabling this only
results in the compilation of the ACPICA debugger files.
ACPI / debugger: Add module support for ACPI debugger This patch converts AML debugger into a loadable module. Note that, it implements driver unloading at the level dependent on the module reference count. Which means if ACPI debugger is being used by a userspace program, "rmmod acpi_dbg" should result in failure. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-03 02:43:14 +00:00
if ACPI_DEBUGGER
config ACPI_DEBUGGER_USER
ACPI: Kconfig: Fix a typo in Kconfig This patch fixes a spelling typo in acpi/Kconfig Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-09-21 06:21:24 +00:00
tristate "Userspace debugger accessibility"
ACPI / debugger: Add module support for ACPI debugger This patch converts AML debugger into a loadable module. Note that, it implements driver unloading at the level dependent on the module reference count. Which means if ACPI debugger is being used by a userspace program, "rmmod acpi_dbg" should result in failure. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-03 02:43:14 +00:00
depends on DEBUG_FS
help
Export /sys/kernel/debug/acpi/acpidbg for userspace utilities
to access the debugger functionalities.
endif
ACPI: parse SPCR and enable matching console 'ARM Server Base Boot Requiremets' [1] mentions SPCR (Serial Port Console Redirection Table) [2] as a mandatory ACPI table that specifies the configuration of serial console. Defer initialization of DT earlycon until ACPI/DT decision is made. Parse the ACPI SPCR table, setup earlycon if required, enable specified console. Thanks to Peter Hurley for explaining how this should work. [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html [2] https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=vs.85).aspx Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com> Tested-by: Christopher Covington <cov@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-27 20:54:13 +00:00
config ACPI_SPCR_TABLE
ACPI: SPCR: Make SPCR available to x86 SPCR is currently only enabled or ARM64 and x86 can use SPCR to setup an early console. General fixes include updating Documentation & Kconfig (for x86), updating comments, and changing parse_spcr() to acpi_parse_spcr(), and earlycon_init_is_deferred to earlycon_acpi_spcr_enable to be more descriptive. On x86, many systems have a valid SPCR table but the table version is not 2 so the table version check must be a warning. On ARM64 when the kernel parameter earlycon is used both the early console and console are enabled. On x86, only the earlycon should be enabled by by default. Modify acpi_parse_spcr() to allow options for initializing the early console and console separately. Signed-off-by: Prarit Bhargava <prarit@redhat.com> Acked-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Mark Salter <msalter@redhat.com> Tested-by: Mark Salter <msalter@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-01-18 15:09:51 +00:00
bool "ACPI Serial Port Console Redirection Support"
default y if X86
help
Enable support for Serial Port Console Redirection (SPCR) Table.
This table provides information about the configuration of the
earlycon console.
ACPI: parse SPCR and enable matching console 'ARM Server Base Boot Requiremets' [1] mentions SPCR (Serial Port Console Redirection Table) [2] as a mandatory ACPI table that specifies the configuration of serial console. Defer initialization of DT earlycon until ACPI/DT decision is made. Parse the ACPI SPCR table, setup earlycon if required, enable specified console. Thanks to Peter Hurley for explaining how this should work. [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html [2] https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=vs.85).aspx Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com> Tested-by: Christopher Covington <cov@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-27 20:54:13 +00:00
ACPI: tables: introduce support for FPDT table ACPI Firmware Performance Data Table (FPDT) provides information about firmware performance during system boot, S3 suspend and S3 resume. Have the kernel parse the FPDT table, and expose the firmware performance data to userspace as sysfs attributes under /sys/firmware/acpi/fpdt/. Tested-by: Todd Brandt <todd.e.brandt@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-29 06:15:48 +00:00
config ACPI_FPDT
bool "ACPI Firmware Performance Data Table (FPDT) support"
ACPI: Enable FPDT on arm64 FPDT provides some boot timing records useful for analyzing parts of the UEFI boot stack. Given the existing code works on arm64, and allows reading the values without utilizing /dev/mem it seems like a good idea to turn it on. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Link: https://lore.kernel.org/r/20221109174720.203723-1-jeremy.linton@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2022-11-09 17:47:20 +00:00
depends on X86_64 || ARM64
ACPI: tables: introduce support for FPDT table ACPI Firmware Performance Data Table (FPDT) provides information about firmware performance during system boot, S3 suspend and S3 resume. Have the kernel parse the FPDT table, and expose the firmware performance data to userspace as sysfs attributes under /sys/firmware/acpi/fpdt/. Tested-by: Todd Brandt <todd.e.brandt@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-29 06:15:48 +00:00
help
Enable support for the Firmware Performance Data Table (FPDT).
This table provides information on the timing of the system
boot, S3 suspend and S3 resume firmware code paths.
ACPI / LPIT: Add Low Power Idle Table (LPIT) support Add functionality to read LPIT table, which provides: - Sysfs interface to read residency counters via /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us Here the count "low_power_idle_cpu_residency_us" shows the time spent by CPU package in low power state. This is read via MSR interface, which points to MSR for PKG C10. Here the count "low_power_idle_system_residency_us" show the count the system was in low power state. This is read via MMIO interface. This is mapped to SLP_S0 residency on modern Intel systems. This residency is achieved only when CPU is in PKG C10 and all functional blocks are in low power state. It is possible that none of the above counters present or anyone of the counter present or all counters present. For example: On my Kabylake system both of the above counters present. After suspend to idle these counts updated and prints: 6916179 6998564 This counter can be read by tools like turbostat to display. Or it can be used to debug, if modern systems are reaching desired low power state. - Provides an interface to read residency counter memory address This address can be used to get the base address of PMC memory mapped IO. This is utilized by intel_pmc_core driver to print more debug information. In addition, to avoid code duplication to read iomem, removed the read of iomem from acpi_os_read_memory() in osl.c and made a common function acpi_os_read_iomem(). This new function is used for reading iomem in in both osl.c and acpi_lpit.c. Link: http://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-10-05 23:24:03 +00:00
config ACPI_LPIT
bool
depends on X86_64
default y
ACPI: restore CONFIG_ACPI_SLEEP Restore the 2.6.22 CONFIG_ACPI_SLEEP build option, but now shadowing the new CONFIG_PM_SLEEP option. Signed-off-by: Len Brown <len.brown@intel.com> [ Modified to work with the PM config setup changes. ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-28 07:33:16 +00:00
config ACPI_SLEEP
bool
ACPI suspend: Fix CONFIG_ACPI_SLEEP dependence and some compilation warnings Initially CONFIG_PM_SLEEP was defined as CONFIG_SUSPEND || CONFIG_HIBERNATION and some ACPI code, most importantly the code in drivers/acpi/main.c, was written with this assumption. Currently, however, CONFIG_PM_SLEEP is also set when CONFIG_XEN_SAVE_RESTORE is set. This causes some compilation warnings to appear in drivers/acpi/main.c if both CONFIG_SUSPEND and CONFIG_HIBERNATION are unset and CONFIG_PM_SLEEP is set (this was impossible before). To fix this problem, redefine CONFIG_ACPI_SLEEP do depend directly on CONFIG_SUSPEND || CONFIG_HIBERNATION, as originally intended, and use it instead of CONFIG_PM_SLEEP in drivers/acpi/main.c, wherever appropriate. Additionally, move the acpi_target_sleep_state definition from under the #ifdef to prevent compilation from failing in some cases. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2008-10-22 18:58:43 +00:00
depends on SUSPEND || HIBERNATION
ACPI / sleep: Introduce CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT ACPI 5.1 does not currently support S states for ARM64 hardware but ACPI code will call acpi_target_system_state() and acpi_sleep_init() for device power management, so introduce CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT and select it for x86 and ia64 only to make sleep functions available, and also introduce stub function to allow other drivers to function until S states are defined for ARM64. It will be no functional change for x86 and IA64. Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
2015-03-24 14:02:39 +00:00
depends on ACPI_SYSTEM_POWER_STATES_SUPPORT
ACPI: restore CONFIG_ACPI_SLEEP Restore the 2.6.22 CONFIG_ACPI_SLEEP build option, but now shadowing the new CONFIG_PM_SLEEP option. Signed-off-by: Len Brown <len.brown@intel.com> [ Modified to work with the PM config setup changes. ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-28 07:33:16 +00:00
default y
ACPI / init: Make it possible to override _REV The platform firmware on some systems expects Linux to return "5" as the supported ACPI revision which makes it expose system configuration information in a special way. For example, based on what ACPI exports as the supported revision, Dell XPS 13 (2015) configures its audio device to either work in HDA mode or in I2S mode, where the former is supposed to be used on Linux until the latter is fully supported (in the kernel as well as in user space). Since ACPI 6 mandates that _REV should return "2" if ACPI 2 or later is supported by the OS, a subsequent change will make that happen, so make it possible to override that on systems where "5" is expected to be returned for Linux to work correctly one them (such as the Dell machine mentioned above). Original-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-02 23:06:00 +00:00
config ACPI_REV_OVERRIDE_POSSIBLE
treewide: Fix printk() message errors This patch fix spelling typos in printk and kconfig. Signed-off-by: Masanari Iida <standby24x7@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-09-17 14:44:17 +00:00
bool "Allow supported ACPI revision to be overridden"
ACPI / init: Make it possible to override _REV The platform firmware on some systems expects Linux to return "5" as the supported ACPI revision which makes it expose system configuration information in a special way. For example, based on what ACPI exports as the supported revision, Dell XPS 13 (2015) configures its audio device to either work in HDA mode or in I2S mode, where the former is supposed to be used on Linux until the latter is fully supported (in the kernel as well as in user space). Since ACPI 6 mandates that _REV should return "2" if ACPI 2 or later is supported by the OS, a subsequent change will make that happen, so make it possible to override that on systems where "5" is expected to be returned for Linux to work correctly one them (such as the Dell machine mentioned above). Original-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-02 23:06:00 +00:00
depends on X86
default y
help
The platform firmware on some systems expects Linux to return "5" as
the supported ACPI revision which makes it expose system configuration
information in a special way.
For example, based on what ACPI exports as the supported revision,
Dell XPS 13 (2015) configures its audio device to either work in HDA
mode or in I2S mode, where the former is supposed to be used on Linux
until the latter is fully supported (in the kernel as well as in user
space).
This option enables a DMI-based quirk for the above Dell machine (so
that HDA audio is exposed by the platform firmware to the kernel) and
makes it possible to force the kernel to return "5" as the supported
ACPI revision via the "acpi_rev_override" command line switch.
ACPI: EC: make EC support compile-time conditional The embedded controller code is mainly used on x86 laptops and cannot work without PC style I/O port access. Make this a user-visible configuration option that is default enabled on x86 but otherwise disabled, and that can never be enabled unless CONFIG_HAS_IOPORT is also available. The empty stubs in internal.h help ignore the EC code in configurations that don't support it. In order to see those stubs, the sbshc code also has to include this header and drop duplicate declarations. All the direct callers of ec_read/ec_write already had an x86 dependency and now also need to depend on APCI_EC. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Hans de Goede <hdegoede@redhat.com> Link: https://patch.msgid.link/20241011061948.3211423-1-arnd@kernel.org [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-10-11 06:18:17 +00:00
config ACPI_EC
bool "Embedded Controller"
depends on HAS_IOPORT
ACPI: EC: Enable EC support on LoongArch by default Commit a6021aa24f6417416d933 ("ACPI: EC: make EC support compile-time conditional") only enable ACPI_EC on X86 by default, but the embedded controller is also widely used on LoongArch laptops so we also enable ACPI_EC for LoongArch. The laptop driver cannot work without EC, so also update the dependency of LOONGSON_LAPTOP to let it depend on APCI_EC. Fixes: a6021aa24f6417416d933 ("ACPI: EC: make EC support compile-time conditional") Reported-by: Xiaotian Wu <wuxiaotian@loongson.cn> Tested-by: Binbin Zhou <zhoubinbin@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Link: https://patch.msgid.link/20241217073704.3339587-1-chenhuacai@loongson.cn [ rjw: Added Fixes: ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-12-17 07:37:04 +00:00
default X86 || LOONGARCH
ACPI: EC: make EC support compile-time conditional The embedded controller code is mainly used on x86 laptops and cannot work without PC style I/O port access. Make this a user-visible configuration option that is default enabled on x86 but otherwise disabled, and that can never be enabled unless CONFIG_HAS_IOPORT is also available. The empty stubs in internal.h help ignore the EC code in configurations that don't support it. In order to see those stubs, the sbshc code also has to include this header and drop duplicate declarations. All the direct callers of ec_read/ec_write already had an x86 dependency and now also need to depend on APCI_EC. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Hans de Goede <hdegoede@redhat.com> Link: https://patch.msgid.link/20241011061948.3211423-1-arnd@kernel.org [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-10-11 06:18:17 +00:00
help
This driver handles communication with the microcontroller
ACPI: EC: Enable EC support on LoongArch by default Commit a6021aa24f6417416d933 ("ACPI: EC: make EC support compile-time conditional") only enable ACPI_EC on X86 by default, but the embedded controller is also widely used on LoongArch laptops so we also enable ACPI_EC for LoongArch. The laptop driver cannot work without EC, so also update the dependency of LOONGSON_LAPTOP to let it depend on APCI_EC. Fixes: a6021aa24f6417416d933 ("ACPI: EC: make EC support compile-time conditional") Reported-by: Xiaotian Wu <wuxiaotian@loongson.cn> Tested-by: Binbin Zhou <zhoubinbin@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Link: https://patch.msgid.link/20241217073704.3339587-1-chenhuacai@loongson.cn [ rjw: Added Fixes: ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-12-17 07:37:04 +00:00
on many x86/LoongArch laptops and other machines.
ACPI: EC: make EC support compile-time conditional The embedded controller code is mainly used on x86 laptops and cannot work without PC style I/O port access. Make this a user-visible configuration option that is default enabled on x86 but otherwise disabled, and that can never be enabled unless CONFIG_HAS_IOPORT is also available. The empty stubs in internal.h help ignore the EC code in configurations that don't support it. In order to see those stubs, the sbshc code also has to include this header and drop duplicate declarations. All the direct callers of ec_read/ec_write already had an x86 dependency and now also need to depend on APCI_EC. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Hans de Goede <hdegoede@redhat.com> Link: https://patch.msgid.link/20241011061948.3211423-1-arnd@kernel.org [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-10-11 06:18:17 +00:00
ACPI: Provide /sys/kernel/debug/ec/... This patch provides the same information through debugfs, which previously was provided through /proc/acpi/embedded_controller/*/info This is the gpe the EC is connected to and whether the global lock gets used. The io ports used are added to /proc/ioports in another patch. Beside the fact that /proc/acpi is deprecated for quite some time, this info is not needed for applications and thus can be moved to debugfs instead of a public interface like /sys. Signed-off-by: Thomas Renninger <trenn@suse.de> CC: Alexey Starikovskiy <astarikovskiy@suse.de> CC: Len Brown <lenb@kernel.org> CC: linux-kernel@vger.kernel.org CC: linux-acpi@vger.kernel.org CC: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: platform-driver-x86@vger.kernel.org Signed-off-by: Matthew Garrett <mjg@redhat.com>
2010-07-16 11:11:31 +00:00
config ACPI_EC_DEBUGFS
tristate "EC read/write access through /sys/kernel/debug/ec"
ACPI: EC: make EC support compile-time conditional The embedded controller code is mainly used on x86 laptops and cannot work without PC style I/O port access. Make this a user-visible configuration option that is default enabled on x86 but otherwise disabled, and that can never be enabled unless CONFIG_HAS_IOPORT is also available. The empty stubs in internal.h help ignore the EC code in configurations that don't support it. In order to see those stubs, the sbshc code also has to include this header and drop duplicate declarations. All the direct callers of ec_read/ec_write already had an x86 dependency and now also need to depend on APCI_EC. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Hans de Goede <hdegoede@redhat.com> Link: https://patch.msgid.link/20241011061948.3211423-1-arnd@kernel.org [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-10-11 06:18:17 +00:00
depends on ACPI_EC
ACPI: Provide /sys/kernel/debug/ec/... This patch provides the same information through debugfs, which previously was provided through /proc/acpi/embedded_controller/*/info This is the gpe the EC is connected to and whether the global lock gets used. The io ports used are added to /proc/ioports in another patch. Beside the fact that /proc/acpi is deprecated for quite some time, this info is not needed for applications and thus can be moved to debugfs instead of a public interface like /sys. Signed-off-by: Thomas Renninger <trenn@suse.de> CC: Alexey Starikovskiy <astarikovskiy@suse.de> CC: Len Brown <lenb@kernel.org> CC: linux-kernel@vger.kernel.org CC: linux-acpi@vger.kernel.org CC: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: platform-driver-x86@vger.kernel.org Signed-off-by: Matthew Garrett <mjg@redhat.com>
2010-07-16 11:11:31 +00:00
help
Say N to disable Embedded Controller /sys/kernel/debug interface
acpi ec_sys: Be more cautious about ec write access - Set Kconfig option default n - Only allow root to read/write io file (sever bug!) - Introduce write support module param -> default off - Properly clean up if any debugfs files cannot be created Signed-off-by: Thomas Renninger <trenn@suse.de> CC: mjg59@srcf.ucam.org CC: platform-driver-x86@vger.kernel.org CC: linux-acpi@vger.kernel.org CC: astarikovskiy@suse.de Signed-off-by: Matthew Garrett <mjg@redhat.com>
2010-07-29 20:30:24 +00:00
Be aware that using this interface can confuse your Embedded
Controller in a way that a normal reboot is not enough. You then
ACPI: Kconfig: fix typo. "power of" -> "power off" Signed-off-by: Len Brown <len.brown@intel.com>
2010-08-18 13:22:10 +00:00
have to power off your system, and remove the laptop battery for
acpi ec_sys: Be more cautious about ec write access - Set Kconfig option default n - Only allow root to read/write io file (sever bug!) - Introduce write support module param -> default off - Properly clean up if any debugfs files cannot be created Signed-off-by: Thomas Renninger <trenn@suse.de> CC: mjg59@srcf.ucam.org CC: platform-driver-x86@vger.kernel.org CC: linux-acpi@vger.kernel.org CC: astarikovskiy@suse.de Signed-off-by: Matthew Garrett <mjg@redhat.com>
2010-07-29 20:30:24 +00:00
some seconds.
ACPI: Provide /sys/kernel/debug/ec/... This patch provides the same information through debugfs, which previously was provided through /proc/acpi/embedded_controller/*/info This is the gpe the EC is connected to and whether the global lock gets used. The io ports used are added to /proc/ioports in another patch. Beside the fact that /proc/acpi is deprecated for quite some time, this info is not needed for applications and thus can be moved to debugfs instead of a public interface like /sys. Signed-off-by: Thomas Renninger <trenn@suse.de> CC: Alexey Starikovskiy <astarikovskiy@suse.de> CC: Len Brown <lenb@kernel.org> CC: linux-kernel@vger.kernel.org CC: linux-acpi@vger.kernel.org CC: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: platform-driver-x86@vger.kernel.org Signed-off-by: Matthew Garrett <mjg@redhat.com>
2010-07-16 11:11:31 +00:00
An Embedded Controller typically is available on laptops and reads
sensor values like battery state and temperature.
acpi ec_sys: Be more cautious about ec write access - Set Kconfig option default n - Only allow root to read/write io file (sever bug!) - Introduce write support module param -> default off - Properly clean up if any debugfs files cannot be created Signed-off-by: Thomas Renninger <trenn@suse.de> CC: mjg59@srcf.ucam.org CC: platform-driver-x86@vger.kernel.org CC: linux-acpi@vger.kernel.org CC: astarikovskiy@suse.de Signed-off-by: Matthew Garrett <mjg@redhat.com>
2010-07-29 20:30:24 +00:00
The kernel accesses the EC through ACPI parsed code provided by BIOS
tables. This option allows to access the EC directly without ACPI
code being involved.
ACPI: Provide /sys/kernel/debug/ec/... This patch provides the same information through debugfs, which previously was provided through /proc/acpi/embedded_controller/*/info This is the gpe the EC is connected to and whether the global lock gets used. The io ports used are added to /proc/ioports in another patch. Beside the fact that /proc/acpi is deprecated for quite some time, this info is not needed for applications and thus can be moved to debugfs instead of a public interface like /sys. Signed-off-by: Thomas Renninger <trenn@suse.de> CC: Alexey Starikovskiy <astarikovskiy@suse.de> CC: Len Brown <lenb@kernel.org> CC: linux-kernel@vger.kernel.org CC: linux-acpi@vger.kernel.org CC: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: platform-driver-x86@vger.kernel.org Signed-off-by: Matthew Garrett <mjg@redhat.com>
2010-07-16 11:11:31 +00:00
Thus this option is a debug option that helps to write ACPI drivers
and can be used to identify ACPI code or EC firmware bugs.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
config ACPI_AC
tristate "AC Adapter"
ACPI ac/battery/sbs: sysfs I/F always built in, procfs I/F disabled by default ACPI AC/Battery/SBS driver has different kernel option for procfs and sysfs I/F. This patch, 1. Change CONFIG_ACPI_PROCFS_POWER to 'n' by default so that we can remove it in the next release or two. 2. Remove CONFIG_ACPI_SYSFS_POWER and always build in the sysfs I/F of these drivers. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-10-08 05:54:57 +00:00
select POWER_SUPPLY
[ACPI] remove "default m" from acpi/Kconfig Andi Kleen suggested it was unconventional for us to "default m" on ACPI modules -- even though they are expected to be deployed as modules. But as "default n" would likely result in some users building nonsense kernels, we compromise to "default y". Distros are expected to continue to use =m in their configs. Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-25 16:22:04 +00:00
default y
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
help
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
This driver supports the AC Adapter object, which indicates
whether a system is on AC or not. If you have a system that can
[ACPI] remove "default m" from acpi/Kconfig Andi Kleen suggested it was unconventional for us to "default m" on ACPI modules -- even though they are expected to be deployed as modules. But as "default n" would likely result in some users building nonsense kernels, we compromise to "default y". Distros are expected to continue to use =m in their configs. Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-25 16:22:04 +00:00
switch between A/C and battery, say Y.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
To compile this driver as a module, choose M here:
the module will be called ac.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
config ACPI_BATTERY
tristate "Battery"
ACPI ac/battery/sbs: sysfs I/F always built in, procfs I/F disabled by default ACPI AC/Battery/SBS driver has different kernel option for procfs and sysfs I/F. This patch, 1. Change CONFIG_ACPI_PROCFS_POWER to 'n' by default so that we can remove it in the next release or two. 2. Remove CONFIG_ACPI_SYSFS_POWER and always build in the sysfs I/F of these drivers. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-10-08 05:54:57 +00:00
select POWER_SUPPLY
[ACPI] remove "default m" from acpi/Kconfig Andi Kleen suggested it was unconventional for us to "default m" on ACPI modules -- even though they are expected to be deployed as modules. But as "default n" would likely result in some users building nonsense kernels, we compromise to "default y". Distros are expected to continue to use =m in their configs. Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-25 16:22:04 +00:00
default y
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
help
This driver adds support for battery information through
/proc/acpi/battery. If you have a mobile system with a battery,
say Y.
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
To compile this driver as a module, choose M here:
the module will be called battery.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
config ACPI_BUTTON
tristate "Button"
ACPI: button: register with input layer In addition to signalling button/lid events through /proc/acpi/event, create separate input devices and report KEY_POWER, KEY_SLEEP and SW_LID through input layer. Also remove unnecessary casts and variable initializations, clean up formatting. Sleep button may autorepeat but userspace will have to filter duplicate sleep requests anyway (and discard unprocessed events right after wakeup). Unlike /proc/acpi/event interface input device corresponding to LID switch reports true lid state instead of just a counter. SW_LID is active when lid is closed. The driver now depends on CONFIG_INPUT. Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Len Brown <len.brown@intel.com>
2006-11-09 05:40:13 +00:00
depends on INPUT
[ACPI] remove "default m" from acpi/Kconfig Andi Kleen suggested it was unconventional for us to "default m" on ACPI modules -- even though they are expected to be deployed as modules. But as "default n" would likely result in some users building nonsense kernels, we compromise to "default y". Distros are expected to continue to use =m in their configs. Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-25 16:22:04 +00:00
default y
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
help
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
This driver handles events on the power, sleep, and lid buttons.
ACPI: remove /proc/acpi/event from ACPI_BUTTON help Commit 1696d9d (ACPI: Remove the old /proc/acpi/event interface) left /proc/acpi/event in the ACPI_BUTTON help in Kconfig, so remove it from there. [rjw: Changelog] Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-12 22:11:00 +00:00
A daemon reads events from input devices or via netlink and
performs user-defined actions such as shutting down the system.
This is necessary for software-controlled poweroff.
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
To compile this driver as a module, choose M here:
the module will be called button.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
ACPI: Add new tiny-power-button driver to directly signal init Virtual machines often use an ACPI power button event to tell the machine to shut down gracefully. Provide an extremely lightweight "tiny power button" driver to handle this event by signaling init directly, rather than running a separate daemon (such as acpid or systemd-logind) that adds to startup time and VM image complexity. The kernel configuration defines the default signal to send init, and userspace can change this signal via a module parameter. Suggested-by: "Rafael J. Wysocki" <rafael@kernel.org> Signed-off-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-02-11 23:38:06 +00:00
config ACPI_TINY_POWER_BUTTON
tristate "Tiny Power Button Driver"
depends on !ACPI_BUTTON
help
This driver provides a tiny alternative to the ACPI Button driver.
The tiny power button driver only handles the power button. Rather
than notifying userspace via the input layer or a netlink event, this
driver directly signals the init process to shut down.
This driver is particularly suitable for cloud and VM environments,
which use a simulated power button to initiate a controlled poweroff,
but which may not want to run a separate userspace daemon to process
input events.
config ACPI_TINY_POWER_BUTTON_SIGNAL
int "Tiny Power Button Signal"
depends on ACPI_TINY_POWER_BUTTON
default 38
help
Default signal to send to init in response to the power button.
Likely values here include 38 (SIGRTMIN+4) to power off, or 2
(SIGINT) to simulate Ctrl+Alt+Del.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
config ACPI_VIDEO
tristate "Video"
ACPI: video: Drop X86 dependency from Kconfig The ACPI video device is also present in ARM64 laptops, so drop the Kconfig dependency on X86 for ACPI_VIDEO. Signed-off-by: Riwen Lu <luriwen@kylinos.cn> [ rjw: Subject rewrite, changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-06-13 09:33:47 +00:00
depends on BACKLIGHT_CLASS_DEVICE
acpi_video: kernel build error if !INPUT Commit e9dab1960ac9746fa34eff726b81635147615a79 (ACPI video hotkey: export missing ACPI video hotkey events via input layer) exports ACPI video hotkey events via input layer. But this breaks kernel build if ACPI_VIDEO && !INPUT: LD .tmp_vmlinux1 drivers/built-in.o: In function `acpi_video_bus_remove': drivers/acpi/video.c:2007: undefined reference to `input_unregister_device' ... Signed-off-by: Andreas Herrmann <aherrman@arcor.de> Signed-off-by: Len Brown <len.brown@intel.com>
2007-09-17 21:41:05 +00:00
depends on INPUT
ACPI: video: Add Nvidia WMI EC brightness control detection (v3) On some new laptop designs a new Nvidia specific WMI interface is present which gives info about panel brightness control and may allow controlling the brightness through this interface when the embedded controller is used for brightness control. When this WMI interface is present and indicates that the EC is used, then this interface should be used for brightness control. Changes in v2: - Use the new shared nvidia-wmi-ec-backlight.h header for the WMI firmware API definitions - ACPI_VIDEO can now be enabled on non X86 too, adjust the Kconfig changes to match this. Changes in v3: - Use WMI_BRIGHTNESS_GUID define Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Daniel Dadap <ddadap@nvidia.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-06-04 12:06:18 +00:00
depends on ACPI_WMI || !X86
thermal: add the support for building the generic thermal as a module Build the generic thermal driver as module "thermal_sys". Make ACPI thermal, video, processor and fan SELECT the generic thermal driver, as these drivers rely on it to build the sysfs I/F. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Acked-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Len Brown <len.brown@intel.com>
2008-04-21 08:07:13 +00:00
select THERMAL
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
help
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
This driver implements the ACPI Extensions For Display Adapters
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
for integrated graphics devices on motherboard, as specified in
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
ACPI 2.0 Specification, Appendix B. This supports basic operations
such as defining the video POST device, retrieving EDID information,
and setting up a video output.
To compile this driver as a module, choose M here:
the module will be called video.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
config ACPI_FAN
tristate "Fan"
Thermal: int340x thermal: select ACPI fan driver we share the same driver for both ACPI predefined Fan device and INT3404 Fan device, thus we should select the ACPI Fan driver when int340x thermal drivers are enabeld. Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2014-06-19 07:43:29 +00:00
depends on THERMAL
[ACPI] remove "default m" from acpi/Kconfig Andi Kleen suggested it was unconventional for us to "default m" on ACPI modules -- even though they are expected to be deployed as modules. But as "default n" would likely result in some users building nonsense kernels, we compromise to "default y". Distros are expected to continue to use =m in their configs. Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-25 16:22:04 +00:00
default y
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
help
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
This driver supports ACPI fan devices, allowing user-mode
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
applications to perform basic fan control (on, off, status).
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
To compile this driver as a module, choose M here:
the module will be called fan.
ACPI: Add Time and Alarm Device (TAD) driver Introduce a driver for the ACPI Time and Alarm Device (TAD) based on Section 9.18 of ACPI 6.2. This driver only supports the system wakeup capabilities of the TAD which are mandatory. Support for the RTC capabilities of the TAD will be added to it in the future. This driver is entirely sysfs-based. It provides attributes (under the TAD platform device) to allow user space to manage the AC and DC wakeup timers of the TAD: set and read their values, set and check their expire timer wake policies, check and clear their status and check the capabilities of the TAD reported by AML. The DC timer attributes are only present if the TAD supports a separate DC alarm timer. The wakeup events handling and power management of the TAD is expected to be taken care of by the ACPI PM domain attached to its platform device. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2018-03-16 12:51:01 +00:00
config ACPI_TAD
tristate "ACPI Time and Alarm (TAD) Device Support"
depends on SYSFS && PM_SLEEP
help
The ACPI Time and Alarm (TAD) device is an alternative to the Real
Time Clock (RTC). Its wake timers allow the system to transition from
the S3 (or optionally S4/S5) state to S0 state after a time period
elapses. In comparison with the RTC Alarm, the TAD provides a larger
scale of flexibility in the wake timers. The time capabilities of the
TAD maintain the time of day information across platform power
transitions, and keep track of time even when the platform is turned
off.
Revert "Revert "ACPI: dock driver"" This reverts 953969ddf5b049361ed1e8471cc43dc4134d2a6f commit.
2006-07-09 21:22:28 +00:00
config ACPI_DOCK
dock: make dock driver not a module To avoid dock driver is loaded after other drivers like libata, let's make dock driver not a module. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-09-27 03:10:28 +00:00
bool "Dock"
Revert "Revert "ACPI: dock driver"" This reverts 953969ddf5b049361ed1e8471cc43dc4134d2a6f commit.
2006-07-09 21:22:28 +00:00
help
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
This driver supports ACPI-controlled docking stations and removable
drive bays such as the IBM Ultrabay and the Dell Module Bay.
ACPI: bay: new driver adding removable drive bay support Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
2006-10-20 21:30:25 +00:00
ACPI: Split out ACPI PSS from ACPI Processor driver The ACPI processor driver is currently tied too closely to the ACPI P-states (PSS) and other related constructs for controlling CPU performance. The newer ACPI specification (v5.1 onwards) introduces alternative methods to PSS. These new mechanisms are described within each ACPI Processor object and so they need to be scanned whenever a new Processor object is detected. This patch introduces a new Kconfig symbol to allow for finer configurability among the two options for controlling performance states. There is no change in functionality and the option is auto-selected by the architectures which support it. A future commit will introduce support for CPPC: A newer method of controlling CPU performance. The OS is not expected to support CPPC and PSS at the same time, so the Kconfig option lets us make the two mutually exclusive at compile time. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-08-05 13:40:25 +00:00
config ACPI_CPU_FREQ_PSS
bool
ACPI / processor_idle: introduce ACPI_PROCESSOR_CSTATE ACPI 6.0 adds a new method to specify the CPU idle states(C-states) called Low Power Idle(LPI) states. Since new architectures like ARM64 use only LPIs, introduce ACPI_PROCESSOR_CSTATE to encapsulate all the code supporting the old style C-states(_CST). This patch will help to extend the processor_idle module to support LPI. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-07-19 17:52:53 +00:00
config ACPI_PROCESSOR_CSTATE
def_bool y
ACPI: processor: Make ACPI_PROCESSOR_CSTATE depend on ACPI_PROCESSOR To avoid build errors when CONFIG_ACPI_PROCESSOR_CSTATE is set and CONFIG_ACPI_PROCESSOR is not (that may appear in randconfig builds), make the former depend on the latter. Acked-by: Len Brown <len.brown@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-12-16 11:07:01 +00:00
depends on ACPI_PROCESSOR
arch: Remove Itanium (IA-64) architecture The Itanium architecture is obsolete, and an informal survey [0] reveals that any residual use of Itanium hardware in production is mostly HP-UX or OpenVMS based. The use of Linux on Itanium appears to be limited to enthusiasts that occasionally boot a fresh Linux kernel to see whether things are still working as intended, and perhaps to churn out some distro packages that are rarely used in practice. None of the original companies behind Itanium still produce or support any hardware or software for the architecture, and it is listed as 'Orphaned' in the MAINTAINERS file, as apparently, none of the engineers that contributed on behalf of those companies (nor anyone else, for that matter) have been willing to support or maintain the architecture upstream or even be responsible for applying the odd fix. The Intel firmware team removed all IA-64 support from the Tianocore/EDK2 reference implementation of EFI in 2018. (Itanium is the original architecture for which EFI was developed, and the way Linux supports it deviates significantly from other architectures.) Some distros, such as Debian and Gentoo, still maintain [unofficial] ia64 ports, but many have dropped support years ago. While the argument is being made [1] that there is a 'for the common good' angle to being able to build and run existing projects such as the Grid Community Toolkit [2] on Itanium for interoperability testing, the fact remains that none of those projects are known to be deployed on Linux/ia64, and very few people actually have access to such a system in the first place. Even if there were ways imaginable in which Linux/ia64 could be put to good use today, what matters is whether anyone is actually doing that, and this does not appear to be the case. There are no emulators widely available, and so boot testing Itanium is generally infeasible for ordinary contributors. GCC still supports IA-64 but its compile farm [3] no longer has any IA-64 machines. GLIBC would like to get rid of IA-64 [4] too because it would permit some overdue code cleanups. In summary, the benefits to the ecosystem of having IA-64 be part of it are mostly theoretical, whereas the maintenance overhead of keeping it supported is real. So let's rip off the band aid, and remove the IA-64 arch code entirely. This follows the timeline proposed by the Debian/ia64 maintainer [5], which removes support in a controlled manner, leaving IA-64 in a known good state in the most recent LTS release. Other projects will follow once the kernel support is removed. [0] https://lore.kernel.org/all/CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com/ [1] https://lore.kernel.org/all/0075883c-7c51-00f5-2c2d-5119c1820410@web.de/ [2] https://gridcf.org/gct-docs/latest/index.html [3] https://cfarm.tetaneutral.net/machines/list/ [4] https://lore.kernel.org/all/87bkiilpc4.fsf@mid.deneb.enyo.de/ [5] https://lore.kernel.org/all/ff58a3e76e5102c94bb5946d99187b358def688a.camel@physik.fu-berlin.de/ Acked-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-10-20 13:54:33 +00:00
depends on X86
ACPI / processor_idle: introduce ACPI_PROCESSOR_CSTATE ACPI 6.0 adds a new method to specify the CPU idle states(C-states) called Low Power Idle(LPI) states. Since new architectures like ARM64 use only LPIs, introduce ACPI_PROCESSOR_CSTATE to encapsulate all the code supporting the old style C-states(_CST). This patch will help to extend the processor_idle module to support LPI. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-07-19 17:52:53 +00:00
ACPI: Decouple ACPI idle and ACPI processor drivers This patch introduces a new Kconfig symbol, ACPI_PROCESSOR_IDLE, which is auto selected by architectures which support the ACPI based C states for CPU Idle management. The processor_idle driver in its present form contains declarations specific to X86 and IA64. Since there are no reasonable defaults for other architectures e.g. ARM64, the driver is selected only for X86 or IA64. This helps in decoupling the ACPI processor_driver from the ACPI processor_idle driver which is useful for the upcoming alternative patchwork for controlling CPU Performance (CPPC) and CPU Idle (LPI). Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-08-05 13:40:26 +00:00
config ACPI_PROCESSOR_IDLE
bool
select CPU_IDLE
PCI/ACPI: Add generic MCFG table handling On ACPI systems that support memory-mapped config space access, i.e., ECAM, the PCI Firmware Specification says the OS can learn where the ECAM space is from either: - the static MCFG table (for non-hotpluggable bridges), or - the _CBA method (for hotpluggable bridges) The current MCFG table handling code cannot be easily generalized owing to x86-specific quirks, which makes it hard to reuse on other architectures. Implement generic MCFG handling from scratch, including: - Simple MCFG table parsing (via pci_mmcfg_late_init() as in current x86) - MCFG region lookup for a (domain, bus_start, bus_end) tuple [bhelgaas: changelog] Signed-off-by: Tomasz Nowicki <tn@semihalf.com> Signed-off-by: Jayachandran C <jchandra@broadcom.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2016-06-10 19:55:13 +00:00
config ACPI_MCFG
bool
ACPI: Introduce CPU performance controls using CPPC CPPC stands for Collaborative Processor Performance Controls and is defined in the ACPI v5.0+ spec. It describes CPU performance controls on an abstract and continuous scale allowing the platform (e.g. remote power processor) to flexibly optimize CPU performance with its knowledge of power budgets and other architecture specific knowledge. This patch adds a shim which exports commonly used functions to get and set CPPC specific controls for each CPU. This enables CPUFreq drivers to gather per CPU performance data and use with exisiting governors or even allows for customized governors which are implemented inside CPUFreq drivers. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Reviewed-by: Al Stone <al.stone@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-10-02 14:01:19 +00:00
config ACPI_CPPC_LIB
bool
depends on ACPI_PROCESSOR
select MAILBOX
select PCC
help
If this option is enabled, this file implements common functionality
to parse CPPC tables as described in the ACPI 5.1+ spec. The
routines implemented are meant to be used by other
drivers to control CPU performance using CPPC semantics.
If your platform does not support CPPC in firmware,
leave this option disabled.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
config ACPI_PROCESSOR
tristate "Processor"
ACPI: Enable ACPI_PROCESSOR for RISC-V The ACPI processor driver is not currently enabled for RISC-V. This is required to enable CPU related functionalities like LPI and CPPC. Hence, enable ACPI_PROCESSOR for RISC-V. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20240118062930.245937-4-sunilvl@ventanamicro.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2024-01-18 06:29:30 +00:00
depends on X86 || ARM64 || LOONGARCH || RISCV
ACPI: enable ACPI_PROCESSOR_IDLE on ARM64 Now that ACPI processor idle driver supports LPI(Low Power Idle), lets enable ACPI_PROCESSOR_IDLE for ARM64 too. This patch just removes the IA64 and X86 dependency on ACPI_PROCESSOR_IDLE Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-07-19 17:52:59 +00:00
select ACPI_PROCESSOR_IDLE
arch: Remove Itanium (IA-64) architecture The Itanium architecture is obsolete, and an informal survey [0] reveals that any residual use of Itanium hardware in production is mostly HP-UX or OpenVMS based. The use of Linux on Itanium appears to be limited to enthusiasts that occasionally boot a fresh Linux kernel to see whether things are still working as intended, and perhaps to churn out some distro packages that are rarely used in practice. None of the original companies behind Itanium still produce or support any hardware or software for the architecture, and it is listed as 'Orphaned' in the MAINTAINERS file, as apparently, none of the engineers that contributed on behalf of those companies (nor anyone else, for that matter) have been willing to support or maintain the architecture upstream or even be responsible for applying the odd fix. The Intel firmware team removed all IA-64 support from the Tianocore/EDK2 reference implementation of EFI in 2018. (Itanium is the original architecture for which EFI was developed, and the way Linux supports it deviates significantly from other architectures.) Some distros, such as Debian and Gentoo, still maintain [unofficial] ia64 ports, but many have dropped support years ago. While the argument is being made [1] that there is a 'for the common good' angle to being able to build and run existing projects such as the Grid Community Toolkit [2] on Itanium for interoperability testing, the fact remains that none of those projects are known to be deployed on Linux/ia64, and very few people actually have access to such a system in the first place. Even if there were ways imaginable in which Linux/ia64 could be put to good use today, what matters is whether anyone is actually doing that, and this does not appear to be the case. There are no emulators widely available, and so boot testing Itanium is generally infeasible for ordinary contributors. GCC still supports IA-64 but its compile farm [3] no longer has any IA-64 machines. GLIBC would like to get rid of IA-64 [4] too because it would permit some overdue code cleanups. In summary, the benefits to the ecosystem of having IA-64 be part of it are mostly theoretical, whereas the maintenance overhead of keeping it supported is real. So let's rip off the band aid, and remove the IA-64 arch code entirely. This follows the timeline proposed by the Debian/ia64 maintainer [5], which removes support in a controlled manner, leaving IA-64 in a known good state in the most recent LTS release. Other projects will follow once the kernel support is removed. [0] https://lore.kernel.org/all/CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com/ [1] https://lore.kernel.org/all/0075883c-7c51-00f5-2c2d-5119c1820410@web.de/ [2] https://gridcf.org/gct-docs/latest/index.html [3] https://cfarm.tetaneutral.net/machines/list/ [4] https://lore.kernel.org/all/87bkiilpc4.fsf@mid.deneb.enyo.de/ [5] https://lore.kernel.org/all/ff58a3e76e5102c94bb5946d99187b358def688a.camel@physik.fu-berlin.de/ Acked-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-10-20 13:54:33 +00:00
select ACPI_CPU_FREQ_PSS if X86 || LOONGARCH
ACPI: processor: Split out thermal initialization from ACPI PSS Commit 239708a3af44 ("ACPI: Split out ACPI PSS from ACPI Processor driver"), moves processor thermal registration to acpi_pss_perf_init(), which doesn't get executed if ACPI_CPU_FREQ_PSS is not enabled. As ARM64 supports P-states using CPPC, it should be possible to also support processor passive cooling even if PSS is not enabled. Split out the processor thermal cooling register from ACPI PSS to support this, and move it into a separate function in processor_thermal.c. Signed-off-by: Riwen Lu <luriwen@kylinos.cn> Reviewed-by: Punit Agrawal <punit.agrawal@bytedance.com> [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-06-17 02:51:51 +00:00
select THERMAL
[ACPI] remove "default m" from acpi/Kconfig Andi Kleen suggested it was unconventional for us to "default m" on ACPI modules -- even though they are expected to be deployed as modules. But as "default n" would likely result in some users building nonsense kernels, we compromise to "default y". Distros are expected to continue to use =m in their configs. Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-25 16:22:04 +00:00
default y
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
help
ACPI: Split out ACPI PSS from ACPI Processor driver The ACPI processor driver is currently tied too closely to the ACPI P-states (PSS) and other related constructs for controlling CPU performance. The newer ACPI specification (v5.1 onwards) introduces alternative methods to PSS. These new mechanisms are described within each ACPI Processor object and so they need to be scanned whenever a new Processor object is detected. This patch introduces a new Kconfig symbol to allow for finer configurability among the two options for controlling performance states. There is no change in functionality and the option is auto-selected by the architectures which support it. A future commit will introduce support for CPPC: A newer method of controlling CPU performance. The OS is not expected to support CPPC and PSS at the same time, so the Kconfig option lets us make the two mutually exclusive at compile time. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-08-05 13:40:25 +00:00
This driver adds support for the ACPI Processor package. It is required
by several flavors of cpufreq performance-state, thermal, throttling and
idle drivers.
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
To compile this driver as a module, choose M here:
the module will be called processor.
ACPI / IPMI: Cleanup some Kconfig codes This (trivial) patch: 1. Deletes duplicate Kconfig dependency as there is "if IPMI_HANDLER" around "IPMI_SI". Signed-off-by: Lv Zheng <lv.zheng@intel.com> Reviewed-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-13 05:14:51 +00:00
IPMI/ACPI: Add the IPMI opregion driver to enable ACPI to access BMC controller ACPI 4.0 spec adds the ACPI IPMI opregion, which means that the ACPI AML code can also communicate with the BMC controller. This is to install the ACPI IPMI opregion and enable the ACPI to access the BMC controller through the IPMI message. It will create IPMI user interface for every IPMI device detected in ACPI namespace and install the corresponding IPMI opregion space handler. Then it can enable ACPI to access the BMC controller through the IPMI message. The following describes how to process the IPMI request in IPMI space handler: 1. format the IPMI message based on the request in AML code. IPMI system address. Now the address type is SYSTEM_INTERFACE_ADDR_TYPE IPMI net function & command IPMI message payload 2. send the IPMI message by using the function of ipmi_request_settime 3. wait for the completion of IPMI message. It can be done in different routes: One is in handled in IPMI user recv callback function. Another is handled in timeout function. 4. format the IPMI response and return it to ACPI AML code. At the same time it also addes the module dependency. The ACPI IPMI opregion will depend on the IPMI subsystem. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-12-08 02:10:18 +00:00
config ACPI_IPMI
tristate "IPMI"
ACPI / IPMI: allow ACPI_IPMI with IPMI_SSIF ACPI_IPMI driver currently depends on IPMI System Interface (IPMI_SI) driver to be enabled. IPMI_SI driver only handles KCS, SMIC and BT BMC interfaces. IPMI_SSIF is an alternative BMC communication method. It allows BMC to be accessed over an I2C bus instead of a standard interface. Change the dependency to IPMI_HANDLER so that ACPI_IPMI works with all IPMI providers. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Signed-off-by: Corey Minyard <cminyard@mvista.com> Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net>
2017-03-25 14:02:54 +00:00
depends on IPMI_HANDLER
IPMI/ACPI: Add the IPMI opregion driver to enable ACPI to access BMC controller ACPI 4.0 spec adds the ACPI IPMI opregion, which means that the ACPI AML code can also communicate with the BMC controller. This is to install the ACPI IPMI opregion and enable the ACPI to access the BMC controller through the IPMI message. It will create IPMI user interface for every IPMI device detected in ACPI namespace and install the corresponding IPMI opregion space handler. Then it can enable ACPI to access the BMC controller through the IPMI message. The following describes how to process the IPMI request in IPMI space handler: 1. format the IPMI message based on the request in AML code. IPMI system address. Now the address type is SYSTEM_INTERFACE_ADDR_TYPE IPMI net function & command IPMI message payload 2. send the IPMI message by using the function of ipmi_request_settime 3. wait for the completion of IPMI message. It can be done in different routes: One is in handled in IPMI user recv callback function. Another is handled in timeout function. 4. format the IPMI response and return it to ACPI AML code. At the same time it also addes the module dependency. The ACPI IPMI opregion will depend on the IPMI subsystem. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-12-08 02:10:18 +00:00
help
This driver enables the ACPI to access the BMC controller. And it
uses the IPMI request/response message to communicate with BMC
ACPI: clean up double words in two comments Remove the second 'on' and 'those'. Signed-off-by: Tom Rix <trix@redhat.com> [ rjw: Subject adjustments ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-02-06 14:58:03 +00:00
controller, which can be found on the server.
IPMI/ACPI: Add the IPMI opregion driver to enable ACPI to access BMC controller ACPI 4.0 spec adds the ACPI IPMI opregion, which means that the ACPI AML code can also communicate with the BMC controller. This is to install the ACPI IPMI opregion and enable the ACPI to access the BMC controller through the IPMI message. It will create IPMI user interface for every IPMI device detected in ACPI namespace and install the corresponding IPMI opregion space handler. Then it can enable ACPI to access the BMC controller through the IPMI message. The following describes how to process the IPMI request in IPMI space handler: 1. format the IPMI message based on the request in AML code. IPMI system address. Now the address type is SYSTEM_INTERFACE_ADDR_TYPE IPMI net function & command IPMI message payload 2. send the IPMI message by using the function of ipmi_request_settime 3. wait for the completion of IPMI message. It can be done in different routes: One is in handled in IPMI user recv callback function. Another is handled in timeout function. 4. format the IPMI response and return it to ACPI AML code. At the same time it also addes the module dependency. The ACPI IPMI opregion will depend on the IPMI subsystem. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-12-08 02:10:18 +00:00
To compile this driver as a module, choose M here:
the module will be called as acpi_ipmi.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
config ACPI_HOTPLUG_CPU
[ACPI] ACPI_HOTPLUG_CPU Kconfig dependency update prevent: HOTPLUG_CPU=y ACPI_PROCESSOR=y ACPI_HOTPLUG_CPU=n Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
2005-07-30 08:18:00 +00:00
bool
drivers/acpi: remove depends on CONFIG_EXPERIMENTAL The CONFIG_EXPERIMENTAL config item has not carried much meaning for a while now and is almost always enabled by default. As agreed during the Linux kernel summit, remove it from any "depends on" lines in Kconfigs. CC: Len Brown <lenb@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-17 02:53:28 +00:00
depends on ACPI_PROCESSOR && HOTPLUG_CPU
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
select ACPI_CONTAINER
ACPI: create Processor Aggregator Device driver ACPI 4.0 created the logical "processor aggregator device" as a mechinism for platforms to ask the OS to force otherwise busy processors to enter (power saving) idle. The intent is to lower power consumption to ride-out transient electrical and thermal emergencies, rather than powering off the server. On platforms that can save more power/performance via P-states, the platform will first exhaust P-states before forcing idle. However, the relative benefit of P-states vs. idle states is platform dependent, and thus this driver need not know or care about it. This driver does not use the kernel's CPU hot-plug mechanism because after the transient emergency is over, the system must be returned to its normal state, and hotplug would permanently break both cpusets and binding. So to force idle, the driver creates a power saving thread. The scheduler will migrate the thread to the preferred CPU. The thread has max priority and has SCHED_RR policy, so it can occupy one CPU. To save power, the thread will invoke the deep C-state entry instructions. To avoid starvation, the thread will sleep 5% of the time time for every second (current RT scheduler has threshold to avoid starvation, but if other CPUs are idle, the CPU can borrow CPU timer from other, which makes the mechanism not work here) Vaidyanathan Srinivasan has proposed scheduler enhancements to allow injecting idle time into the system. This driver doesn't depend on those enhancements, but could cut over to them when they are available. Peter Z. does not favor upstreaming this driver until the those scheduler enhancements are in place. However, we favor upstreaming this driver now because it is useful now, and can be enhanced over time. Signed-off-by: Shaohua Li <shaohua.li@intel.com> NACKed-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-07-27 22:11:02 +00:00
config ACPI_PROCESSOR_AGGREGATOR
tristate "Processor Aggregator"
depends on ACPI_PROCESSOR
acpi_pad: build only on X86 X86_FEATURE_MWAIT doesn't exist on ia64... Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-27 06:35:55 +00:00
depends on X86
ACPI: create Processor Aggregator Device driver ACPI 4.0 created the logical "processor aggregator device" as a mechinism for platforms to ask the OS to force otherwise busy processors to enter (power saving) idle. The intent is to lower power consumption to ride-out transient electrical and thermal emergencies, rather than powering off the server. On platforms that can save more power/performance via P-states, the platform will first exhaust P-states before forcing idle. However, the relative benefit of P-states vs. idle states is platform dependent, and thus this driver need not know or care about it. This driver does not use the kernel's CPU hot-plug mechanism because after the transient emergency is over, the system must be returned to its normal state, and hotplug would permanently break both cpusets and binding. So to force idle, the driver creates a power saving thread. The scheduler will migrate the thread to the preferred CPU. The thread has max priority and has SCHED_RR policy, so it can occupy one CPU. To save power, the thread will invoke the deep C-state entry instructions. To avoid starvation, the thread will sleep 5% of the time time for every second (current RT scheduler has threshold to avoid starvation, but if other CPUs are idle, the CPU can borrow CPU timer from other, which makes the mechanism not work here) Vaidyanathan Srinivasan has proposed scheduler enhancements to allow injecting idle time into the system. This driver doesn't depend on those enhancements, but could cut over to them when they are available. Peter Z. does not favor upstreaming this driver until the those scheduler enhancements are in place. However, we favor upstreaming this driver now because it is useful now, and can be enhanced over time. Signed-off-by: Shaohua Li <shaohua.li@intel.com> NACKed-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-07-27 22:11:02 +00:00
help
ACPI 4.0 defines processor Aggregator, which enables OS to perform
ACPI: Kconfig, fix proc aggregator text Fix two typos in the Kconfig text about ACPI_PROCESSOR_AGGREGATOR. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-10-09 13:53:24 +00:00
specific processor configuration and control that applies to all
ACPI: create Processor Aggregator Device driver ACPI 4.0 created the logical "processor aggregator device" as a mechinism for platforms to ask the OS to force otherwise busy processors to enter (power saving) idle. The intent is to lower power consumption to ride-out transient electrical and thermal emergencies, rather than powering off the server. On platforms that can save more power/performance via P-states, the platform will first exhaust P-states before forcing idle. However, the relative benefit of P-states vs. idle states is platform dependent, and thus this driver need not know or care about it. This driver does not use the kernel's CPU hot-plug mechanism because after the transient emergency is over, the system must be returned to its normal state, and hotplug would permanently break both cpusets and binding. So to force idle, the driver creates a power saving thread. The scheduler will migrate the thread to the preferred CPU. The thread has max priority and has SCHED_RR policy, so it can occupy one CPU. To save power, the thread will invoke the deep C-state entry instructions. To avoid starvation, the thread will sleep 5% of the time time for every second (current RT scheduler has threshold to avoid starvation, but if other CPUs are idle, the CPU can borrow CPU timer from other, which makes the mechanism not work here) Vaidyanathan Srinivasan has proposed scheduler enhancements to allow injecting idle time into the system. This driver doesn't depend on those enhancements, but could cut over to them when they are available. Peter Z. does not favor upstreaming this driver until the those scheduler enhancements are in place. However, we favor upstreaming this driver now because it is useful now, and can be enhanced over time. Signed-off-by: Shaohua Li <shaohua.li@intel.com> NACKed-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-07-27 22:11:02 +00:00
processors in the platform. Currently only logical processor idling
is defined, which is to reduce power consumption. This driver
ACPI: Kconfig, fix proc aggregator text Fix two typos in the Kconfig text about ACPI_PROCESSOR_AGGREGATOR. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-10-09 13:53:24 +00:00
supports the new device.
ACPI: create Processor Aggregator Device driver ACPI 4.0 created the logical "processor aggregator device" as a mechinism for platforms to ask the OS to force otherwise busy processors to enter (power saving) idle. The intent is to lower power consumption to ride-out transient electrical and thermal emergencies, rather than powering off the server. On platforms that can save more power/performance via P-states, the platform will first exhaust P-states before forcing idle. However, the relative benefit of P-states vs. idle states is platform dependent, and thus this driver need not know or care about it. This driver does not use the kernel's CPU hot-plug mechanism because after the transient emergency is over, the system must be returned to its normal state, and hotplug would permanently break both cpusets and binding. So to force idle, the driver creates a power saving thread. The scheduler will migrate the thread to the preferred CPU. The thread has max priority and has SCHED_RR policy, so it can occupy one CPU. To save power, the thread will invoke the deep C-state entry instructions. To avoid starvation, the thread will sleep 5% of the time time for every second (current RT scheduler has threshold to avoid starvation, but if other CPUs are idle, the CPU can borrow CPU timer from other, which makes the mechanism not work here) Vaidyanathan Srinivasan has proposed scheduler enhancements to allow injecting idle time into the system. This driver doesn't depend on those enhancements, but could cut over to them when they are available. Peter Z. does not favor upstreaming this driver until the those scheduler enhancements are in place. However, we favor upstreaming this driver now because it is useful now, and can be enhanced over time. Signed-off-by: Shaohua Li <shaohua.li@intel.com> NACKed-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-07-27 22:11:02 +00:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
config ACPI_THERMAL
tristate "Thermal Zone"
depends on ACPI_PROCESSOR
ACPI: register ACPI thermal zone as generic thermal zone devices Register ACPI thermal zone as thermal zone device. the new sys I/F for ACPI thermal zone will be like this: /sys/class/thermal: |thermal_zone1: |-----type: "ACPI thermal zone". RO |-----temp: the current temperature. RO |-----mode: the current working mode. RW. the default value is "kernel" which means thermal management is done by ACPI thermal driver. "echo user > mode" prevents all the ACPI thermal driver actions upon any trip points. |-----trip_point_0_temp: the threshold of trip point 0. RO. |-----trip_point_0_type: "critical". RO. the type of trip point 0 This may be one of critical/hot/passive/active[x] for an ACPI thermal zone. ... |-----trip_point_3_temp: |-----trip_point_3_type: "active[1]" Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Thomas Sujith <sujith.thomas@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-01-17 07:51:11 +00:00
select THERMAL
thermal: ACPI: Move the ACPI thermal library to drivers/acpi/ The ACPI thermal library contains functions that can be used to retrieve trip point temperature values through the platform firmware for various types of trip points. Each of these functions basically evaluates a specific ACPI object, checks if the value produced by it is reasonable and returns it (or THERMAL_TEMP_INVALID if anything fails). It made sense to hold it in drivers/thermal/ so long as it was only used by the code in that directory, but since it is also going to be used by the ACPI thermal driver located in drivers/acpi/, move it to the latter in order to keep the code related to evaluating ACPI objects defined in the specification proper together. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-10-17 20:05:23 +00:00
select ACPI_THERMAL_LIB
[ACPI] remove "default m" from acpi/Kconfig Andi Kleen suggested it was unconventional for us to "default m" on ACPI modules -- even though they are expected to be deployed as modules. But as "default n" would likely result in some users building nonsense kernels, we compromise to "default y". Distros are expected to continue to use =m in their configs. Signed-off-by: Len Brown <len.brown@intel.com>
2005-08-25 16:22:04 +00:00
default y
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
help
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
This driver supports ACPI thermal zones. Most mobile and
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
some desktop systems support ACPI thermal zones. It is HIGHLY
recommended that this option be enabled, as your processor(s)
may be damaged without it.
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
To compile this driver as a module, choose M here:
the module will be called thermal.
ACPI: platform: Add platform profile support This is the initial implementation of the platform-profile feature. It provides the details discussed and outlined in the sysfs-platform_profile document. Many modern systems have the ability to modify the operating profile to control aspects like fan speed, temperature and power levels. This module provides a common sysfs interface that platform modules can register against to control their individual profile options. Signed-off-by: Mark Pearson <markpearson@lenovo.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> [ rjw: Use full words in enum values names ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-30 00:18:26 +00:00
config ACPI_PLATFORM_PROFILE
ACPI: platform: Hide ACPI_PLATFORM_PROFILE option The ACPI_PLATFORM_PROFILE option essentially provides a library and not really an independent module. Thus it seems to be more user-friendly to hide this option and simply make drivers depending on it select it. Suggested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-02-11 20:17:00 +00:00
tristate
ACPI: platform: Add platform profile support This is the initial implementation of the platform-profile feature. It provides the details discussed and outlined in the sysfs-platform_profile document. Many modern systems have the ability to modify the operating profile to control aspects like fan speed, temperature and power levels. This module provides a common sysfs interface that platform modules can register against to control their individual profile options. Signed-off-by: Mark Pearson <markpearson@lenovo.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> [ rjw: Use full words in enum values names ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-30 00:18:26 +00:00
ACPI: prevent randconfig build failure on empty ACPI_CUSTOM_DSDT_FILE Make ACPI_CUSTOM_DSDT boolean config symbol a hidden and derived value, based on the value of ACPI_CUSTOM_DSDT_FILE (string). Only the latter is presented to the user as a config option. This fixes problems with "make randconfig" setting ACPI_CUSTOM_DSDT but leaving ACPI_CUSTOM_DSDT_FILE empty/blank. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-02-22 19:25:04 +00:00
config ACPI_CUSTOM_DSDT_FILE
string "Custom DSDT Table file to include"
default ""
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
depends on !STANDALONE
help
ACPI: update DSDT override documentation Signed-off-by: Len Brown <len.brown@intel.com>
2008-02-07 00:28:02 +00:00
This option supports a custom DSDT by linking it into the kernel.
fix typos "wich" -> "which" Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-03-24 17:23:14 +00:00
Enter the full path name to the file which includes the AmlCode
ACPI / tables: add DSDT AmlCode new declaration name support A new naming rule was added in ACPICA version 20180427 changing the DSDT AML code name from "AmlCode" to "dsdt_aml_code". That change was made by commit 83b2fa943ba8 "ACPICA: iASL: Enhance the -tc option (create AML hex file in C)". Tested: ACPICA release version 20180427+. ARM64: QCOM QDF2400 GCC: 4.8.5 20150623 Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-11-13 10:46:23 +00:00
or dsdt_aml_code declaration.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
ACPI: prevent randconfig build failure on empty ACPI_CUSTOM_DSDT_FILE Make ACPI_CUSTOM_DSDT boolean config symbol a hidden and derived value, based on the value of ACPI_CUSTOM_DSDT_FILE (string). Only the latter is presented to the user as a config option. This fixes problems with "make randconfig" setting ACPI_CUSTOM_DSDT but leaving ACPI_CUSTOM_DSDT_FILE empty/blank. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-02-22 19:25:04 +00:00
If unsure, don't enter a file name.
config ACPI_CUSTOM_DSDT
bool
default ACPI_CUSTOM_DSDT_FILE != ""
ACPI / tables: introduce ARCH_HAS_ACPI_TABLE_UPGRADE We want to use the table upgrade feature in ARM64. Introduce a new configuration option that allows that. Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-06-20 10:56:12 +00:00
config ARCH_HAS_ACPI_TABLE_UPGRADE
def_bool n
ACPI / tables: Convert initrd table override to table upgrade mechanism This patch converts the initrd table override mechanism to the table upgrade mechanism by restricting its usage to the tables released with compatibility and more recent revision. This use case has been encouraged by the ACPI specification: 1. OEMID: An OEM-supplied string that identifies the OEM. 2. OEM Table ID: An OEM-supplied string that the OEM uses to identify the particular data table. This field is particularly useful when defining a definition block to distinguish definition block functions. OEM assigns each dissimilar table a new OEM Table Id. 3. OEM Revision: An OEM-supplied revision number. Larger numbers are assumed to be newer revisions. For OEMs, good practices will ensure consistency when assigning OEMID and OEM Table ID fields in any table. The intent of these fields is to allow for a binary control system that support services can use. Because many support function can be automated, it is useful when a tool can programatically determine which table release is a compatible and more recent revision of a prior table on the same OEMID and OEM Table ID. The facility can now be used by the vendors to upgrade wrong tables for bug fixing purpose, thus lockdep disabling taint is not suitable for it and it should be a default 'y' option to implement the spec encouraged use case. Note that, by implementing table upgrade inside of ACPICA itself, it is possible to remove acpi_table_initrd_override() and tables can be upgraded by acpi_install_table() automatically. Though current ACPICA impelentation hasn't implemented this, this patched changes the table flag setting timing to allow this to be implemented in ACPICA without changing the code here. Documentation of initrd override mechanism is upgraded accordingly. Original-by: Octavian Purdila <octavian.purdila@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-11 02:13:33 +00:00
config ACPI_TABLE_UPGRADE
bool "Allow upgrading ACPI tables via initrd"
ACPI / tables: introduce ARCH_HAS_ACPI_TABLE_UPGRADE We want to use the table upgrade feature in ARM64. Introduce a new configuration option that allows that. Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-06-20 10:56:12 +00:00
depends on BLK_DEV_INITRD && ARCH_HAS_ACPI_TABLE_UPGRADE
ACPI / tables: Convert initrd table override to table upgrade mechanism This patch converts the initrd table override mechanism to the table upgrade mechanism by restricting its usage to the tables released with compatibility and more recent revision. This use case has been encouraged by the ACPI specification: 1. OEMID: An OEM-supplied string that identifies the OEM. 2. OEM Table ID: An OEM-supplied string that the OEM uses to identify the particular data table. This field is particularly useful when defining a definition block to distinguish definition block functions. OEM assigns each dissimilar table a new OEM Table Id. 3. OEM Revision: An OEM-supplied revision number. Larger numbers are assumed to be newer revisions. For OEMs, good practices will ensure consistency when assigning OEMID and OEM Table ID fields in any table. The intent of these fields is to allow for a binary control system that support services can use. Because many support function can be automated, it is useful when a tool can programatically determine which table release is a compatible and more recent revision of a prior table on the same OEMID and OEM Table ID. The facility can now be used by the vendors to upgrade wrong tables for bug fixing purpose, thus lockdep disabling taint is not suitable for it and it should be a default 'y' option to implement the spec encouraged use case. Note that, by implementing table upgrade inside of ACPICA itself, it is possible to remove acpi_table_initrd_override() and tables can be upgraded by acpi_install_table() automatically. Though current ACPICA impelentation hasn't implemented this, this patched changes the table flag setting timing to allow this to be implemented in ACPICA without changing the code here. Documentation of initrd override mechanism is upgraded accordingly. Original-by: Octavian Purdila <octavian.purdila@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-11 02:13:33 +00:00
default y
ACPI: Store valid ACPI tables passed via early initrd in reserved memblock areas A later patch will compare them with ACPI tables that get loaded at boot or runtime and if criteria match, a stored one is loaded. Signed-off-by: Thomas Renninger <trenn@suse.de> Link: http://lkml.kernel.org/r/1349043837-22659-4-git-send-email-trenn@suse.de Cc: Len Brown <lenb@kernel.org> Cc: Robert Moore <robert.moore@intel.com> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Eric Piel <eric.piel@tremplin-utc.net> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2012-09-30 22:23:54 +00:00
help
ACPI / tables: Convert initrd table override to table upgrade mechanism This patch converts the initrd table override mechanism to the table upgrade mechanism by restricting its usage to the tables released with compatibility and more recent revision. This use case has been encouraged by the ACPI specification: 1. OEMID: An OEM-supplied string that identifies the OEM. 2. OEM Table ID: An OEM-supplied string that the OEM uses to identify the particular data table. This field is particularly useful when defining a definition block to distinguish definition block functions. OEM assigns each dissimilar table a new OEM Table Id. 3. OEM Revision: An OEM-supplied revision number. Larger numbers are assumed to be newer revisions. For OEMs, good practices will ensure consistency when assigning OEMID and OEM Table ID fields in any table. The intent of these fields is to allow for a binary control system that support services can use. Because many support function can be automated, it is useful when a tool can programatically determine which table release is a compatible and more recent revision of a prior table on the same OEMID and OEM Table ID. The facility can now be used by the vendors to upgrade wrong tables for bug fixing purpose, thus lockdep disabling taint is not suitable for it and it should be a default 'y' option to implement the spec encouraged use case. Note that, by implementing table upgrade inside of ACPICA itself, it is possible to remove acpi_table_initrd_override() and tables can be upgraded by acpi_install_table() automatically. Though current ACPICA impelentation hasn't implemented this, this patched changes the table flag setting timing to allow this to be implemented in ACPICA without changing the code here. Documentation of initrd override mechanism is upgraded accordingly. Original-by: Octavian Purdila <octavian.purdila@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-11 02:13:33 +00:00
This option provides functionality to upgrade arbitrary ACPI tables
ACPI: Store valid ACPI tables passed via early initrd in reserved memblock areas A later patch will compare them with ACPI tables that get loaded at boot or runtime and if criteria match, a stored one is loaded. Signed-off-by: Thomas Renninger <trenn@suse.de> Link: http://lkml.kernel.org/r/1349043837-22659-4-git-send-email-trenn@suse.de Cc: Len Brown <lenb@kernel.org> Cc: Robert Moore <robert.moore@intel.com> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Eric Piel <eric.piel@tremplin-utc.net> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2012-09-30 22:23:54 +00:00
via initrd. No functional change if no ACPI tables are passed via
initrd, therefore it's safe to say Y.
docs: fix broken documentation links Mostly due to x86 and acpi conversion, several documentation links are still pointing to the old file. Fix them. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Reviewed-by: Wolfram Sang <wsa@the-dreams.de> Reviewed-by: Sven Van Asbroeck <TheSven73@gmail.com> Reviewed-by: Bhupesh Sharma <bhsharma@redhat.com> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2019-06-07 18:54:32 +00:00
See Documentation/admin-guide/acpi/initrd_table_override.rst for details
ACPI: Store valid ACPI tables passed via early initrd in reserved memblock areas A later patch will compare them with ACPI tables that get loaded at boot or runtime and if criteria match, a stored one is loaded. Signed-off-by: Thomas Renninger <trenn@suse.de> Link: http://lkml.kernel.org/r/1349043837-22659-4-git-send-email-trenn@suse.de Cc: Len Brown <lenb@kernel.org> Cc: Robert Moore <robert.moore@intel.com> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Eric Piel <eric.piel@tremplin-utc.net> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2012-09-30 22:23:54 +00:00
ACPI / tables: table override from built-in initrd In some scenario, we need to build initrd with kernel in a single image. This can simplify system deployment process by downloading the whole system once, such as in IC verification. This patch adds support to override ACPI tables from built-in initrd. Signed-off-by: Shunyong Yang <shunyong.yang@hxt-semitech.com> [ rjw: Minor cleanups ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-12-18 06:02:45 +00:00
config ACPI_TABLE_OVERRIDE_VIA_BUILTIN_INITRD
bool "Override ACPI tables from built-in initrd"
depends on ACPI_TABLE_UPGRADE
ACPI: Kconfig: Fix table override from built-in initrd During a rework of initramfs code the INITRAMFS_COMPRESSION config option was removed in commit 65e00e04e5ae. A leftover as a dependency broke the config option ACPI_TABLE_OVERRIDE_VIA_ BUILTIN_INITRD that is used to enable the overriding of ACPI tables from built-in initrd. Fixing the dependency. Fixes: 65e00e04e5ae ("initramfs: refactor the initramfs build rules") Signed-off-by: Robert Richter <rrichter@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-07-15 09:26:01 +00:00
depends on INITRAMFS_SOURCE!="" && INITRAMFS_COMPRESSION_NONE
ACPI / tables: table override from built-in initrd In some scenario, we need to build initrd with kernel in a single image. This can simplify system deployment process by downloading the whole system once, such as in IC verification. This patch adds support to override ACPI tables from built-in initrd. Signed-off-by: Shunyong Yang <shunyong.yang@hxt-semitech.com> [ rjw: Minor cleanups ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-12-18 06:02:45 +00:00
help
This option provides functionality to override arbitrary ACPI tables
from built-in uncompressed initrd.
docs: fix broken documentation links Mostly due to x86 and acpi conversion, several documentation links are still pointing to the old file. Fix them. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Reviewed-by: Wolfram Sang <wsa@the-dreams.de> Reviewed-by: Sven Van Asbroeck <TheSven73@gmail.com> Reviewed-by: Bhupesh Sharma <bhsharma@redhat.com> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2019-06-07 18:54:32 +00:00
See Documentation/admin-guide/acpi/initrd_table_override.rst for details
ACPI / tables: table override from built-in initrd In some scenario, we need to build initrd with kernel in a single image. This can simplify system deployment process by downloading the whole system once, such as in IC verification. This patch adds support to override ACPI tables from built-in initrd. Signed-off-by: Shunyong Yang <shunyong.yang@hxt-semitech.com> [ rjw: Minor cleanups ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-12-18 06:02:45 +00:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
config ACPI_DEBUG
bool "Debug Statements"
help
ACPI: update debug parameter documentation Reformat acpi.debug_layer and acpi.debug_level documentation so it's more readable, add some clues about how to figure out the mask bits that enable a specific ACPI_DEBUG_PRINT statement, and include some useful examples. Move the list of masks to Documentation/acpi/debug.txt (these are copies of the authoritative values in acoutput.h and acpi_drivers.h). Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-07 23:58:05 +00:00
The ACPI subsystem can produce debug output. Saying Y enables this
output and increases the kernel size by around 50K.
Use the acpi.debug_layer and acpi.debug_level kernel command-line
docs: fix broken documentation links Mostly due to x86 and acpi conversion, several documentation links are still pointing to the old file. Fix them. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Reviewed-by: Wolfram Sang <wsa@the-dreams.de> Reviewed-by: Sven Van Asbroeck <TheSven73@gmail.com> Reviewed-by: Bhupesh Sharma <bhsharma@redhat.com> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2019-06-07 18:54:32 +00:00
parameters documented in Documentation/firmware-guide/acpi/debug.rst and
docs: fix locations of several documents that got moved The previous patch renamed several files that are cross-referenced along the Kernel documentation. Adjust the links to point to the right places. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-10-18 12:12:27 +00:00
Documentation/admin-guide/kernel-parameters.rst to control the type and
ACPI: update debug parameter documentation Reformat acpi.debug_layer and acpi.debug_level documentation so it's more readable, add some clues about how to figure out the mask bits that enable a specific ACPI_DEBUG_PRINT statement, and include some useful examples. Move the list of masks to Documentation/acpi/debug.txt (these are copies of the authoritative values in acoutput.h and acpi_drivers.h). Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-07 23:58:05 +00:00
amount of debug output.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
PCI: ACPI PCI slot detection driver Detect all physical PCI slots as described by ACPI, and create entries in /sys/bus/pci/slots/. Not all physical slots are hotpluggable, and the acpiphp module does not detect them. Now we know the physical PCI geography of our system, without caring about hotplug. [kaneshige.kenji@jp.fujitsu.com: export-kobject_rename-for-pci_hotplug_core] Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Acked-by: Greg KH <greg@kroah.com> [akpm@linux-foundation.org: build fix] [akpm@linux-foundation.org: fix build with CONFIG_DMI=n] Signed-off-by: Alex Chiang <achiang@hp.com> Cc: Greg KH <greg@kroah.com> Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Cc: Len Brown <lenb@kernel.org> Acked-by: Len Brown <len.brown@intel.com> Acked-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-06-10 21:30:42 +00:00
config ACPI_PCI_SLOT
ACPI / PCI: Make pci_slot built-in only, not a module As discussed in thread at https://patchwork.kernel.org/patch/1946851/, there's no value in supporting CONFIG_ACPI_PCI_SLOT=m any more. So change Kconfig and code to only support building pci_slot as built-in driver. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-01-18 16:07:42 +00:00
bool "PCI slot detection driver"
ACPI: Make PCI slot detection driver depend on PCI Since this is ACPI PCI slot detection driver for PCI, it doesn't make sense to compile this without PCI support in place. Signed-off-by: Sinan Kaya <okaya@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-12-19 22:46:59 +00:00
depends on SYSFS && PCI
PCI: ACPI PCI slot detection driver Detect all physical PCI slots as described by ACPI, and create entries in /sys/bus/pci/slots/. Not all physical slots are hotpluggable, and the acpiphp module does not detect them. Now we know the physical PCI geography of our system, without caring about hotplug. [kaneshige.kenji@jp.fujitsu.com: export-kobject_rename-for-pci_hotplug_core] Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Acked-by: Greg KH <greg@kroah.com> [akpm@linux-foundation.org: build fix] [akpm@linux-foundation.org: fix build with CONFIG_DMI=n] Signed-off-by: Alex Chiang <achiang@hp.com> Cc: Greg KH <greg@kroah.com> Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Cc: Len Brown <lenb@kernel.org> Acked-by: Len Brown <len.brown@intel.com> Acked-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-06-10 21:30:42 +00:00
help
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
This driver creates entries in /sys/bus/pci/slots/ for all PCI
slots in the system. This can help correlate PCI bus addresses,
i.e., segment/bus/device/function tuples, with physical slots in
the system. If you are unsure, say N.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
config ACPI_CONTAINER
Driver core patches for 3.9-rc1 Here is the big driver core merge for 3.9-rc1 There are two major series here, both of which touch lots of drivers all over the kernel, and will cause you some merge conflicts: - add a new function called devm_ioremap_resource() to properly be able to check return values. - remove CONFIG_EXPERIMENTAL If you need me to provide a merged tree to handle these resolutions, please let me know. Other than those patches, there's not much here, some minor fixes and updates. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEABECAAYFAlEmV0cACgkQMUfUDdst+yncCQCfbmnQZju7kzWXk6PjdFuKspT9 weAAoMCzcAtEzzc4LXuUxxG/sXBVBCjW =yWAQ -----END PGP SIGNATURE----- Merge tag 'driver-core-3.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core patches from Greg Kroah-Hartman: "Here is the big driver core merge for 3.9-rc1 There are two major series here, both of which touch lots of drivers all over the kernel, and will cause you some merge conflicts: - add a new function called devm_ioremap_resource() to properly be able to check return values. - remove CONFIG_EXPERIMENTAL Other than those patches, there's not much here, some minor fixes and updates" Fix up trivial conflicts * tag 'driver-core-3.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (221 commits) base: memory: fix soft/hard_offline_page permissions drivercore: Fix ordering between deferred_probe and exiting initcalls backlight: fix class_find_device() arguments TTY: mark tty_get_device call with the proper const values driver-core: constify data for class_find_device() firmware: Ignore abort check when no user-helper is used firmware: Reduce ifdef CONFIG_FW_LOADER_USER_HELPER firmware: Make user-mode helper optional firmware: Refactoring for splitting user-mode helper code Driver core: treat unregistered bus_types as having no devices watchdog: Convert to devm_ioremap_resource() thermal: Convert to devm_ioremap_resource() spi: Convert to devm_ioremap_resource() power: Convert to devm_ioremap_resource() mtd: Convert to devm_ioremap_resource() mmc: Convert to devm_ioremap_resource() mfd: Convert to devm_ioremap_resource() media: Convert to devm_ioremap_resource() iommu: Convert to devm_ioremap_resource() drm: Convert to devm_ioremap_resource() ...
2013-02-21 20:05:51 +00:00
bool "Container and Module Devices"
acpi: remove reference to ACPI_HOTPLUG_IO The Kconfig entry for ACPI Container and Module Devices got added in v2.6.11. Its default value has always been set to (ACPI_HOTPLUG_MEMORY || ACPI_HOTPLUG_CPU || ACPI_HOTPLUG_IO) But the Kconfig symbol ACPI_HOTPLUG_IO has never existed. So it's pointless to use it to set this default value. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-03-11 10:53:48 +00:00
default (ACPI_HOTPLUG_MEMORY || ACPI_HOTPLUG_CPU)
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
help
This driver supports ACPI Container and Module devices (IDs
ACPI0004, PNP0A05, and PNP0A06).
[ACPI] update CONFIG_ACPI_CONTAINER Kconfig help Signed-off-by: Keiichiro Tokunaga <tokunaga.keiich@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
2005-03-02 05:00:00 +00:00
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
This helps support hotplug of nodes, CPUs, and memory.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
config ACPI_HOTPLUG_MEMORY
ACPI / scan: Make memory hotplug driver use struct acpi_scan_handler Make the ACPI memory hotplug driver use struct acpi_scan_handler for representing the object used to set up ACPI memory hotplug functionality and to remove hotplug memory ranges and data structures used by the driver before unregistering ACPI device nodes representing memory. Register the new struct acpi_scan_handler object with the help of acpi_scan_add_handler_with_hotplug() to allow user space to manipulate the attributes of the memory hotplug profile. This results in a significant reduction of the drvier's code size and removes some ACPI hotplug code duplication. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Tested-by: Toshi Kani <toshi.kani@hp.com>
2013-03-03 22:18:03 +00:00
bool "Memory Hotplug"
[PATCH] pgdat allocation for new node add (specify node id) Change the name of old add_memory() to arch_add_memory. And use node id to get pgdat for the node at NODE_DATA(). Note: Powerpc's old add_memory() is defined as __devinit. However, add_memory() is usually called only after bootup. I suppose it may be redundant. But, I'm not well known about powerpc. So, I keep it. (But, __meminit is better at least.) Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com> Cc: Dave Hansen <haveblue@us.ibm.com> Cc: "Brown, Len" <len.brown@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-27 09:53:30 +00:00
depends on MEMORY_HOTPLUG
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
help
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
This driver supports ACPI memory hotplug. The driver
fields notifications on ACPI memory devices (PNP0C80),
which represent memory ranges that may be onlined or
offlined during runtime.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
If your hardware and firmware do not support adding or
removing memory devices at runtime, you need not enable
this driver.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
x86/irq, ACPI: Implement ACPI driver to support IOAPIC hotplug Enable support of IOAPIC hotplug by: 1) reintroducing ACPI based IOAPIC driver 2) enhance pci_root driver to hook hotplug events The ACPI IOAPIC driver is always enabled if all of ACPI, PCI and IOAPIC are enabled. Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Len Brown <lenb@kernel.org> Link: http://lkml.kernel.org/r/1414387308-27148-19-git-send-email-jiang.liu@linux.intel.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-05 05:44:49 +00:00
config ACPI_HOTPLUG_IOAPIC
bool
depends on PCI
depends on X86_IO_APIC
default y
ACPI: add support for Smart Battery Most batteries today are ACPI "Control Method" batteries, but some models ship with the older "Smart Battery" that requires this code. Rich Townsend and Bruno Ducrot were the original authors. Vladimir Lebedev updated to run on latest kernel. http://bugzilla.kernel.org/show_bug.cgi?id=3734 Signed-off-by: Len Brown <len.brown@intel.com>
2006-07-01 15:36:54 +00:00
config ACPI_SBS
ACPI: SBS: Add support for power_supply class (and sysfs) Add support for power_supply class and sysfs interface of it. Refer to Documentation/power_supply_class.txt for interface description. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2007-09-26 15:43:48 +00:00
tristate "Smart Battery System"
ACPI: EC: make EC support compile-time conditional The embedded controller code is mainly used on x86 laptops and cannot work without PC style I/O port access. Make this a user-visible configuration option that is default enabled on x86 but otherwise disabled, and that can never be enabled unless CONFIG_HAS_IOPORT is also available. The empty stubs in internal.h help ignore the EC code in configurations that don't support it. In order to see those stubs, the sbshc code also has to include this header and drop duplicate declarations. All the direct callers of ec_read/ec_write already had an x86 dependency and now also need to depend on APCI_EC. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Hans de Goede <hdegoede@redhat.com> Link: https://patch.msgid.link/20241011061948.3211423-1-arnd@kernel.org [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-10-11 06:18:17 +00:00
depends on X86 && ACPI_EC
ACPI ac/battery/sbs: sysfs I/F always built in, procfs I/F disabled by default ACPI AC/Battery/SBS driver has different kernel option for procfs and sysfs I/F. This patch, 1. Change CONFIG_ACPI_PROCFS_POWER to 'n' by default so that we can remove it in the next release or two. 2. Remove CONFIG_ACPI_SYSFS_POWER and always build in the sysfs I/F of these drivers. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-10-08 05:54:57 +00:00
select POWER_SUPPLY
ACPI: add support for Smart Battery Most batteries today are ACPI "Control Method" batteries, but some models ship with the older "Smart Battery" that requires this code. Rich Townsend and Bruno Ducrot were the original authors. Vladimir Lebedev updated to run on latest kernel. http://bugzilla.kernel.org/show_bug.cgi?id=3734 Signed-off-by: Len Brown <len.brown@intel.com>
2006-07-01 15:36:54 +00:00
help
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
This driver supports the Smart Battery System, another
ACPI: SBS: Add support for power_supply class (and sysfs) Add support for power_supply class and sysfs interface of it. Refer to Documentation/power_supply_class.txt for interface description. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2007-09-26 15:43:48 +00:00
type of access to battery information, found on some laptops.
ACPI: add support for Smart Battery Most batteries today are ACPI "Control Method" batteries, but some models ship with the older "Smart Battery" that requires this code. Rich Townsend and Bruno Ducrot were the original authors. Vladimir Lebedev updated to run on latest kernel. http://bugzilla.kernel.org/show_bug.cgi?id=3734 Signed-off-by: Len Brown <len.brown@intel.com>
2006-07-01 15:36:54 +00:00
ACPI: update Kconfig help texts (no functional changes) Use "help" (not "---help---") consistently throughout. ACPI can't be a module, so if both ACPI & APM are configured, we use ACPI. Update pointers to ACPI CA and Linux ACPI projects. Replace "Compaq" with "Hewlett-Packard" in the spec developer list. Fix typo in /sys/module path. The user-space daemon is "acpid", not "acpi". Add standard "To compile this driver as a module ..." help text. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-19 21:45:47 +00:00
To compile this driver as a module, choose M here:
the modules will be called sbs and sbshc.
ACPI Hardware Error Device (PNP0C33) support Hardware Error Device (PNP0C33) is used to report some hardware errors notified via SCI, mainly the corrected errors. Some APEI Generic Hardware Error Source (GHES) may use SCI on hardware error device to notify hardware error to kernel. After receiving notification from ACPI core, it is forwarded to all listeners via a notifier chain. The listener such as APEI GHES should check corresponding error source for new events when notified. Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 06:35:17 +00:00
config ACPI_HED
tristate "Hardware Error Device"
help
This driver supports the Hardware Error Device (PNP0C33),
which is used to report some hardware errors notified via
SCI, mainly the corrected errors.
ACPI: Add support for exposing BGRT data ACPI 5.0 adds the BGRT, a table that contains a pointer to the firmware boot splash and associated metadata. This simple driver exposes it via /sys/firmware/acpi in order to allow bootsplash applications to draw their splash around the firmware image and reduce the number of jarring graphical transitions during boot. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-01-31 18:19:20 +00:00
config ACPI_BGRT
efi: Fix the ACPI BGRT driver for images located in EFI boot services memory The ACPI BGRT driver accesses the BIOS logo image when it initializes. However, ACPI 5.0 (which introduces the BGRT) recommends putting the logo image in EFI boot services memory, so that the OS can reclaim that memory. Production systems follow this recommendation, breaking the ACPI BGRT driver. Move the bulk of the BGRT code to run during a new EFI late initialization phase, which occurs after switching EFI to virtual mode, and after initializing ACPI, but before freeing boot services memory. Copy the BIOS logo image to kernel memory at that point, and make it accessible to the BGRT driver. Rework the existing ACPI BGRT driver to act as a simple wrapper exposing that image (and the properties from the BGRT) via sysfs. Signed-off-by: Josh Triplett <josh@joshtriplett.org> Link: http://lkml.kernel.org/r/93ce9f823f1c1f3bb88bdd662cce08eee7a17f5d.1348876882.git.josh@joshtriplett.org Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2012-09-29 00:57:05 +00:00
bool "Boottime Graphics Resource Table support"
LoongArch: Enable ACPI BGRT handling Add ACPI BGRT support on LoongArch so it can display image provied by acpi table at boot stage and switch to graphical UI smoothly. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2024-09-24 07:32:06 +00:00
depends on EFI && (X86 || ARM64 || LOONGARCH)
ACPI: Fix Kconfig indentation Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-11-20 13:43:10 +00:00
help
ACPI: Add support for exposing BGRT data ACPI 5.0 adds the BGRT, a table that contains a pointer to the firmware boot splash and associated metadata. This simple driver exposes it via /sys/firmware/acpi in order to allow bootsplash applications to draw their splash around the firmware image and reduce the number of jarring graphical transitions during boot. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
2012-01-31 18:19:20 +00:00
This driver adds support for exposing the ACPI Boottime Graphics
Resource Table, which allows the operating system to obtain
data from the firmware boot splash. It will appear under
/sys/firmware/acpi/bgrt/ .
ACPI: introduce CONFIG_ACPI_REDUCED_HARDWARE_ONLY ACPI hardware reduced mode exists to allow newer platforms to use a simpler form of ACPI that does not require supporting legacy versions of the specification and their associated hardware. This mode was introduced in the ACPI 5.0 specification. The ACPI hardware reduced mode is supposed to be used on systems having the HW_REDUCED_ACPI flag set in the FADT. ACPICA checks that flag to determine whether or not it should work in the HW reduced mode and there are pieces of code in it that will never be used in that case. Since some architecutres will always use the ACPI HW reduced mode, it doesn't make sense for them to ever compile support for anything else. Thus, they should set the flag ACPI_REDUCED_HARDWARE to TRUE in the ACPICA source. To enable them to do that, introduce a new kernel configuration option, CONFIG_ACPI_REDUCED_HARDWARE_ONLY, that will cause the ACPICA's ACPI_REDUCED_HARDWARE flag to be TRUE when set. Introducing this configuration item is based on suggestions from Lv Zheng saying that this does not belong in ACPICA, but rather to the Linux kernel itself. References: http://www.spinics.net/lists/linux-acpi/msg46369.html Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Al Stone <al.stone@linaro.org> [rjw: Subject and changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-17 18:51:30 +00:00
config ACPI_REDUCED_HARDWARE_ONLY
bool "Hardware-reduced ACPI support only" if EXPERT
help
ACPI / Kconfig: Remove redundant depends on ACPI Since config ACPI_REDUCED_HARDWARE_ONLY is already depended on ACPI (inside if ACPI / endif), so depdens on ACPI is redundant, remove it and fix the minor syntax problem also. Signed-off-by: Hanjun Guo <hanjun.guo@linaro.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-14 09:44:07 +00:00
This config item changes the way the ACPI code is built. When this
option is selected, the kernel will use a specialized version of
ACPICA that ONLY supports the ACPI "reduced hardware" mode. The
resulting kernel will be smaller but it will also be restricted to
running in ACPI reduced hardware mode ONLY.
ACPI: introduce CONFIG_ACPI_REDUCED_HARDWARE_ONLY ACPI hardware reduced mode exists to allow newer platforms to use a simpler form of ACPI that does not require supporting legacy versions of the specification and their associated hardware. This mode was introduced in the ACPI 5.0 specification. The ACPI hardware reduced mode is supposed to be used on systems having the HW_REDUCED_ACPI flag set in the FADT. ACPICA checks that flag to determine whether or not it should work in the HW reduced mode and there are pieces of code in it that will never be used in that case. Since some architecutres will always use the ACPI HW reduced mode, it doesn't make sense for them to ever compile support for anything else. Thus, they should set the flag ACPI_REDUCED_HARDWARE to TRUE in the ACPICA source. To enable them to do that, introduce a new kernel configuration option, CONFIG_ACPI_REDUCED_HARDWARE_ONLY, that will cause the ACPICA's ACPI_REDUCED_HARDWARE flag to be TRUE when set. Introducing this configuration item is based on suggestions from Lv Zheng saying that this does not belong in ACPICA, but rather to the Linux kernel itself. References: http://www.spinics.net/lists/linux-acpi/msg46369.html Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Al Stone <al.stone@linaro.org> [rjw: Subject and changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-17 18:51:30 +00:00
ACPI / Kconfig: Remove redundant depends on ACPI Since config ACPI_REDUCED_HARDWARE_ONLY is already depended on ACPI (inside if ACPI / endif), so depdens on ACPI is redundant, remove it and fix the minor syntax problem also. Signed-off-by: Hanjun Guo <hanjun.guo@linaro.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-14 09:44:07 +00:00
If you are unsure what to do, do not enable this option.
ACPI: introduce CONFIG_ACPI_REDUCED_HARDWARE_ONLY ACPI hardware reduced mode exists to allow newer platforms to use a simpler form of ACPI that does not require supporting legacy versions of the specification and their associated hardware. This mode was introduced in the ACPI 5.0 specification. The ACPI hardware reduced mode is supposed to be used on systems having the HW_REDUCED_ACPI flag set in the FADT. ACPICA checks that flag to determine whether or not it should work in the HW reduced mode and there are pieces of code in it that will never be used in that case. Since some architecutres will always use the ACPI HW reduced mode, it doesn't make sense for them to ever compile support for anything else. Thus, they should set the flag ACPI_REDUCED_HARDWARE to TRUE in the ACPICA source. To enable them to do that, introduce a new kernel configuration option, CONFIG_ACPI_REDUCED_HARDWARE_ONLY, that will cause the ACPICA's ACPI_REDUCED_HARDWARE flag to be TRUE when set. Introducing this configuration item is based on suggestions from Lv Zheng saying that this does not belong in ACPICA, but rather to the Linux kernel itself. References: http://www.spinics.net/lists/linux-acpi/msg46369.html Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Al Stone <al.stone@linaro.org> [rjw: Subject and changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-17 18:51:30 +00:00
ACPI: NHLT: Introduce API for the table The table is composed of a range of endpoints with each describing audio formats they support. Most of the operations involve iterating over elements of the table and filtering them. Simplify the process by implementing range of getters. While the acpi_nhlt_endpoint_mic_count() stands out a bit, it is a critical component for any AudioDSP driver to know how many digital microphones it is dealing with. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-03-19 08:30:16 +00:00
config ACPI_NHLT
bool
nfit: move to nfit/ sub-directory With the arrival of x86-machine-check support the nfit driver will add a (conditionally-compiled) source file. Prepare for this by moving all nfit source to drivers/acpi/nfit/. This is pure code movement, no functional changes. Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2016-07-24 04:24:19 +00:00
source "drivers/acpi/nfit/Kconfig"
ACPI: NUMA: Establish a new drivers/acpi/numa/ directory Currently hmat.c lives under an "hmat" directory which does not enhance the description of the file. The initial motivation for giving hmat.c its own directory was to delineate it as mm functionality in contrast to ACPI device driver functionality. As ACPI continues to play an increasing role in conveying memory location and performance topology information to the OS take the opportunity to co-locate these NUMA relevant tables in a combined directory. numa.c is renamed to srat.c and moved to drivers/acpi/numa/ along with hmat.c. Signed-off-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-11-07 01:42:55 +00:00
source "drivers/acpi/numa/Kconfig"
ACPI, APEI, APEI supporting infrastructure APEI stands for ACPI Platform Error Interface, which allows to report errors (for example from the chipset) to the operating system. This improves NMI handling especially. In addition it supports error serialization and error injection. For more information about APEI, please refer to ACPI Specification version 4.0, chapter 17. This patch provides some common functions used by more than one APEI tables, mainly framework of interpreter for EINJ and ERST. A machine readable language is defined for EINJ and ERST for OS to execute, and so to drive the firmware to fulfill the corresponding functions. The machine language for EINJ and ERST is compatible, so a common framework is defined for them. Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 06:35:12 +00:00
source "drivers/acpi/apei/Kconfig"
ACPI / DPTF: Add DPTF power participant driver This driver adds support for Dynamic Platform and Thermal Framework (DPTF) Platform Power Participant device (INT3407) support. This participant is responsible for exposing platform telemetry such as: max_platform_power platform_power_source adapter_rating battery_steady_power charger_type These attributes are presented via sysfs interface under the INT3407 platform device: $ls /sys/bus/platform/devices/INT3407\:00/dptf_power/ adapter_rating_mw battery_steady_power_mw charger_type max_platform_power_mw platform_power_source ` ACPI methods description used in this driver: PMAX: Maximum platform power that can be supported by the battery in mW. PSRC: System charge source, 0x00 = DC 0x01 = AC 0x02 = USB 0x03 = Wireless Charger ARTG: Adapter rating in mW (Maximum Adapter power) Must be 0 if no AC adapter is plugged in. CTYP: Charger Type, Traditional : 0x01 Hybrid: 0x02 NVDC: 0x03 PBSS: Returns max sustained power for battery in milliWatts. The INT3407 also contains _BTS and _BIX objects, which are compliant to ACPI 5.0, specification. Those objects are already used by ACPI battery (PNP0C0A) driver and information about them is exported via Linux power supply class registration. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-07-17 20:45:32 +00:00
source "drivers/acpi/dptf/Kconfig"
ACPI, APEI, APEI supporting infrastructure APEI stands for ACPI Platform Error Interface, which allows to report errors (for example from the chipset) to the operating system. This improves NMI handling especially. In addition it supports error serialization and error injection. For more information about APEI, please refer to ACPI Specification version 4.0, chapter 17. This patch provides some common functions used by more than one APEI tables, mainly framework of interpreter for EINJ and ERST. A machine readable language is defined for EINJ and ERST for OS to execute, and so to drive the firmware to fulfill the corresponding functions. The machine language for EINJ and ERST is compatible, so a common framework is defined for them. Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 06:35:12 +00:00
ACPI / watchdog: Add support for WDAT hardware watchdog Starting from Intel Skylake the iTCO watchdog timer registers were moved to reside in the same register space with SMBus host controller. Not all needed registers are available though and we need to unhide P2SB (Primary to Sideband) device briefly to be able to read status of required NO_REBOOT bit. The i2c-i801.c SMBus driver used to handle this and creation of the iTCO watchdog platform device. Windows, on the other hand, does not use the iTCO watchdog hardware directly even if it is available. Instead it relies on ACPI Watchdog Action Table (WDAT) table to describe the watchdog hardware to the OS. This table contains necessary information about the the hardware and also set of actions which are executed by a driver as needed. This patch implements a new watchdog driver that takes advantage of the ACPI WDAT table. We split the functionality into two parts: first part enumerates the WDAT table and if found, populates resources and creates platform device for the actual driver. The second part is the driver itself. The reason for the split is that this way we can make the driver itself to be a module and loaded automatically if the WDAT table is found. Otherwise the module is not loaded. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-20 12:30:51 +00:00
config ACPI_WATCHDOG
bool
ACPI, x86: Extended error log driver for x86 platform This H/W error log driver (a.k.a eMCA driver) is implemented based on http://www.intel.com/content/www/us/en/architecture-and-technology/enhanced-mca-logging-xeon-paper.html After errors are captured, more detailed platform specific information can be got via this new enhanced H/W error log driver. Most notably we can track memory errors back to the DIMM slot silk screen label. Signed-off-by: Chen, Gong <gong.chen@linux.intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2013-10-21 21:29:25 +00:00
config ACPI_EXTLOG
tristate "Extended Error Log support"
ACPI/extlog: Add EDAC dependency We are calling EDAC functions - make the proper dependencies explicit. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: linux-acpi@vger.kernel.org
2017-02-03 13:17:43 +00:00
depends on X86_MCE && X86_LOCAL_APIC && EDAC
Move cper.c from drivers/acpi/apei to drivers/firmware/efi cper.c contains code to decode and print "Common Platform Error Records". Originally added under drivers/acpi/apei because the only user was in that same directory - but now we have another consumer, and we shouldn't have to force CONFIG_ACPI_APEI get access to this code. Since CPER is defined in the UEFI specification - the logical home for this code is under drivers/firmware/efi/ Acked-by: Matt Fleming <matt.fleming@intel.com> Acked-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
2013-10-28 21:06:55 +00:00
select UEFI_CPER
ACPI, x86: Extended error log driver for x86 platform This H/W error log driver (a.k.a eMCA driver) is implemented based on http://www.intel.com/content/www/us/en/architecture-and-technology/enhanced-mca-logging-xeon-paper.html After errors are captured, more detailed platform specific information can be got via this new enhanced H/W error log driver. Most notably we can track memory errors back to the DIMM slot silk screen label. Signed-off-by: Chen, Gong <gong.chen@linux.intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2013-10-21 21:29:25 +00:00
help
Certain usages such as Predictive Failure Analysis (PFA) require
more information about the error than what can be described in
processor machine check banks. Most server processors log
additional information about the error in processor uncore
registers. Since the addresses and layout of these registers vary
widely from one processor to another, system software cannot
readily make use of them. To complicate matters further, some of
the additional error information cannot be constructed without
detailed knowledge about platform topology.
Enhanced MCA Logging allows firmware to provide additional error
information to system software, synchronous with MCE or CMCI. This
trace, RAS: Add eMCA trace event interface Add trace interface to elaborate all H/W error related information. Signed-off-by: Chen, Gong <gong.chen@linux.intel.com> Acked-by: Borislav Petkov <bp@suse.de> Signed-off-by: Tony Luck <tony.luck@intel.com>
2014-06-18 02:33:07 +00:00
driver adds support for that functionality with corresponding
tracepoint which carries that information to userspace.
ACPI, x86: Extended error log driver for x86 platform This H/W error log driver (a.k.a eMCA driver) is implemented based on http://www.intel.com/content/www/us/en/architecture-and-technology/enhanced-mca-logging-xeon-paper.html After errors are captured, more detailed platform specific information can be got via this new enhanced H/W error log driver. Most notably we can track memory errors back to the DIMM slot silk screen label. Signed-off-by: Chen, Gong <gong.chen@linux.intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2013-10-21 21:29:25 +00:00
ACPI/ADXL: Add address translation interface using an ACPI DSM Some new Intel servers provide an interface so that the OS can ask the BIOS to translate a system physical address to a memory address (socket, memory controller, channel, rank, dimm, etc.). This is useful for EDAC drivers that want to take the address of an error reported in a machine check bank and let the user know which DIMM may need to be replaced. Specification for this interface is available at: https://cdrdv2.intel.com/v1/dl/getContent/603354 [ Based on earlier code by Qiuxu Zhuo <qiuxu.zhuo@intel.com>. ] [ bp: Make the first pr_info() in adxl_init() pr_debug() so that it doesn't pollute every dmesg. ] Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> CC: Len Brown <lenb@kernel.org> CC: linux-acpi@vger.kernel.org CC: linux-edac@vger.kernel.org Link: http://lkml.kernel.org/r/20181015202620.23610-1-tony.luck@intel.com
2018-10-15 23:11:31 +00:00
config ACPI_ADXL
bool
ACPI: add support for configfs Register the ACPI subsystem with configfs. Signed-off-by: Octavian Purdila <octavian.purdila@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-07-08 16:13:13 +00:00
config ACPI_CONFIGFS
tristate "ACPI configfs support"
select CONFIGFS_FS
help
Select this option to enable support for ACPI configuration from
userspace. The configurable ACPI groups will be visible under
/config/acpi, assuming configfs is mounted under /config.
ACPI: Introduce Platform Firmware Runtime Update device driver Introduce the pfr_update driver which can be used for Platform Firmware Runtime code injection and driver update [1]. The user is expected to provide the EFI capsule, and pass it to the driver by writing the capsule to a device special file. The capsule is transferred by the driver to the platform firmware with the help of an ACPI _DSM method under the special ACPI Platform Firmware Runtime Update device (INTC1080), and the actual firmware update is carried out by the low-level Management Mode code in the platform firmware. This change allows certain pieces of the platform firmware to be updated on the fly while the system is running (runtime) without the need to restart it, which is key in the cases when the system needs to be available 100% of the time and it cannot afford the downtime related to restarting it, or when the work carried out by the system is particularly important, so it cannot be interrupted, and it is not practical to wait until it is complete. Link: https://uefi.org/sites/default/files/resources/Intel_MM_OS_Interface_Spec_Rev100.pdf # [1] Tested-by: Hongyu Ning <hongyu.ning@intel.com> Signed-off-by: Chen Yu <yu.c.chen@intel.com> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-12-22 04:31:41 +00:00
config ACPI_PFRUT
tristate "ACPI Platform Firmware Runtime Update and Telemetry"
depends on 64BIT
help
This mechanism allows certain pieces of the platform firmware
to be updated on the fly while the system is running (runtime)
without the need to restart it, which is key in the cases when
the system needs to be available 100% of the time and it cannot
afford the downtime related to restarting it, or when the work
carried out by the system is particularly important, so it cannot
be interrupted, and it is not practical to wait until it is complete.
The existing firmware code can be modified (driver update) or
extended by adding new code to the firmware (code injection).
ACPI: Introduce Platform Firmware Runtime Telemetry driver This driver allows user space to fetch telemetry data from the firmware with the help of the Platform Firmware Runtime Telemetry interface. Both PFRU and PFRT are based on ACPI _DSM interfaces located under special device objects in the ACPI Namespace, but these interfaces are different from each other, so it is better to provide a separate driver from each of them, even though they share some common definitions and naming conventions. Tested-by: Hongyu Ning <hongyu.ning@intel.com> Signed-off-by: Chen Yu <yu.c.chen@intel.com> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-12-22 04:32:02 +00:00
Besides, the telemetry driver allows user space to fetch telemetry
data from the firmware with the help of the Platform Firmware Runtime
Telemetry interface.
To compile the drivers as modules, choose M here:
the modules will be called pfr_update and pfr_telemetry.
ACPI: Introduce Platform Firmware Runtime Update device driver Introduce the pfr_update driver which can be used for Platform Firmware Runtime code injection and driver update [1]. The user is expected to provide the EFI capsule, and pass it to the driver by writing the capsule to a device special file. The capsule is transferred by the driver to the platform firmware with the help of an ACPI _DSM method under the special ACPI Platform Firmware Runtime Update device (INTC1080), and the actual firmware update is carried out by the low-level Management Mode code in the platform firmware. This change allows certain pieces of the platform firmware to be updated on the fly while the system is running (runtime) without the need to restart it, which is key in the cases when the system needs to be available 100% of the time and it cannot afford the downtime related to restarting it, or when the work carried out by the system is particularly important, so it cannot be interrupted, and it is not practical to wait until it is complete. Link: https://uefi.org/sites/default/files/resources/Intel_MM_OS_Interface_Spec_Rev100.pdf # [1] Tested-by: Hongyu Ning <hongyu.ning@intel.com> Signed-off-by: Chen Yu <yu.c.chen@intel.com> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-12-22 04:31:41 +00:00
ACPI: I/O Remapping Table (IORT) initial support IORT shows representation of IO topology for ARM based systems. It describes how various components are connected together on parent-child basis e.g. PCI RC -> SMMU -> ITS. Also see IORT spec. http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf Initial support allows to detect IORT table presence and save its root pointer obtained through acpi_get_table(). The pointer validity depends on acpi_gbl_permanent_mmap because if acpi_gbl_permanent_mmap is not set while using IORT nodes we would dereference unmapped pointers. For the aforementioned reason call acpi_iort_init() from acpi_init() which guarantees acpi_gbl_permanent_mmap to be set at that point. Add generic helpers which are helpful for scanning and retrieving information from IORT table content. List of the most important helpers: - iort_find_dev_node() finds IORT node for a given device - iort_node_map_rid() maps device RID and returns IORT node which provides final translation IORT support is placed under drivers/acpi/arm64/ new directory due to its ARM64 specific nature. The code there is considered only for ARM64. The long term plan is to keep all ARM64 specific tables support in this place e.g. GTDT table. Signed-off-by: Tomasz Nowicki <tn@semihalf.com> Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2016-09-12 18:54:20 +00:00
if ARM64
source "drivers/acpi/arm64/Kconfig"
LoongArch: Add SMT (Simultaneous Multi-Threading) support Loongson-3A6000 has SMT (Simultaneous Multi-Threading) support, each physical core has two logical cores (threads). This patch add SMT probe and scheduler support via ACPI PPTT. If SCHED_SMT enabled, Loongson-3A6000 is treated as 4 cores, 8 threads; If SCHED_SMT disabled, Loongson-3A6000 is treated as 8 cores, 8 threads. Remove smp_num_siblings to support HMP (Heterogeneous Multi-Processing). Signed-off-by: Liupu Wang <wangliupu@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2023-06-29 12:58:43 +00:00
endif
ACPI: Enable PPTT support on ARM64 Now that we have a PPTT parser, in preparation for its use on arm64, lets build it. Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Vijaya Kumar K <vkilari@codeaurora.org> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2018-05-11 23:58:01 +00:00
config ACPI_PPTT
bool
ACPI: I/O Remapping Table (IORT) initial support IORT shows representation of IO topology for ARM based systems. It describes how various components are connected together on parent-child basis e.g. PCI RC -> SMMU -> ITS. Also see IORT spec. http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf Initial support allows to detect IORT table presence and save its root pointer obtained through acpi_get_table(). The pointer validity depends on acpi_gbl_permanent_mmap because if acpi_gbl_permanent_mmap is not set while using IORT nodes we would dereference unmapped pointers. For the aforementioned reason call acpi_iort_init() from acpi_init() which guarantees acpi_gbl_permanent_mmap to be set at that point. Add generic helpers which are helpful for scanning and retrieving information from IORT table content. List of the most important helpers: - iort_find_dev_node() finds IORT node for a given device - iort_node_map_rid() maps device RID and returns IORT node which provides final translation IORT support is placed under drivers/acpi/arm64/ new directory due to its ARM64 specific nature. The code there is considered only for ARM64. The long term plan is to keep all ARM64 specific tables support in this place e.g. GTDT table. Signed-off-by: Tomasz Nowicki <tn@semihalf.com> Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2016-09-12 18:54:20 +00:00
ACPI: PCC: Implement OperationRegion handler for the PCC Type 3 subtype PCC OpRegion provides a mechanism to communicate with the platform directly from the AML. PCCT provides the list of PCC channel available in the platform, a subset or all of them can be used in PCC Opregion. This patch registers the PCC OpRegion handler before ACPI tables are loaded. This relies on the special context data passed to identify and set up the PCC channel before the OpRegion handler is executed for the first time. Typical PCC Opregion declaration looks like this: OperationRegion (PFRM, PCC, 2, 0x74) Field (PFRM, ByteAcc, NoLock, Preserve) { SIGN, 32, FLGS, 32, LEN, 32, CMD, 32, DATA, 800 } It contains four named double words followed by 100 bytes of buffer names DATA. ASL can fill out the buffer something like: /* Create global or local buffer */ Name (BUFF, Buffer (0x0C){}) /* Create double word fields over the buffer */ CreateDWordField (BUFF, 0x0, WD0) CreateDWordField (BUFF, 0x04, WD1) CreateDWordField (BUFF, 0x08, WD2) /* Fill the named fields */ WD0 = 0x50434300 SIGN = BUFF WD0 = 1 FLGS = BUFF WD0 = 0x10 LEN = BUFF /* Fill the payload in the DATA buffer */ WD0 = 0 WD1 = 0x08 WD2 = 0 DATA = BUFF /* Write to CMD field to trigger handler */ WD0 = 0x4404 CMD = BUFF This buffer is received by acpi_pcc_opregion_space_handler. This handler will fetch the complete buffer via internal_pcc_buffer. The setup handler will receive the special PCC context data which will contain the PCC channel index which used to set up the channel. The buffer pointer and length is saved in region context which is then used in the handler. (kernel test robot: Build failure with CONFIG_ACPI_DEBUGGER) Link: https://lore.kernel.org/r/202201041539.feAV0l27-lkp@intel.com Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-01-04 19:51:08 +00:00
config ACPI_PCC
bool "ACPI PCC Address Space"
depends on PCC
default y
help
The PCC Address Space also referred as PCC Operation Region pertains
to the region of PCC subspace that succeeds the PCC signature.
The PCC Operation Region works in conjunction with the PCC Table
(Platform Communications Channel Table). PCC subspaces that are
marked for use as PCC Operation Regions must not be used as PCC
subspaces for the standard ACPI features such as CPPC, RASF, PDTT and
MPST. These standard features must always use the PCC Table instead.
Enable this feature if you want to set up and install the PCC Address
Space handler to handle PCC OpRegion in the firmware.
ACPI: Implement a generic FFH Opregion handler This registers the FFH OpRegion handler before ACPI tables are loaded. The platform support for the same is checked via Platform-Wide OSPM Capabilities(OSC) before registering the OpRegion handler. It relies on the special context data passed to offset and the length. However the interpretation of the values is platform/architecture specific. This generic handler just passed all the information to the platform/architecture specific callback. It also implements the default callbacks which return as not supported. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-11-10 13:45:04 +00:00
config ACPI_FFH
bool "ACPI FFH Address Space"
default n
help
The FFH(Fixed Function Hardware) Address Space also referred as FFH
Operation Region allows to define platform specific opregion.
Enable this feature if you want to set up and install the FFH Address
Space handler to handle FFH OpRegion in the firmware.
ACPI / PMIC: Split out Kconfig and Makefile specific for ACPI PMIC It's a bit better to maintain and allows to avoid mistakes in the future with PMIC OpRegion drivers, if we split out Kconfig and Makefile for ACPI PMIC to its own folder. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-08-14 13:27:25 +00:00
source "drivers/acpi/pmic/Kconfig"
ACPI: Add driver for the VIOT table The ACPI Virtual I/O Translation Table describes topology of para-virtual platforms, similarly to vendor tables DMAR, IVRS and IORT. For now it describes the relation between virtio-iommu and the endpoints it manages. Three steps are needed to configure DMA of endpoints: (1) acpi_viot_init(): parse the VIOT table, find or create the fwnode associated to each vIOMMU device. This needs to happen after acpi_scan_init(), because it relies on the struct device and their fwnode to be available. (2) When probing the vIOMMU device, the driver registers its IOMMU ops within the IOMMU subsystem. This step doesn't require any intervention from the VIOT driver. (3) viot_iommu_configure(): before binding the endpoint to a driver, find the associated IOMMU ops. Register them, along with the endpoint ID, into the device's iommu_fwspec. If step (3) happens before step (2), it is deferred until the IOMMU is initialized, then retried. Tested-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Link: https://lore.kernel.org/r/20210618152059.1194210-4-jean-philippe@linaro.org Signed-off-by: Joerg Roedel <jroedel@suse.de>
2021-06-18 15:20:58 +00:00
config ACPI_VIOT
bool
ACPI: Move PRM config option under the main ACPI config Currently PRM(Platform Runtime Mechanism) config option is listed along with the main ACPI (Advanced Configuration and Power Interface) option at the same level. On ARM64 platforms unlike x86, ACPI option is listed at the topmost level of configuration menu. It is rather very confusing to see PRM option also listed along with ACPI in the topmost level. Move the same under ACPI config option. No functional change, just changes the level of visibility of this option under the configuration menu. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-06-28 12:53:46 +00:00
config ACPI_PRMT
bool "Platform Runtime Mechanism Support"
acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers Instead of bypassing the kernel's adaptation layer for performing EFI runtime calls, wire up ACPI PRM handling into it. This means these calls can no longer occur concurrently with EFI runtime calls, and will be made from the EFI runtime workqueue. It also means any page faults occurring during PRM handling will be identified correctly as originating in firmware code. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2023-07-02 09:57:34 +00:00
depends on EFI_RUNTIME_WRAPPERS && (X86_64 || ARM64)
ACPI: Move PRM config option under the main ACPI config Currently PRM(Platform Runtime Mechanism) config option is listed along with the main ACPI (Advanced Configuration and Power Interface) option at the same level. On ARM64 platforms unlike x86, ACPI option is listed at the topmost level of configuration menu. It is rather very confusing to see PRM option also listed along with ACPI in the topmost level. Move the same under ACPI config option. No functional change, just changes the level of visibility of this option under the configuration menu. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-06-28 12:53:46 +00:00
default y
help
Platform Runtime Mechanism (PRM) is a firmware interface exposing a
set of binary executables that can be called from the AML interpreter
or directly from device drivers.
Say Y to enable the AML interpreter to execute the PRM code.
While this feature is optional in principle, leaving it out may
substantially increase computational overhead related to the
initialization of some server systems.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
endif # ACPI
x86/jailhouse: Enable PMTIMER Jailhouse exposes the PMTIMER as only reference clock to all cells. Pick up its address from the setup data. Allow to enable the Linux support of it by relaxing its strict dependency on ACPI. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: jailhouse-dev@googlegroups.com Link: https://lkml.kernel.org/r/6d5c3fadd801eb3fba9510e2d3db14a9c404a1a0.1511770314.git.jan.kiszka@siemens.com
2017-11-27 08:11:48 +00:00
config X86_PM_TIMER
bool "Power Management Timer Support" if EXPERT
depends on X86 && (ACPI || JAILHOUSE_GUEST)
default y
help
The Power Management Timer is available on all ACPI-capable,
in most cases even if ACPI is unusable or blacklisted.
This timing source is not affected by power management features
like aggressive processor idling, throttling, frequency and/or
voltage scaling, unlike the commonly used Time Stamp Counter
(TSC) timing source.
You should nearly always say Y here because many modern
systems require this timer.
Reference in New Issue Copy Permalink