The whole patch-set aims at making cpuid <-> nodeid mapping persistent. So that,
when node online/offline happens, cache based on cpuid <-> nodeid mapping such as
wq_numa_possible_cpumask will not cause any problem.
It contains 4 steps:
1. Enable apic registeration flow to handle both enabled and disabled cpus.
2. Introduce a new array storing all possible cpuid <-> apicid mapping.
3. Enable _MAT and MADT relative apis to return non-present or disabled cpus' apicid.
4. Establish all possible cpuid <-> nodeid mapping.
This patch finishes step 3.
There are four mappings in the kernel:
1. nodeid (logical node id) <-> pxm (persistent)
2. apicid (physical cpu id) <-> nodeid (persistent)
3. cpuid (logical cpu id) <-> apicid (not persistent, now persistent by step 2)
4. cpuid (logical cpu id) <-> nodeid (not persistent)
So, in order to setup persistent cpuid <-> nodeid mapping for all possible CPUs,
we should:
1. Setup cpuid <-> apicid mapping for all possible CPUs, which has been done in step 1, 2.
2. Setup cpuid <-> nodeid mapping for all possible CPUs. But before that, we should
obtain all apicids from MADT.
All processors' apicids can be obtained by _MAT method or from MADT in ACPI.
The current code ignores disabled processors and returns -ENODEV.
After this patch, a new parameter will be added to MADT APIs so that caller
is able to control if disabled processors are ignored.
Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
Signed-off-by: Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Cc: mika.j.penttila@gmail.com
Cc: len.brown@intel.com
Cc: rafael@kernel.org
Cc: rjw@rjwysocki.net
Cc: yasu.isimatu@gmail.com
Cc: linux-mm@kvack.org
Cc: linux-acpi@vger.kernel.org
Cc: isimatu.yasuaki@jp.fujitsu.com
Cc: gongzhaogang@inspur.com
Cc: tj@kernel.org
Cc: izumi.taku@jp.fujitsu.com
Cc: cl@linux.com
Cc: chen.tang@easystack.cn
Cc: akpm@linux-foundation.org
Cc: kamezawa.hiroyu@jp.fujitsu.com
Cc: lenb@kernel.org
Link: http://lkml.kernel.org/r/1472114120-3281-5-git-send-email-douly.fnst@cn.fujitsu.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
For the DSMs where the kernel knows the format of the output buffer and
originates those DSMs from within the kernel, return -EIO for any
non-zero status. If the BIOS is indicating a status that we do not know
how to handle, fail the DSM.
Cc: <stable@vger.kernel.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Currently the AER severity is calculated by calling cper_severity_to_aer(),
but the parameter sent is actually the GHES severity. This causes the AER
severity to be incorrect.
Fix the parameter to be the CPER severity instead of the GHES severity.
Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
Given following simplified device hierarchy:
// PCI device having BAR0 (RMEM) split between 4 GPIO devices.
Device (P2S)
{
Name (_ADR, 0x000d0000)
Device (GPO0)
{
Name (_HID, "INT3452")
Name (_UID, 1)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0x0000)
})
}
Device (GPO1)
{
Name (_HID, "INT3452")
Name (_UID, 2)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0x4000)
})
}
Device (GPO2)
{
Name (_HID, "INT3452")
Name (_UID, 3)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0x8000)
})
}
Device (GPO3)
{
Name (_HID, "INT3452")
Name (_UID, 4)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0xc000)
})
}
}
The current ACPI platform enumeration code allocates resources from the
global MMIO resource pool (/proc/iomem) for all the four GPIO devices.
After this PCI core calls pcibios_resource_survey() to allocate resources
for all PCI devices including the parent device for these GPIO devices
(P2S). Since that resource range has already been reserved the allocation
fails.
The reason for this is that we never bother with parent device's resources
when ACPI platform devices are created.
Fix this by checking whether there is a parent device and in that case make
sure we assign correct parent resource to the resources for the child ACPI
platform device. Currently we only deal with parent devices if they are PCI
devices but we may expand this later to cover other bus types as well.
Reported-by: Aaron Durbin <adurbin@google.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
For PCC mailbox with interrupt flag, CPPC should call mbox_chan_txdone()
function to notify the mailbox framework about TX completion.
Signed-off-by: Hoan Tran <hotran@apm.com>
Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch cleans up sysfs table signature handling code:
1. Convert the signature handling code to use the ACPICA APIs to
benefit from the future improvements of the APIs.
2. Add 'filename' attribute in order to handle both BE/LE name tags.
3. Add instance check in order to avoid the possible buffer overflow
related to the table file name.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
OEM tables can be installed via RSDT/XSDT, in this case, they have already
been created under /sys/firmware/acpi/tables.
For this kind of tables, normally LoadTable opcode will be executed to load
them. If LoadTable opcode is executed after acpi_sysfs_init(),
acpi_sysfs_table_handler() will be invoked, thus a redundant table file
will be created under /sys/firmware/acpi/tables/dynamic. Then running
"acpidump" on such platform results in an error, complaining blank empty
table (see Link 1 below).
The bug can be reproduced by customizing an OEM1 table, allowing it to be
overridden via 'table_sigs' (drivers/acpi/tables.c), adding the following
code to the customized DSDT to load it:
Name (OEMH, Zero)
Name (OEMF, One)
If (LEqual (OEMF, One)) {
Store (LoadTable ("OEM1", "Intel", "Test"), OEMH)
Store (Zero, OEMF)
}
In order to make sure that the OEM1 table is installed after
acpi_sysfs_init(), acpi_sysfs_init() can be moved before invoking
acpi_load_tables(). Then the following command execution result can be
seen:
# acpidump > acpidump.txt
Could not read table header: /sysfs/firmware/acpi/tables/dynamic/OEM12
Could not get ACPI table at index 17, AE_BAD_HEADER
Link: https://bugzilla.kernel.org/show_bug.cgi?id=150841 # [1]
Link: https://github.com/acpica/acpica/commit/ed6a5fbc
Reported-by: Jason Voelz <jason.voelz@intel.com>
Reported-by: Francisco Leoner <francisco.j.lenoer.soto@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In the following commit, the return value of acpi_tb_find_table() is
incorrect:
commit ac0f06ebb8
Author: Lv Zheng <lv.zheng@intel.com>
Date: Wed Sep 7 14:07:24 2016 +0800
ACPICA: Tables: Tune table mutex to be a leaf lock
ACPICA commit f564d57c6501b97a2871f0b4c048e79910f71783
This causes LoadTable opcode to fail. Fix this mistake.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
For structure types defined in the same file or local header files, find
top-level static structure declarations that have the following
properties:
1. Never reassigned.
2. Address never taken
3. Not passed to a top-level macro call
4. No pointer or array-typed field passed to a function or stored in a
variable.
Declare structures having all of these properties as const.
Done using Coccinelle.
Based on a suggestion by Joe Perches <joe@perches.com>.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
For ITS, MSI functionality consists on building domain stack and
during that process we need to reference to domain stack components
e.g. before we create new DOMAIN_BUS_PCI_MSI domain we need to specify
its DOMAIN_BUS_NEXUS parent domain. In order to manage that process
properly, maintain list which elements contain domain token
(unique for MSI domain stack) and ITS ID: iort_register_domain_token()
and iort_deregister_domain_token(). Then retrieve domain token
any time later with ITS ID being key off: iort_find_domain_token().
With domain token and domain type we are able to find corresponding
IRQ domain.
Since IORT is prepared to describe MSI domain on a per-device basis,
use existing IORT helpers and implement two calls:
1. iort_msi_map_rid() to map MSI RID for a device
2. iort_get_device_domain() to find domain token for a device
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
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>
Pull libnvdimm fixes from Dan Williams:
"nvdimm fixes for v4.8, two of them are tagged for -stable:
- Fix devm_memremap_pages() to use track_pfn_insert(). Otherwise,
DAX pmd mappings end up with an uncached pgprot, and unusable
performance for the device-dax interface. The device-dax interface
appeared in 4.7 so this is tagged for -stable.
- Fix a couple VM_BUG_ON() checks in the show_smaps() path to
understand DAX pmd entries. This fix is tagged for -stable.
- Fix a mis-merge of the nfit machine-check handler to flip the
polarity of an if() to match the final version of the patch that
Vishal sent for 4.8-rc1. Without this the nfit machine check
handler never detects / inserts new 'badblocks' entries which
applications use to identify lost portions of files.
- For test purposes, fix the nvdimm_clear_poison() path to operate on
legacy / simulated nvdimm memory ranges. Without this fix a test
can set badblocks, but never clear them on these ranges.
- Fix the range checking done by dax_dev_pmd_fault(). This is not
tagged for -stable since this problem is mitigated by specifying
aligned resources at device-dax setup time.
These patches have appeared in a next release over the past week. The
recent rebase you can see in the timestamps was to drop an invalid fix
as identified by the updated device-dax unit tests [1]. The -mm
touches have an ack from Andrew"
[1]: "[ndctl PATCH 0/3] device-dax test for recent kernel bugs"
https://lists.01.org/pipermail/linux-nvdimm/2016-September/006855.html
* 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
libnvdimm: allow legacy (e820) pmem region to clear bad blocks
nfit, mce: Fix SPA matching logic in MCE handler
mm: fix cache mode of dax pmd mappings
mm: fix show_smap() for zone_device-pmd ranges
dax: fix mapping size check
On ACPI ARM based systems the GIC interrupt controller
and corresponding interrupt model permit only the high
polarity for level interrupts.
ACPI firmware describes PCI legacy IRQs through entries
in the _PRT objects. Entries in the _PRT can be of two types:
- Static: not configurable, trigger/polarity default to level-low,
_PRT entry defines the global GSI interrupt number
- Configurable: _PRT interrupt entry contains a reference to the
corresponding PCI interrupt link device (that in turn provides the
interrupt descriptor through its _CRS/_PRS methods)
Configurable IRQ entries are not currently allowed by the ACPI
specification on ARM since they can only be used for interrupt pins that
are routable, as per ACPI specifications (version 6.1, 6.2.13):
"[...] There are two ways that _PRT can be used. Typically, the
interrupt input that a given PCI interrupt is on is configurable. For
example, a given PCI interrupt might be configured for either IRQ 10 or
11 on an 8259 interrupt controller. In this model, each interrupt is
represented in the ACPI namespace as a PCI Interrupt Link Device. [...]"
ARM platforms GIC configurations do not allow dynamic IRQ routing,
since routing is statically laid out at synthesis time; therefore PCI
interrupt links cannot be used for PCI legacy IRQ descriptions in the
_PRT on ARM systems.
On the other hand, current core ACPI code handling PCI legacy IRQs
consider IRQ trigger/polarity for static _PRT entries as level-low.
On ARM systems with a GIC interrupt controller and corresponding
ACPI interrupt model this does not work in that GIC interrupt
controller is only capable of handling level interrupts whose
polarity is high (for PCI legacy IRQs - that are level-low by
specification - this means that the legacy IRQs are inverted before
reaching the interrupt controller pin), resulting in IRQ allocation
failures such as:
genirq: Setting trigger mode 8 for irq 18 failed (gic_set_type+0x0/0x48)
Change the default polarity for PCI legacy IRQs to high on systems
booting wth ACPI on platforms with a GIC interrupt controller model,
fixing the discrepancy between specification and HW behaviour.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Tested-by: Duc Dang <dhdang@apm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit f564d57c6501b97a2871f0b4c048e79910f71783
This patch tunes MTX_TABLES into a leaf lock by always ensuring it is
released before holding other locks.
This patch also collects all table loading related functions into
acpi_tb_load_table() (invoked by load_table opcode) and
acpi_tb_install_and_load_table() (invoked by Load opcode and acpi_load_table()) so
that we can have lock tuning code collected at the boundary of these 2
functions. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/f564d57c
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Dutch Guy <lucht_piloot@gmx.net>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit fd305eda14f1a1e684edef4fac53f194bf00ed3f
This patch fixes an issue with acpi_ds_auto_serialized_method().
The parser will invoke acpi_ex_release_all_mutexes(), which in return
cause mutexes held in ACPI_ERROR_METHOD() failed. Lv Zheng.
Link: https://bugs.acpica.org/show_bug.cgi?id=1324
Link: https://github.com/acpica/acpica/commit/fd305eda
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Greg White <gwhite@kupulau.com>
Tested-by: Dutch Guy <lucht_piloot@gmx.net>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 767ee53354e0c4b7e8e7c57c6dd7bf569f0d52bb
There are issues related to the namespace/interpreter locks, which causes
several ACPI functionalities not specification compliant. The lock issues
were detectec when we were trying to fix the functionalities (please see
Link # [1] for the details).
What's the lock issues? Let's first look into the namespace/interpreter
lock usages inside of the object evaluation and the table loading which are
the key AML interpretion code paths:
Table loading:
acpi_ns_load_table
L(Namespace)
acpi_ns_parse_table
acpi_ns_one_complete_parse(LOAD_PASS1/LOAD_PASS2)
acpi_ds_load1_begion_op
acpi_ds_load1_end_op
acpi_ds_load2_begion_op
acpi_ds_load2_end_op
U(Namespace)
Object evaluation:
acpi_ns_evaluate
L(Interpreter)
acpi_ps_execute_method
acpi_ds_exec_begin_op
acpi_ds_exec_end_op
U(Interpreter)
acpi_ns_load_table
L(Namespace)
U(Namespace)
acpi_ev_initialize_region
L(Namespace)
U(Namespace)
address_space.Setup
address_space.Handler
acpi_os_wait_semaphore
acpi_os_acquire_mutex
acpi_os_sleep
L(Interpreter)
U(Interpreter)
L(Interpreter)
acpi_ex_resolve_node_to_value
U(Interpreter)
acpi_ns_check_return_value
Where:
1. L(Interpreter) means acquire(MTX_INTERPRETER);
2. U(Interpreter) means release(MTX_INTERPRETER);
3. L(Namespace) means acquire(MTX_NAMESPACE);
4. U(Namespace) means release(MTX_NAMESPACE);
We can see that acpi_ns_exec_module_code() (which invokes acpi_ns_evaluate) is
implemented in a deferred way just in order to avoid to reacquire the
namespace lock. This is in fact the root cause of many other ACPICA issues:
1. We now know for sure that the module code should be executed right in
place by the Windows AML interpreter. So in the current design, if
the region initializations/accesses or the table loadings (where the
namespace surely should be locked again) happening during the table
loading period, dead lock could happen because ACPICA never unlocks the
namespace during the AML interpretion.
2. ACPICA interpreter just ensures that all static namespace nodes (named
objects created during the acpi_load_tables()) are created
(acpi_ns_lookup()) with the correct lock held, but doesn't ensure that
the named objects created by the control method are created with the
same correct lock held. It requires the control methods to be executed
in a serial way after "loading a table", that's why ACPICA requires
method auto serialization.
This patch fixes these software design issues by extending interpreter
enter/exit APIs to hold both interpreter/namespace locks to ensure the lock
order correctness, so that we can get these code paths:
Table loading:
acpi_ns_load_table
E(Interpreter)
acpi_ns_parse_table
acpi_ns_one_complete_parse
acpi_ns_execute_table
X(Interpreter)
acpi_ns_load_table
acpi_ev_initialize_region
address_space.Setup
address_space.Handler
acpi_os_wait_semaphore
acpi_os_acquire_mutex
acpi_os_sleep
E(Interpreter)
X(Interpreter)
Object evaluation:
acpi_ns_evaluate
E(Interpreter)
acpi_ps_execute_method
X(Interpreter)
acpi_ns_load_table
acpi_ev_initialize_region
address_space.Setup
address_space.Handler
acpi_os_wait_semaphore
acpi_os_acquire_mutex
acpi_os_sleep
E(Interpreter)
X(Interpreter)
Where:
1. E(Interpreter) means acquire(MTX_INTERPRETER, MTX_NAMESPACE);
2. X(Interpreter) means release(MTX_NAMESPACE, MTX_INTERPRETER);
After this change, we can see:
1. All namespace nodes creations are locked by the namespace lock.
2. All namespace nodes referencing are locked with the same lock.
3. But we also can notice a defact that, all namespace nodes deletions
could be affected by this change. As a consequence,
acpi_ns_delete_namespace_subtree() may delete a static namespace node that
is still referenced by the interpreter (for example, the parser scopes).
Currently, we needn't worry about the last defact because in ACPICA, table
unloading is not fully functioning, its design strictly relies on the fact
that when the namespace deletion happens, either the AML table or the OSPMs
should have been notified and thus either the AML table or the OSPMs
shouldn't reference deletion-related namespace nodes during the namespace
deletion. And this change still works with the above restrictions applied.
While making this a-step-forward helps us to correct the wrong grammar to
pull many things back to the correct rail. And pulling things back to the
correct rail in return makes it possible for us to support fully
functioning table unloading after doing many cleanups.
While this patch is generated, all namespace locks are examined to ensure
that they can meet either of the following pattens:
1. L(Namespace)
U(Namespace)
2. E(Interpreter)
X(Interpreter)
3. E(Interpreter)
X(Interpreter)
L(Namespace)
U(Namespace)
E(Interpreter)
X(Interpreter)
We ensure this by adding X(Interpreter)/E(Interpreter) or removing
U(Namespace)/L(Namespace) for those currently are executed in the following
order:
E(Interpreter)
L(Namespace)
U(Namespace)
X(Interpreter)
And adding E(Interpreter)/X(Interpreter) for those currently are executed
in the following order:
X(Interpreter)
E(Interpreter)
Originally, the interpreter lock is held for the execution AML opcodes, the
namespace lock is held for the named object creation AML opcodes. Since
they are actually same in MS interpreter (can all be executed during the
table loading), we can combine the 2 locks and tune the locking code better
in this way. Lv Zheng.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=153541 # [1]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=121701 # [1]
Link: https://bugs.acpica.org/show_bug.cgi?id=1323
Link: https://github.com/acpica/acpica/commit/767ee533
Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reported-and-tested-by: Greg White <gwhite@kupulau.com>
Reported-and-tested-by: Dutch Guy <lucht_piloot@gmx.net>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 3ef1a1bf5612fe1a629424c09eaaeb6f299d313c
Add acpi_ns_get_node_unlocked() to be used when ACPI_MTX_NAMESPACE is
locked. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/3ef1a1bf
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Greg White <gwhite@kupulau.com>
Tested-by: Dutch Guy <lucht_piloot@gmx.net>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 0e24fb67cde08d7df7671d7d7b183490dc79707e
The MLC (Module Level Code) is an ACPICA terminology describing the AML
code out of any control method, its support is an indication of the
interpreter behavior during the table loading.
The original implementation of MLC in ACPICA had several issues:
1. Out of any control method, besides of the object creating opcodes, only
the code blocks wrapped by "If/Else/While" opcodes were supported.
2. The supported MLC code blocks were executed after loading the table
rather than being executed right in place.
============================================================
The demo of this order issue is as follows:
Name (OBJ1, 1)
If (CND1 == 1)
{
Name (OBJ2, 2)
}
Name (OBJ3, 3)
The original MLC support created OBJ2 after OBJ3's creation.
============================================================
Other than these limitations, MLC support in ACPICA looks correct. And
supporting this should be easy/natural for ACPICA, but enabling of this was
blocked by some ACPICA internal and OSPM specific initialization order
issues we've fixed recently. The wrong support started from the following
false bug fixing commit:
Commit: 7f0c826a43
Subject: ACPICA: Add support for module-level executable AML code
Commit: 9a884ab64a
Subject: ACPICA: Add additional module-level code support
...
We can confirm Windows interpreter behavior via reverse engineering means.
It can be proven that not only If/Else/While wrapped code blocks, all
opcodes can be executed at the module level, including operation region
accesses. And it can be proven that the MLC should be executed right in
place, not in such a deferred way executed after loading the table.
And the above facts indeed reflect the spec words around ACPI definition
block tables (DSDT/SSDT/...), the entire table and the Scope object is
defined by the AML specification in BNF style as:
AMLCode := def_block_header term_list
def_scope := scope_op pkg_length name_string term_list
The bodies of the scope opening terms (AMLCode/Scope) are all term_list,
thus the table loading should be no difference than the control method
evaluations as the body of the Method is also defined by the AML
specification as term_list:
def_method := method_op pkg_length name_string method_flags term_list
The only difference is: after evaluating control method, created named
objects may be freed due to no reference, while named objects created by
the table loading should only be freed after unloading the table.
So this patch follows the spec and the de-facto standard behavior, enables
the new grammar (term_list) for the table loading.
By doing so, beyond the fixes to the above issues, we can see additional
differences comparing to the old grammar based table loading:
1. Originally, beyond the scope opening terms (AMLCode/Scope),
If/Else/While wrapped code blocks under the scope creating terms
(Device/power_resource/Processor/thermal_zone) are also supported as
deferred MLC, which violates the spec defined grammar where object_list
is enforced. With MLC support improved as non-deferred, the interpreter
parses such scope creating terms as term_list rather object_list like the
scope opening terms.
After probing the Windows behavior and proving that it also parses these
terms as term_list, we submitted an ECR (Engineering Change Request) to
the ASWG (ACPI Specification Working Group) to clarify this. The ECR is
titled as "ASL Grammar Clarification for Executable AML Opcodes" and has
been accepted by the ASWG. The new grammar will appear in ACPI
specification 6.2.
2. Originally, Buffer/Package/operation_region/create_XXXField/bank_field
arguments are evaluated in a deferred way after loading the table. With
MLC support improved, they are also parsed right in place during the
table loading.
This is also Windows compliant and the only difference is the removal
of the debugging messages implemented before acpi_ds_execute_arguments(),
see Link # [1] for the details. A previous commit should have ensured
that acpi_check_address_range() won't regress.
Note that enabling this feature may cause regressions due to long term
Linux ACPI support on top of the wrong grammar. So this patch also prepares
a global option to be used to roll back to the old grammar during the
period between a regression is reported and the regression is
root-cause-fixed. Lv Zheng.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=112911 # [1]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=117671 # [1]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=153541 # [1]
Link: https://github.com/acpica/acpica/issues/122
Link: https://bugs.acpica.org/show_bug.cgi?id=963
Link: https://github.com/acpica/acpica/commit/0e24fb67
Reported-and-tested-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Reported-by: Ehsan <dashesy@gmail.com>
Reported-and-tested-by: Dutch Guy <lucht_piloot@gmx.net>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 82101009c7c04845edb3495e66a274a613758bca
Instead of 0xFFFFFFFF, _OSI is now defined to return "Ones".
This is for compatibility with Windows. The ACPI spec will
be updated to reflect this.
Link: https://github.com/acpica/acpica/commit/82101009
Reported-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit aaace77db4c3b267a65b75c33f84ace6f65bbcf7
Originally, when acpi_gbl_use32_bit_fadt_addresses is TRUE, GAS override can
only happen when the Address field mismatches.
According to the investigation result, Windows may favor 32-bit FADT
addresses in some cases. So we need this quirk working after enabling full
GAS support. This requires us to override GAS access_size/bit_width/bit_offset
fields as long as acpi_gbl_use32_bit_fadt_addresses is TRUE.
This patch enhances this quirk mechanism to make it working with full GAS
support. Lv Zheng.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=151501
Link: https://github.com/acpica/acpica/commit/aaace77d
Reported-and-tested-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit ed6a5fbc694f3a27d93014391aa9a6f6fe490461
This patch adds 2 new table events to indicate table
installation/uninstallation.
Currently, as ACPICA never uninstalls tables, this patch thus only adds
table handler invocation for the table installation event. Lv Zheng.
The 2 events are to be used to fix a sysfs table handling issue related to
LoadTable opcode (see Link # [1] below). The actual sysfs fixing code is
not included, the sysfs fixes will be sent as separate patches.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=150841 # [1]
Link: https://github.com/acpica/acpica/commit/ed6a5fbc
Reported-by: Jason Voelz <jason.voelz@intel.com>
Reported-by: Francisco Leoner <francisco.j.lenoer.soto@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 42c7b848d2faa02c7691ef2c53ea741c23cd4665
acpi_tb_install_fixed_table() is now redundant as we've removed the fixed
table indexing mechanism:
Commit: 8ec3f45907
Subject: ACPICA: Tables: Fix global table list issues by removing
fixed table indexes
This patch cleans up the code accordingly.
No functional change. Lv Zheng.
Link: https://bugs.acpica.org/show_bug.cgi?id=1320
Link: https://github.com/acpica/acpica/commit/42c7b848
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 2ba5d3fdaa24d66d67694cbae6ec66971a7a67c1
Required in some environments.
Link: https://github.com/acpica/acpica/commit/2ba5d3fd
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit e2e72a351201fd58e4694418859ae2c247dafca0
Consolidate multiple versions of strtoul64 to one common version.
limit possible bases to either 10 or 16.
Handles both implicit and explicit conversions.
Added a 2-character ascii-to-hex function for GPEs and buffers.
Adds a new file, utstrtoul64.c
Link: https://github.com/acpica/acpica/commit/e2e72a35
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit be5808f0e642ff9963d86f362521b4af2340e2f5
"Execute Predefined" will execute all predefined (public) names
within the namespace.
Link: https://github.com/acpica/acpica/commit/be5808f0
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The check for a 'pmem' type SPA in the MCE handler was inverted due to a
merge/rebase error.
Fixes: 6839a6d nfit: do an ARS scrub on hitting a latent media error
Cc: linux-acpi@vger.kernel.org
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
There are issues related to the boot_ec:
1. If acpi_ec_remove() is invoked, boot_ec will also be freed, this is not
expected as the boot_ec could be enumerated via ECDT.
2. Address space handler installation/unstallation lead to unexpected _REG
evaluations.
This patch adds acpi_is_boot_ec() check to be used to fix the above issues.
However, since acpi_ec_remove() actually won't be invoked, this patch
doesn't handle the reference counting of "struct acpi_ec", it only ensures
the correctness of the boot_ec destruction during the boot.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=153511
Reported-and-tested-by: Jonh Henderson <jw.hendy@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
It is possible to register _Qxx from namespace and use the ECDT EC to
perform event handling. The reported bug reveals that Windows is using ECDT
in this way in case the namespace EC is not present. This patch facilitates
Linux to support ECDT in this way.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=115021
Reported-and-tested-by: Luya Tshimbalanga <luya@fedoraproject.org>
Tested-by: Jonh Henderson <jw.hendy@gmail.com>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When the handler installation failed, there was no code to free the
allocated EC device. This patch fixes this memory leakage issue.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=115021
Reported-and-tested-by: Luya Tshimbalanga <luya@fedoraproject.org>
Tested-by: Jonh Henderson <jw.hendy@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In order to support full ECDT (driving the ECDT EC after probing the
namespace EC), we need to change our EC device alloc/free algorithm, ensure
not to free old boot EC before qualifying new boot EC.
This patch achieves this by cleaning up first_ec/boot_ec logic:
1. first_ec: used to perform transactions, so it is assigned in new
acpi_ec_setup() function.
2. boot_ec: used to track early EC device, so it is assigned in new
acpi_config_boot_ec() function which explictly tells the driver to save
the EC device as early EC device.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=115021
Reported-and-tested-by: Luya Tshimbalanga <luya@fedoraproject.org>
Tested-by: Jonh Henderson <jw.hendy@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch adds new PSTORE_FLAGS for each pstore type so that they can
be enabled separately. This is a preparation for ongoing virtio-pstore
work to support those types flexibly.
The PSTORE_FLAGS_FRAGILE is changed to PSTORE_FLAGS_DMESG to preserve the
original behavior.
Cc: Anton Vorontsov <anton@enomsg.org>
Cc: Colin Cross <ccross@android.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: linux-acpi@vger.kernel.org
Cc: linux-efi@vger.kernel.org
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
[kees: retained "FRAGILE" for now to make merges easier]
Signed-off-by: Kees Cook <keescook@chromium.org>
Since struct cpudata is defined in a header file, add prefix cppc_ to
make it not a generic name. Otherwise it causes compile issue in locally
define structure with the same name.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The CPPC registers can also be accessed via functional fixed hardware
addresse(FFH) in X86. Add support by modifying cpc_read and cpc_write to
be able to read/write MSRs on x86 platform on per cpu basis.
Also with this change, acpi_cppc_processor_probe doesn't bail out if
address space id is not equal to PCC or memory address space and FFH
is supported on the system.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
It is still possible to continue even CPPC data is invalid or missing.
Suggested-by: Alexey Klimov <alexey.klimov@arm.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Some newer x86 platforms have support for both _CPC and _PSS object. So
kernel config can have both ACPI_CPU_FREQ_PSS and ACPI_CPPC_LIB. So remove
restriction for ACPI_CPPC_LIB to build only when ACPI_CPU_FREQ_PSS is not
defined.
Also for legacy systems with only _PSS, we shouldn't bail out if
acpi_cppc_processor_probe() fails, if ACPI_CPU_FREQ_PSS is also defined.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit e647b53227 ("ACPI: Add early device probing infrastructure")
introduced code that allows inserting driver specific
struct acpi_probe_entry probe entries into ACPI linker sections
(one per-subsystem, eg irqchip, clocksource) that are then walked
to retrieve the data and function hooks required to probe the
respective kernel components.
Probing for all entries in a section is triggered through
the __acpi_probe_device_table() function, that in turn, according
to the table ID a given probe entry reports parses the table
with the function retrieved from the respective section structures
(ie struct acpi_probe_entry). Owing to the current ACPI table
parsing implementation, the __acpi_probe_device_table() function
has to share global variables with the acpi_match_madt() function, so
in order to guarantee mutual exclusion locking is required
between the two functions.
Current kernel code implements the locking through the acpi_probe_lock
spinlock; this has the side effect of requiring all code called
within the lock (ie struct acpi_probe_entry.probe_{table/subtbl} hooks)
not to sleep.
However, kernel subsystems that make use of the early probing
infrastructure are relying on kernel APIs that may sleep (eg
irq_domain_alloc_fwnode(), among others) in the function calls
pointed at by struct acpi_probe_entry.{probe_table/subtbl} entries
(eg gic_v2_acpi_init()), which is a bug.
Since __acpi_probe_device_table() is called from context
that is allowed to sleep the acpi_probe_lock spinlock can be replaced
with a mutex; this fixes the issue whilst still guaranteeing
mutual exclusion.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Fixes: e647b53227 (ACPI: Add early device probing infrastructure)
Cc: 4.4+ <stable@vger.kernel.org> # 4.4+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Trigger an nmemX/nfit/flags attribute to fire an event whenever a
smart-threshold DSM is received.
Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The function acpi_parse_entries_array() has a limiting parameter,
max_entries, which tells the function to stop looking at subtables
once that limit has been reached. If the limit is reached, it is
reported. However, the logic is incorrect in that the loop to
examine all subtables will always report that zero subtables have
been ignored since it does not continue once the max_entries have
been reached.
One approach to fixing this would be to correct the logic so that
all subtables are examined, even if we have hit the max_entries, but
without executing all the callback functions. This could be risky
since we cannot guarantee that no callback will ever have side effects
that another callback depends on to work correctly.
So, the simplest approach is to just remove the part of the error
message that will always be incorrect.
Signed-off-by: Al Stone <ahs3@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The acpi_parse_entries_array() function currently returns the very first
time there is any error found by one of the callback functions, or if one
of the callbacks returns a non-zero value. However, the ACPI subtables
being traversed could still have valid entries that could be used by one
of the callback functions. And, if the comments are correct, that is
what should happen -- always traverse all of the subtables, calling as
many of the callbacks as possible.
This patch makes the function consistent with its description so that it
will properly invoke all callbacks for all matching entries, for all
subtables, instead of stopping abruptly as it does today.
This does change the semantics of using acpi_parse_entries_array(). In
examining all users of the function, none of them rely on the current
behavior; that is, there appears to be no assumption that either all
subtables are traversed and all callbacks invoked, or that the function
will return immediately on any error from a callback. Each callback
operates independently. Hence, there should be no functional change
due to this change in semantics.
Future patches being prepared will rely on this new behavior; indeed,
they were written assuming the acpi_parse_entries_array() function
operated as its comments describe. For example, a callback that
counts the number of subtables of a specific type can now be assured
that as many subtables as possible have been enumerated.
Signed-off-by: Al Stone <ahs3@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The static function acpi_parse_entries_array() is provided an array of
type struct acpi_subtable_proc that has a callback function and a count.
The count should reflect how many times the callback has been called.
However, the current code only increments the 0th element of the array,
regardless of the number of entries in the array, or which callback has
been invoked. The result is that we know the total number of callbacks
made but we cannot determine which callbacks were made, nor how often.
The fix is to index into the array of structs and increment the proper
counts.
There is one place in the x86 code for acpi_parse_madt_lapic_entries()
where the counts for each callback are used. If no LAPICs *and* no
X2APICs are found, an ENODEV is supposed to be returned; as it stands,
the count of X2APICs will always be zero, regardless of what is in the
MADT. Should there be no LAPICs, ENODEV will be returned in error, if
there are X2APICs in the MADT.
Otherwise, there are no other functional consequences of the count being
done as it currently is; all other uses simply check that the return value
from acpi_parse_entries_array() or passed back via its callers is either
non-zero, an error, or in one case just ignored.
In future patches, I will also need these counts to be correct; I need
to count the number of instances of subtables of certain types within
the MADT to determine whether or not an ACPI IORT is required or not,
and report when it is not present when it should be.
Signed-off-by: Al Stone <ahs3@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The UART driver, dw8250.c, needs some details regarding the
Designware UART. For ACPI enumerated devices the values are
hard-coded, but since the driver also reads the values from
device properties, providing them with build-in properties.
This allows us to later remove the hard-coded values from
the driver.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The UART driver, dw8250.c, needs some details regarding the
Designware UART. For ACPI enumerated devices the values are
hard-coded, but since the driver also reads the values from
device properties, providing them with build-in properties.
This allows us to later remove the hard-coded values from
the driver.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
On most platforms, _LID returning value, lid open/close events are all
reliable, but there are exceptions. Some AML tables report wrong initial
lid state [1], and some of them never report lid open state [2].
The usage model on such buggy platforms is:
1. The initial lid state returned from _LID is not reliable;
2. The lid open event is not reliable;
3. The lid close event is always reliable, used by the platform firmware to
trigger OSPM power saving operations.
This usage model is not compliant to the Linux SW_LID model as the Linux
userspace is very strict to the reliability of the open events.
In order not to trigger issues on such buggy platforms, the ACPI button
driver currently implements a lid_init_state=open quirk to send additional
"open" event after resuming. However, this is still not sufficient because:
1. Some special usage models (e.x., the dark resume scenario) cannot be
supported by this mode.
2. If a "close" event is not used to trigger "suspend", then the subsequent
"close" events cannot be seen by the userspace.
So we need to stop sending the additional "open" event and switch the
driver to lid_init_state=ignore mode and make sure the platform triggered
events can be reliably delivered to the userspace. The userspace programs
then can be changed to not to be strict to the "open" events on such buggy
platforms.
Why will the subsequent "close" events be lost? This is because the input
layer automatically filters redundant events for switch events. Thus given
that the buggy AML tables do not guarantee paired "open"/"close" events,
the ACPI button driver currently is not able to guarantee that the platform
triggered reliable events can be always be seen by the userspace via
SW_LID.
This patch adds a mechanism to insert lid events as a compensation for the
platform triggered ones to form a complete event switches in order to make
sure that the platform triggered events can always be reliably delivered
to the userspace. This essentially guarantees that the platform triggered
reliable "close" events will always be relibly delivered to the userspace.
However this mechanism is not suitable for lid_init_state=open/method as
it should not send the complement switch event for the unreliable initial
lid state notification. 2 unreliable events can trigger unexpected
behavior. Thus this patch only implements this mechanism for
lid_init_state=ignore.
Known issues:
1. Possible alternative approach
This approach is based on the fact that Linux requires a switch event
type for LID events. Another approach is to use key event type to
implement ACPI lid events.
With SW event type, since ACPI button driver inserts wrong lid events,
there could be a potential issue that an "open" event issued from some
AML update methods could result in a wrong "close" event to be delivered
to the userspace. While using KEY event type, there is no such problem.
However there may not be such a kind of real case, and if there is such
a case, it is worked around in this patch as the complement switch event
is only generated for "close" event in order to deliver the reliable
"close" event to the userspace.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=89211 # [1]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=106151 # [1]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=106941 # [2]
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
PCC status field exposes an error bit(2) to indicate any errors during
the execution of last comamnd. This patch checks the error bit before
notifying success/failure to the cpufreq driver.
Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There are several global variables in cppc driver that are related
to PCC channel used for CPPC. This patch collects all such
information into a single consolidated structure(cppc_pcc_data).
Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The CPPC tables contain entries for per CPU feedback counters which
allows us to compute the delivered performance over a given interval
of time.
The math for delivered performance per the CPPCv5.0+ spec is:
reference perf * delta(delivered perf ctr)/delta(ref perf ctr)
Maintaining deltas of the counters in the kernel is messy, as it
depends on when the reads are triggered. (e.g. via the cpufreq
->get() interface). Also the ->get() interace only returns one
value, so cant return raw values. So instead, leave it to userspace
to keep track of raw values and do its math for CPUs it cares about.
delivered and reference perf counters are exposed via the same
sysfs file to avoid the potential "skid", if these values are read
individually from userspace.
Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Compute the expected transition latency for frequency transitions
using the values from the PCCT tables when the desired perf
register is in PCC.
Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org>
Reviewed-by: Alexey Klimov <alexey.klimov@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CPPC defined in section 8.4.7 of ACPI 6.0 specification suggests
"To amortize the cost of PCC transactions, OSPM should read or write
all PCC registers via a single read or write command when possible"
This patch enables opportunistic batching of frequency transition
requests whenever the request happen to overlap in time.
Currently the access to pcc is serialized by a spin lock which does
not scale well as we increase the number of cores in the system. This
patch improves the scalability by allowing the differnt CPU cores to
update PCC subspace in parallel and by batching requests which will
reduce the certain types of operation(checking command completion bit,
ringing doorbell) by a significant margin.
Profiling shows significant improvement in the overall effeciency
to service freq. transition requests. With this patch we observe close
to 30% of the frequency transition requests being batched with other
requests while running apache bench on a ARM platform with 6
independent domains(or sets of related cpus).
Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
We need to acquire pcc_lock only when we are accessing registers
that are in the PCC subspsace.
Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
For cases where sys mapped CPC registers need to be accessed
frequently, it helps immensly to pre-map them rather than map
and unmap for each operation. e.g. case where feedback counters
are sys mem map registers.
Restructure cpc_read/write and the cpc_regs structure to allow
pre-mapping the system addresses and unmap them when the CPU exits.
Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Thus move sysfs_add_battery() after acpi_battery_get_state(), which doesn't
require the power_supply. Prevents possible hanged tasks if
acpi_battery_get_state() fails consistently (and takes a long time in doing
so) when called inside acpi_battery_add().
In this situation the battery module first calls sysfs_add_battery(),
which creates a power_supply, which spawns an async
power_supply_deferred_register_work() task, which shall try to hold the
parent battery device mutex (being already held) so this register work
is set up after device initialization. If initialization takes long enough
the thread will be eventually run and try to hold the mutex before
acpi_battery_add() had the chance to finish.
Eventually the 5 retries in acpi_battery_update_retry() fail, the error
state is propagated, and results in sysfs_remove_battery() being called
within the error handling paths of acpi_battery_add(), and the power_supply
tear down too.
This triggers a cancel_delayed_work_sync() of the deferred_register_work
task, which ends up in schedule(). The end result is that the deferred
task is blocked trying to acquire the parent device mutex, which is not
released because the thread doing initialization (and failure handling)
went to sleep awaiting for the deferred task to be cancelled.
The hanged tasks look like this:
INFO: task kworker/u8:0:6 blocked for more than 120 seconds.
...
Call Trace:
[<ffffffff815daec5>] schedule+0x35/0x80
[<ffffffff815dda3c>] schedule_timeout+0x1ec/0x250
[<ffffffff810a0572>] ? check_preempt_curr+0x52/0x90
[<ffffffff810a05c9>] ? ttwu_do_wakeup+0x19/0xe0
[<ffffffff815db915>] wait_for_common+0xc5/0x190
[<ffffffff810a1500>] ? wake_up_q+0x70/0x70
[<ffffffff815db9fd>] wait_for_completion+0x1d/0x20
[<ffffffff8108ffb1>] flush_work+0x111/0x1c0
[<ffffffff8108dfe0>] ? flush_workqueue_prep_pwqs+0x1a0/0x1a0
[<ffffffff810909af>] __cancel_work_timer+0x9f/0x1d0
[<ffffffff81090b13>] cancel_delayed_work_sync+0x13/0x20
[<ffffffff8147ac67>] power_supply_unregister+0x37/0xc0
[<ffffffffa058b03d>] sysfs_remove_battery+0x3d/0x52 [battery]
[<ffffffffa058bf3a>] acpi_battery_add+0x112/0x181 [battery]
[<ffffffff81366db6>] acpi_device_probe+0x54/0x19b
[<ffffffff81427e9c>] driver_probe_device+0x22c/0x440
[<ffffffff81428181>] __driver_attach+0xd1/0xf0
[<ffffffff814280b0>] ? driver_probe_device+0x440/0x440
[<ffffffff8142591c>] bus_for_each_dev+0x6c/0xc0
[<ffffffff8142758e>] driver_attach+0x1e/0x20
[<ffffffff81426fc3>] bus_add_driver+0x1c3/0x280
[<ffffffff81428b00>] driver_register+0x60/0xe0
[<ffffffff81366c80>] acpi_bus_register_driver+0x3b/0x43
[<ffffffffa0591040>] acpi_battery_init_async+0x1c/0x1e [battery]
[<ffffffff81099268>] async_run_entry_fn+0x48/0x150
[<ffffffff81090d09>] process_one_work+0x1e9/0x440
[<ffffffff81090fab>] worker_thread+0x4b/0x4f0
[<ffffffff81090f60>] ? process_one_work+0x440/0x440
[<ffffffff81096b58>] kthread+0xd8/0xf0
[<ffffffff815de97f>] ret_from_fork+0x1f/0x40
[<ffffffff81096a80>] ? kthread_worker_fn+0x180/0x180
INFO: task kworker/u8:4:282 blocked for more than 120 seconds.
...
Call Trace:
[<ffffffff810ad745>] ? put_prev_entity+0x35/0x8b0
[<ffffffff815daec5>] schedule+0x35/0x80
[<ffffffff815db14e>] schedule_preempt_disabled+0xe/0x10
[<ffffffff815dc533>] __mutex_lock_slowpath+0xb3/0x120
[<ffffffff815dc5bf>] mutex_lock+0x1f/0x30
[<ffffffff8147a59b>] power_supply_deferred_register_work+0x2b/0x50
[<ffffffff81090d09>] process_one_work+0x1e9/0x440
[<ffffffff81090fab>] worker_thread+0x4b/0x4f0
[<ffffffff81090f60>] ? process_one_work+0x440/0x440
[<ffffffff81090f60>] ? process_one_work+0x440/0x440
[<ffffffff81096b58>] kthread+0xd8/0xf0
[<ffffffff815de97f>] ret_from_fork+0x1f/0x40
[<ffffffff81096a80>] ? kthread_worker_fn+0x180/0x180
Making sysfs_add_battery() the last operation here means that the
power_supply won't be created yet when the acpi_add_battery() failure
handling happens, the deferred task won't even spawn, and
sysfs_remove_battery will just skip over the NULL battery->bat.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch enables the event freeze mode, flushing the EC event handling in
.suspend() callback. This feature is experimental, if it is bisected out to
be the cause of the real issues, please report the issues to the kernel
bugzilla for further root causing and improvement.
This mode eliminates useless _Qxx handling during the power saving
operations, thus can help to tune the power saving operations faster. Tests
show that this mode can efficiently block flooding _Qxx during the suspend
process and tune the speed of the suspend faster.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Todd E Brandt <todd.e.brandt@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In the original EC driver, though the event handling is not explicitly
stopped, the EC driver is actually not able to handle events during the
noirq stage as the EC driver is not prepared to handle the EC events in the
polling mode. So if there is no advance_transaction() triggered, the EC
driver couldn't notice the EC events.
However, do we actually need to handle EC events during suspend/resume
stage? EC events are mostly useless for the suspend/resume period (key
strokes and battery/thermal updates, etc.,), and the useful ones (lid
close, power/sleep button press) should have already been delivered to the
OSPM to trigger the power saving operations.
Thus this patch implements acpi_ec_disable_event() to be a reverse call of
acpi_ec_enable_event(), with which, the EC driver is able to stop handling
the EC events in a position before entering the noirq stage.
Since there are actually 2 choices for us:
1. implement event handling in polling mode;
2. stop event handling before entering noirq stage.
And this patch only implements the second choice using .suspend() callback.
Thus this is experimental (first choice is better? or different hook
position is better?). This patch finally keeps the old behavior by default
and prepares a boot parameter to enable this feature.
The differences of the event handling availability between the old behavior
(this patch is not applied) and the new behavior (this patch is applied)
are as follows:
!FreezeEvents FreezeEvents
before suspend Y Y
suspend before EC Y Y
suspend after EC Y N
suspend_late Y N
suspend_noirq Y (actually N) N
resume_noirq Y (actually N) N
resume_late Y (actually N) N
resume before EC Y (actually N) N
resume after EC Y Y
after resume Y Y
Where "actually N" means if there is no EC transactions, the EC driver
is actually not able to notice the pending events.
We can see that FreezeEvents is the only approach now can actually flush
the EC event handling with both query commands and _Qxx evaluations
flushed, other modes can only flush the EC event handling with only query
commands flushed, _Qxx evaluations occurred after stopping the EC driver
may end up failure due to the failure of the EC transaction carried out in
the _Qxx control methods.
We also can see that this feature should be able to trigger some platform
notifications later than resuming other drivers.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Todd E Brandt <todd.e.brandt@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch makes 2 changes:
1. Restore old behavior
Originally, EC driver stops handling both events and transactions in
acpi_ec_block_transactions(), and restarts to handle transactions in
acpi_ec_unblock_transactions_early(), restarts to handle both events and
transactions in acpi_ec_unblock_transactions().
While currently, EC driver still stops handling both events and
transactions in acpi_ec_block_transactions(), but restarts to handle both
events and transactions in acpi_ec_unblock_transactions_early().
This patch tries to restore the old behavior by dropping
__acpi_ec_enable_event() from acpi_unblock_transactions_early().
2. Improve old behavior
However this still cannot fix the real issue as both of the
acpi_ec_unblock_xxx() functions are invoked in the noirq stage. Since the
EC driver actually doesn't implement the event handling in the polling
mode, re-enabling the event handling too early in the noirq stage could
result in the problem that if there is no triggering source causing
advance_transaction() to be invoked, pending SCI_EVT cannot be detected by
the EC driver and _Qxx cannot be triggered.
It actually makes sense to restart the event handling in any point during
resuming after the noirq stage. Just like the boot stage where the event
handling is enabled in .add(), this patch further moves
acpi_ec_enable_event() to .resume(). After doing that, the following 2
functions can be combined:
acpi_ec_unblock_transactions_early()/acpi_ec_unblock_transactions().
The differences of the event handling availability between the old behavior
(this patch isn't applied) and the new behavior (this patch is applied) are
as follows:
!Applied Applied
before suspend Y Y
suspend before EC Y Y
suspend after EC Y Y
suspend_late Y Y
suspend_noirq Y (actually N) Y (actually N)
resume_noirq Y (actually N) Y (actually N)
resume_late Y (actually N) Y (actually N)
resume before EC Y (actually N) Y (actually N)
resume after EC Y (actually N) Y
after resume Y (actually N) Y
Where "actually N" means if there is no triggering source, the EC driver
is actually not able to notice the pending SCI_EVT occurred in the noirq
stage. So we can clearly see that this patch has improved the situation.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Todd E Brandt <todd.e.brandt@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
After enabling the EC event handling, Linux is still in the noirq stage, if
there is no triggering source (EC transaction, GPE STS status),
advance_transaction() will not be invoked and SCI_EVT cannot be detected.
This patch adds one more triggering source after enabling the EC event
handling to poll the pending SCI_EVT.
Known issues:
1. Still no SCI_EVT triggering source
There could still be no SCI_EVT triggering source after handling the
first SCI_EVT (polled by this patch if any). Because after handling the
first SCI_EVT, Linux could still be in noirq stage and there could still
be no further triggering source in this stage. Then the second SCI_EVT
indicated during this stage still cannot be detected by the EC driver.
With this improvement applied, it is then possible to move
acpi_ec_enable_event() out of the noirq stage to fix this issue (if the
first SCI_EVT is handled out of the noirq stage, the follow-up SCI_EVTs
should be able to trigger IRQs).
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Todd E Brandt <todd.e.brandt@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There is a hidden logic in the EC driver:
1. During boot, EC_FLAGS_QUERY_PENDING is responsible for blocking event
handling;
2. During suspend, EC_FLAGS_STARTED is responsible for blocking event
handling.
This patch uses a new EC_FLAGS_QUERY_ENABLED flag to make this hidden
logic explicit and have code cleaned up. No functional change.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Todd E Brandt <todd.e.brandt@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Following the fwnode of a device is currently a one-way road: We provide
ACPI_COMPANION() to obtain the fwnode but there's no (public) method to
do the reverse. Granted, there may be multiple physical_nodes, but often
the first one in the list is sufficient.
A handy function to obtain it was introduced with commit 3b95bd1605
("ACPI: introduce a function to find the first physical device"), but
currently it's only available internally.
We're about to add an EFI Device Path parser which needs this function.
Consider the following device path: ACPI(PNP0A03,0)/PCI(28,2)/PCI(0,0)
The PCI root is encoded as an ACPI device in the path, so the parser
has to find the corresponding ACPI device, then find its physical node,
find the PCI bridge in slot 1c (decimal 28), function 2 below it and
finally find the PCI device in slot 0, function 0.
To this end, make acpi_get_first_physical_node() public.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Per "ACPI 6.1 Section 9.20.3" NVDIMM devices, children of the ACPI0012
NVDIMM Root device, can receive health event notifications.
Given that these devices are precluded from registering a notification
handler via acpi_driver.acpi_device_ops (due to no _HID), we use
acpi_install_notify_handler() directly. The registered handler,
acpi_nvdimm_notify(), triggers a poll(2) event on the nmemX/nfit/flags
sysfs attribute when a health event notification is received.
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hpe.com>
Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Reviewed-by: Toshi Kani <toshi.kani@hpe.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
We have had a couple bugs in this implementation in the past and before
we add another ->notify() implementation for nvdimm devices, lets allow
this routine to be exercised via nfit_test.
Rewrite acpi_nfit_notify() in terms of a generic struct device and
acpi_handle parameter, and then implement a mock acpi_evaluate_object()
that returns a _FIT payload.
Cc: Vishal Verma <vishal.l.verma@intel.com>
Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Commit 209851649d "acpi: nfit: Add support for hot-add" added
support for _FIT notifications, but it neglected to verify the
notification event code matches the one in the ACPI spec for
"NFIT Update". Currently there is only one code in the spec, but
once additional codes are added, older kernels (without this fix)
will misbehave by assuming all event notifications are for an
NFIT Update.
Fixes: 209851649d ("acpi: nfit: Add support for hot-add")
Cc: <stable@vger.kernel.org>
Cc: <linux-acpi@vger.kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reported-by: Linda Knippers <linda.knippers@hpe.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
handle_ioapic_add() uses request_resource() to request ACPI "_CRS"
resources. This can fail with the following error message:
[ 247.325693] ACPI: \_SB_.IIO1.AID1: failed to insert resource
This happens when there are multiple IOAPICs and DSDT groups their
"_CRS" resources as the children of a parent resource, as seen from
/proc/iomem:
fec00000-fecfffff : PNP0003:00
fec00000-fec003ff : IOAPIC 0
fec01000-fec013ff : IOAPIC 1
fec40000-fec403ff : IOAPIC 2
In this case request_resource() fails because there's a conflicting
resource which is the parent (fec0000-fecfffff). Fix it by using
insert_resource() which can request resources by taking the conflicting
resource as the parent.
Signed-off-by: Rui Wang <rui.y.wang@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bhelgaas@google.com
Cc: helgaas@kernel.org
Cc: linux-acpi@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: rjw@rjwysocki.net
Cc: tony.luck@intel.com
Link: http://lkml.kernel.org/r/1471420837-31003-6-git-send-email-rui.y.wang@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
IOAPIC resource at 0xfecxxxxx gets lost from /proc/iomem after
hot-removing and then hot-adding the IOAPIC device.
After system boot, in /proc/iomem:
fec00000-fecfffff : PNP0003:00
fec00000-fec003ff : IOAPIC 0
fec01000-fec013ff : IOAPIC 1
fec40000-fec403ff : IOAPIC 2
fec80000-fec803ff : IOAPIC 3
fecc0000-fecc03ff : IOAPIC 4
Then hot-remove IOAPIC 2 and hot-add it again:
fec00000-fecfffff : PNP0003:00
fec00000-fec003ff : IOAPIC 0
fec01000-fec013ff : IOAPIC 1
fec80000-fec803ff : IOAPIC 3
fecc0000-fecc03ff : IOAPIC 4
The range at 0xfec40000 is lost from /proc/iomem - which is a bug.
This bug happens because handle_ioapic_add() requests resources from
either PCI config BAR or ACPI "_CRS", not both. But Intel platforms
map the IOxAPIC registers both at the PCI config BAR (called MBAR, dynamic),
and at the ACPI "_CRS" (called ABAR, static). The 0xfecX_YZ00 to 0xfecX_YZFF
range appears in "_CRS" of each IOAPIC device.
Both ranges should be claimed from /proc/iomem for exclusive use.
Signed-off-by: Rui Wang <rui.y.wang@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bhelgaas@google.com
Cc: helgaas@kernel.org
Cc: linux-acpi@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: rjw@rjwysocki.net
Cc: tony.luck@intel.com
Link: http://lkml.kernel.org/r/1471420837-31003-5-git-send-email-rui.y.wang@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Add device HID for SPI controller on Broadcom Vulcan ARM64.
The default frequency for SPI on Vulcan is 133MHz.
Signed-off-by: Kamlakant Patel <kamlakant.patel@broadcom.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
It is reported that on some platforms, resume speed is not fast. The cause
is: in noirq stage, EC driver is working in polling mode, and each state
machine advancement requires a context switch.
The context switch is not necessary to the EC driver's polling mode. This
patch implements PM hooks to automatically switch the driver to/from the
busy polling mode to eliminate the overhead caused by the context switch.
This finally contributes to the tuning result: acpi_pm_finish() execution
time is improved from 192ms to 6ms.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reported-and-tested-by: Todd E Brandt <todd.e.brandt@linux.intel.com>
[ rjw: Subject ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Now GPE can be masked via the new acpi_mask_gpe() API and this patch
modifies /sys/firmware/acpi/interrupts/gpexx to use this new facility.
Writes "mask/unmask" to this file now invokes acpi_mask_gpe().
Reads from this file now returns new "EN/STS" when the corresponding GPE
hardware register's EN/STS bits are flagged, and new "masked/unmasked"
attribute to indicate the status of the masking mechanism.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
[ rjw: Subject ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit d1b7372c7eb89cdba3d3c239fb07e2fdc5abf880
This is a regression fix, restoring usage macro to its original
implementation.
There is an issue for usage macros, if an command line option changed
acpi_gbl_debug_file, then the follow up usage message may be errornously
dumped to the debug file.
This is just a bug in theory, because currently acpi_gbl_debug_file can only
be modified by acpibin and acpiexec. And this will not trigger such issue
because:
1. For acpibin, acpi_gbl_debug_file will be modified by "-t" option and the
program exits after processing this option without dumping help message
or other error options.
2. For acpiexec, acpi_gbl_debug_file will only be modified by the open
command, which happens after parsing the command line options, so no
help message will be dumped into the debug file.
But maintaining this logic is difficult, so this patch modifies
acpi_os_printf() into printf() for usage macros so that the help messages are
ensured to be dumped to the stdout. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/d1b7372c
Link: https://bugs.acpica.org/show_bug.cgi?id=1142
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 189429fb7d06cdb89043ae32d615faf553467f1d
This patch follows new ACPICA design, eliminates old portable OSLs, and
implements fopen/fread/fwrite/fclose/fseek/ftell for GNU EFI
environment. This patch also eliminates acpi_log_error(), convering them
into fprintf(stderr)/perror(). Lv Zheng.
Link: https://github.com/acpica/acpica/commit/189429fb
Link: https://bugs.acpica.org/show_bug.cgi?id=1302
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit d261d40ea168f8e4c4e3986de720b8651c4aba1c
This patch adds sprintf()/snprintf()/vsnprintf()/printf()/vfprintf()
support for OSPMs that have ACPI_USE_SYSTEM_CLIBRARY defined but do not
have ACPI_USE_STANDARD_HEADERS defined.
-iwithprefix include is required to include <stdarg.h> which contains
compiler specific implementation of vargs when -nostdinc is specified.
-fno-builtin is required for GCC to avoid optimization performed printf().
This optimization cannot be automatically disabled by specifying -nostdlib.
Please refer to the first link below for the details. However, the build
option changes do not affect Linux kernel builds and are not included.
Lv Zheng.
Link: http://www.ciselant.de/projects/gcc_printf/gcc_printf.html
Link: https://github.com/acpica/acpica/commit/d261d40e
Link: https://bugs.acpica.org/show_bug.cgi?id=1302
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 9bb265c2afb9910e46f820d6759648580edabd09
When /Za is specified, headers of some Windows SDKs contain bugs breaking
VC builds, and MSVC9's default SDK is one of such header-buggy library.
In order to solve this issue, many VC developers stop using /Za. However
we've been asked to have this fixed without removing /Za.
In MSVC9 default SDK, this issue can be fixed by restricting <sys/stat.h>
to be the last standard file included by every source file in the projects.
This patch thus moves <sys/stat.h> inclusion to "acapps.h", so that this
issue can be fixed by ensuring that "acapps.h" is always the last standard
file included by all of the ACPICA source files. This is in fact also a
useful cleanup because applications can only include one header (e.x.,
acpidump.h) instead of including acapps.h separately. Lv Zheng.
Except some harmless header inclusion re-ordering, Linux kernel is not
affected by this change.
Link: https://github.com/acpica/acpica/commit/9bb265c2
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 7f9b359b7c78c69b07f62eb2d58f710c351fd75d
EFI header should use standard C library stuffs (integer types and IO
handles) rather than implementing such standard stuffs.
This patch fixes this issue by:
1. Implementing standard integer types for ACPI_USE_STANDARD_HADERS=n;
2. Defining EFI types using standard integer types and standard IO handles;
3. Tuning header inclusion order and environment definition order;
4. Removing wrong standard header inclusion from ACPICA core files;
5. Moving several application headers from acpidump.h to acenv.h.
This patch corrects some of them. Lv Zheng.
Except some harmless header inclusion re-ordering, Linux kernel is not
affected by this change.
Link: https://github.com/acpica/acpica/commit/7f9b359b
Link: https://bugs.acpica.org/show_bug.cgi?id=1300
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 408198c8c9786f9f104ee925020c3ab1701906e4
The acpi_gbl_debug_timeout which is used by acpiexec -et option now is only
implemented in oswinxf.c and used for WIN32 builds. This makes it very
difficult to remember that we need to add this variable to other os
specific layer files in order for linking. This patch makes it a global
option dependent on ACPI_APPLICATION so that it can always be linked by the
applications. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/408198c8
Link: https://bugs.acpica.org/show_bug.cgi?id=1295
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 649eb441fbef21965d10a1aca6ff41dcf23f8e05
dbfileio.c implements debugger functionalities that can only be used by the
application layer debugger (acpiexec), thus it should always include
<acapps.h> and thus shouldn't include <stdio.h> separately. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/649eb441
Link: https://bugs.acpica.org/show_bug.cgi?id=1292
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 34ccd43af3fd1870fddfac0617dd0ba706963558
Remove all vestiges of the version 2 FADT which never was included
in the ACPI specification.
This enabled significant cleanup of both the data table compiler
and the disassembler.
Added many clarification comments to associate each FADT version
with the version of the ACPI spec where it was originally
defined.
Link: https://github.com/acpica/acpica/commit/34ccd43a
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 23a417ca406a527e7ae1710893e59a8b6db30e14
There is a facility in Linux, developers can control the enabling/disabling
of a GPE via /sys/firmware/acpi/interrupts/gpexx. This is mainly for
debugging purposes.
But many users expect to use this facility to implement quirks to mask a
specific GPE when there is a gap in Linux causing this GPE to flood. This
is not working correctly because currently this facility invokes
enabling/disabling counting based GPE driver APIs:
acpi_enable_gpe()/acpi_disable_gpe()
and the GPE drivers can still affect the count to mess up the GPE
masking purposes.
However, most of the IRQ chip designs allow masking/unmasking IRQs via a
masking bit which is different from the enabled bit to achieve the same
purpose. But the GPE hardware doesn't contain such a feature, this brings
the trouble.
In this patch, we introduce a software mechanism to implement the GPE
masking feature, and acpi_mask_gpe() are provided to the OSPMs to
mask/unmask GPEs in the above mentioned situation instead of
acpi_enable_gpe()/acpi_disable_gpe(). ACPICA BZ 1102. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/23a417ca
Link: https://bugs.acpica.org/show_bug.cgi?id=1102
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit c160cae765412f5736cf88a9ebcc6138aa761a48
Linux uses asmlinkage and sparse macros to mark function symbols. This
leads to the divergences between the Linux and the ACPICA.
This patch ports such declarators back to ACPICA. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/c160cae7
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 857c510d70e18eecc275dd3087807a18bae8aa51
Allow for static configuration of this parameter. It is used
to abort out of infinite loops caused by non-response from
hardware.
Link: https://github.com/acpica/acpica/commit/857c510d
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 152a8ca2c7fc877d6aff0f9d0965184ef2ddce5c
Opcode 0x15 was added in ACPI 6.0 for disassemblers.
The disassembler by default does not emit the actual opcodes, they
are used internally. Option added for internal debugging only.
This patch doesn't affect Linux kernel as disassembler is not in
the Linux kernel.
Link: https://github.com/acpica/acpica/commit/152a8ca2
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 622063bae684490191c8e8b10bf18e86d0ab4ebf
Fix a couple of arbitrarily small output line lengths.
Link: https://github.com/acpica/acpica/commit/622063ba
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 58c9e7b83ae35247e430c39363f55b6f70fa04a2
It is reported that the logging level of the ACPICA messages are not
correct in the Linux kernel. This patch fixes this issue. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/58c9e7b8
Link: https://bugzilla.kernel.org/show_bug.cgi?id=117461
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit f2d349f8a11efc0f438ad6903564f3a6755dc6b9
The interpreter should never see this opcode (it is used by
disassemblers), so the final implementation is to return an
error.
Link: https://github.com/acpica/acpica/commit/f2d349f8
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 8b3b57c9d11d9c322e09cb06bedac7aa783458fd
Link: https://github.com/acpica/acpica/commit/8b3b57c9
Signed-off-by: Jung-uk Kim <jkim@FreeBSD.org>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit f722da0372261331b74d3ac67645bba912a21643
Link: https://github.com/acpica/acpica/commit/f722da03
Signed-off-by: Jung-uk Kim <jkim@FreeBSD.org>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The "NVDIMM Block Window Driver Writer's Guide":
http://pmem.io/documents/NVDIMM_DriverWritersGuide-July-2016.pdf
...defines the layout of the block window status register. For the July
2016 version of the spec linked to above, this happens in Figure 4 on
page 26.
The only bits defined in this spec are bits 31, 5, 4, 2, 1 and 0. The
rest of the bits in the status register are reserved, and there is a
warning following the diagram that says:
Note: The driver cannot assume the value of the RESERVED bits in the
status register are zero. These reserved bits need to be masked off, and
the driver must avoid checking the state of those bits.
This change ensures that for hardware implementations that set these
reserved bits in the status register, the driver won't incorrectly fail the
block I/Os.
Cc: <stable@vger.kernel.org> #v4.2+
Reviewed-by: Lee, Chun-Yi <jlee@suse.com>
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
- An ACPI EC driver fix from the 4.3 cycle may cause the ACPICA's
method reentrancy limit to be exceeded for a _Qxx method due to a
large number of concurrent EC operations, so prevent that from
happening by moving the EC handling into a separate workqueue
with a limit on the number of concurrently executed work items
(Lv Zheng).
- Fix the cleanup code in the ACPI button driver that forgets to
clear two variables on exit which causes an error to occur on the
next attmpt to load the driver (Benjamin Tissoires).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJXpKM9AAoJEILEb/54YlRxTagP/0FSQSfUX5N7UERhpV5zmC/D
hw8xv4nsZwdBicABuOT2dqIB6Xs2J3WtK93exR6EvVTw2OY0qZCcEluj4OYDvqP6
JtgHiWnoLjGN66hWcTDjY4ncWjC7vO8ohH/fisBrUkMhK6bNE3E/E1ffFx+BSnxP
1BpJH8erFxWVAREuYYqv7CdGFVNa3Ij7D678+3BtRVncfpCXSRyhT37/RZXyEJgu
zZ+c0aU1vaLYtyyrGVnQ5b420CQSWO8Mi7o5hD5D6mR4zKE4p/KtdivE9ipivgzh
axuotmOdQQn1qu+EpKyEDHj1OgMg+5tVlfw/zkUeRmtWC5xcwvRvWKiAA4bVNkur
PxWnvUUSc1PLPz2ex0NmXwHBwHTVQtcJpZy/NH/v4E+TbtRMLBt85Cg7V7Hwn5RR
mDBOP526LClwrxnBpioSD/lNYeaM4F8STVbk0MpC4n/vmPQkhsKn6eyRNCM9gw0q
F2z2NLekqrSiI5kuR36yR32m5mbydIAEhxRXFTQL2ggCY8CZUOiLLRsQerQ4wIgH
p2LKLVpQRgZCh/gcsLfCRv6i/wD7Lmzokf6lQD/JXzv/prXRq0oCvRs96JbxNT6q
NepJsAI0AtUqEcuMaadMGnMPZLoJAMzFPSGdK/ZHMpSxGy0xBuEmNUHl1Vm50hcr
MMZlQPz05afSMApzLBAf
=Uafi
-----END PGP SIGNATURE-----
Merge tag 'acpi-extra-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull more ACPI updates from Rafael Wysocki:
"Two more fixes in ACPI drivers, one in the ACPI EC driver
(stable-candidate) and one in the ACPI button driver.
Specifics:
- An ACPI EC driver fix from the 4.3 cycle may cause the ACPICA's
method reentrancy limit to be exceeded for a _Qxx method due to a
large number of concurrent EC operations, so prevent that from
happening by moving the EC handling into a separate workqueue with
a limit on the number of concurrently executed work items (Lv
Zheng)
- Fix the cleanup code in the ACPI button driver that forgets to
clear two variables on exit which causes an error to occur on the
next attmpt to load the driver (Benjamin Tissoires)"
* tag 'acpi-extra-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / EC: Work around method reentrancy limit in ACPICA for _Qxx
ACPI / button: remove pointer to old lid_sysfs on unbind
Cleanups:
- huge cleanup of rtc-generic and char/genrtc this allowed to cleanup rtc-cmos,
rtc-sh, rtc-m68k, rtc-powerpc and rtc-parisc
- move mn10300 to rtc-cmos
Subsystem:
- fix wakealarms after hibernate
- multiples fixes for rctest
- simplify implementations of .read_alarm
New drivers:
- Maxim MAX6916
Drivers:
- ds1307: fix weekday
- m41t80: add wakeup support
- pcf85063: add support for PCF85063A variant
- rv8803: extend i2c fix and other fixes
- s35390a: fix alarm reading, this fixes instant reboot after shutdown for QNAP
TS-41x
- s3c: clock fixes
-----BEGIN PGP SIGNATURE-----
iQIcBAABCgAGBQJXokhIAAoJENiigzvaE+LCZqQP+wWzintN/N1u3dKiVB7iSdwq
+S/jAXD9wW8OK9PI60/YUGRYeUXmZW9t4XYg1VKCxU9KpVC17LgOtDyXD8BufP1V
uREJEzZw9O7zCCjeHp/ICFjBkc62Net6ZDOO+ZyXPNfddpS1Xq1uUgXLZc/202UR
ID/kewu0pJRDnoxyqznWn9+8D33w/ygXs2slY2Ive0ONtjdgxGcsj2rNbb2RYn2z
OP7br3lLg7qkFh4TtXb61eh/9GYIk6wzP/CrX5l/jH4SjQnrIk5g/X/Cd1qQ/qso
JZzFoonOKvIp5Gw/+fZ9NP3YFcnkoRMv4NjZV8PAmsYLds+ibRiBcoB8u6FmiJV7
WW5uopgPkfCGN5BV3+QHwJDVe+WlgnlzaT5zPUCcP5KWusDts4fWIgzP7vrtAzf4
3OJLrgSGdBeOqWnJD21nxKUD27JOseX7D+BFtwxR4lMsXHqlHJfETpZ8gts1ZGH3
2U353j/jkZvGWmc6dMcuxOXT2K4VqpYeIIqs0IcLu6hM9crtR89zPR2Iu1AilfDW
h2NroF+Q//SgMMzWoTEG6Tn7RAc7MthgA/tRCFZF9CBMzNs988w0CTHnKsIHmjpU
UKkMeJGAC9YrPYIcqrg0oYsmLUWXc8JuZbGJBnei3BzbaMTlcwIN9qj36zfq6xWc
TMLpbWEoIsgFIZMP/hAP
=rpGB
-----END PGP SIGNATURE-----
Merge tag 'rtc-4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux
Pull RTC updates from Alexandre Belloni:
"RTC for 4.8
Cleanups:
- huge cleanup of rtc-generic and char/genrtc this allowed to cleanup
rtc-cmos, rtc-sh, rtc-m68k, rtc-powerpc and rtc-parisc
- move mn10300 to rtc-cmos
Subsystem:
- fix wakealarms after hibernate
- multiples fixes for rctest
- simplify implementations of .read_alarm
New drivers:
- Maxim MAX6916
Drivers:
- ds1307: fix weekday
- m41t80: add wakeup support
- pcf85063: add support for PCF85063A variant
- rv8803: extend i2c fix and other fixes
- s35390a: fix alarm reading, this fixes instant reboot after
shutdown for QNAP TS-41x
- s3c: clock fixes"
* tag 'rtc-4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (65 commits)
rtc: rv8803: Clear V1F when setting the time
rtc: rv8803: Stop the clock while setting the time
rtc: rv8803: Always apply the I²C workaround
rtc: rv8803: Fix read day of week
rtc: rv8803: Remove the check for valid time
rtc: rv8803: Kconfig: Indicate rx8900 support
rtc: asm9260: remove .owner field for driver
rtc: at91sam9: Fix missing spin_lock_init()
rtc: m41t80: add suspend handlers for alarm IRQ
rtc: m41t80: make it a real error message
rtc: pcf85063: Add support for the PCF85063A device
rtc: pcf85063: fix year range
rtc: hym8563: in .read_alarm set .tm_sec to 0 to signal minute accuracy
rtc: explicitly set tm_sec = 0 for drivers with minute accurancy
rtc: s3c: Add s3c_rtc_{enable/disable}_clk in s3c_rtc_setfreq()
rtc: s3c: Remove unnecessary call to disable already disabled clock
rtc: abx80x: use devm_add_action_or_reset()
rtc: m41t80: use devm_add_action_or_reset()
rtc: fix a typo and reduce three empty lines to one
rtc: s35390a: improve two comments in .set_alarm
...
A regression is caused by the following commit:
Commit: 02b771b64b
Subject: ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations
In this commit, using system workqueue causes that the maximum parallel
executions of _Qxx can exceed 255. This violates the method reentrancy
limit in ACPICA and generates the following error log:
ACPI Error: Method reached maximum reentrancy limit (255) (20150818/dsmethod-341)
This patch creates a seperate workqueue and limits the number of parallel
_Qxx evaluations down to a configurable value (can be tuned against number
of online CPUs).
Since EC events are handled after driver probe, we can create the workqueue
in acpi_ec_init().
Fixes: 02b771b64b (ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=135691
Cc: 4.3+ <stable@vger.kernel.org> # 4.3+
Reported-and-tested-by: Helen Buus <ubuntu@hbuus.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge yet more updates from Andrew Morton:
- the rest of ocfs2
- various hotfixes, mainly MM
- quite a bit of misc stuff - drivers, fork, exec, signals, etc.
- printk updates
- firmware
- checkpatch
- nilfs2
- more kexec stuff than usual
- rapidio updates
- w1 things
* emailed patches from Andrew Morton <akpm@linux-foundation.org>: (111 commits)
ipc: delete "nr_ipc_ns"
kcov: allow more fine-grained coverage instrumentation
init/Kconfig: add clarification for out-of-tree modules
config: add android config fragments
init/Kconfig: ban CONFIG_LOCALVERSION_AUTO with allmodconfig
relay: add global mode support for buffer-only channels
init: allow blacklisting of module_init functions
w1:omap_hdq: fix regression
w1: add helper macro module_w1_family
w1: remove need for ida and use PLATFORM_DEVID_AUTO
rapidio/switches: add driver for IDT gen3 switches
powerpc/fsl_rio: apply changes for RIO spec rev 3
rapidio: modify for rev.3 specification changes
rapidio: change inbound window size type to u64
rapidio/idt_gen2: fix locking warning
rapidio: fix error handling in mbox request/release functions
rapidio/tsi721_dma: advance queue processing from transfer submit call
rapidio/tsi721: add messaging mbox selector parameter
rapidio/tsi721: add PCIe MRRS override parameter
rapidio/tsi721_dma: add channel mask and queue size parameters
...
When we removed the procfs dir on error or if the driver is
unbound, the two variables acpi_lid_dir and acpi_button_dir
were not reset. On the next rebind, those static variables
were not null and we couldn't re-register the device again.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There was only one use of __initdata_refok and __exit_refok
__init_refok was used 46 times against 82 for __ref.
Those definitions are obsolete since commit 312b1485fb ("Introduce new
section reference annotations tags: __ref, __refdata, __refconst")
This patch removes the following compatibility definitions and replaces
them treewide.
/* compatibility defines */
#define __init_refok __ref
#define __initdata_refok __refdata
#define __exit_refok __ref
I can also provide separate patches if necessary.
(One patch per tree and check in 1 month or 2 to remove old definitions)
[akpm@linux-foundation.org: coding-style fixes]
Link: http://lkml.kernel.org/r/1466796271-3043-1-git-send-email-fabf@skynet.be
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull smp hotplug updates from Thomas Gleixner:
"This is the next part of the hotplug rework.
- Convert all notifiers with a priority assigned
- Convert all CPU_STARTING/DYING notifiers
The final removal of the STARTING/DYING infrastructure will happen
when the merge window closes.
Another 700 hundred line of unpenetrable maze gone :)"
* 'smp-hotplug-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (70 commits)
timers/core: Correct callback order during CPU hot plug
leds/trigger/cpu: Move from CPU_STARTING to ONLINE level
powerpc/numa: Convert to hotplug state machine
arm/perf: Fix hotplug state machine conversion
irqchip/armada: Avoid unused function warnings
ARC/time: Convert to hotplug state machine
clocksource/atlas7: Convert to hotplug state machine
clocksource/armada-370-xp: Convert to hotplug state machine
clocksource/exynos_mct: Convert to hotplug state machine
clocksource/arm_global_timer: Convert to hotplug state machine
rcu: Convert rcutree to hotplug state machine
KVM/arm/arm64/vgic-new: Convert to hotplug state machine
smp/cfd: Convert core to hotplug state machine
x86/x2apic: Convert to CPU hotplug state machine
profile: Convert to hotplug state machine
timers/core: Convert to hotplug state machine
hrtimer: Convert to hotplug state machine
x86/tboot: Convert to hotplug state machine
arm64/armv8 deprecated: Convert to hotplug state machine
hwtracing/coresight-etm4x: Convert to hotplug state machine
...
1/ Replace pcommit with ADR / directed-flushing:
The pcommit instruction, which has not shipped on any product, is
deprecated. Instead, the requirement is that platforms implement either
ADR, or provide one or more flush addresses per nvdimm. ADR
(Asynchronous DRAM Refresh) flushes data in posted write buffers to the
memory controller on a power-fail event. Flush addresses are defined in
ACPI 6.x as an NVDIMM Firmware Interface Table (NFIT) sub-structure:
"Flush Hint Address Structure". A flush hint is an mmio address that
when written and fenced assures that all previous posted writes
targeting a given dimm have been flushed to media.
2/ On-demand ARS (address range scrub):
Linux uses the results of the ACPI ARS commands to track bad blocks
in pmem devices. When latent errors are detected we re-scrub the media
to refresh the bad block list, userspace can also request a re-scrub at
any time.
3/ Support for the Microsoft DSM (device specific method) command format.
4/ Support for EDK2/OVMF virtual disk device memory ranges.
5/ Various fixes and cleanups across the subsystem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXmXBsAAoJEB7SkWpmfYgCEwwP/1IOt9ocP+iHLMDH9KE7VaTZ
NmUDR+Zy6g5cRQM7SgcuU5BXUcx+OsSrSrUTVF1cW994o9Gbz1mFotkv0ZAsPcYY
ZVRQxo2oqHrssyOcg+PsgKWiXn68rJOCgmpEyzaJywl5qTMst7pzsT1s1f7rSh6h
trCf4VaJJwxZR8fARGtlHUnnhPe2Orp99EZRKEWprAsIv2kPuWpPHSjRjuEgN1JG
KW8AYwWqFTtiLRUk86I4KBB0wcDrfctsjgN9Ogd6+aHyQBRnVSr2U+vDCFkC8KLu
qiDCpYp+yyxBjclnljz7tRRT3GtzfCUWd4v2KVWqgg2IaobUc0Lbukp/rmikUXQP
WLikT2OCQ994eFK5OX3Q3cIU/4j459TQnof8q14yVSpjAKrNUXVSR5puN7Hxa+V7
41wKrAsnsyY1oq+Yd/rMR8VfH7PHx3bFkrmRCGZCufLX1UQm4aYj+sWagDKiV3yA
DiudghbOnhfurfGsnXUVw7y7GKs+gNWNBmB6ndAD6ZEHmKoGUhAEbJDLCc3DnANl
b/2mv1MIdIcC1DlCmnbbcn6fv6bICe/r8poK3VrCK3UgOq/EOvKIWl7giP+k1JuC
6DdVYhlNYIVFXUNSLFAwz8OkLu8byx7WDm36iEqrKHtPw+8qa/2bWVgOU6OBgpjV
cN3edFVIdxvZeMgM5Ubq
=xCBG
-----END PGP SIGNATURE-----
Merge tag 'libnvdimm-for-4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
Pull libnvdimm updates from Dan Williams:
- Replace pcommit with ADR / directed-flushing.
The pcommit instruction, which has not shipped on any product, is
deprecated. Instead, the requirement is that platforms implement
either ADR, or provide one or more flush addresses per nvdimm.
ADR (Asynchronous DRAM Refresh) flushes data in posted write buffers
to the memory controller on a power-fail event.
Flush addresses are defined in ACPI 6.x as an NVDIMM Firmware
Interface Table (NFIT) sub-structure: "Flush Hint Address Structure".
A flush hint is an mmio address that when written and fenced assures
that all previous posted writes targeting a given dimm have been
flushed to media.
- On-demand ARS (address range scrub).
Linux uses the results of the ACPI ARS commands to track bad blocks
in pmem devices. When latent errors are detected we re-scrub the
media to refresh the bad block list, userspace can also request a
re-scrub at any time.
- Support for the Microsoft DSM (device specific method) command
format.
- Support for EDK2/OVMF virtual disk device memory ranges.
- Various fixes and cleanups across the subsystem.
* tag 'libnvdimm-for-4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: (41 commits)
libnvdimm-btt: Delete an unnecessary check before the function call "__nd_device_register"
nfit: do an ARS scrub on hitting a latent media error
nfit: move to nfit/ sub-directory
nfit, libnvdimm: allow an ARS scrub to be triggered on demand
libnvdimm: register nvdimm_bus devices with an nd_bus driver
pmem: clarify a debug print in pmem_clear_poison
x86/insn: remove pcommit
Revert "KVM: x86: add pcommit support"
nfit, tools/testing/nvdimm/: unify shutdown paths
libnvdimm: move ->module to struct nvdimm_bus_descriptor
nfit: cleanup acpi_nfit_init calling convention
nfit: fix _FIT evaluation memory leak + use after free
tools/testing/nvdimm: add manufacturing_{date|location} dimm properties
tools/testing/nvdimm: add virtual ramdisk range
acpi, nfit: treat virtual ramdisk SPA as pmem region
pmem: kill __pmem address space
pmem: kill wmb_pmem()
libnvdimm, pmem: use nvdimm_flush() for namespace I/O writes
fs/dax: remove wmb_pmem()
libnvdimm, pmem: flush posted-write queues on shutdown
...
- ACPI support for guests on ARM platforms.
- Generic steal time support for arm and x86.
- Support cases where kernel cpu is not Xen VCPU number (e.g., if
in-guest kexec is used).
- Use the system workqueue instead of a custom workqueue in various
places.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJXmLlrAAoJEFxbo/MsZsTRvRQH/1wOMF8BmlbZfR7H3qwDfjst
ApNifCiZE08xDtWBlwUaBFAQxyflQS9BBiNZDVK0sysIdXeOdpWV7V0ZjRoLL+xr
czsaaGXDcmXxJxApoMDVuT7FeP6rEk6LVAYRoHpVjJjMZGW3BbX1vZaMW4DXl2WM
9YNaF2Lj+rpc1f8iG31nUxwkpmcXFog6ct4tu7HiyCFT3hDkHt/a4ghuBdQItCkd
vqBa1pTpcGtQBhSmWzlylN/PV2+NKcRd+kGiwd09/O/rNzogTMCTTWeHKAtMpPYb
Cu6oSqJtlK5o0vtr0qyLSWEGIoyjE2gE92s0wN3iCzFY1PldqdsxUO622nIj+6o=
=G6q3
-----END PGP SIGNATURE-----
Merge tag 'for-linus-4.8-rc0-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull xen updates from David Vrabel:
"Features and fixes for 4.8-rc0:
- ACPI support for guests on ARM platforms.
- Generic steal time support for arm and x86.
- Support cases where kernel cpu is not Xen VCPU number (e.g., if
in-guest kexec is used).
- Use the system workqueue instead of a custom workqueue in various
places"
* tag 'for-linus-4.8-rc0-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: (47 commits)
xen: add static initialization of steal_clock op to xen_time_ops
xen/pvhvm: run xen_vcpu_setup() for the boot CPU
xen/evtchn: use xen_vcpu_id mapping
xen/events: fifo: use xen_vcpu_id mapping
xen/events: use xen_vcpu_id mapping in events_base
x86/xen: use xen_vcpu_id mapping when pointing vcpu_info to shared_info
x86/xen: use xen_vcpu_id mapping for HYPERVISOR_vcpu_op
xen: introduce xen_vcpu_id mapping
x86/acpi: store ACPI ids from MADT for future usage
x86/xen: update cpuid.h from Xen-4.7
xen/evtchn: add IOCTL_EVTCHN_RESTRICT
xen-blkback: really don't leak mode property
xen-blkback: constify instance of "struct attribute_group"
xen-blkfront: prefer xenbus_scanf() over xenbus_gather()
xen-blkback: prefer xenbus_scanf() over xenbus_gather()
xen: support runqueue steal time on xen
arm/xen: add support for vm_assist hypercall
xen: update xen headers
xen-pciback: drop superfluous variables
xen-pciback: short-circuit read path used for merging write values
...
- Support for ACPI SSDT overlays allowing Secondary System
Description Tables (SSDTs) to be loaded at any time from EFI
variables or via configfs (Octavian Purdila, Mika Westerberg).
- Support for the ACPI LPI (Low-Power Idle) feature introduced in
ACPI 6.0 and allowing processor idle states to be represented in
ACPI tables in a hierarchical way (with the help of Processor
Container objects) and support for ACPI idle states management
on ARM64, based on LPI (Sudeep Holla).
- General improvements of ACPI support for NUMA and ARM64 support
for ACPI-based NUMA (Hanjun Guo, David Daney, Robert Richter).
- General improvements of the ACPI table upgrade mechanism and
ARM64 support for that feature (Aleksey Makarov, Jon Masters).
- Support for the Boot Error Record Table (BERT) in APEI and
improvements of kernel messages printed by the error injection
code (Huang Ying, Borislav Petkov).
- New driver for the Intel Broxton WhiskeyCove PMIC operation
region and support for the REGS operation region on Broxton,
PMIC code cleanups (Bin Gao, Felipe Balbi, Paul Gortmaker).
- New driver for the power participant device which is part of the
Dynamic Power and Thermal Framework (DPTF) and DPTF-related code
reorganization (Srinivas Pandruvada).
- Support for the platform-initiated graceful shutdown feature
introduced in ACPI 6.1 (Prashanth Prakash).
- ACPI button driver update related to lid input events generated
automatically on initialization and system resume that have been
problematic for some time (Lv Zheng).
- ACPI EC driver cleanups (Lv Zheng).
- Documentation of the ACPICA release automation process and the
in-kernel ACPI AML debugger (Lv Zheng).
- New blacklist entry and two fixes for the ACPI backlight driver
(Alex Hung, Arvind Yadav, Ralf Gerbig).
- Cleanups of the ACPI pci_slot driver (Joe Perches, Paul Gortmaker).
- ACPI CPPC code changes to make it more robust against possible
defects in ACPI tables and new symbol definitions for PCC (Hoan
Tran).
- System reboot code modification to execute the ACPI _PTS (Prepare
To Sleep) method in addition to _TTS (Ocean He).
- ACPICA-related change to carry out lock ordering checks in ACPICA
if ACPICA debug is enabled in the kernel (Lv Zheng).
- Assorted minor fixes and cleanups (Andy Shevchenko, Baoquan He,
Bhaktipriya Shridhar, Paul Gortmaker, Rafael Wysocki).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJXl8A7AAoJEILEb/54YlRxF0kQAI6mH0yan60Osu4598+VNvgv
wxOWl1TEbKd+LaJkofRZ+FPzZkQf5c/h/8Oo8Q3LEpFhjkARhhX7ThDjS5v2Nx6v
I/icQ64ynPUPrw6hGNVrmec9ofZjiAs3j3Rt2bEiae+YN6guvfhWE+kBCHo2G/nN
o4BSaxYjkphUTDSi4/5BfaocV2sl3apvwjtAj8zgGn4RD81bFFLnblynHkqJVcoN
HAfm7QTVjT01Zkv565OSZgK8CFcD8Ky2KKKBQvcIW8zQmD6IXaoTHSYSwL0SH+oK
bxUZUmWVfFWw4kDTAY9mw0QwtWz9ODTWh/WMhs3itWRRN5qHfogs99rCVYFtFufQ
ODVy4wpt4wmpzZVhyUDTTigAhznPAtCam6EpL1YeNbtyrRN4evvZVFHBZJnmhosX
zI9iLF4eqdnJZKvh+L1VFU+py8aAZpz1ZEOatNMI+xdhArbGm7v89cldzaRkJhuW
LZr+JqYQGaOZS5qSnymwJL1KfF66+2QGpzdvzJN5FNIDACoqanATbZ/Iie2ENcM+
WwCEWrGJFDmM30raBNNcvx0yHFtVkcNbOymla4paVg7i29nu88Ynw4Z6seIIP11C
DryzLFhw+3jdTg2zK/te/wkhciJ0F+iZjo6VXywSMnwatf36bpdp4r4JLUVfEo2t
8DOGKyFMLYY1zOPMK9Th
=YwbM
-----END PGP SIGNATURE-----
Merge tag 'acpi-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI updates from Rafael Wysocki:
"The new feaures here are the support for ACPI overlays (allowing ACPI
tables to be loaded at any time from EFI variables or via configfs)
and the LPI (Low-Power Idle) support. Also notable is the ACPI-based
NUMA support for ARM64.
Apart from that we have two new drivers, for the DPTF (Dynamic Power
and Thermal Framework) power participant device and for the Intel
Broxton WhiskeyCove PMIC, some more PMIC-related changes, support for
the Boot Error Record Table (BERT) in APEI and support for
platform-initiated graceful shutdown.
Plus two new pieces of documentation and usual assorted fixes and
cleanups in quite a few places.
Specifics:
- Support for ACPI SSDT overlays allowing Secondary System
Description Tables (SSDTs) to be loaded at any time from EFI
variables or via configfs (Octavian Purdila, Mika Westerberg).
- Support for the ACPI LPI (Low-Power Idle) feature introduced in
ACPI 6.0 and allowing processor idle states to be represented in
ACPI tables in a hierarchical way (with the help of Processor
Container objects) and support for ACPI idle states management on
ARM64, based on LPI (Sudeep Holla).
- General improvements of ACPI support for NUMA and ARM64 support for
ACPI-based NUMA (Hanjun Guo, David Daney, Robert Richter).
- General improvements of the ACPI table upgrade mechanism and ARM64
support for that feature (Aleksey Makarov, Jon Masters).
- Support for the Boot Error Record Table (BERT) in APEI and
improvements of kernel messages printed by the error injection code
(Huang Ying, Borislav Petkov).
- New driver for the Intel Broxton WhiskeyCove PMIC operation region
and support for the REGS operation region on Broxton, PMIC code
cleanups (Bin Gao, Felipe Balbi, Paul Gortmaker).
- New driver for the power participant device which is part of the
Dynamic Power and Thermal Framework (DPTF) and DPTF-related code
reorganization (Srinivas Pandruvada).
- Support for the platform-initiated graceful shutdown feature
introduced in ACPI 6.1 (Prashanth Prakash).
- ACPI button driver update related to lid input events generated
automatically on initialization and system resume that have been
problematic for some time (Lv Zheng).
- ACPI EC driver cleanups (Lv Zheng).
- Documentation of the ACPICA release automation process and the
in-kernel ACPI AML debugger (Lv Zheng).
- New blacklist entry and two fixes for the ACPI backlight driver
(Alex Hung, Arvind Yadav, Ralf Gerbig).
- Cleanups of the ACPI pci_slot driver (Joe Perches, Paul Gortmaker).
- ACPI CPPC code changes to make it more robust against possible
defects in ACPI tables and new symbol definitions for PCC (Hoan
Tran).
- System reboot code modification to execute the ACPI _PTS (Prepare
To Sleep) method in addition to _TTS (Ocean He).
- ACPICA-related change to carry out lock ordering checks in ACPICA
if ACPICA debug is enabled in the kernel (Lv Zheng).
- Assorted minor fixes and cleanups (Andy Shevchenko, Baoquan He,
Bhaktipriya Shridhar, Paul Gortmaker, Rafael Wysocki)"
* tag 'acpi-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (71 commits)
ACPI: enable ACPI_PROCESSOR_IDLE on ARM64
arm64: add support for ACPI Low Power Idle(LPI)
drivers: firmware: psci: initialise idle states using ACPI LPI
cpuidle: introduce CPU_PM_CPU_IDLE_ENTER macro for ARM{32, 64}
arm64: cpuidle: drop __init section marker to arm_cpuidle_init
ACPI / processor_idle: Add support for Low Power Idle(LPI) states
ACPI / processor_idle: introduce ACPI_PROCESSOR_CSTATE
ACPI / DPTF: move int340x_thermal.c to the DPTF folder
ACPI / DPTF: Add DPTF power participant driver
ACPI / lpat: make it explicitly non-modular
ACPI / dock: make dock explicitly non-modular
ACPI / PCI: make pci_slot explicitly non-modular
ACPI / PMIC: remove modular references from non-modular code
ACPICA: Linux: Enable ACPI_MUTEX_DEBUG for Linux kernel
ACPI: Rename configfs.c to acpi_configfs.c to prevent link error
ACPI / debugger: Add AML debugger documentation
ACPI: Add documentation describing ACPICA release automation
ACPI: add support for loading SSDTs via configfs
ACPI: add support for configfs
efi / ACPI: load SSTDs from EFI variables
...
Pull x86 platform updates from Ingo Molnar:
"The main changes in this cycle were:
- Intel-SoC enhancements (Andy Shevchenko)
- Intel CPU symbolic model definition rework (Dave Hansen)
- ... other misc changes"
* 'x86-platform-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (25 commits)
x86/sfi: Enable enumeration of SD devices
x86/pci: Use MRFLD abbreviation for Merrifield
x86/platform/intel-mid: Make vertical indentation consistent
x86/platform/intel-mid: Mark regulators explicitly defined
x86/platform/intel-mid: Rename mrfl.c to mrfld.c
x86/platform/intel-mid: Enable spidev on Intel Edison boards
x86/platform/intel-mid: Extend PWRMU to support Penwell
x86/pci, x86/platform/intel_mid_pci: Remove duplicate power off code
x86/platform/intel-mid: Add pinctrl for Intel Merrifield
x86/platform/intel-mid: Enable GPIO expanders on Edison
x86/platform/intel-mid: Add Power Management Unit driver
x86/platform/atom/punit: Enable support for Merrifield
x86/platform/intel_mid_pci: Rework IRQ0 workaround
x86, thermal: Clean up and fix CPU model detection for intel_soc_dts_thermal
x86, mmc: Use Intel family name macros for mmc driver
x86/intel_telemetry: Use Intel family name macros for telemetry driver
x86/acpi/lss: Use Intel family name macros for the acpi_lpss driver
x86/cpufreq: Use Intel family name macros for the intel_pstate cpufreq driver
x86/platform: Use new Intel model number macros
x86/intel_idle: Use Intel family macros for intel_idle
...
* acpi-drivers:
ACPI / DPTF: move int340x_thermal.c to the DPTF folder
ACPI / DPTF: Add DPTF power participant driver
* acpi-misc:
ACPI / lpat: make it explicitly non-modular
ACPI / dock: make dock explicitly non-modular
* acpi-tools:
tools/acpi: use CROSS_COMPILE to define prefix
* acpi-pmic:
ACPI / PMIC: remove modular references from non-modular code
ACPI / PMIC: intel: initialize result to 0
ACPI / PMIC: intel: add REGS operation region support
ACPI / PMIC: Add opregion driver for Intel BXT WhiskeyCove PMIC
ACPI / PMIC: modify the pen function signature to take bit field
Conflicts:
drivers/acpi/Makefile
* acpi-processor:
ACPI: enable ACPI_PROCESSOR_IDLE on ARM64
arm64: add support for ACPI Low Power Idle(LPI)
drivers: firmware: psci: initialise idle states using ACPI LPI
cpuidle: introduce CPU_PM_CPU_IDLE_ENTER macro for ARM{32, 64}
arm64: cpuidle: drop __init section marker to arm_cpuidle_init
ACPI / processor_idle: Add support for Low Power Idle(LPI) states
ACPI / processor_idle: introduce ACPI_PROCESSOR_CSTATE
* acpi-cppc:
mailbox: pcc: Add PCC request and free channel declarations
ACPI / CPPC: Prevent cpc_desc_ptr points to the invalid data
ACPI: CPPC: Return error if _CPC is invalid on a CPU
* acpi-apei:
ACPI / APEI: Add Boot Error Record Table (BERT) support
ACPI / einj: Make error paths more talkative
ACPI / einj: Convert EINJ_PFX to proper pr_fmt
* acpi-sleep:
ACPI: Execute _PTS before system reboot
* acpi-tables:
ACPI: Rename configfs.c to acpi_configfs.c to prevent link error
ACPI: add support for loading SSDTs via configfs
ACPI: add support for configfs
efi / ACPI: load SSTDs from EFI variables
spi / ACPI: add support for ACPI reconfigure notifications
i2c / ACPI: add support for ACPI reconfigure notifications
ACPI: add support for ACPI reconfiguration notifiers
ACPI / scan: fix enumeration (visited) flags for bus rescans
ACPI / documentation: add SSDT overlays documentation
ACPI: ARM64: support for ACPI_TABLE_UPGRADE
ACPI / tables: introduce ARCH_HAS_ACPI_TABLE_UPGRADE
ACPI / tables: move arch-specific symbol to asm/acpi.h
ACPI / tables: table upgrade: refactor function definitions
ACPI / tables: table upgrade: use cacheable map for tables
Conflicts:
arch/arm64/include/asm/acpi.h
When a latent (unknown to 'badblocks') error is encountered, it will
trigger a machine check exception. On a system with machine check
recovery, this will only SIGBUS the process(es) which had the bad page
mapped (as opposed to a kernel panic on platforms without machine
check recovery features). In the former case, we want to trigger a full
rescan of that nvdimm bus. This will allow any additional, new errors
to be captured in the block devices' badblocks lists, and offending
operations on them can be trapped early, avoiding machine checks.
This is done by registering a callback function with the
x86_mce_decoder_chain and calling the new ars_rescan functionality with
the address in the mce notificatiion.
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
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>
Normally, an ARS (Address Range Scrub) only happens at
boot/initialization time. There can however arise situations where a
bus-wide rescan is needed - notably, in the case of discovering a latent
media error, we should do a full rescan to figure out what other sectors
are bad, and thus potentially avoid triggering an mce on them in the
future. Also provide a sysfs trigger to start a bus-wide scrub.
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Pull libnvdimm fix from Dan Williams:
"This contains a regression fix for a problem that was introduced in
v4.7-rc6.
In 4.7-rc1 we introduced auto-probing for the ACPI DSM (device-
specific-method) format that the platform firmware implements for
nvdimm devices. We initially fixed a regression in probing the QEMU
DSM implementation by making acpi_check_dsm() tolerant of the way QEMU
reports the "0 DSMs supported" condition.
However, that broke HPE platforms since that tolerance caused the
driver to mistakenly match the 1-zero-byte response those platforms
give to "unknown" commands. Instead, we simply make the driver
tolerant of not finding any supported DSMs. This has been tested to
work with both QEMU and HPE platforms.
This commit has appeared in a -next release with no reported issues"
* 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
nfit: make DIMM DSMs optional
While testing the new on-demand ARS patches we discovered that
differences between the nfit_test and normal nfit driver shutdown paths
can leak resources. Unify the shutdown paths to trigger via a devm_
callback when the acpi_desc->dev is unbound from its driver.
Reviewed-by: Lee, Chun-Yi <jlee@suse.com>
Reported-by: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Let the provider module be explicitly passed in rather than implicitly
assumed by the module that calls nvdimm_bus_register(). This is in
preparation for unifying the nfit and nfit_test driver teardown paths.
Reviewed-by: Lee, Chun-Yi <jlee@suse.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
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>
ACPI 6.0 introduced an optional object _LPI that provides an alternate
method to describe Low Power Idle states. It defines the local power
states for each node in a hierarchical processor topology. The OSPM can
use _LPI object to select a local power state for each level of processor
hierarchy in the system. They used to produce a composite power state
request that is presented to the platform by the OSPM.
Since multiple processors affect the idle state for any non-leaf hierarchy
node, coordination of idle state requests between the processors is
required. ACPI supports two different coordination schemes: Platform
coordinated and OS initiated.
This patch adds initial support for Platform coordination scheme of LPI.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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>
Pass the nfit buffer as a parameter rather than hanging it off of
acpi_desc.
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
acpi_evaluate_object() allocates memory. Free the buffer allocated
during acpi_nfit_add(). In order for this memory to be freed
acpi_nfit_init() needs to be converted to duplicate the nfit contents in
its internal allocation. Use zero-length arrays to minimize the thrash
with the rest of the nfit driver implementation.
All of the add_<nfit-sub-table>() routines now validate a minimum table
size and expect hotplugged tables to match the size of the original
table to count as a duplicate. For variable length tables, like 'idt'
and 'flush', we calculate the dynamic size. Note that hotplug by
definition cannot change the interleave as it would cause data
corruption of in-use namespaces.
Cc: Vishal Verma <vishal.l.verma@intel.com>
Reported-by: Xiao Guangrong <guangrong.xiao@intel.com>
Reported-by: Haozhong Zhang <haozhong.zhang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
This patch adds logic to treat virtual ramdisk SPA as pmem region, then
ramdisk's /dev/pmem* device can be mounted with iso9660.
It's useful to work with the httpboot in EFI firmware to pull a remote
ISO file to the local memory region for booting and installation.
Wiki page of UEFI HTTPBoot with OVMF:
https://en.opensuse.org/UEFI_HTTPBoot_with_OVMF
The ramdisk function in EDK2/OVMF generates a ACPI0012 root device that
it contains empty _STA but without _DSM:
DefinitionBlock ("ssdt2.aml", "SSDT", 2, "INTEL ", "RamDisk ", 0x00001000)
{
Scope (\_SB)
{
Device (NVDR)
{
Name (_HID, "ACPI0012") // _HID: Hardware ID
Name (_STR, Unicode ("NVDIMM Root Device")) // _STR: Description String
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
}
}
}
In section 5.2.25.2 of ACPI 6.1 spec, it mentions that the "SPA Range
Structure Index" of virtual SPA shall be set to zero. That means virtual SPA
will not be associated by any NVDIMM region mapping.
The VCD's SPA Range Structure in NFIT is similar to virtual disk region
as following:
[028h 0040 2] Subtable Type : 0000 [System Physical Address Range]
[02Ah 0042 2] Length : 0038
[02Ch 0044 2] Range Index : 0000
[02Eh 0046 2] Flags (decoded below) : 0000
Add/Online Operation Only : 0
Proximity Domain Valid : 0
[030h 0048 4] Reserved : 00000000
[034h 0052 4] Proximity Domain : 00000000
[038h 0056 16] Address Range GUID : 77AB535A-45FC-624B-5560-F7B281D1F96E
[048h 0072 8] Address Range Base : 00000000B6ABD018
[050h 0080 8] Address Range Length : 0000000005500000
[058h 0088 8] Memory Map Attribute : 0000000000000000
The way to not associate a SPA range is to never reference it from a "flush hint",
"interleave", or "control region" table.
After testing on OVMF, pmem driver can support the region that it doesn't
assoicate to any NVDIMM mapping. So, treat VCD like pmem is a idea to get
a pmem block device that it contains iso.
v4:
Instoduce nfit_spa_is_virtual() to check virtual ramdisk SPA and create
pmem region.
v3:
To simplify patch, removed useless VCD region in libnvdimm.
v2:
Removed the code for setting VCD to a read-only region.
Cc: Gary Lin <GLin@suse.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Linda Knippers <linda.knippers@hpe.com>
Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Since DPTF has its own folder under ACPI, move this file also there.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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>
Commit 4995734e97 "acpi, nfit: fix acpi_check_dsm() vs zero functions
implemented" attempted to fix a QEMU regression by supporting its usage
of a zero-mask as a valid response to a DSM-family probe request.
However, this behavior breaks HP platforms that return a zero-mask by
default causing the probe to misidentify the DSM-family.
Instead, the QEMU regression can be fixed by simply not requiring the DSM
family to be identified.
This effectively reverts commit 4995734e97, and removes the DSM
requirement from the init path.
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Cc: Linda Knippers <linda.knippers@hpe.com>
Fixes: 4995734e97 ("acpi, nfit: fix acpi_check_dsm() vs zero functions implemented")
Reported-by: Jerry Hoemann <jerry.hoemann@hpe.com>
Tested-by: Jerry Hoemann <jerry.hoemann@hpe.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The Makefile for building this is "acpi-y" and so it is not built
as a module. Hence including module.h and everything that comes
with it just for the no-op MODULE_LICENSE is rather heavy handed.
The license info is found at the top of the file, so we just remove
the MODULE_LICENSE and the include of module.h
We add an include of export.h since the file exports some symbols.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The Kconfig for this file is:
drivers/acpi/Kconfig:config ACPI_DOCK
drivers/acpi/Kconfig: bool "Dock"
...and so it is not built as a module. Hence including module.h
and everything that comes with it just for the no-op MODULE_LICENSE
and friends is rather heavy handed.
The license/author info is found at the top of the file, so we
just remove the MODULE_LICENSE etc and the include of module.h
The file does still have some module_param() so we add the right
include for that infrastructure.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The Kconfig for this file is:
drivers/acpi/Kconfig:config ACPI_PCI_SLOT
drivers/acpi/Kconfig: bool "PCI slot detection driver"
...and so it is not built as a module. Hence including module.h
and everything that comes with it just for the no-op MODULE_LICENSE
and friends is rather heavy handed.
The license/author info is found at the top of the file, so we
just remove the MODULE_LICENSE etc and the include of module.h
We delete the DRIVER_VERSION macro as well since it is unused.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The Kconfig currently controlling compilation of these files are:
drivers/acpi/Kconfig:menuconfig PMIC_OPREGION
drivers/acpi/Kconfig: bool "PMIC (Power Management Integrated Circuit) operation region support"
drivers/acpi/Kconfig:config BXT_WC_PMIC_OPREGION
drivers/acpi/Kconfig: bool "ACPI operation region support for BXT WhiskeyCove PMIC"
drivers/acpi/Kconfig:config XPOWER_PMIC_OPREGION
drivers/acpi/Kconfig: bool "ACPI operation region support for XPower AXP288 PMIC"
...meaning they currently are not being built as a module by anyone.
Lets remove the couple traces of modular infrastructure use, so that
when reading the code there is no doubt it is builtin-only.
We delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
One file was using module_init. Since module_init translates to
device_initcall in the non-modular case, the init ordering remains
unchanged with this commit.
In one case we replace the module.h with export.h since that file
is exporting some symbols, but does not use __init. The other two
are using __init and so module.h gets replaced with init.h there.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
As part of the hotplug cleanup, the CPU_STARTING/DYING actions are going
away soon. This driver needlessly uses those two macro, and so this patch
replaces that code with something more sensible.
Commit:
8da8373447 ("ACPI / processor: Fix STARTING/DYING action in acpi_cpu_soft_notify()")
added checks for those two actions, because the notification callback can
sleep, causing a hung CPU. This patch instead checks for the ONLINE/DEAD
actions, which are the ones that are handled by the driver in the first
place.
Signed-off-by: Richard Cochran <rcochran@linutronix.de>
Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Len Brown <lenb@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-acpi@vger.kernel.org
Cc: rt@linutronix.de
Link: http://lkml.kernel.org/r/20160713153335.964962885@linutronix.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The __pmem address space was meant to annotate codepaths that touch
persistent memory and need to coordinate a call to wmb_pmem(). Now that
wmb_pmem() is gone, there is little need to keep this annotation.
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
nvdimm_flush() is a replacement for the x86 'pcommit' instruction. It is
an optional write flushing mechanism that an nvdimm bus can provide for
the pmem driver to consume. In the case of the NFIT nvdimm-bus-provider
nvdimm_flush() is implemented as a series of flush-hint-address [1]
writes to each dimm in the interleave set (region) that backs the
namespace.
The nvdimm_has_flush() routine relies on platform firmware to describe
the flushing capabilities of a platform. It uses the heuristic of
whether an nvdimm bus provider provides flush address data to return a
ternary result:
1: flush addresses defined
0: dimm topology described without flush addresses (assume ADR)
-errno: no topology information, unable to determine flush mechanism
The pmem driver is expected to take the following actions on this ternary
result:
1: nvdimm_flush() in response to REQ_FUA / REQ_FLUSH and shutdown
0: do not set, WC or FUA on the queue, take no further action
-errno: warn and then operate as if nvdimm_has_flush() returned '0'
The caveat of this heuristic is that it can not distinguish the "dimm
does not have flush address" case from the "platform firmware is broken
and failed to describe a flush address". Given we are already
explicitly trusting the NFIT there's not much more we can do beyond
blacklisting broken firmwares if they are ever encountered.
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
In preparation for triggering flushes of a DIMM's writes-posted-queue
(WPQ) via the pmem driver move mapping of flush hint addresses to the
region driver. Since this uses devm_nvdimm_memremap() the flush
addresses will remain mapped while any region to which the dimm belongs
is active.
We need to communicate more information to the nvdimm core to facilitate
this mapping, namely each dimm object now carries an array of flush hint
address resources.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Now that all shared mappings are handled by devm_nvdimm_memremap() we no
longer need nfit_spa_map() nor do we need to trigger a callback to the
bus provider at region disable time.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Revert commit 2f38b1b16d (ACPICA: Namespace: Fix deadlock triggered by
MLC support in dynamic table loading) that attempted to fix a deadlock
issue introduced by a previous commit, but it led to a lock ordering
inconsistency that caused further problems to appear.
Fixes: 2f38b1b16d (ACPICA: Namespace: Fix deadlock triggered by MLC support in dynamic table loading)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
If we compile ACPI configfs.c as module it will confuse the linker as it
hides symbols from the actual configfs:
Kernel: arch/x86/boot/bzImage is ready (#1236)
MODPOST 5739 modules
ERROR: "configfs_unregister_subsystem" [samples/configfs/configfs_sample.ko] undefined!
ERROR: "configfs_register_subsystem" [samples/configfs/configfs_sample.ko] undefined!
ERROR: "config_group_init" [samples/configfs/configfs_sample.ko] undefined!
ERROR: "config_item_init_type_name" [samples/configfs/configfs_sample.ko] undefined!
ERROR: "config_group_init_type_name" [samples/configfs/configfs_sample.ko] undefined!
ERROR: "configfs_undepend_item" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] undefined!
...
Prevent these by renaming the file to acpi_configfs.c instead.
Reported-by: Scott Lawson <scott.lawson@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
New tables can be loaded by creating directories under /config/table/
and writing the AML code into the aml table attribute. Various table
attributes will be readable once the table is successfully loaded.
Unloading tables is not supported at the moment, but it can be easily
implemented once ACPI loading functions provide a table handle to be
used for unloading.
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>
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>
Add support for ACPI reconfiguration notifiers to allow subsystems
to react to changes in the ACPI tables that happen after the initial
enumeration. This is similar with the way dynamic device tree
notifications work.
The reconfigure notifications supported for now are device add and
device remove.
Since ACPICA allows only one table notification handler, this patch
makes the table notifier function generic and moves it out of the
sysfs specific code.
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>
If the ACPI tables change as a result of a dinamically loaded table
and a bus rescan is required the enumeration/visited flag are not
consistent.
I2C/SPI are not directly enumerated in acpi_bus_attach(), however
the visited flag is set. This makes it impossible to check if an
ACPI device has already been enumerated by the I2C and SPI
subsystems. To fix this issue we only set the visited flags if
the device is not I2C or SPI.
With this change we also need to remove setting visited to false
from acpi_bus_attach(), otherwise if we rescan already enumerated
I2C/SPI devices we try to re-enumerate them.
Note that I2C/SPI devices can be enumerated either via a scan handler
(when using PRP0001) or via regular device_attach(). In either case
the flow goes through acpi_default_enumeration() which makes it the
ideal place to mark the ACPI device as enumerated.
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>
There is an order issue in ec_remove_handlers() that acpi_ec_stop()
is called before removing the operation region handler. That is
incorrect, because the operation region handler removal triggers
_REG(DISCONNECT) which may result in new EC transactions to carry
out.
That existing issue has been triggered by the following commit:
Commit: dcf15cbded
Subject: ACPI / EC: Fix a boot EC regresion by restoring boot EC
which changed the driver to call ec_remove_handlers() after invoking
_REG(CONNECT), so the issue has become visible.
Fixes: dcf15cbded (ACPI / EC: Fix a boot EC regresion by restoring boot EC)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=102421
Reported-and-tested-by: Wolfram Sang <wsa@the-dreams.de>
Reported-by: Nicholas <nkudriavtsev@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In preparation for generically mapping flush hint addresses for both the
BLK and PMEM use case, provide a generic / reference counted mapping
api. Given the fact that a dimm may belong to multiple regions (PMEM
and BLK), the flush hint addresses need to be held valid as long as any
region associated with the dimm is active. This is similar to the
existing BLK-region case where multiple BLK-regions may share an
aperture mapping. Up-level this shared / reference-counted mapping
capability from the nfit driver to a core nvdimm capability.
This eliminates the need for the nd_blk_region.disable() callback. Note
that the removal of nfit_spa_map() and related infrastructure is
deferred to a later patch.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Before enabling use of flush hints for pmem regions, we need to make
sure they are always associated. Move the initialization of nfit_flush
out of the block-window specific init path to the general init path.
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
If devm_add_action() fails, we are explicitly calling the cleanup to free
the resources allocated. Lets use the helper devm_add_action_or_reset()
and return directly in case of error, since the cleanup function
has been already called by the helper if there was any error.
Signed-off-by: Vikas C Sajjan <vikas.cha.sajjan@hpe.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Lee, Chun-Yi <jlee@suse.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
This patch adds support for platform initited graceful shutdown as
described in sections 5.6.6(Table-143) and 6.3.5.1 of ACPI 6.1 spec
The OSPM will get a graceful shutdown request via a Notify operator
on \_SB device with a value of 0x81 per section 5.6.6. Following the
shutdown request from platform the OSPM needs to follow the
processing sequence as described in section 6.2.5.1.
v3
* Switched to regular work with delays from delayed work
* Dropped changes to actypes.h
* Small style changes
v2
* Switched from standalone driver to a simple notify handler
v1
* Initial
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.
CC: "Rafael J. Wysocki" <rjw@rjwysocki.net> (supporter:ACPI)
CC: Len Brown <lenb@kernel.org> (supporter:ACPI)
CC: linux-acpi@vger.kernel.org (open list:ACPI)
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In acpi_subsystem_init(), function acpi_enable_subsystem() is
called to do the real job. However with different flags passed to
acpi_enable_subsystem(), different code is executed.
In acpi_subsystem_init(), with "~ACPI_NO_ACPI_ENABLE" passed in, it
will only switch over the platform to the ACPI mode. The remaining
part of acpi_enable_subsystem() is done when acpi_bus_init() is
called.
So the comments above acpi_subsystem_init() is not exact, change it
here.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The FIFO unlocking mechanism in acpi_dbg has been broken by the
following commit:
Commit: 287980e49f
Subject: remove lots of IS_ERR_VALUE abuses
It converted !IS_ERR_VALUE(ret) into !ret which was not entirely
correct. Fix the regression by taking ret > 0 into account too as
appropriate.
Fixes: 287980e49f (remove lots of IS_ERR_VALUE abuses)
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
[ rjw: Simplifications, changelog & subject massage ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There is a lock order issue in acpi_load_tables(). The namespace lock
is held before holding the interpreter lock.
With ACPI_MUTEX_DEBUG enabled in the kernel, this is printed to the
log during boot:
[ 0.885699] ACPI Error: Invalid acquire order: Thread 405884224 owns [ACPI_MTX_Namespace], wants [ACPI_MTX_Interpreter] (20160422/utmutex-263)
[ 0.885881] ACPI Error: Could not acquire AML Interpreter mutex (20160422/exutils-95)
[ 0.893846] ACPI Error: Mutex [0x0] is not acquired, cannot release (20160422/utmutex-326)
[ 0.894019] ACPI Error: Could not release AML Interpreter mutex (20160422/exutils-133)
The issue has been introduced by the following commit:
Commit: 2f38b1b16d
ACPICA Commit: bfe03ffcde8ed56a7eae38ea0b188aeb12f9c52e
Subject: ACPICA: Namespace: Fix a regression that MLC support triggers
dead lock in dynamic table loading
Which fixed a deadlock issue for acpi_ns_load_table() in
acpi_ex_add_table() but didn't take care of the lock order in
acpi_ns_load_table() correctly.
Originally (before the above commit), ACPICA used the
namespace/interpreter locks in the following 2 key code
paths:
1. Table loading:
acpi_ns_load_table
L(Namespace)
acpi_ns_parse_table
acpi_ns_one_complete_parse
U(Namespace)
2. Object evaluation:
acpi_ns_evaluate
L(Interpreter)
acpi_ps_execute_method
U(Interpreter)
acpi_ns_load_table
L(Namespace)
U(Namespace)
acpi_ev_initialize_region
L(Namespace)
U(Namespace)
address_space.setup
L(Namespace)
U(Namespace)
address_space.handler
L(Namespace)
U(Namespace)
acpi_os_wait_semaphore
acpi_os_acquire_mutex
acpi_os_sleep
L(Interpreter)
U(Interpreter)
During runtime, while acpi_ns_evaluate is called, the lock order is
always Interpreter -> Namespace.
In turn, the problematic commit acquires the locks in the following
order:
3. Table loading:
acpi_ns_load_table
L(Namespace)
acpi_ns_parse_table
L(Interpreter)
acpi_ns_one_complete_parse
U(Interpreter)
U(Namespace)
To fix the lock order issue, move the interpreter lock to
acpi_ns_load_table() to ensure the lock order correctness:
4. Table loading:
acpi_ns_load_table
L(Interpreter)
L(Namespace)
acpi_ns_parse_table
acpi_ns_one_complete_parse
U(Namespace)
U(Interpreter)
However, this doesn't fix the current design issues related to the
namespace lock. For example, we can notice that in acpi_ns_evaluate(),
outside of acpi_ns_load_table(), the namespace objects may be created
by the named object creation control methods. And the creation of
the method-owned namespace objects are not locked by the namespace
lock. This patch doesn't try to fix such kind of existing issues.
Fixes: 2f38b1b16d (ACPICA: Namespace: Fix a regression that MLC support triggers dead lock in dynamic table loading)
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Our Windows probe result shows that EC._REG is evaluated after evaluating
all _INI/_STA control methods.
With boot EC always switched in acpi_ec_dsdt_probe(), we can see that as
long as there is no EC opregion accesses in the MLC (module level code, AML
code out of any control methods) and in _INI/_STA, there is no need to make
sure that ECDT must be correct.
Bugs of 9399/12461 were reported against an order issue that BAT0/1._STA
evaluations contain EC accesses while the ECDT setting is wrong.
>From the acpidump output posted on bug 9399, we can see that it is actually
a different issue. In this table, if EC._REG is not executed, EC accesses
will be done in a platform specific manner. As we've already ensured not to
execute EC._REG during the eary stage, we can remove the quirks for bug
9399.
From the acpidump output posted on bug 12461, we can see that it still
needs the quirk. In this table, EC._REG flags a named object whose default
value is One, thus BAT1._STA surely should invoke EC accesses whatever we
invoke EC._REG or not. We have to keep the quirk for it before we can root
cause the issue.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Failure handling of the boot EC code is not tidy. This patch cleans
them up with acpi_ec_alloc().
This patch also changes acpi_ec_dsdt_probe(), always switches the
boot EC from the ECDT one to the DSDT one in this function.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Since commit 103544d869 (ACPI,PCI,IRQ: reduce resource requirements)
the penalty values are calculated on the fly rather than at boot time.
This works fine for PCI interrupts but not so well for ISA interrupts.
The information on whether or not an ISA interrupt is in use is not
available to the pci_link.c code directly. That information is
obtained from the outside via acpi_penalize_isa_irq(). [If its
"active" argument is true, then the IRQ is in use by ISA.]
Since the current code relies on PCI Link objects for determination
of penalties, we are factoring in the PCI penalty twice after
acpi_penalize_isa_irq() function is called.
To avoid that, limit the newly added functionality to just PCI
interrupts so that old behavior is still maintained.
Fixes: 103544d869 (ACPI,PCI,IRQ: reduce resource requirements)
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Tested-by: Wim Osterholt <wim@djo.tudelft.nl>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Trying to make the ISA and PCI init functionality common turned out
to be a bad idea, because the ISA path depends on external
functionality.
Restore the previous behavior and limit the refactoring to PCI
interrupts only.
Fixes: 1fcb6a813c "ACPI,PCI,IRQ: remove redundant code in acpi_irq_penalty_init()"
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Tested-by: Wim Osterholt <wim@djo.tudelft.nl>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The change introduced in commit 103544d869 (ACPI,PCI,IRQ: reduce
resource requirements) omitted the initially applied PCI_POSSIBLE
penalty when the IRQ is active.
Incorrect calculation of the penalty leads the ACPI code to assigning
a wrong interrupt number to a PCI INTx interrupt.
This would not be as bad as it sounds in theory. It would just cause
the interrupts to be shared and result in performance penalty.
However, some drivers (like the parallel port driver) don't like
interrupt sharing and in the above case they will causes all of
the PCI drivers wanting to share the interrupt to be unable to
request it.
The issue has not been caught in testing because the behavior is
platform-specific and depends on the peripherals ending up sharing
the IRQ and their drivers.
Before the above commit the code would add the PCI_POSSIBLE value
divided by the number of possible IRQ users to the IRQ penalty
during initialization.
Later in that code path, if the IRQ is chosen as the active IRQ or
if it is used by ISA; additional penalties are added.
Fixes: 103544d869 (ACPI,PCI,IRQ: reduce resource requirements)
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Tested-by: Wim Osterholt <wim@djo.tudelft.nl>
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Fix an expression in the ACPI PCI IRQ management code added by a
recent commit that overlooked missing parens in it, so the result
of the computation is incorrect in some cases (Sinan Kaya).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJXdtScAAoJEILEb/54YlRx5r4P/AwWjfh3wPsDCXCajSkiqR7b
raPnXYXvVhEC4ZfqLpuID1sk/DzQL/MZmkFpB8PUYkf1onOKXcd9MDsyiVdOuJi/
gqP64yzGI+n79qq4u+vhUlujsDH11X8WtKxNQoZWWdHoLR5o/qhYA4c3kZ0yjzim
uD/3GWtXsmbPMyBMJjOIFJLFpj3DgizxER3PUL0WdX1XB8YXX/e16WT4+8IkHVru
mM8Mk389+iQoKfDgWAL9ImOcfY9xXh0IPkKF/kHT2D0CG4qHfjGWUfu124hu83Fp
YGIhcmX0De5cwb3PchQ4Uga2U4KbzKgAhW574RFD+pCmY5EX/fjYDaPPCU4Gctzf
RNTG3JIS+mpR2maC+t73lJUanQSxS4GahXtEGfJ7ci3q85sIXuX5GSqd9CkXScCZ
/0Ww+xjiXyeo1EE/PFC0rXZT7h5bzCdpqWbUUhcSDnFKj8TLz/LjiNd6vCFZAVUF
G/7p9rY2n+Nid8j7DVITKcYS6HuaucKOTGKbPp7P3HBXc5N3d5vqrSrVcwQ/Yi+g
hwaoDle506BUvTgIwrjCEPBRFRmFz8uRHOMMbpugzYZm2Kn5UUF3Za358NqI6pYR
LiosgEiCXYFQScDeFOV5QD9hRGRoWaL6C54po1d459MGjqgwDt4lolbOhy7BIWXj
pJMmdHbczB0VT6KRyYxs
=r8BR
-----END PGP SIGNATURE-----
Merge tag 'acpi-4.7-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fix from Rafael Wysocki:
"Fix an expression in the ACPI PCI IRQ management code added by a
recent commit that overlooked missing parens in it, so the result of
the computation is incorrect in some cases (Sinan Kaya)"
* tag 'acpi-4.7-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI,PCI,IRQ: correct operator precedence
Pull libnvdimm fixes from Dan Williams:
"1/ Two regression fixes since v4.6: one for the byte order of a sysfs
attribute (bz121161) and another for QEMU 2.6's NVDIMM _DSM (ACPI
Device Specific Method) implementation that gets tripped up by new
auto-probing behavior in the NFIT driver.
2/ A fix tagged for -stable that stops the kernel from
clobbering/ignoring changes to the configuration of a 'pfn'
instance ("struct page" driver). For example changing the
alignment from 2M to 1G may silently revert to 2M if that value is
currently stored on media.
3/ A fix from Eric for an xfstests failure in dax. It is not
currently tagged for -stable since it requires an 8-exabyte file
system to trigger, and there appear to be no user visible side
effects"
* 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
nfit: fix format interface code byte order
dax: fix offset overflow in dax_io
acpi, nfit: fix acpi_check_dsm() vs zero functions implemented
libnvdimm, pfn, dax: fix initialization vs autodetect for mode + alignment
The omitted parenthesis prevents the addition operation when
acpi_penalize_isa_irq function is called.
Fixes: 103544d869 (ACPI,PCI,IRQ: reduce resource requirements)
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The _PTS control method is defined in the section 7.4.1 of acpi 6.0
spec. The _PTS control method is executed by the OS during the sleep
transition process for S1, S2, S3, S4, and for orderly S5 shutdown.
The _PTS control method provides the BIOS a mechanism for performing
some housekeeping, such as writing the sleep type value to the embedded
controller, before entering the system sleeping state. Note that some
Lenovo Server BIOS use this mechanism to detect reboot event and
prompt user by popped dialog box.
According to section 7.5 of acpi 6.0 spec, _PTS should run after _TTS.
Add a _PTS evaulation to the existing _TTS reboot notifier and change
the notifier name to reflect the fact that it's not for _TTS only any
more.
Signed-off-by: Ocean He <hehy1@lenovo.com>
Signed-off-by: Nagananda Chumbalkar <nchumbalkar@lenovo.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI/APEI is designed to verifiy/report H/W errors, like Corrected
Error(CE) and Uncorrected Error(UC). It contains four tables: HEST,
ERST, EINJ and BERT. The first three tables have been merged for
a long time, but because of lacking BIOS support for BERT, the
support for BERT is pending until now. Recently on ARM 64 platform
it is has been supported. So here we come.
Under normal circumstances, when a hardware error occurs, kernel will
be notified via NMI, MCE or some other method, then kernel will
process the error condition, report it, and recover it if possible.
But sometime, the situation is so bad, so that firmware may choose to
reset directly without notifying Linux kernel.
Linux kernel can use the Boot Error Record Table (BERT) to get the
un-notified hardware errors that occurred in a previous boot. In this
patch, the error information is reported via printk.
For more information about BERT, please refer to ACPI Specification
version 6.0, section 18.3.1:
http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf
The following log is a BERT record after system reboot because of hitting
a fatal memory error:
BERT: Error records from previous boot:
[Hardware Error]: It has been corrected by h/w and requires no further action
[Hardware Error]: event severity: corrected
[Hardware Error]: Error 0, type: recoverable
[Hardware Error]: section_type: memory error
[Hardware Error]: error_status: 0x0000000000000400
[Hardware Error]: physical_address: 0xffffffffffffffff
[Hardware Error]: card: 1 module: 2 bank: 3 row: 1 column: 2 bit_position: 5
[Hardware Error]: error_type: 2, single-bit ECC
[Tomasz Nowicki: Clear error status at the end of error handling]
[Tony: Applied some cleanups suggested by Fu Wei]
[Fu Wei: delete EXPORT_SYMBOL_GPL(bert_disable), improve the code]
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Signed-off-by: Chen, Gong <gong.chen@linux.intel.com>
Tested-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
Signed-off-by: Fu Wei <fu.wei@linaro.org>
Tested-by: Tyler Baicar <tbaicar@codeaurora.org>
Reviewed-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Per JEDEC Annex L Release 3 the SPD data is:
Bits 9~5 00 000 = Function Undefined
00 001 = Byte addressable energy backed
00 010 = Block addressed
00 011 = Byte addressable, no energy backed
All other codes reserved
Bits 4~0 0 0000 = Proprietary interface
0 0001 = Standard interface 1
All other codes reserved; see Definitions of Functions
...and per the ACPI 6.1 spec:
byte0: Bits 4~0 (0 or 1)
byte1: Bits 9~5 (1, 2, or 3)
...so a format interface code displayed as 0x301 should be stored in the
nfit as (0x1, 0x3), little-endian.
Cc: Toshi Kani <toshi.kani@hpe.com>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Robert Elliott <elliott@hpe.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=121161
Fixes: 30ec5fd464 ("nfit: fix format interface code byte order per ACPI6.1")
Fixes: 5ad9a7fde0 ("acpi/nfit: Update nfit driver to comply with ACPI 6.1")
Reported-by: Kristin Jacque <kristin.jacque@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Fixes compiler warning.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
At least some of the Broxtons have a third custom OpRegion
named REGS. This adds handling for it.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When CPPC fails to request a PCC channel, the CPC data is freed
and cpc_desc_ptr points to the invalid data.
Avoid this issue by moving the cpc_desc_ptr assignment after the PCC
channel request.
Signed-off-by: Hoan Tran <hotran@apm.com>
Acked-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
QEMU 2.6 implements nascent support for nvdimm DSMs. Depending on
configuration it may only implement the function0 dsm to indicate that
no other DSMs are available. Commit 31eca76ba2 "nfit, libnvdimm:
limited/whitelisted dimm command marshaling mechanism" breaks QEMU, but
QEMU is spec compliant. Per the spec the way to indicate that no
functions are supported is:
If Function Index is zero, the return is a buffer containing one bit
for each function index, starting with zero. Bit 0 indicates whether
there is support for any functions other than function 0 for the
specified UUID and Revision ID. If set to zero, no functions are
supported (other than function zero) for the specified UUID and
Revision ID.
Update the nfit driver to determine the family (interface UUID) without
requiring the implementation to define any other functions, i.e.
short-circuit acpi_check_dsm() to succeed per the spec. The nfit driver
appears to be the only user passing funcs==0 to acpi_check_dsm(), so
this behavior change of the common routine should be limited to the
probing done by the nfit driver.
Cc: Len Brown <lenb@kernel.org>
Cc: Jerry Hoemann <jerry.hoemann@hpe.com>
Acked-by: "Rafael J. Wysocki" <rafael@kernel.org>
Fixes: 31eca76ba2 ("nfit, libnvdimm: limited/whitelisted dimm command marshaling mechanism")
Reported-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Tested-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
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>
Issue description: On some pmics, the policy enable for thermal alerts
refers to different bit fields of the same registers, whereas on other
pmics, the policy enable refers to the same bit field on different
registers. Previous implementation did not provide the flexibility for
supporting the first approach.
Solution: Modified the policy enable function to take bit field as well.
The use of bit field is left to the pmic specific opregion driver.
Signed-off-by: Yegnesh Iyer <yegnesh.s.iyer@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>
It is absolutely unfriendly when one sees this:
# modprobe einj
modprobe: ERROR: could not insert 'einj': No such device
without anything in dmesg to tell one why the load failed.
Beef up the error handling of the init function to be more user-friendly
when the load fails.
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Based on 8.4.7.1 section of ACPI 6.1 specification, if the platform
supports CPPC, the _CPC object must exist under all processor objects.
If cpc_desc_ptr pointer is invalid on any CPUs, acpi_get_psd_map()
should return error and CPPC cpufreq driver can not be registered.
Signed-off-by: Hoan Tran <hotran@apm.com>
Reviewed-by: Prashanth Prakash <pprakash@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
acpi_print_osc_error() basically duplicates the functionalit of
acpi_handle_debug(), so use that one in there.
While at it, convert the explicit KERN_DEBUG prints to pr_debug()
(and apply it to continuation messages too).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
alloc_workqueue replaces deprecated create_workqueue().
A dedicated workqueue has been used since the workqueue
acpi_thermal_pm_queue with workitem &tz->thermal_check_work
(maps to acpi_thermal_check_fn), is involved in thermal zone polling.
Wallclock time is actually important and getting delayed in handling
critical temperature event can actually lead to unnecessary hardware
damage. So while this is not used during memory reclaim, we still want
forward progress guarantee and be generally snappy in servicing it.
Hence, WQ_MEM_RECLAIM and WQ_HIGHPRI have been used here.
Since there are only a fixed number of work items, explicit concurrency
limit is unnecessary here.
Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Linux userspace (systemd-logind) keeps on rechecking lid state when the
lid state is closed. If it failed to update the lid state to open after
boot/resume, the system suspending right after the boot/resume could be
resulted.
Graphics drivers also use the lid notifications to implment
MODESET_ON_LID_OPEN option.
Before the situation is improved from the userspace and from the graphics
driver, users can simply configure ACPI button driver to send initial
"open" lid state using button.lid_init_state=open to avoid such kind of
issues.
And our ultimate target should be making button.lid_init_state=ignore
the default behavior. This patch implements the 2 options and keep the
old behavior (button.lid_init_state=method).
Link: https://lkml.org/2016/3/7/460
Link: https://github.com/systemd/systemd/issues/2087
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(Correct a wrong macro usage.)
This patch simplies the code by merging some redundant code.
No functional changes.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The _LID control method's initial returning value is not reliable.
The _LID control method is described to return the "current" lid state.
However the word of "current" has ambiguity, many BIOSen return the lid
state upon the last lid notification instead of returning the lid state
upon the last _LID evaluation. There won't be difference when the _LID
control method is evaluated during the runtime, the problem is its initial
returning value. When the BIOSen implement this control method with cached
value, the initial returning value is likely not reliable. There are simply
so many examples retuning "close" as initial lid state (Link 1), sending
this state to the userspace causes suspending right after booting/resuming.
Since the lid state is implemented by the BIOSen, the kernel lid driver has
no idea how it can be correct, this patch stops sending the initial lid
state to the userspace to try to avoid sending the wrong lid state to the
userspace to trigger such kind of wrong suspending. This actually reverts
the following commit introduced for fixing a Novell bug:
Commit: 23de5d9ef2
Subject: ACPI: button: send initial lid state after add and resume
Link: https://bugzilla.kernel.org/show_bug.cgi?id=89211
Link: https://bugzilla.kernel.org/show_bug.cgi?id=106151
Link: https://bugzilla.kernel.org/show_bug.cgi?id=106941
Link: https://bugzilla.novell.com/show_bug.cgi?id=326814
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Remove the dbg macro and debug module parameter and use
the generic kernel facility.
Trivially reduces defconfig object size on x86-64
$ size drivers/acpi/pci_slot.o*
text data bss dec hex filename
880 752 4 1636 664 drivers/acpi/pci_slot.o.new
935 752 5 1692 69c drivers/acpi/pci_slot.o.old
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Use generic pr_<level> functions with pr_fmt for info and err.
This also reduces object size a trivial bit:
$ size drivers/acpi/pci_slot.o*
text data bss dec hex filename
935 752 5 1692 69c drivers/acpi/pci_slot.o.new
1027 752 5 1784 6f8 drivers/acpi/pci_slot.o.old
Miscellanea:
o Remove unnecessary OOM message as k.alloc functions get a generic
stack dump on OOM
o Remove unnecessary embedded prefix from a dbg() message
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Some system supports hybrid graphics and its discrete VGA
does not have any connectors and therefore has no _DOD method.
Signed-off-by: Alex Hung <alex.hung@canonical.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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>
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>
The constant that defines max phys address where the new upgraded
ACPI table should be allocated is arch-specific. Move it to
<asm/acpi.h>
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Refer initrd_start, initrd_end directly from drivers/acpi/tables.c.
This allows to use the table upgrade feature in architectures
other than x86. Also this simplifies header files.
The patch renames acpi_table_initrd_init() to acpi_table_upgrade()
(what reflects the purpose of the function) and removes the unneeded
wraps early_acpi_table_init() and early_initrd_acpi_init().
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
Acked-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The new memory allocated in acpi_table_initrd_init() is used to
copy the upgraded tables to it. So it should be mapped with
early_memunmap() instead of early_ioremap().
This is critical for ARM.
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
Acked-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The new module-level code (MLC) approach invokes MLC on the per-table
basis, but the dynamic loading support of this is incorrect because
of the lock order:
acpi_ns_evaluate
acpi_ex_enter_intperter
acpi_ns_load_table (triggered by Load opcode)
acpi_ns_exec_module_code_list
acpi_ex_enter_intperter
The regression is introduced by the following commit:
Commit: 2785ce8d0d
ACPICA Commit: 071eff738c59eda1792ac24b3b688b61691d7e7c
Subject: ACPICA: Add per-table execution of module-level code
This patch fixes this regression by unlocking the interpreter lock
before invoking MLC. However, the unlocking is done to the
acpi_ns_load_table(), in which the interpreter lock should be locked
by acpi_ns_parse_table() but it wasn't.
Fixes: 2785ce8d0d (ACPICA: Add per-table execution of module-level code)
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: 4.5+ <stable@vger.kernel.org> # 4.5+
[ rjw : Subject ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add the Microsoft _DSM command set to the white list of NVDIMM command
sets.
This command set is documented at:
https://msdn.microsoft.com/library/windows/hardware/mt604741
Cc: Pavel Machek <pavel@ucw.cz>
[pavel: fix up braces]
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Revert commit 66b1ed5aa8 "ACPICA: ACPI 2.0, Hardware: Add
access_width/bit_offset support for acpi_hw_write()" that is reported
to break suspend-to-RAM (ACPI S3) on one system.
The root cause of the failure is a wrong access width value for one of
the involved registers provided by the ACPI tables, but before commit
66b1ed5aa8 that value was not taken into account at all and things
worked.
Fixes: 66b1ed5aa8 "ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support for acpi_hw_write()"
Reported-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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>
Gu Zheng