* acpi-pm:
ACPI / PM: Add missing pm_generic_complete() invocation
ACPI / PM: Turn power resources on and off in the right order during resume
ACPI / PM: Rework device power management to follow ACPI 6
ACPI / PM: Drop stale comment from acpi_power_transition()
* acpi-apei:
GHES: Make NMI handler have a single reader
GHES: Elliminate double-loop in the NMI handler
GHES: Panic right after detection
GHES: Carve out the panic functionality
GHES: Carve out error queueing in a separate function
* acpi-osl:
ACPI / osl: use same type for acpi_predefined_names values as in definition
* acpi-pci:
ACPI / PCI: remove stale list_head in struct acpi_prt_entry
* acpica: (22 commits)
ACPICA: Fix for ill-formed GUID strings for NFIT tables.
ACPICA: acpihelp: Update for new NFIT table GUIDs.
ACPICA: Update version to 20150515.
ACPICA: ACPI 6.0: Add support for NFIT table.
ACPICA: acpi_help: Add option to display all known/supported ACPI tables.
ACPICA: iASL/disassembler - fix possible fault for -e option.
ACPICA: ACPI 6.0: Add changes for DRTM table.
ACPICA: ACPI 6.0: Add support for IORT table.
ACPICA: ACPI 6.0: Add ACPI_SUB_PTR().
ACPICA: ACPI 6.0: Add changes for MADT table.
ACPICA: Hardware: Fix a resource leak issue in acpi_hw_build_pci_list().
ACPICA: Dispatcher: Fix a resource leak issue in acpi_ds_auto_serialize_method().
ACPICA: ACPI 6.0: Add changes for LPIT table.
ACPICA: ACPI 6.0: Add changes for FADT table.
ACPICA: ACPI 6.0: Add support for WPBT table.
ACPICA: iASL: Enhance detection of non-ascii or corrupted input files.
ACPICA: Parser: Move a couple externals to the proper header.
ACPICA: ACPI 6.0: Add support for XENV table.
ACPICA: ACPI 6.0: Add support for new predefined names.
ACPICA: ACPI 6.0: Add support for STAO table.
...
Commit b9a5e5e18f "ACPI / init: Fix the ordering of
acpi_reserve_resources()" overlooked the fact that the memory
and/or I/O regions reserved by acpi_reserve_resources() may
conflict with those reserved by the PNP "system" driver.
If that conflict actually takes place, it causes the reservations
made by the "system" driver to fail while before commit b9a5e5e18f
all reservations made by it and by acpi_reserve_resources() would be
successful. In turn, that allows the resources that haven't been
reserved by the "system" driver to be used by others (e.g. PCI) which
sometimes leads to functional problems (up to and including boot
failures).
To fix that issue, introduce a common resource reservation routine,
acpi_reserve_region(), to be used by both acpi_reserve_resources()
and the "system" driver, that will track all resources reserved by
it and avoid making conflicting requests.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=99831
Link: http://marc.info/?t=143389402600001&r=1&w=2
Fixes: b9a5e5e18f "ACPI / init: Fix the ordering of acpi_reserve_resources()"
Reported-by: Roland Dreier <roland@purestorage.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When the QR_EC transaction fails, the EC_FLAGS_QUERY_PENDING flag prevents
the event handling work queue from being scheduled again.
Though there shouldn't be failed QR_EC transactions, and this gap was
efficiently used for catching and learning the SCI_EVT clearing timing
compliance issues, we need to fix this as we are not fully compatible
with all platforms/Windows to handle SCI_EVT clearing timing correctly.
Fixing this gives the EC driver the chances to recover from a state machine
failure.
So this patch fixes this issue. When nr_pending_queries drops to 0, it
clears EC_FLAGS_QUERY_PENDING at the proper position for different modes in
order to ensure that the SCI_EVT handling can proceed.
In order to be clearer for future ec_event_clearing modes, all checks in
this patch are written in the inclusive style, not the exclusive style.
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
It is reported that on several platforms, EC firmware will not respond
non-expected QR_EC (see EC_FLAGS_QUERY_HANDSHAKE, only write QR_EC when
SCI_EVT is set).
Unfortunately, ACPI specification doesn't define when the SCI_EVT should be
cleared by the firmware, thus the original implementation queued up second
QR_EC right after writing QR_EC command and before reading the returned
event value as at that time the SCI_EVT is ensured not cleared. This
behavior is also based on the assumption that the firmware should be able
to return 0x00 to indicate "no outstanding event". This behavior did fix
issues on Samsung platforms where the spurious query value of 0x00 is
supported and didn't break platforms in my test queue.
But recently, specific Acer, Asus, Lenovo platforms keep on blaming this
change.
This patch changes the behavior to re-check the SCI_EVT a bit later and
removes EC_FLAGS_QUERY_HANDSHAKE quirks, hoping this is the Windows
compliant EC driver behavior.
In order to be robust to the possible regressions, instead of removing the
quirk directly, this patch keeps the quirk code, removes the quirk users
and keeps old behavior for Samsung platforms.
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Link: https://bugzilla.kernel.org/show_bug.cgi?id=94411
Link: https://bugzilla.kernel.org/show_bug.cgi?id=97381
Link: https://bugzilla.kernel.org/show_bug.cgi?id=98111
Reported-and-tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Reported-and-tested-by: Tigran Gabrielyan <tigrangab@gmail.com>
Reported-and-tested-by: Adrien D <ghbdtn@openmailbox.org>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
We've been suffering from the uncertainty of the SCI_EVT clearing timing.
This patch implements 3 of 4 possible modes to handle SCI_EVT clearing
variations. The old behavior is kept in this patch.
Status: QR_EC is re-checked as early as possible after checking previous
SCI_EVT. This always leads to 2 QR_EC transactions per SCI_EVT
indication and the target may implement event queue which returns
0x00 indicating "no outstanding event".
This is proven to be a conflict against Windows behavior, but is
still kept in this patch to make the EC driver robust to the
possible regressions that may occur on Samsung platforms.
Query: QR_EC is re-checked after the target has handled the QR_EC query
request command pushed by the host.
Event: QR_EC is re-checked after the target has noticed the query event
response data pulled by the host.
This timing is not determined by any IRQs, so we may need to use a
guard period in this mode, which may explain the existence of the
ec_guard() code used by the old EC driver where the re-check timing
is implemented in the similar way as this mode.
Method: QR_EC is re-checked as late as possible after completing the _Qxx
evaluation. The target may implement SCI_EVT like a level triggered
interrupt.
It is proven on kernel bugzilla 94411 that, Windows will have all
_Qxx evaluations parallelized. Thus unless required by further
evidences, we needn't implement this mode as it is a conflict of
the _Qxx parallelism requirement.
Note that, according to the reports, there are platforms that cannot be
handled using the "Status" mode without enabling the
EC_FLAGS_QUERY_HANDSHAKE quirk. But they can be handled with the other
modes according to the tests (kernel bugzilla 97381).
The following log entry can be used to confirm the differences of the 3
modes as it should appear at the different positions for the 3 modes:
Command(QR_EC) unblocked
Status: appearing after
EC_SC(W) = 0x84
Query: appearing after
EC_DATA(R) = 0xXX
where XX is the event number used to determine _QXX
Event: appearing after first
EC_SC(R) = 0xX0 SCI_EVT=x BURST=0 CMD=0 IBF=0 OBF=0
that is next to the following log entry:
Command(QR_EC) completed by hardware
Link: https://bugzilla.kernel.org/show_bug.cgi?id=94411
Link: https://bugzilla.kernel.org/show_bug.cgi?id=97381
Link: https://bugzilla.kernel.org/show_bug.cgi?id=98111
Reported-and-tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Reported-and-tested-by: Tigran Gabrielyan <tigrangab@gmail.com>
Reported-and-tested-by: Adrien D <ghbdtn@openmailbox.org>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
During the period that a work queue is scheduled (queued up for run) but
hasn't been run, second schedule_work() could fail. This may not lead to
the loss of queries because QR_EC is always ensured to be submitted after
the work queue has been in the running state.
The event handling work queue can be changed into the loop style to allow
us to control the code in a more flexible way:
1. Makes it possible to add event=0x00 termination condition in the loop.
2. Increases the thoughput of the QR_EC transactions as the 2nd+ QR_EC
transactions may be handled in the same work item used for the 1st QR_EC
transaction, thus the delay caused by the 2nd+ work item scheduling can
be eliminated.
Except the logging message changes and the throughput improvement, this
patch is just a funcitonal no-op.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Tested-by: Tigran Gabrielyan <tigrangab@gmail.com>
Tested-by: Adrien D <ghbdtn@openmailbox.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch collects transaction state transition code into one function. We
then could have a single function to maintain transaction transition
related behaviors. No functional changes.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Tested-by: Tigran Gabrielyan <tigrangab@gmail.com>
Tested-by: Adrien D <ghbdtn@openmailbox.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Make the button ACPI device ID array static const. Safes us a little bit
of code.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit 73f7d1ca32 "ACPI / init: Run acpi_early_init() before
timekeeping_init()" moved the ACPI subsystem initialization,
including the ACPI mode enabling, to an earlier point in the
initialization sequence, to allow the timekeeping subsystem
use ACPI early. Unfortunately, that resulted in boot regressions
on some systems and the early ACPI initialization was moved toward
its original position in the kernel initialization code by commit
c4e1acbb35 "ACPI / init: Invoke early ACPI initialization later".
However, that turns out to be insufficient, as boot is still broken
on the Tyan S8812 mainboard.
To fix that issue, split the ACPI early initialization code into
two pieces so the majority of it still located in acpi_early_init()
and the part switching over the platform into the ACPI mode goes into
a new function, acpi_subsystem_init(), executed at the original early
ACPI initialization spot.
That fixes the Tyan S8812 boot problem, but still allows ACPI
tables to be loaded earlier which is useful to the EFI code in
efi_enter_virtual_mode().
Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141
Fixes: 73f7d1ca32 "ACPI / init: Run acpi_early_init() before timekeeping_init()"
Reported-and-tested-by: Marius Tolzmann <tolzmann@molgen.mpg.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Lee, Chun-Yi <jlee@suse.com>
Add missing invocation of pm_generic_complete() to
acpi_subsys_complete() to allow ->complete callbacks provided
by the drivers of devices using the ACPI PM domain to be executed
during system resume.
Fixes: f25c0ae2b4 (ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspend)
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
According to Section 7.2 of ACPI 6.0, power resources should
always be enabled and disabled in order given by the "resourceorder"
field of the corresponding Power Resource objects: "Power Resource
levels are enabled from low values to high values and are disabled
from high values to low values."
However, this is not what happens during system resume, because
in that case the enabling/disabling is carried out in the power
resource registration order which may not reflect the ordering
required by the platform.
For this reason, make the ordering of the global list of all
power resources in the system (used by the system resume code)
reflect the one given by the "resourceorder" attributes of the
Power Resource objects in the ACPI namespace and modify
acpi_resume_power_resources() to walk the list in the reverse
order when turning off the power resources that had been off
before the system was suspended.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Use a #defined symbol ACPI_DT_NAMESPACE_HID instead of the PRP0001
string.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
list_head "list" in struct acpi_prt_entry was used to connect
_PRT entries for PCI irq, but after commit 181380b702 ("PCI/ACPI:
Don't cache _PRT, and don't associate them with bus numbers"),
the list head for _PRT entries was removed, but left "list" in
struct acpi_prt_entry which is useless and stale, remove it now.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit d6d003556c6fc22e067d5d511577128a661266c3
-t option displays all ACPI tables.
Link: https://github.com/acpica/acpica/commit/d6d00355
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 403b8b0023fd7549b2f9bf818fcc1ba481047b69
If non-AML files are used with the -e option, the disassembler
can fault. The fix is to ensure that all -e files are either
SSDTs or a DSDT. ACPICA BZ 1158.
Link: https://github.com/acpica/acpica/commit/403b8b00
Reference: https://bugs.acpica.org/show_bug.cgi?id=1158
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 e4f0b73c107680841d7dd01cc04ec108df6580bd
There is code in acpi_hw_build_pci_list() destructing returned object
(return_list_head) before touching it while the allocated new object
(list_head) is not tracked correctly to be destructed on the error case,
which is detected as unsecure code by the "Coverity" tool.
This patch fixes this issue by always intializing the returned object in
acpi_hw_build_pci_list() so that the caller of acpi_hw_build_pci_list() needn't
initialize it and always using the returned object to track the new
allocated objects. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/e4f0b73c
Link: https://jira01.devtools.intel.com/browse/LCK-2143
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 29d03840cbab435e8ea82e9339ff9d84535c647d
This patch fixes a resource leak issue in acpi_ds_auto_serialize_method().
It is reported by the "Coverity" tool as unsecure code. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/29d03840
Link: https://jira01.devtools.intel.com/browse/LCK-2142
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 08170904011f1e8f817d9e3a9f2bb2438aeacf60
For the compiler part (not disassembler).
- Characters not within a comment must be be ASCII (0-0x7F), and
now either printable or a "space" character.
Provides better detection of files that cannot be compiled.
This patch only affects iASL which is not in the Linux upstream.
Link: https://github.com/acpica/acpica/commit/08170904
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 7325b59c8b5d1522ded51ae6a76b804f6e8da5d2
Moved from a C module.
Link: https://github.com/acpica/acpica/commit/7325b59c
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 ACPI 6 specification has made some changes in the device power
management area. In particular:
* The D3hot power state is now supposed to be always available
(instead of D3cold) and D3cold is only regarded as valid if the
_PR3 object is present for the given device.
* The required ordering of transitions into power states deeper than
D0 is now such that for a transition into state Dx the _PSx method
is supposed to be executed first, if present, and the states of
the power resources the device depends on are supposed to be
changed after that.
* It is now explicitly forbidden to transition devices from
lower-power (deeper) into higher-power (shallower) power states
other than D0.
Those changes have been made so the specification reflects the
Windows' device power management code that the vast majority of
systems using ACPI is validated against.
To avoid artificial differences in ACPI device power management
between Windows and Linux, modify the ACPI device power management
code to follow the new specification. Add comments explaining the
code flow in some unclear places.
This only may affect some real corner cases in which the OS behavior
expected by the firmware is different from the Windows one, but that's
quite unlikely. The transition ordering change affects transitions
to D1 and D2 which are rarely used (if at all) and into D3hot and
D3cold for devices actually having _PR3, but those are likely to
be validated against Windows anyway. The other changes may affect
code calling acpi_device_get_power() or acpi_device_update_power()
where ACPI_STATE_D3_HOT may be returned instead of ACPI_STATE_D3_COLD
(that's why the ACPI fan driver needs to be updated too) and since
transitions into ACPI_STATE_D3_HOT may remove power now, it is better
to avoid this one in acpi_pm_device_sleep_state() if the "no power
off" PM QoS flag is set.
The only existing user of acpi_device_can_poweroff() really cares
about the case when _PR3 is present, so the change in that function
should not cause any problems to happen too.
A plus is that PCI_D3hot can be mapped to ACPI_STATE_D3_HOT
now and the compatibility with older systems should be covered
automatically.
In any case, if any real problems result from this, it still will
be better to follow the Windows' behavior (which now is reflected
by the specification too) in general and handle the cases when it
doesn't work via quirks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
{ Update to correct 1 patch subject in the description }
We have fixed a lot of race issues in the EC driver recently.
The following commit introduces MSI udelay()/msleep() quirk to MSI laptops
to make EC firmware working for bug 12011 without root causing any EC
driver race issues:
Commit: 5423a0cb3f
Subject: ACPI: EC: Add delay for slow MSI controller
Commit: 34ff4dbccc
Subject: ACPI: EC: Separate delays for MSI hardware
The following commit extends ECDT validation quirk to MSI laptops to make
EC driver locating EC registers properly for bug 12461:
Commit: a5032bfdd9
Subject: ACPI: EC: Always parse EC device
This is a different quirk than the MSI udelay()/msleep() quirk. This patch
keeps validating ECDT for only "Micro-Star MS-171F" as reported.
The following commit extends MSI udelay()/msleep() quirk to Quanta laptops
to make EC firmware working for bug 20242, there is no requirement to
validate ECDT for Quanta laptops:
Commit: 534bc4e3d2 Mon Sep 17 00:00:00 2001
Subject: ACPI EC: enable MSI workaround for Quanta laptops
The following commit extends MSI udelay()/msleep() quirk to Clevo laptops
to make EC firmware working for bug 77431, there is no requirement to
validate ECDT for Clevo laptops:
Commit: 777cb38295
Subject: ACPI / EC: Add msi quirk for Clevo W350etq
All udelay()/msleep() quirks for MSI/Quanta/Clevo seem to be the wrong
fixes generated without fixing the EC driver race issues.
And even if it is not wrong, the guarding can be covered by the following
commits in wait polling mode:
Commit: 9e295ac14d
Subject: ACPI / EC: Reduce ec_poll() by referencing the last register access timestamp.
Commit: commit in the same series
Subject: ACPI / EC: Fix and clean up register access guarding logics.
The only case that is not covered is the inter-transaction guarding. And
there is no evidence that we need the inter-transaction guarding upon
reading the noted bug entries.
So it is time to remove the quirks and let the users to try again. If there
is a regression, the only thing we need to do is to restore the
inter-transaction guarding for the reported platforms.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=12011
Link: https://bugzilla.kernel.org/show_bug.cgi?id=12461
Link: https://bugzilla.kernel.org/show_bug.cgi?id=20242
Link: https://bugzilla.kernel.org/show_bug.cgi?id=77431
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
We have 2 polling modes in the EC driver:
1. busy polling: originally used for the MSI quirks. udelay() is used to
perform register access guarding.
2. wait polling: normal code path uses wait_event_timeout() and it can be
woken up as soon as the transaction is completed in the interrupt mode.
It also contains the register acces guarding logic in case the interrupt
doesn't arrive and the EC driver is about to advance the transaction in
task context (the polling mode).
The wait polling is useful for interrupt mode to allow other tasks to use
the CPU during the wait.
But for the polling mode, the busy polling takes less time than the wait
polling, because if no interrupt arrives, the wait polling has to wait the
minimal HZ interval.
We have a new use case for using the busy polling mode. Some GPIO drivers
initialize PIN configuration which cause a GPIO multiplexed EC GPE to be
disabled out of the GPE register's control. Busy polling mode is useful
here as it takes less time than the wait polling. But the guarding logic
prevents it from responding even faster. We should spinning around the EC
status rather than spinning around the nop execution lasted a determined
period.
This patch introduces 2 module params for the polling mode switch and the
guard time, so that users can use the busy polling mode without the
guarding in case the guarding is not necessary. This is an example to use
the 2 module params for this purpose:
acpi.ec_busy_polling acpi.ec_polling_guard=0
We've tested the patch on a test platform. The platform suffers from such
kind of the GPIO PIN issue. The GPIO driver resets all PIN configuration
and after that, EC interrupt cannot arrive because of the multiplexing.
Then the platform suffers from a long delay carried out by the
wait_event_timeout() as all further EC transactions will run in the polling
mode. We switched the EC driver to use the busy polling mechanism instead
of the wait timeout polling mechanism and the delay is still high:
[ 44.283005] calling PNP0C0B:00+ @ 1305, parent: platform
[ 44.417548] call PNP0C0B:00+ returned 0 after 131323 usecs
And this patch can significantly reduce the delay:
[ 44.502625] calling PNP0C0B:00+ @ 1308, parent: platform
[ 44.503760] call PNP0C0B:00+ returned 0 after 1103 usecs
Tested-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In the polling mode, EC driver shouldn't access the EC registers too
frequently. Though this statement is concluded from the non-root caused
bugs (see links below), we've maintained the register access guarding
logics in the current EC driver. The guarding logics can be found here and
there, makes it hard to root cause real timing issues. This patch collects
the guarding logics into one single function so that all hidden logics
related to this can be seen clearly.
The current guarding related code also has several issues:
1. Per-transaction timestamp prevents inter-transaction guarding from being
implemented in the same place. We have an inter-transaction udelay() in
acpi_ec_transaction_unblocked(), this logic can be merged into ec_poll()
if we can use per-device timestamp. This patch completes such merge to
form a new ec_guard() function and collects all guarding related hidden
logics in it.
One hidden logic is: there is no inter-transaction guarding performed
for non MSI quirk (wait polling mode), this patch skips
inter-transaction guarding before wait_event_timeout() for the wait
polling mode to reveal the hidden logic.
The other hidden logic is: there is msleep() inter-transaction guarding
performed when the GPE storming is observed. As after merging this
commit:
Commit: e1d4d90fc0
Subject: ACPI / EC: Refine command storm prevention support
EC_FLAGS_COMMAND_STORM is ensured to be cleared after invoking
acpi_ec_transaction_unlocked(), the msleep() guard logic will never
happen now. Since no one complains such change, this logic is likely
added during the old times where the EC race issues are not fixed and
the bugs are false root-caused to the timing issue. This patch simply
removes the out-dated logic. We can restore it by stop skipping
inter-transaction guarding for wait polling mode.
Two different delay values are defined for msleep() and udelay() while
they are merged in this patch to 550us.
2. time_after() causes additional delay in the polling mode (can only be
observed in noirq suspend/resume processes where polling mode is always
used) before advance_transaction() is invoked ("wait polling" log is
added before wait_event_timeout()). We can see 2 wait_event_timeout()
invocations. This is because time_after() ensures a ">" validation while
we only need a ">=" validation here:
[ 86.739909] ACPI: Waking up from system sleep state S3
[ 86.742857] ACPI : EC: 2: Increase command
[ 86.742859] ACPI : EC: ***** Command(RD_EC) started *****
[ 86.742861] ACPI : EC: ===== TASK (0) =====
[ 86.742871] ACPI : EC: EC_SC(R) = 0x20 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=0
[ 86.742873] ACPI : EC: EC_SC(W) = 0x80
[ 86.742876] ACPI : EC: ***** Event started *****
[ 86.742880] ACPI : EC: ~~~~~ wait polling ~~~~~
[ 86.743972] ACPI : EC: ~~~~~ wait polling ~~~~~
[ 86.747966] ACPI : EC: ===== TASK (0) =====
[ 86.747977] ACPI : EC: EC_SC(R) = 0x20 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=0
[ 86.747978] ACPI : EC: EC_DATA(W) = 0x06
[ 86.747981] ACPI : EC: ~~~~~ wait polling ~~~~~
[ 86.751971] ACPI : EC: ~~~~~ wait polling ~~~~~
[ 86.755969] ACPI : EC: ===== TASK (0) =====
[ 86.755991] ACPI : EC: EC_SC(R) = 0x21 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=1
[ 86.755993] ACPI : EC: EC_DATA(R) = 0x03
[ 86.755994] ACPI : EC: ~~~~~ wait polling ~~~~~
[ 86.755995] ACPI : EC: ***** Command(RD_EC) stopped *****
[ 86.755996] ACPI : EC: 1: Decrease command
This patch corrects this by using time_before() instead in ec_guard():
[ 54.283146] ACPI: Waking up from system sleep state S3
[ 54.285414] ACPI : EC: 2: Increase command
[ 54.285415] ACPI : EC: ***** Command(RD_EC) started *****
[ 54.285416] ACPI : EC: ~~~~~ wait polling ~~~~~
[ 54.285417] ACPI : EC: ===== TASK (0) =====
[ 54.285424] ACPI : EC: EC_SC(R) = 0x20 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=0
[ 54.285425] ACPI : EC: EC_SC(W) = 0x80
[ 54.285427] ACPI : EC: ***** Event started *****
[ 54.285429] ACPI : EC: ~~~~~ wait polling ~~~~~
[ 54.287209] ACPI : EC: ===== TASK (0) =====
[ 54.287218] ACPI : EC: EC_SC(R) = 0x20 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=0
[ 54.287219] ACPI : EC: EC_DATA(W) = 0x06
[ 54.287222] ACPI : EC: ~~~~~ wait polling ~~~~~
[ 54.291190] ACPI : EC: ===== TASK (0) =====
[ 54.291210] ACPI : EC: EC_SC(R) = 0x21 SCI_EVT=1 BURST=0 CMD=0 IBF=0 OBF=1
[ 54.291213] ACPI : EC: EC_DATA(R) = 0x03
[ 54.291214] ACPI : EC: ~~~~~ wait polling ~~~~~
[ 54.291215] ACPI : EC: ***** Command(RD_EC) stopped *****
[ 54.291216] ACPI : EC: 1: Decrease command
After cleaning up all guarding logics, we have one single function
ec_guard() collecting all old, non-root-caused, hidden logics. Then we can
easily tune the logics in one place to respond to the bug reports.
Except the time_before() change, all other changes do not change the
behavior of the EC driver.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=12011
Link: https://bugzilla.kernel.org/show_bug.cgi?id=20242
Link: https://bugzilla.kernel.org/show_bug.cgi?id=77431
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The following commit merges polling and interrupt modes for EC driver:
Commit: 2a84cb9852 Mon Sep 17 00:00:00 2001
Subject: ACPI: EC: Merge IRQ and POLL modes
The irqs_disabled() check introduced in it tries to fall into busy polling
mode when the context of ec_poll() cannot sleep.
Actually ec_poll() is ensured to be invoked in the contexts that can sleep
(from a sysfs /sys/kernel/debug/ec/ec0/io access, or from
acpi_evaluate_object(), or from acpi_ec_gpe_poller()). Without the MSI
quirk, we never saw the udelay() logic invoked. Thus this check is useless
and can be removed.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch removes the storming threashold enlarging quirk.
After applying the following commit, we can notice that there is no no-op
GPE handling invocation can be observed, thus it is unlikely that the
no-op counts can exceed the storming threashold:
Commit: ca37bfdfbc
Subject: ACPI / EC: Fix several GPE handling issues by deploying ACPI_GPE_DISPATCH_RAW_HANDLER mode.
Even when the storming happens, we have already limited its affection to
the only transaction and no further transactions will be affected. This is
done by this commit:
Commit: e1d4d90fc0
Subject: ACPI / EC: Refine command storm prevention support
So it's time to remove this quirk.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=45151
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch updates acpi_ec_is_gpe_raised() according to the following
commit:
Commit: 09af8e8290
Subject: ACPICA: Events: Add support to return both enable/status register values for GPE and fixed event.
This is actually a no-op change as both the flags are defined to a same
value.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In the definition of struct acpi_predefined_names, value is of
type char *. Make the OSL override function also work with type
char * (or, more precisely, with a pointer to it).
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Revert commit b1ef297258 (ACPICA: Permanently set _REV to the value
'2'.) as it causes a sound regression to happen on Dell XPS 13 (2015).
Reported-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
An old comment in acpi_power_transition() indicates that support
for ordering power resources needs to be added, but the current
code handles that already.
Drop the comment to avoid confusion.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* acpi-resources:
x86/PCI/ACPI: Make all resources except [io 0xcf8-0xcff] available on PCI bus
* acpi-battery:
ACPI / SBS: Add 5 us delay to fix SBS hangs on MacBook
* acpi-doc:
ACPI / documentation: Fix ambiguity in the GPIO properties document
ACPI / documentation: fix a sentence about GPIO resources
* acpi-pnp:
ACPI / PNP: add two IDs to list for PNPACPI device enumeration
Since acpi_reserve_resources() is defined as a device_initcall(),
there's no guarantee that it will be executed in the right order
with respect to the rest of the ACPI initialization code. On some
systems this leads to breakage if, for example, the address range
that should be reserved for the ACPI fixed registers is given to
the PCI host bridge instead if the race is won by the wrong code
path.
Fix this by turning acpi_reserve_resources() into a void function
and calling it directly from within the ACPI initialization sequence.
Reported-and-tested-by: George McCollister <george.mccollister@gmail.com>
Link: http://marc.info/?t=143092384600002&r=1&w=2
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ACPI procfs power interface is initialized by compilation units
that are only selectable on X86 platforms. Since its usage is
deprecated and it cannot even be used on platforms other than X86
it should be compiled in only on X86 platforms.
This patch makes CONFIG_ACPI_PROCFS_POWER dependent on X86, so
that other architectures are prevented from compiling it in for
no purpose.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Refine the check for the presence of the "compatible" property
if the PRP0001 device ID is present in the device's list of
ACPI/PNP IDs to also print the message if _DSD is missing
entirely or the format of it is incorrect.
One special case to take into accout is that the "compatible"
property need not be provided for devices having the PRP0001
device ID in their lists of ACPI/PNP IDs if they are ancestors
of PRP0001 devices with the "compatible" property present.
This is to cover heriarchies of device objects where the kernel
is only supposed to use a struct device representation for the
topmost one and the others represent, for example, functional
blocks of a composite device.
While at it, reduce the log level of the message to "info"
and reduce the log level of the "broken _DSD" message to
"debug" (noise reduction).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
This is the result of us seeing this during boot
[ 24.332560] INFO: NMI handler (ghes_notify_nmi) took too long to run: 3.265 msecs
[ 24.332567] INFO: NMI handler (ghes_notify_nmi) took too long to run: 5.946 msecs
[ 24.332568] INFO: NMI handler (ghes_notify_nmi) took too long to run: 5.948 msecs
and a report of people running perf stat and the machine softlocking.
"hest_disable" was helping in this case, which made us look at that
particular NMI handler. It was grabbing a lock each time it is run and
on each CPU. But this is not needed as the GHES sources are global and
they need only a single reader.
This patchset does that and cleans up the handler in the process.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVRzqjAAoJEBLB8Bhh3lVKFQUQAKmPPaWp2qPUkRHtrdFfae0n
Um9PSAHlvO8oHPrr+5j+CEVX1gQ1qUFMuxSVuBYYhmMZnsAVCwKX8gOi3slZmElo
L0MoqxygP2v3Rc79Jk8KEkov+80zzp46VoB5Yh0mTfzSejeS+c1owwS0RzVIpda3
Zp1cAThTVsCdDmmWGhnWfc8T/wniPc2zbbVhtjivO/wwSu7ArWUR5/03pbxzex8M
3xnJY29USB62xO5OJf0mxAIhTqv4a7NSQ6NziBrI2Mt4inHj0oSR7KLVFpeSx4mX
LLo8dWfDpMIbwd2sZYg5fG6Kz2i3Cc5I252V4j7MI+srvvZzZPBr1aB8qNyQVGPF
grrQKQuD2Az0WZRo2gK2LvxvlHfmJyOJMaFPW+RMnARbtKMmmAIwaN4+zmPGHoH8
aQK7cKUyb1JxICpy9iAZjXMvqxc5zbhYra0G+zuLKruhEvmLrwibphjI82BNdaBZ
rhkK+cw47lPgwKVNRWKjpNGGziwqU2cBlmc50k9OyQhhv5HF2TeYyBRryykOVmLV
DpsUxO4rCj0YEioyoJEruBO1Ks167HGrg5sbSemO/YeM7wLgr7hMfVNlGM4DI68X
b3Ie81/7qD8d3nQZ/gkk8ex1D0QhS0FWZthbNKpvkX+Zc/ELbGhfgHxX55HmfGuD
DUmvP2oXlALAIPiJAYVP
=Qj+0
-----END PGP SIGNATURE-----
Merge tag 'ras_for_4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras into acpi-apei
Pull GHES changes for 4.2 from Borislav Petkov:
"GHES: Seriously speedup and cleanup NMI handler (Jiri Kosina and Borislav Petkov)
This is the result of us seeing this during boot
[ 24.332560] INFO: NMI handler (ghes_notify_nmi) took too long to run: 3.265 msecs
[ 24.332567] INFO: NMI handler (ghes_notify_nmi) took too long to run: 5.946 msecs
[ 24.332568] INFO: NMI handler (ghes_notify_nmi) took too long to run: 5.948 msecs
and a report of people running perf stat and the machine softlocking.
"hest_disable" was helping in this case, which made us look at that
particular NMI handler. It was grabbing a lock each time it is run and
on each CPU. But this is not needed as the GHES sources are global and
they need only a single reader.
This patchset does that and cleans up the handler in the process."
* tag 'ras_for_4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras:
GHES: Make NMI handler have a single reader
GHES: Elliminate double-loop in the NMI handler
GHES: Panic right after detection
GHES: Carve out the panic functionality
GHES: Carve out error queueing in a separate function
Commit eec15edbb0 (ACPI / PNP: use device ID list for PNPACPI device
enumeration) changed the way how ACPI devices are enumerated and when
they are added to the PNP bus.
However, it broke the sound card support on (at least) a vintage
IBM ThinkPad 600E: with said commit applied, two of the necessary
"CSC01xx" devices are not added to the PNP bus and hence can not be
found during the initialization of the "snd-cs4236" module. As a
consequence, loading "snd-cs4236" causes null pointer exceptions.
The attached patch fixes the problem end re-enables sound on the
IBM ThinkPad 600E.
Fixes: eec15edbb0 (ACPI / PNP: use device ID list for PNPACPI device enumeration)
Signed-off-by: Witold Szczeponik <Witold.Szczeponik@gmx.net>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit 7bc5a2bad0 'ACPI: Support _OSI("Darwin") correctly' caused
the MacBook firmware to expose the SBS, resulting in intermittent
hangs of several minutes on boot, and failure to detect or report
the battery. Fix this by adding a 5 us delay to the start of each
SMBUS transaction. This timing is the result of experimentation -
hangs were observed with 3 us but never with 5 us.
Fixes: 7bc5a2bad0 'ACPI: Support _OSI("Darwin") correctly'
Link: https://bugzilla.kernel.org/show_bug.cgi?id=94651
Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Cc: 3.18+ <stable@vger.kernel.org> # 3.18+
[ rjw: Subject and changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
An IO port or MMIO resource assigned to a PCI host bridge may be
consumed by the host bridge itself or available to its child
bus/devices. The ACPI specification defines a bit (Producer/Consumer)
to tell whether the resource is consumed by the host bridge itself,
but firmware hasn't used that bit consistently, so we can't rely on it.
Before commit 593669c2ac ("x86/PCI/ACPI: Use common ACPI resource
interfaces to simplify implementation"), arch/x86/pci/acpi.c ignored
all IO port resources defined by acpi_resource_io and
acpi_resource_fixed_io to filter out IO ports consumed by the host
bridge itself.
Commit 593669c2ac ("x86/PCI/ACPI: Use common ACPI resource interfaces
to simplify implementation") started accepting all IO port and MMIO
resources, which caused a regression that IO port resources consumed
by the host bridge itself became available to its child devices.
Then commit 63f1789ec7 ("x86/PCI/ACPI: Ignore resources consumed by
host bridge itself") ignored resources consumed by the host bridge
itself by checking the IORESOURCE_WINDOW flag, which accidently removed
MMIO resources defined by acpi_resource_memory24, acpi_resource_memory32
and acpi_resource_fixed_memory32.
On x86 and IA64 platforms, all IO port and MMIO resources are assumed
to be available to child bus/devices except one special case:
IO port [0xCF8-0xCFF] is consumed by the host bridge itself
to access PCI configuration space.
So explicitly filter out PCI CFG IO ports[0xCF8-0xCFF]. This solution
will also ease the way to consolidate ACPI PCI host bridge common code
from x86, ia64 and ARM64.
Related ACPI table are archived at:
https://bugzilla.kernel.org/show_bug.cgi?id=94221
Related discussions at:
http://patchwork.ozlabs.org/patch/461633/https://lkml.org/lkml/2015/3/29/304
Fixes: 63f1789ec7 (Ignore resources consumed by host bridge itself)
Reported-by: Bernhard Thaler <bernhard.thaler@wvnet.at>
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Cc: 4.0+ <stable@vger.kernel.org> # 4.0+
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit 9faf6136ff (ACPI / SBS: Disable smart battery manager on
Apple) introduced a regression disabling the SBS battery manager.
The battery manager should be marked as present when
acpi_manager_get_info() returns 0.
Fixes: 9faf6136ff (ACPI / SBS: Disable smart battery manager on Apple)
Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Cc: 3.18+ <stable@vger.kernel.org> # 3.18+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Since GHES sources are global, we theoretically need only a single CPU
reading them per NMI instead of a thundering herd of CPUs waiting on a
spinlock in NMI context for no reason at all.
Do that.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Borislav Petkov <bp@suse.de>
There's no real need to iterate twice over the HW error sources in the
NMI handler. With the previous cleanups, elliminating the second loop is
almost trivial.
Signed-off-by: Borislav Petkov <bp@suse.de>
The moment we log an error of panic severity, there's no need to noodle
through the ghes_nmi list anymore. So panic instead right then and
there.
Signed-off-by: Borislav Petkov <bp@suse.de>
- Fix a build warning in the intel_pstate driver showing up in non-SMP
builds (Borislav Petkov).
- Change one of the intel_pstate's P-state selection parameters for
Baytrail and Cherrytrail CPUs to significantly improve performance
at the cost of a small increase in energy consumption (Kristen
Carlson Accardi).
- Fix a NULL pointer dereference in the ACPI EC driver due to an unsafe
list walk in the query handler removal routine (Chris Bainbridge).
- Get rid of a false-positive lockdep warning in the ACPI container
hot-remove code (Rafael J Wysocki).
- Prevent the ACPI device enumeration code from creating device
objects of a wrong type in some cases (Rafael J Wysocki).
- Add Skylake processors support to the Intel RAPL power capping
driver (Brian Bian).
- Drop the stale MAINTAINERS entry for the ACPI dock driver that is
regarded as part of the ACPI core and maintained along with it now
(Chao Yu).
- Fix cpupower tool breakage caused by a library API change in libpci
3.3.0 (Lucas Stach).
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJVOoMNAAoJEILEb/54YlRxx+QP/A/gaX9GgB6rv627Khlaw2AK
PpE1SrJoU9jAEwPqXtRnYc/6nducDzO5XaHOdWaV02YCpKLL5vIyia6wcy7cf4kr
6vJUnBz0OiHjp4e4sYrvIGt7RrLnlodayKAzNgtjDjF2JE3gzOOldD0klcfisiUP
Uc7Y3bpFndS8fwpcJO0tGm73aA9kNC5N8sYxgtuv/OAeMmJgi0fIi2V227XIurJU
48nMJ1v7M3OChmhdfxEtUSR9TM8J0Ck3yJwPYORNFItRCGqHJb3WY6lo1kbNcv1g
SLwbw+nCaq+E4k2PtDAsg68Ni0uGGnytcBTzhtPeUOdPRulp4CHCnZEyMUBwFVV8
gZlgL2S3CxcBlZ52hVB9tAhAyRcxmaWrp1v/hNsTh1xX9v9JFUFdpjYvk1RlHKwD
aT30G1mV8icU9lrYzhNOnh9gMrZVv6wy4sp4Uk1NLa17WXu+p0LMrCX8HJEb3PT3
rYZ8jbzo422lTksopiLTLhY4ipgX+kysa7NhTtw/J5Hb9xctho0uTsIhP6sSkh2e
eHO8WthEpF36228n6qiGGTBMcs4xPD8goxXCeBmgsBeVAQDaVR1IcArVTS+HAaJX
KOhemws+ThpEpjqB8jbpa42OEmY1Um3UUufHwnJIX54vGkSlXBxXE9r3hCwK7Mgu
hQhnM9hargHcy9Z8vd91
=0bKD
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-4.1-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull more power management and ACPI updates from Rafael Wysocki:
"These are fixes mostly (intel_pstate, ACPI core, ACPI EC driver,
cpupower tool), a new CPU ID for the Intel RAPL driver and one
intel_pstate driver improvement that didn't make it to my previous
pull requests due to timing.
Specifics:
- Fix a build warning in the intel_pstate driver showing up in
non-SMP builds (Borislav Petkov)
- Change one of the intel_pstate's P-state selection parameters for
Baytrail and Cherrytrail CPUs to significantly improve performance
at the cost of a small increase in energy consumption (Kristen
Carlson Accardi)
- Fix a NULL pointer dereference in the ACPI EC driver due to an
unsafe list walk in the query handler removal routine (Chris
Bainbridge)
- Get rid of a false-positive lockdep warning in the ACPI container
hot-remove code (Rafael J Wysocki)
- Prevent the ACPI device enumeration code from creating device
objects of a wrong type in some cases (Rafael J Wysocki)
- Add Skylake processors support to the Intel RAPL power capping
driver (Brian Bian)
- Drop the stale MAINTAINERS entry for the ACPI dock driver that is
regarded as part of the ACPI core and maintained along with it now
(Chao Yu)
- Fix cpupower tool breakage caused by a library API change in libpci
3.3.0 (Lucas Stach)"
* tag 'pm+acpi-4.1-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / scan: Add a scan handler for PRP0001
ACPI / scan: Annotate physical_node_lock in acpi_scan_is_offline()
ACPI / EC: fix NULL pointer dereference in acpi_ec_remove_query_handler()
MAINTAINERS: remove maintainship entry of docking station driver
powercap / RAPL: Add support for Intel Skylake processors
cpufreq: intel_pstate: Fix an annoying !CONFIG_SMP warning
intel_pstate: Change the setpoint for Atom params
cpupower: fix breakage from libpci API change
