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 e647b532275b ("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: e647b532275b (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 3b95bd160547
("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 209851649dc4 "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: 209851649dc4 ("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>
