UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/drivers/acpi/Kconfig

588 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 22:07:57 +08: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-17 06:20:36 +08:00
#
# ACPI Configuration
#
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 13:40:59 +08: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-30 05:20:38 +08:00
bool "ACPI (Advanced Configuration and Power Interface) Support"
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-17 06:20:36 +08:00
depends on !IA64_HP_SIM
ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64 When ACPI was originally merged for arm64 it had only been tested on emulators and not on real physical platforms and no platforms were relying on it. This meant that there were concerns that there might be serious issues attempting to use it on practical systems so it had a dependency on EXPERT added to warn people that it was in an early stage of development with very little practical testing. Since then things have moved on a bit. We have seen people testing on real hardware and now have people starting to produce some platforms (the most prominent being the 96boards Cello) which only have ACPI support and which build and run to some useful extent with mainline. This is not to say that ACPI support or support for these systems is completely done, there are still areas being worked on such as PCI, but at this point it seems that we can be reasonably sure that ACPI will be viable for use on ARM64 and that the already merged support works for the cases it handles. For the AMD Seattle based platforms support outside of PCI has been fairly complete in mainline a few releases now. This is also not to say that we don't have vendors working with ACPI who are trying do things that we would not consider optimal but it does not appear that the EXPERT dependency is having a substantial impact on these vendors. Given all this it seems that at this point the EXPERT dependency mainly creates inconvenience for users with systems that are doing the right thing and gets in the way of including the ACPI code in the testing that people are doing on mainline. Removing it should help our ongoing testing cover those platforms with only ACPI support and help ensure that when ACPI code is merged any problems it causes for other users are more easily discovered. Signed-off-by: Mark Brown <broonie@kernel.org> Acked-by: Graeme Gregory <graeme.gregory@linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Al Stone <ahs3@redhat.com> Acked-by: Hanjun Guo <hanjun.guo@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Roy Franz <roy.franz@hpe.com> Acked-by: Olof Johansson <olof@lixom.net> Acked-by: Timur Tabi <timur@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-15 15:53:42 +08:00
depends on IA64 || X86 || ARM64
ACPI: Kconfig: ACPI should depend on, not select PCI Otherwise, illegal configurations like X86_VOYAGER=y, PCI=y are possible. This patch also fixes the options select'ing ACPI to also select PCI. 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>
2006-03-29 06:04:00 +08:00
depends on PCI
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 11:34:36 +08:00
select PNP
ACPI / ARM64: Don't enable ACPI by default on ARM64 If ACPI is selectable it is enabled by default. This is a good choice for architectures where the overwhelming majority of systems use ACPI like x86 and IA-64 but is less clear for architectures where it's less common like ARM64. Change the default selection so that it's only done explicitly on those architectures where ACPI is universally used. Signed-off-by: Mark Brown <broonie@kernel.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Hanjun Guo <hanjun.guo@linaro.org> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-15 15:53:41 +08:00
default y if (IA64 || 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-20 05:45:47 +08: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-17 06:20:36 +08: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-20 05:45:47 +08: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-17 06:20:36 +08: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-20 05:45:47 +08: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-17 06:20:36 +08: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-20 05:45:47 +08:00
The project home page for the Linux ACPI subsystem is here:
ACPI / PM / Documentation: Replace outdated project links and addresses Some links to projects web pages and e-mail addresses in ACPI/PM documentation and Kconfig are outdated, so update them. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-11 05:25:58 +08:00
<https://01.org/linux-acpi>
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-17 06:20:36 +08: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-20 05:45:47 +08:00
Component Architecture (ACPI CA). For more information on the
ACPI CA, see:
<http://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-17 06:20:36 +08: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 20:59:48 +08: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-20 05:45:47 +08:00
The specification is available at:
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-17 06:20:36 +08:00
<http://www.acpi.info>
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 20:59:48 +08:00
<http://www.uefi.org/acpi/specs>
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-17 06:20:36 +08: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 16:53:27 +08: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 18:02:52 +08: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 18:02:54 +08: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-25 01:58:51 +08: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 22:02:39 +08: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-11 00:08:52 +08:00
config ACPI_CCA_REQUIRED
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 10:25:56 +08: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 10:43:00 +08: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 10:25:56 +08: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 10:43:14 +08: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 10:25:56 +08: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 10:43:14 +08:00
if ACPI_DEBUGGER
config ACPI_DEBUGGER_USER
tristate "Userspace debugger accessiblity"
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-28 04:54:13 +08: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 23:09:51 +08: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-28 04:54:13 +08:00
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-06 07:24:03 +08: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 15:33:16 +08: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-23 02:58:43 +08: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 22:02:39 +08: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 15:33:16 +08:00
default y
ACPI: Revert "ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c" The commit 1e2d9cd and 7d7ee95 remove ACPI Proc Battery directory and breaks some old userspace tools. This patch is to revert 7d7ee95. Fixes: 7d7ee958867a (ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c) Cc: 3.13+ <stable@vger.kernel.org> # 3.13+ Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-04 11:07:24 +08:00
config ACPI_PROCFS_POWER
bool "Deprecated power /proc/acpi directories"
ACPI / proc: make ACPI_PROCFS_POWER X86 only The ACPI procfs power interface is initialized by compilation units that are only selectable on X86 platforms. Since its usage is deprecated and it cannot even be used on platforms other than X86 it should be compiled in only on X86 platforms. This patch makes CONFIG_ACPI_PROCFS_POWER dependent on X86, so that other architectures are prevented from compiling it in for no purpose. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-05-01 18:27:01 +08:00
depends on X86 && PROC_FS
ACPI: Revert "ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c" The commit 1e2d9cd and 7d7ee95 remove ACPI Proc Battery directory and breaks some old userspace tools. This patch is to revert 7d7ee95. Fixes: 7d7ee958867a (ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c) Cc: 3.13+ <stable@vger.kernel.org> # 3.13+ Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-04 11:07:24 +08:00
help
For backwards compatibility, this option allows
deprecated power /proc/acpi/ directories to exist, even when
they have been replaced by functions in /sys.
The deprecated directories (and their replacements) include:
ACPI / Kconfig: Update ACPI_PROCFS_POWER help text Fix grammar and punctuation (end sentences with a period) in the Kconfig help text for ACPI_PROCFS_POWER. I was looking at this since it appears to be going away (again, some day) and I have a working script that uses this info to tell me battery usage. I can update the script to use /sys/class/power_supply (in theory) but the contents (with units) should be documented in Documentation/ABI/ before /proc/acpi/battery/ is removed (IMO). Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-03 08:55:54 +08:00
/proc/acpi/battery/* (/sys/class/power_supply/*) and
/proc/acpi/ac_adapter/* (sys/class/power_supply/*).
ACPI: Revert "ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c" The commit 1e2d9cd and 7d7ee95 remove ACPI Proc Battery directory and breaks some old userspace tools. This patch is to revert 7d7ee95. Fixes: 7d7ee958867a (ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c) Cc: 3.13+ <stable@vger.kernel.org> # 3.13+ Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-04 11:07:24 +08:00
This option has no effect on /proc/acpi/ directories
ACPI / Kconfig: Update ACPI_PROCFS_POWER help text Fix grammar and punctuation (end sentences with a period) in the Kconfig help text for ACPI_PROCFS_POWER. I was looking at this since it appears to be going away (again, some day) and I have a working script that uses this info to tell me battery usage. I can update the script to use /sys/class/power_supply (in theory) but the contents (with units) should be documented in Documentation/ABI/ before /proc/acpi/battery/ is removed (IMO). Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-03 08:55:54 +08:00
and functions which do not yet exist in /sys.
ACPI: Revert "ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c" The commit 1e2d9cd and 7d7ee95 remove ACPI Proc Battery directory and breaks some old userspace tools. This patch is to revert 7d7ee95. Fixes: 7d7ee958867a (ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c) Cc: 3.13+ <stable@vger.kernel.org> # 3.13+ Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-04 11:07:24 +08:00
This option, together with the proc directories, will be
ACPI / proc: Do not say when /proc interfaces will be deleted in Kconfig Do not tell people in the Kconfig help when exactly we are going to remove the deprecated ACPI interfaces in /proc, because, honestly, we don't know. We will remove them when they are not used any more. In particular, do not tell them that the interfaces will be removed in a kernel release that already happened long ago. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-10 19:51:36 +08:00
deleted in the future.
ACPI: Revert "ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c" The commit 1e2d9cd and 7d7ee95 remove ACPI Proc Battery directory and breaks some old userspace tools. This patch is to revert 7d7ee95. Fixes: 7d7ee958867a (ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c) Cc: 3.13+ <stable@vger.kernel.org> # 3.13+ Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-04 11:07:24 +08:00
ACPI / Kconfig: Update ACPI_PROCFS_POWER help text Fix grammar and punctuation (end sentences with a period) in the Kconfig help text for ACPI_PROCFS_POWER. I was looking at this since it appears to be going away (again, some day) and I have a working script that uses this info to tell me battery usage. I can update the script to use /sys/class/power_supply (in theory) but the contents (with units) should be documented in Documentation/ABI/ before /proc/acpi/battery/ is removed (IMO). Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-03 08:55:54 +08:00
Say N to delete power /proc/acpi/ directories that have moved to /sys.
ACPI: Revert "ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c" The commit 1e2d9cd and 7d7ee95 remove ACPI Proc Battery directory and breaks some old userspace tools. This patch is to revert 7d7ee95. Fixes: 7d7ee958867a (ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c) Cc: 3.13+ <stable@vger.kernel.org> # 3.13+ Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-04 11:07:24 +08:00
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-03 07:06:00 +08: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 22:44:17 +08: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-03 07:06:00 +08: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: 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 19:11:31 +08:00
config ACPI_EC_DEBUGFS
tristate "EC read/write access through /sys/kernel/debug/ec"
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-30 04:30:24 +08:00
default n
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 19:11:31 +08: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-30 04:30:24 +08: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 21:22:10 +08: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-30 04:30:24 +08: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 19:11:31 +08: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-30 04:30:24 +08: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 19:11:31 +08: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-17 06:20:36 +08:00
config ACPI_AC
tristate "AC Adapter"
ACPI: use select POWER_SUPPLY for AC, BATTERY and SBS POWER_SUPPLY is needed for AC, battery, and SBS sysfs support. Use 'select' instead of 'depends on', as it is will not be selected by anything else, leading to confusion. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Tested-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-30 05:08:59 +08:00
depends on X86
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 13:54:57 +08: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-26 00:22:04 +08: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-17 06:20:36 +08: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-20 05:45:47 +08: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-26 00:22:04 +08: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-17 06:20:36 +08: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-20 05:45:47 +08: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-17 06:20:36 +08:00
config ACPI_BATTERY
tristate "Battery"
ACPI: use select POWER_SUPPLY for AC, BATTERY and SBS POWER_SUPPLY is needed for AC, battery, and SBS sysfs support. Use 'select' instead of 'depends on', as it is will not be selected by anything else, leading to confusion. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Tested-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-30 05:08:59 +08:00
depends on X86
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 13:54:57 +08: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-26 00:22:04 +08: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-17 06:20:36 +08: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-20 05:45:47 +08: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-17 06:20:36 +08: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 13:40:13 +08: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-26 00:22:04 +08: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-17 06:20:36 +08: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-20 05:45:47 +08: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-13 06:11:00 +08: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-20 05:45:47 +08: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-17 06:20:36 +08:00
config ACPI_VIDEO
tristate "Video"
ACPI / video: fix ACPI_VIDEO dependencies ACPI_VIDEO stopped depending on VIDEO_OUTPUT_CONTROL over 3 years ago (see commit 677bd810, "ACPI video: remove output switching control".) So it's about time to remove the Kconfig dependency between these two options. Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-17 22:46:44 +08:00
depends on X86 && 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-18 05:41:05 +08:00
depends on INPUT
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 16:07:13 +08: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-17 06:20:36 +08: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-20 05:45:47 +08: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-17 06:20:36 +08: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-20 05:45:47 +08: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-17 06:20:36 +08: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 15:43:29 +08: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-26 00:22:04 +08: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-17 06:20:36 +08: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-20 05:45:47 +08: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-17 06:20:36 +08: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-20 05:45:47 +08: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 20:51:01 +08: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-10 05:22:28 +08: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 11:10:28 +08:00
bool "Dock"
Revert "Revert "ACPI: dock driver"" This reverts 953969ddf5b049361ed1e8471cc43dc4134d2a6f commit.
2006-07-10 05:22:28 +08: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-20 05:45:47 +08: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-21 05:30:25 +08: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 21:40:25 +08:00
config ACPI_CPU_FREQ_PSS
bool
select THERMAL
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-20 01:52:53 +08:00
config ACPI_PROCESSOR_CSTATE
def_bool y
depends on IA64 || X86
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 21:40:26 +08: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-11 03:55:13 +08: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 22:01:19 +08: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-17 06:20:36 +08:00
config ACPI_PROCESSOR
tristate "Processor"
ACPI: Allow selection of the ACPI processor driver for ARM64 Now that the ACPI processor driver has been decoupled from the C states and P states functionality, make it selectable on ARM64 so that it can be used by others e.g. CPPC. The C states and P states code is selected only on X86 or IA64 until the relevant support is added on ARM64. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-09-10 04:27:08 +08:00
depends on X86 || IA64 || ARM64
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-20 01:52:59 +08:00
select ACPI_PROCESSOR_IDLE
ACPI: Allow selection of the ACPI processor driver for ARM64 Now that the ACPI processor driver has been decoupled from the C states and P states functionality, make it selectable on ARM64 so that it can be used by others e.g. CPPC. The C states and P states code is selected only on X86 or IA64 until the relevant support is added on ARM64. Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-09-10 04:27:08 +08:00
select ACPI_CPU_FREQ_PSS if X86 || IA64
[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-26 00:22:04 +08: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-17 06:20:36 +08: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 21:40:25 +08: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-20 05:45:47 +08: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 13:14:51 +08: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 10:10:18 +08: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 22:02:54 +08: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 10:10:18 +08:00
default n
help
This driver enables the ACPI to access the BMC controller. And it
uses the IPMI request/response message to communicate with BMC
controller, which can be found on on the server.
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-17 06:20:36 +08: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 16:18:00 +08: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 10:53:28 +08: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-17 06:20:36 +08:00
select ACPI_CONTAINER
[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 16:18:00 +08: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-17 06:20:36 +08:00
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-28 06:11:02 +08: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 14:35:55 +08: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-28 06:11:02 +08: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 21:53:24 +08: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-28 06:11:02 +08: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 21:53:24 +08: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-28 06:11:02 +08: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-17 06:20:36 +08: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 15:51:11 +08: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-26 00:22:04 +08: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-17 06:20:36 +08: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-20 05:45:47 +08: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-17 06:20:36 +08: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-20 05:45:47 +08:00
To compile this driver as a module, choose M here:
the module will be called 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-17 06:20:36 +08:00
config ACPI_NUMA
bool "NUMA support"
depends on NUMA
ACPI / NUMA: Enable ACPI based NUMA on ARM64 Add function needed for cpu to node mapping, and enable ACPI based NUMA for ARM64 in Kconfig Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Robert Richter <rrichter@cavium.com> [david.daney@cavium.com added ACPI_NUMA default to y for ARM64] Signed-off-by: David Daney <david.daney@cavium.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-06-17 11:53:02 +08:00
depends on (X86 || IA64 || ARM64)
default y if IA64_GENERIC || IA64_SGI_SN2 || ARM64
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-17 06:20:36 +08: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-23 03:25:04 +08: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-17 06:20:36 +08:00
depends on !STANDALONE
help
ACPI: update DSDT override documentation Signed-off-by: Len Brown <len.brown@intel.com>
2008-02-07 08:28:02 +08:00
This option supports a custom DSDT by linking it into the kernel.
See Documentation/acpi/dsdt-override.txt
fix typos "wich" -> "which" Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-03-25 01:23:14 +08:00
Enter the full path name to the file which includes the AmlCode
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-17 06:20:36 +08: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-23 03:25:04 +08: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 18:56:12 +08: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 10:13:33 +08: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 18:56:12 +08: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 10:13:33 +08: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-10-01 06:23:54 +08: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 10:13:33 +08: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-10-01 06:23:54 +08:00
via initrd. No functional change if no ACPI tables are passed via
initrd, therefore it's safe to say Y.
See Documentation/acpi/initrd_table_override.txt for details
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-17 06:20:36 +08:00
config ACPI_DEBUG
bool "Debug Statements"
default n
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-08 07:58:05 +08: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
parameters documented in Documentation/acpi/debug.txt 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 20:12:27 +08: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-08 07:58:05 +08: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-17 06:20:36 +08: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-11 05:30:42 +08: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-19 00:07:42 +08:00
bool "PCI slot detection driver"
PCI: drivers/pci/slot.c should depend on CONFIG_SYSFS There is no way to interact with a physical PCI slot without sysfs, so encode the dependency and prevent this build error: drivers/pci/slot.c: In function 'pci_hp_create_module_link': drivers/pci/slot.c:327: error: 'module_kset' undeclared This patch _should_ make pci-sysfs.o depend on CONFIG_SYSFS too, but we cannot (yet) because the PCI core merrily assumes the existence of sysfs: drivers/built-in.o: In function `pci_bus_add_device': drivers/pci/bus.c:89: undefined reference to `pci_create_sysfs_dev_files' drivers/built-in.o: In function `pci_stop_dev': drivers/pci/remove.c:24: undefined reference to `pci_remove_sysfs_dev_files' So do the minimal bit for now and figure out how to untangle it later. Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fix-suggested-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-06-18 09:03:57 +08:00
depends on SYSFS
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-11 05:30:42 +08:00
default n
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-20 05:45:47 +08: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-17 06:20:36 +08: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-22 04:05:51 +08: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 18:53:48 +08: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-20 05:45:47 +08: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 13:00:00 +08: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-20 05:45:47 +08:00
This helps support hotplug of nodes, CPUs, and memory.
To compile this driver as a module, choose M here:
the module will be called container.
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-17 06:20:36 +08: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-04 06:18:03 +08: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 17:53:30 +08: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-17 06:20:36 +08: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-20 05:45:47 +08: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-17 06:20:36 +08: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-20 05:45:47 +08: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-17 06:20:36 +08: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-20 05:45:47 +08:00
To compile this driver as a module, choose M here:
the module will be called acpi_memhotplug.
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 23:36:54 +08: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 13:44:49 +08: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 23:36:54 +08: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 23:43:48 +08:00
tristate "Smart Battery System"
ACPI: sbs: remove I2C Kconfig dependency SBS does not depend on I2C. Signed-off-by: Vladimir Lebedev <vladimir.p.lebedev@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2007-03-19 22:45:50 +08:00
depends on X86
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 13:54:57 +08: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 23:36:54 +08: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-20 05:45:47 +08: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 23:43:48 +08: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 23:36:54 +08: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-20 05:45:47 +08: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 14:35:17 +08: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: Split out custom_method functionality into an own driver With /sys/kernel/debug/acpi/custom_method root can write to arbitrary memory and increase his priveleges, even if these are restricted. -> Make this an own debug .config option and warn about the security issue in the config description. -> Still keep acpi/debugfs.c which now only creates an empty /sys/kernel/debug/acpi directory. There might be other users of it later. Signed-off-by: Thomas Renninger <trenn@suse.de> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: rui.zhang@intel.com Signed-off-by: Len Brown <len.brown@intel.com>
2011-05-26 18:26:24 +08:00
config ACPI_CUSTOM_METHOD
tristate "Allow ACPI methods to be inserted/replaced at run time"
depends on DEBUG_FS
default n
help
Kconfig: acpi: Fix typo in comment. The below fixes a typo I found in a comment. Signed-off-by: Justin P. Mattock <justinmattock@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2012-01-04 00:49:48 +08:00
This debug facility allows ACPI AML methods to be inserted and/or
ACPI: Split out custom_method functionality into an own driver With /sys/kernel/debug/acpi/custom_method root can write to arbitrary memory and increase his priveleges, even if these are restricted. -> Make this an own debug .config option and warn about the security issue in the config description. -> Still keep acpi/debugfs.c which now only creates an empty /sys/kernel/debug/acpi directory. There might be other users of it later. Signed-off-by: Thomas Renninger <trenn@suse.de> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: rui.zhang@intel.com Signed-off-by: Len Brown <len.brown@intel.com>
2011-05-26 18:26:24 +08:00
replaced without rebooting the system. For details refer to:
Documentation/acpi/method-customizing.txt.
NOTE: This option is security sensitive, because it allows arbitrary
kernel memory to be written to by root (uid=0) users, allowing them
to bypass certain security measures (e.g. if root is not allowed to
load additional kernel modules after boot, this feature may be used
to override that restriction).
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-02-01 02:19:20 +08: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 08:57:05 +08:00
bool "Boottime Graphics Resource Table support"
efi/bgrt: Enable ACPI BGRT handling on arm64 Now that the ACPI BGRT handling code has been made generic, we can enable it for arm64. Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> [ Updated commit log to reflect that BGRT is only enabled for arm64, and added missing 'return' statement to the dummy acpi_parse_bgrt() function. ] Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170404160245.27812-8-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-04-05 00:02:41 +08:00
depends on EFI && (X86 || ARM64)
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-02-01 02:19:20 +08:00
help
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-18 02:51:30 +08:00
config ACPI_REDUCED_HARDWARE_ONLY
bool "Hardware-reduced ACPI support only" if EXPERT
def_bool n
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 17:44:07 +08: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-18 02:51:30 +08: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 17:44:07 +08: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-18 02:51:30 +08:00
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 12:24:19 +08:00
source "drivers/acpi/nfit/Kconfig"
libnvdimm: control (ioctl) messages for nvdimm_bus and nvdimm devices Most discovery/configuration of the nvdimm-subsystem is done via sysfs attributes. However, some nvdimm_bus instances, particularly the ACPI.NFIT bus, define a small set of messages that can be passed to the platform. For convenience we derive the initial libnvdimm-ioctl command formats directly from the NFIT DSM Interface Example formats. ND_CMD_SMART: media health and diagnostics ND_CMD_GET_CONFIG_SIZE: size of the label space ND_CMD_GET_CONFIG_DATA: read label space ND_CMD_SET_CONFIG_DATA: write label space ND_CMD_VENDOR: vendor-specific command passthrough ND_CMD_ARS_CAP: report address-range-scrubbing capabilities ND_CMD_ARS_START: initiate scrubbing ND_CMD_ARS_STATUS: report on scrubbing state ND_CMD_SMART_THRESHOLD: configure alarm thresholds for smart events If a platform later defines different commands than this set it is straightforward to extend support to those formats. Most of the commands target a specific dimm. However, the address-range-scrubbing commands target the bus. The 'commands' attribute in sysfs of an nvdimm_bus, or nvdimm, enumerate the supported commands for that object. Cc: <linux-acpi@vger.kernel.org> Cc: Robert Moore <robert.moore@intel.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reported-by: Nicholas Moulin <nicholas.w.moulin@linux.intel.com> Acked-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-09 02:27:06 +08:00
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 14:35:12 +08: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-18 04:45:32 +08: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 14:35:12 +08: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 20:30:51 +08: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-22 05:29:25 +08: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 21:17:43 +08: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-29 05:06:55 +08: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-22 05:29:25 +08:00
default n
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 10:33:07 +08: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-22 05:29:25 +08:00
ACPI / PMIC: support PMIC operation region for CrystalCove The Baytrail-T platform firmware has defined two customized operation regions for PMIC chip Crystal Cove - one is for power resource handling and one is for thermal: sensor temperature reporting, trip point setting, etc. This patch adds support for them on top of the existing Crystal Cove PMIC driver. The reason to split code into a separate file intel_pmic.c is that there are more PMIC drivers with ACPI operation region support coming and we can re-use those code. The intel_pmic_opregion_data structure is created also for this purpose: when we need to support a new PMIC's operation region, we just need to fill those callbacks and the two register mapping tables. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Lee Jones <lee.jones@linaro.org> for the MFD part Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-24 17:21:54 +08:00
menuconfig PMIC_OPREGION
bool "PMIC (Power Management Integrated Circuit) operation region support"
help
Select this option to enable support for ACPI operation
region of the PMIC chip. The operation region can be used
to control power rails and sensor reading/writing on the
PMIC chip.
if PMIC_OPREGION
config CRC_PMIC_OPREGION
bool "ACPI operation region support for CrystalCove PMIC"
depends on INTEL_SOC_PMIC
help
This config adds ACPI operation region support for CrystalCove PMIC.
ACPI / PMIC: support PMIC operation region for XPower AXP288 The Baytrail-T-CR platform firmware has defined two customized operation regions for PMIC chip Dollar Cove XPower - one is for power resource handling and one is for thermal just like the CrystalCove one. This patch adds support for them on top of the common PMIC opregion region code. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Lee Jones <lee.jones@linaro.org> for the MFD part Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-24 17:24:47 +08:00
config XPOWER_PMIC_OPREGION
bool "ACPI operation region support for XPower AXP288 PMIC"
ACPI / PMIC: Stop xpower OPRegion handler relying on IIO The intel_pmic_xpower code provides an OPRegion handler, which must be available before other drivers using it are loaded, which can only be ensured if both the mfd and opregion drivers are built in, which is why the Kconfig option for intel_pmic_xpower is a bool. The use of IIO is causing trouble for generic distro configs here as distros will typically want to build IIO drivers as modules and there really is no reason to use IIO here. The reading of the ADC value is a single regmap_bulk_read, which is already protected against races by the regmap-lock. This commit removes the use of IIO, allowing distros to enable the driver without needing to built IIO in and also actually simplifies the code. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-04-19 21:07:00 +08:00
depends on MFD_AXP20X_I2C
ACPI / PMIC: support PMIC operation region for XPower AXP288 The Baytrail-T-CR platform firmware has defined two customized operation regions for PMIC chip Dollar Cove XPower - one is for power resource handling and one is for thermal just like the CrystalCove one. This patch adds support for them on top of the common PMIC opregion region code. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Lee Jones <lee.jones@linaro.org> for the MFD part Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-24 17:24:47 +08:00
help
This config adds ACPI operation region support for XPower AXP288 PMIC.
ACPI / PMIC: Add opregion driver for Intel BXT WhiskeyCove PMIC This patch adds operation region driver for Intel BXT WhiskeyCove PMIC. The register mapping is done as per the BXT WC data sheet. Signed-off-by: Ajay Thomas <ajay.thomas.david.rajamanickam@intel.com> Signed-off-by: Bin Gao <bin.gao@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-06-24 08:48:51 +08:00
config BXT_WC_PMIC_OPREGION
bool "ACPI operation region support for BXT WhiskeyCove PMIC"
mfd: intel_soc_pmic: Fix a mess with compilation units Crystal Cove and Whiskey Cove are two different PMICs which are installed on Intel Atom SoC based platforms. Moreover there are two independent drivers that by some reason were supposed (*) to get into one kernel module. Fix the mess by clarifying Kconfig option for Crystal Cove and split Whiskey Cove out of it. (*) It looks like the configuration was never tested with INTEL_SOC_PMIC=n. The line in Makefile is actually wrong. Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI) Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2017-04-04 20:38:56 +08:00
depends on INTEL_SOC_PMIC_BXTWC
ACPI / PMIC: Add opregion driver for Intel BXT WhiskeyCove PMIC This patch adds operation region driver for Intel BXT WhiskeyCove PMIC. The register mapping is done as per the BXT WC data sheet. Signed-off-by: Ajay Thomas <ajay.thomas.david.rajamanickam@intel.com> Signed-off-by: Bin Gao <bin.gao@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-06-24 08:48:51 +08:00
help
This config adds ACPI operation region support for BXT WhiskeyCove PMIC.
ACPI / PMIC: Add opregion driver for Intel CHT Whiskey Cove PMIC Add opregion driver for Intel CHT Whiskey Cove PMIC, based on various non upstreamed CHT Whiskey Cove PMIC patches. This does not include support for the Thermal opregion (DPTF) due to lacking documentation. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-04-19 21:06:59 +08:00
config CHT_WC_PMIC_OPREGION
bool "ACPI operation region support for CHT Whiskey Cove PMIC"
depends on INTEL_SOC_PMIC_CHTWC
help
This config adds ACPI operation region support for CHT Whiskey Cove PMIC.
ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC This patch adds the opregion driver for Dollar Cove TI PMIC on Intel Cherry Trail devices. The patch is based on the original work by Intel, found at: https://github.com/01org/ProductionKernelQuilts with many cleanups and rewrites. The driver is currently provided only as built-in to follow other PMIC opregion drivers convention. The re-enumeration of devices at probe is required for fixing the issues on HP x2 210 G2. See bug#195689. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195689 Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2017-09-04 22:43:40 +08:00
config CHT_DC_TI_PMIC_OPREGION
bool "ACPI operation region support for Dollar Cove TI PMIC"
depends on INTEL_SOC_PMIC_CHTDC_TI
help
This config adds ACPI operation region support for Dollar Cove TI PMIC.
ACPI / PMIC: Add opregion driver for Intel CHT Whiskey Cove PMIC Add opregion driver for Intel CHT Whiskey Cove PMIC, based on various non upstreamed CHT Whiskey Cove PMIC patches. This does not include support for the Thermal opregion (DPTF) due to lacking documentation. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-04-19 21:06:59 +08:00
ACPI / PMIC: support PMIC operation region for CrystalCove The Baytrail-T platform firmware has defined two customized operation regions for PMIC chip Crystal Cove - one is for power resource handling and one is for thermal: sensor temperature reporting, trip point setting, etc. This patch adds support for them on top of the existing Crystal Cove PMIC driver. The reason to split code into a separate file intel_pmic.c is that there are more PMIC drivers with ACPI operation region support coming and we can re-use those code. The intel_pmic_opregion_data structure is created also for this purpose: when we need to support a new PMIC's operation region, we just need to fill those callbacks and the two register mapping tables. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Lee Jones <lee.jones@linaro.org> for the MFD part Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-24 17:21:54 +08:00
endif
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-09 00:13:13 +08: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: 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-13 02:54:20 +08:00
if ARM64
source "drivers/acpi/arm64/Kconfig"
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-12 07:58:01 +08: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-13 02:54:20 +08:00
endif
ACPI / PMIC: Add TI PMIC TPS68470 operation region driver The Kabylake platform coreboot (Chrome OS equivalent of BIOS) has defined 4 operation regions for the TI TPS68470 PMIC. These operation regions are to enable/disable voltage regulators, configure voltage regulators, enable/disable clocks and to configure clocks. This config adds ACPI operation region support for TI TPS68470 PMIC. TPS68470 device is an advanced power management unit that powers a Compact Camera Module (CCM), generates clocks for image sensors, drives a dual LED for flash and incorporates two LED drivers for general purpose indicators. This driver enables ACPI operation region support to control voltage regulators and clocks for the TPS68470 PMIC. Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-29 08:30:26 +08:00
config TPS68470_PMIC_OPREGION
bool "ACPI operation region support for TPS68470 PMIC"
depends on MFD_TPS68470
help
This config adds ACPI operation region support for TI TPS68470 PMIC.
TPS68470 device is an advanced power management unit that powers
a Compact Camera Module (CCM), generates clocks for image sensors,
drives a dual LED for flash and incorporates two LED drivers for
general purpose indicators.
This driver enables ACPI operation region support control voltage
regulators and clocks.
This option is a bool as it provides an ACPI operation
region, which must be available before any of the devices
using this, are probed.
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-17 06:20:36 +08: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 16:11:48 +08: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.