| Age | Commit message (Collapse) | Author |
|---|
|
Eliminate comparisons from the status flags checks in
advance_transaction() (especially from the one that is only correct,
because the value of the flag checked in there is 1) and rearrange
the code for more clarity while at it.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Introduce acpi_ec_spurious_interrupt() for recording spurious
interrupts and use it for error handling in advance_transaction(),
drop the (now redundant) original error handling block from there
along with a frew goto statements that are not necessary any more.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Notice that the value of t in advance_transaction() does not change
after its initialization and:
- Initialize t upfront (and rearrange the definitions of local
variables while at it).
- Check it against NULL in a block executed when it is NULL.
- Skip error handling for t == NULL, because a valid pointer value
of t is required for the error handling.
- Drop the (now redundant) check of t against NULL from the error
handling block and reduce the indentation level in there.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Rename acpi_ec_is_gpe_raised() into acpi_ec_gpe_status_set(),
update its callers accordingly and drop the ternary operator
(which isn't really necessary in there) from it.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Fold acpi_ec_clear_gpe() which is only used in one place into its
caller and clean up comments related to that function while at it.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
advance_transaction() is using in_interrupt() to distinguish between
an invocation from the interrupt handler and an invocation from
another part of the stack.
This looks misleading because chains like
acpi_update_all_gpes() -> acpi_ev_gpe_detect() ->
acpi_ev_detect_gpe() -> acpi_ec_gpe_handler()
should probably also behave as if they were called from an interrupt
handler.
Replace in_interrupt() usage with a function parameter.
Set this parameter to `true' if invoked from an interrupt handler
(acpi_ec_gpe_handler() and acpi_ec_irq_handler()) and `false'
otherwise.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
[ rjw: Subject edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
It turns out that in some cases there are EC events to flush in
acpi_ec_dispatch_gpe() even though the ec_no_wakeup kernel parameter
is set and the EC GPE is disabled while sleeping, so drop the
ec_no_wakeup check that prevents those events from being processed
from acpi_ec_dispatch_gpe().
Reported-by: Todd Brandt <todd.e.brandt@linux.intel.com>
Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Commit 607b9df63057 ("ACPI: EC: PM: Avoid flushing EC work when EC
GPE is inactive") has been reported to cause some power button wakeup
events to be missed on some systems, so modify acpi_ec_dispatch_gpe()
to call acpi_ec_flush_work() unconditionally to effectively reverse
the changes made by that commit.
Also note that the problem which prompted commit 607b9df63057 is not
reproducible any more on the affected machine.
Fixes: 607b9df63057 ("ACPI: EC: PM: Avoid flushing EC work when EC GPE is inactive")
Reported-by: Raymond Tan <raymond.tan@intel.com>
Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
When I cat acpi module parameter
'/sys/module/acpi/parameters/ec_event_clearing', it displays as follows.
It is better to add a newline for easy reading.
[root@hulk-202 ~]# cat /sys/module/acpi/parameters/ec_event_clearing
query[root@hulk-202 ~]#
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI updates from Rafael Wysocki:
"These update the ACPICA code in the kernel to upstream revision
20200430, fix several reference counting errors related to ACPI
tables, add _Exx / _Lxx support to the GED driver, add a new
acpi_evaluate_reg() helper, add new DPTF battery participant driver
and extend the DPFT power participant driver, improve the handling of
memory failures in the APEI code, add a blacklist entry to the
backlight driver, update the PMIC driver and the processor idle
driver, fix two kobject reference count leaks, and make a few janitory
changes.
Specifics:
- Update the ACPICA code in the kernel to upstream revision 20200430:
- Move acpi_gbl_next_cmd_num definition (Erik Kaneda).
- Ignore AE_ALREADY_EXISTS status in the disassembler when parsing
create operators (Erik Kaneda).
- Add status checks to the dispatcher (Erik Kaneda).
- Fix required parameters for _NIG and _NIH (Erik Kaneda).
- Make acpi_protocol_lengths static (Yue Haibing).
- Fix ACPI table reference counting errors in several places, mostly
in error code paths (Hanjun Guo).
- Extend the Generic Event Device (GED) driver to support _Exx and
_Lxx handler methods (Ard Biesheuvel).
- Add new acpi_evaluate_reg() helper and modify the ACPI PCI hotplug
code to use it (Hans de Goede).
- Add new DPTF battery participant driver and make the DPFT power
participant driver create more sysfs device attributes (Srinivas
Pandruvada).
- Improve the handling of memory failures in APEI (James Morse).
- Add new blacklist entry for Acer TravelMate 5735Z to the backlight
driver (Paul Menzel).
- Add i2c address for thermal control to the PMIC driver (Mauro
Carvalho Chehab).
- Allow the ACPI processor idle driver to work on platforms with only
one ACPI C-state present (Zhang Rui).
- Fix kobject reference count leaks in error code paths in two places
(Qiushi Wu).
- Delete unused proc filename macros and make some symbols static
(Pascal Terjan, Zheng Zengkai, Zou Wei)"
* tag 'acpi-5.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (32 commits)
ACPI: CPPC: Fix reference count leak in acpi_cppc_processor_probe()
ACPI: sysfs: Fix reference count leak in acpi_sysfs_add_hotplug_profile()
ACPI: GED: use correct trigger type field in _Exx / _Lxx handling
ACPI: DPTF: Add battery participant driver
ACPI: DPTF: Additional sysfs attributes for power participant driver
ACPI: video: Use native backlight on Acer TravelMate 5735Z
arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work
ACPI: APEI: Kick the memory_failure() queue for synchronous errors
mm/memory-failure: Add memory_failure_queue_kick()
ACPI / PMIC: Add i2c address for thermal control
ACPI: GED: add support for _Exx / _Lxx handler methods
ACPI: Delete unused proc filename macros
ACPI: hotplug: PCI: Use the new acpi_evaluate_reg() helper
ACPI: utils: Add acpi_evaluate_reg() helper
ACPI: debug: Make two functions static
ACPI: sleep: Put the FACS table after using it
ACPI: scan: Put SPCR and STAO table after using it
ACPI: EC: Put the ACPI table after using it
ACPI: APEI: Put the HEST table for error path
ACPI: APEI: Put the error record serialization table for error path
...
|
|
'acpi-pci'
* acpi-processor:
ACPI: processor: idle: Allow probing on platforms with one ACPI C-state
* acpi-cppc:
ACPI: CPPC: Fix reference count leak in acpi_cppc_processor_probe()
ACPI: CPPC: Make some symbols static
* acpi-dbg:
ACPI: debug: Make two functions static
* acpi-misc:
ACPI: GED: use correct trigger type field in _Exx / _Lxx handling
ACPI: GED: add support for _Exx / _Lxx handler methods
ACPI: Delete unused proc filename macros
* acpi-pci:
ACPI: hotplug: PCI: Use the new acpi_evaluate_reg() helper
ACPI: utils: Add acpi_evaluate_reg() helper
|
|
* acpica:
ACPICA: Update version to 20200430
ACPICA: Fix required parameters for _NIG and _NIH
ACPICA: Dispatcher: add status checks
ACPICA: Disassembler: ignore AE_ALREADY_EXISTS status when parsing create operators
ACPICA: Move acpi_gbl_next_cmd_num definition to acglobal.h
ACPICA: Make acpi_protocol_lengths static
* acpi-tables:
ACPI: sleep: Put the FACS table after using it
ACPI: scan: Put SPCR and STAO table after using it
ACPI: EC: Put the ACPI table after using it
ACPI: APEI: Put the HEST table for error path
ACPI: APEI: Put the error record serialization table for error path
ACPI: APEI: Put the error injection table for error path and module exit
ACPI: APEI: Put the boot error record table after parsing
ACPI: watchdog: Put the watchdog action table after parsing
ACPI: LPIT: Put the low power idle table after using it
|
|
Add the "ACPI" string to the "EC GPE dispatched" message as it is
ACPI-related.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Flushing the EC work while suspended to idle when the EC GPE status
is not set causes some EC wakeup events (notably power button and
lid ones) to be missed after a series of spurious wakeups on the Dell
XPS13 9360 in my office.
If that happens, the machine cannot be woken up from suspend-to-idle
by the power button or lid status change and it needs to be woken up
in some other way (eg. by a key press).
Flushing the EC work only after successful dispatching the EC GPE,
which means that its status has been set, avoids the issue, so change
the code in question accordingly.
Fixes: 7b301750f7f8 ("ACPI: EC: PM: Avoid premature returns from acpi_s2idle_wake()")
Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Chris Chiu <chiu@endlessm.com>
|
|
Those were used to create files in /proc/acpi long ago
and were missed when that code was deleted.
Signed-off-by: Pascal Terjan <pterjan@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
If the EC GPE status is not set after checking all of the other GPEs,
acpi_s2idle_wake() returns 'false', to indicate that the SCI event
that has just triggered is not a system wakeup one, but it does that
without canceling the pending wakeup and re-arming the SCI for system
wakeup which is a mistake, because it may cause s2idle_loop() to busy
spin until the next valid wakeup event. [If that happens, the first
spurious wakeup is still pending after acpi_s2idle_wake() has
returned, so s2idle_enter() does nothing, acpi_s2idle_wake()
is called again and it sees that the SCI has triggered, but no GPEs
are active, so 'false' is returned again, and so on.]
Fix that by moving all of the GPE checking logic from
acpi_s2idle_wake() to acpi_ec_dispatch_gpe() and making the
latter return 'true' only if a non-EC GPE has triggered and
'false' otherwise, which will cause acpi_s2idle_wake() to
cancel the pending SCI wakeup and re-arm the SCI for system
wakeup regardless of the EC GPE status.
This also addresses a lockup observed on an Elitegroup EF20EA laptop
after attempting to wake it up from suspend-to-idle by a key press.
Fixes: d5406284ff80 ("ACPI: PM: s2idle: Refine active GPEs check")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=207603
Reported-by: Todd Brandt <todd.e.brandt@linux.intel.com>
Fixes: fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system")
Link: https://lore.kernel.org/linux-acpi/CAB4CAwdqo7=MvyG_PE+PGVfeA17AHF5i5JucgaKqqMX6mjArbQ@mail.gmail.com/
Reported-by: Chris Chiu <chiu@endlessm.com>
Tested-by: Chris Chiu <chiu@endlessm.com>
Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The embedded controller boot resources table needs to be
released after using it.
Signed-off-by: Hanjun Guo <guohanjun@huawei.com>
[ rjw: avoid adding a label in acpi_ec_ecdt_start() ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The fast path check in acpi_ec_add() is not incorrect, because in
fact acpi_device_hid(device) can be equal to ACPI_ECDT_HID only if
boot_ec is not NULL, but it may confuse static checkers, so change
it to explicitly check boot_ec upfront and use the slow path if
that pointer is NULL.
Link: https://lore.kernel.org/linux-acpi/20200406144217.GA68494@mwanda/
Fixes: 3d9b8dd8320d ("ACPI: EC: Use fast path in acpi_ec_add() for DSDT boot EC")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI updates from Rafael Wysocki:
- Update the ACPICA code in the kernel to the 20200214 upstream
release including:
* Fix to re-enable the sleep button after wakeup (Anchal
Agarwal).
* Fixes for mistakes in comments and typos (Bob Moore).
* ASL-ASL+ converter updates (Erik Kaneda).
* Type casting cleanups (Sven Barth).
- Clean up the intialization of the EC driver and eliminate some dead
code from it (Rafael Wysocki).
- Clean up the quirk tables in the AC and battery drivers (Hans de
Goede).
- Fix the global lock handling on x86 to ignore unspecified bit
positions in the global lock field (Jan Engelhardt).
- Add a new "tiny" driver for ACPI button devices exposed by VMs to
guest kernels to send signals directly to init (Josh Triplett).
- Add a kernel parameter to disable ACPI BGRT on x86 (Alex Hung).
- Make the ACPI PCI host bridge and fan drivers use scnprintf() to
avoid potential buffer overflows (Takashi Iwai).
- Clean up assorted pieces of code:
* Reorder "asmlinkage" to make g++ happy (Alexey Dobriyan).
* Drop unneeded variable initialization (Colin Ian King).
* Add missing __acquires/__releases annotations (Jules Irenge).
* Replace list_for_each_safe() with list_for_each_entry_safe()
(chenqiwu)"
* tag 'acpi-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (31 commits)
ACPICA: Update version to 20200214
ACPI: PCI: Use scnprintf() for avoiding potential buffer overflow
ACPI: fan: Use scnprintf() for avoiding potential buffer overflow
ACPI: EC: Eliminate EC_FLAGS_QUERY_HANDSHAKE
ACPI: EC: Do not clear boot_ec_is_ecdt in acpi_ec_add()
ACPI: EC: Simplify acpi_ec_ecdt_start() and acpi_ec_init()
ACPI: EC: Consolidate event handler installation code
acpi/x86: ignore unspecified bit positions in the ACPI global lock field
acpi/x86: add a kernel parameter to disable ACPI BGRT
x86/acpi: make "asmlinkage" part first thing in the function definition
ACPI: list_for_each_safe() -> list_for_each_entry_safe()
ACPI: video: remove redundant assignments to variable result
ACPI: OSL: Add missing __acquires/__releases annotations
ACPI / battery: Cleanup Lenovo Ideapad Miix 320 DMI table entry
ACPI / AC: Cleanup DMI quirk table
ACPI: EC: Use fast path in acpi_ec_add() for DSDT boot EC
ACPI: EC: Simplify acpi_ec_add()
ACPI: EC: Drop AE_NOT_FOUND special case from ec_install_handlers()
ACPI: EC: Avoid passing redundant argument to functions
ACPI: EC: Avoid printing confusing messages in acpi_ec_setup()
...
|
|
The check for any active GPEs added by commit fdde0ff8590b ("ACPI:
PM: s2idle: Prevent spurious SCIs from waking up the system") turns
out to be insufficiently precise to prevent some systems from
resuming prematurely due to a spurious EC wakeup, so refine it
by first checking if any GPEs other than the EC GPE are active
and skipping all of the SCIs coming from the EC that do not produce
any genuine wakeup events after processing.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206629
Fixes: fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system")
Reported-by: Ondřej Caletka <ondrej@caletka.cz>
Tested-by: Ondřej Caletka <ondrej@caletka.cz>
Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The EC_FLAGS_QUERY_HANDSHAKE switch is never set in the current
code (the only function setting it is defined under #if 0) and
has no effect whatever, so eliminate it and drop the code
depending on it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The reason for clearing boot_ec_is_ecdt in acpi_ec_add() (if a
PNP0C09 device object matching the ECDT boot EC had been found in
the namespace) was to cause acpi_ec_ecdt_start() to return early,
but since the latter does not look at boot_ec_is_ecdt any more,
acpi_ec_add() need not clear it.
Moreover, doing that may be confusing as it may cause "DSDT" to be
printed instead of "ECDT" in the EC initialization completion
message, so stop doing it.
While at it, split the EC initialization completion message into
two messages, one regarding the boot EC and another one printed
regardless of whether or not the EC at hand is the boot one.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Notice that the return value of acpi_ec_init() is discarded anyway,
so it can be void and it doesn't need to check the return values of
acpi_bus_register_driver() and acpi_ec_ecdt_start() called by it.
Thus the latter can be void too and it really has nothing to do
if acpi_ec_add() has already found an EC matching the boot one in the
namespace. Also, acpi_ec_ecdt_get_handle() can be folded into it.
Modify the code accordingly and while at it create a propoer kerneldoc
comment to document acpi_ec_ecdt_start() and move the remark regarding
ASUS X550ZE along with the related bug URL from acpi_ec_init() into
that comment.
Additionally, fix up a stale comment in acpi_ec_init().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Commit 406857f773b0 ("ACPI: EC: add support for hardware-reduced
systems") made ec_install_handlers() return an error on failures
to configure a GPIO IRQ for the EC, but that is inconsistent with
the handling of the GPE event handler installation failures even
though it is exactly the same issue and the driver can respond to
it in the same way in both cases (the EC can be actively polled
for events through its registers if the event handler installation
fails).
Moreover, it requires acpi_ec_add() to take that special case into
account and disagrees with the ec_install_handlers() header comment.
For this reason, rework the event handler installation code in
ec_install_handlers() to explicitly take deferred probing (that
may be needed in the GPIO IRQ case) into account and to avoid
failing the EC initialization in any other case.
Among other things, reduce code duplication between
install_gpe_event_handler() and install_gpio_irq_event_handler() by
moving some code from there into ec_install_handlers() itself and
simplify the error code path in acpi_ec_add().
While at it, turn the ec_install_handlers() header comment into
a proper kerneldoc one and add some general control flow information
to it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Jian-Hong Pan <jian-hong@endlessm.com>
|
|
If the boot EC comes from the DSDT, its ACPI handle is equal to the
handle of a device object with the PNP0C09 device ID. If that
device object is passed to acpi_ec_add(), it is not necessary to
allocate a new EC structure for it and parse it, because that has
been done already, so change the function to use the fast path in
that case.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
First, notice that if the device ID in acpi_ec_add() is equal to
ACPI_ECDT_HID, boot_ec_is_ecdt must be set, because this means
that the device object passed to acpi_ec_add() comes from
acpi_ec_ecdt_start() which fails if boot_ec_is_ecdt is unset.
Accordingly, boot_ec_is_ecdt need not be set again in that case,
so drop that redundant update of it from the code.
Next, ec->handle must be a valid ACPI handle right before
returning 0 from acpi_ec_add(), because it either is the handle
of the device object passed to that function, or it is the boot EC
handle coming from acpi_ec_ecdt_start() which fails if it cannot
find a valid handle for the boot EC. Moreover, the object with
that handle is regarded as a valid representation of the EC in all
cases, so there is no reason to avoid the _DEP list update walk if
that handle is the boot EC handle. Accordingly, drop the dep_update
local variable from acpi_ec_add() and call acpi_walk_dep_device_list()
for ec->handle unconditionally before returning 0 from it.
Finally, the ec local variable in acpi_ec_add() need not be
initialized to NULL and the status local variable declaration
can be moved to the block in which it is used, so change the code
in accordance with these observations.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
If the status value returned by acpi_install_address_space_handler()
in ec_install_handlers() is AE_NOT_FOUND, it is treated in a special
way, apparently because it might mean a _REG method evaluation
failure (at least that is the case according to the comment in
there), but acpi_install_address_space_handler() does not take
_REG evaluation errors into account at all, so the AE_NOT_FOUND
special handling is confusing at best.
For this reason, change ec_install_handlers() to stop the EC and
return -ENODEV on all acpi_install_address_space_handler() errors.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
After commit 406857f773b0 ("ACPI: EC: add support for hardware-reduced
systems") the handle_events argument passed to ec_install_handlers()
and acpi_ec_setup() is redundant, because it is always 'false' when
the device argument passed to them in NULL and it is always 'true'
otherwise, so the device argument can be tested against NULL instead
of testing the handle_events one.
Accordingly, modify ec_install_handlers() and acpi_ec_setup() to take
two arguments and reduce the number of checks in the former.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
It doesn't really make sense to pass ec->handle of the ECDT EC to
acpi_handle_info(), because it is set to ACPI_ROOT_OBJECT in
acpi_ec_ecdt_probe(), so rework acpi_ec_setup() to avoid using
acpi_handle_info() for printing messages.
First, notice that the "Used as first EC" message is not really
useful, because it is immediately followed by a more meaningful one
from either acpi_ec_ecdt_probe() or acpi_ec_dsdt_probe() (the latter
also includes the EC object path), so drop it altogether.
Second, use pr_info() for printing the EC configuration information.
While at it, make the code in question avoid printing invalid GPE or
IRQ numbers and make it print the GPE/IRQ information only when the
driver is ready to handle events.
Fixes: 72c77b7ea9ce ("ACPI / EC: Cleanup first_ec/boot_ec code")
Fixes: 406857f773b0 ("ACPI: EC: add support for hardware-reduced systems")
Cc: 5.5+ <stable@vger.kernel.org> # 5.5+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Commit 016b87ca5c8c ("ACPI: EC: Rework flushing of pending work")
introduced a subtle bug into the flushing of pending EC work while
suspended to idle, which may cause the EC driver to fail to
re-enable the EC GPE after handling a non-wakeup event (like a
battery status change event, for example).
The problem is that the work item flushed by flush_scheduled_work()
in __acpi_ec_flush_work() may disable the EC GPE and schedule another
work item expected to re-enable it, but that new work item is not
flushed, so __acpi_ec_flush_work() returns with the EC GPE disabled
and the CPU running it goes into an idle state subsequently. If all
of the other CPUs are in idle states at that point, the EC GPE won't
be re-enabled until at least one CPU is woken up by another interrupt
source, so system wakeup events that would normally come from the EC
then don't work.
This is reproducible on a Dell XPS13 9360 in my office which
sometimes stops reacting to power button and lid events (triggered
by the EC on that machine) after switching from AC power to battery
power or vice versa while suspended to idle (each of those switches
causes the EC GPE to trigger for several times in a row, but they
are not system wakeup events).
To avoid this problem, it is necessary to drain the workqueue
entirely in __acpi_ec_flush_work(), but that cannot be done with
respect to system_wq, because work items may be added to it from
other places while __acpi_ec_flush_work() is running. For this
reason, make the EC driver use a dedicated workqueue for EC events
processing (let that workqueue be ordered so that EC events are
processed sequentially) and use drain_workqueue() on it in
__acpi_ec_flush_work().
Fixes: 016b87ca5c8c ("ACPI: EC: Rework flushing of pending work")
Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
There is a race condition in acpi_ec_get_query_handler()
theoretically allowing query handlers to go away before refernce
counting them.
In order to avoid it, call kref_get() on query handlers under
ec->mutex.
Also simplify the code a bit while at it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
* pm-sleep:
ACPI: PM: s2idle: Rework ACPI events synchronization
ACPI: EC: Rework flushing of pending work
* pm-cpuidle:
cpuidle: minor Kconfig help text fixes
cpuidle: Drop disabled field from struct cpuidle_state
cpuidle: Fix Kconfig indentation
* pm-cpufreq:
cpufreq: Fix Kconfig indentation
* pm-devfreq:
PM / devfreq: Add missing locking while setting suspend_freq
* pm-avs:
power: avs: Fix Kconfig indentation
|
|
There is a race condition in the ACPI EC driver, between
__acpi_ec_flush_event() and acpi_ec_event_handler(), that may
cause systems to stay in suspended-to-idle forever after a wakeup
event coming from the EC.
Namely, acpi_s2idle_wake() calls acpi_ec_flush_work() to wait until
the delayed work resulting from the handling of the EC GPE in
acpi_ec_dispatch_gpe() is processed, and that function invokes
__acpi_ec_flush_event() which uses wait_event() to wait for
ec->nr_pending_queries to become zero on ec->wait, and that wait
queue may be woken up too early.
Suppose that acpi_ec_dispatch_gpe() has caused acpi_ec_gpe_handler()
to run, so advance_transaction() has been called and it has invoked
acpi_ec_submit_query() to queue up an event work item, so
ec->nr_pending_queries has been incremented (under ec->lock). The
work function of that work item, acpi_ec_event_handler() runs later
and calls acpi_ec_query() to process the event. That function calls
acpi_ec_transaction() which invokes acpi_ec_transaction_unlocked()
and the latter wakes up ec->wait under ec->lock, but it drops that
lock before returning.
When acpi_ec_query() returns, acpi_ec_event_handler() acquires
ec->lock and decrements ec->nr_pending_queries, but at that point
__acpi_ec_flush_event() (woken up previously) may already have
acquired ec->lock, checked the value of ec->nr_pending_queries (and
it would not have been zero then) and decided to go back to sleep.
Next, if ec->nr_pending_queries is equal to zero now, the loop
in acpi_ec_event_handler() terminates, ec->lock is released and
acpi_ec_check_event() is called, but it does nothing unless
ec_event_clearing is equal to ACPI_EC_EVT_TIMING_EVENT (which is
not the case by default). In the end, if no more event work items
have been queued up while executing acpi_ec_transaction_unlocked(),
there is nothing to wake up __acpi_ec_flush_event() again and it
sleeps forever, so the suspend-to-idle loop cannot make progress and
the system is permanently suspended.
To avoid this issue, notice that it actually is not necessary to
wait for ec->nr_pending_queries to become zero in every case in
which __acpi_ec_flush_event() is used.
First, during platform-based system suspend (not suspend-to-idle),
__acpi_ec_flush_event() is called by acpi_ec_disable_event() after
clearing the EC_FLAGS_QUERY_ENABLED flag, which prevents
acpi_ec_submit_query() from submitting any new event work items,
so calling flush_scheduled_work() and flushing ec_query_wq
subsequently (in order to wait until all of the queries in that
queue have been processed) would be sufficient to flush all of
the pending EC work in that case.
Second, the purpose of the flushing of pending EC work while
suspended-to-idle described above really is to wait until the
first event work item coming from acpi_ec_dispatch_gpe() is
complete, because it should produce system wakeup events if
that is a valid EC-based system wakeup, so calling
flush_scheduled_work() followed by flushing ec_query_wq is also
sufficient for that purpose.
Rework the code to follow the above observations.
Fixes: 56b9918490 ("PM: sleep: Simplify suspend-to-idle control flow")
Reported-by: Kenneth R. Crudup <kenny@panix.com>
Tested-by: Kenneth R. Crudup <kenny@panix.com>
Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
As defined in the ACPI spec section 12.11, ACPI hardware-reduced
platforms define the EC SCI interrupt as a GpioInt in the _CRS object.
This replaces the previous way of using a GPE for this interrupt;
GPE blocks are not available on reduced hardware platforms.
Add support for handling this interrupt as an EC event source, and
avoid GPE usage on reduced hardware platforms.
This enables the use of several media keys (e.g. screen brightness
up/down) on Asus UX434DA.
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
In preparation for supporting reduced hardware platforms which use a
GpioInt instead of a GPE, rename some functions and constants to have
more appropriate names. No logical changes.
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Commit 10a08fd65ec1 ("ACPI: PM: Set up EC GPE for system wakeup from
drivers that need it") assumed that the EC GPE would only need to be
set up for system wakeup if either the intel-hid or the intel-vbtn
driver was in use, but that turns out to be incorrect. In particular,
on ASUS Zenbook UX430UNR/i7-8550U, if the EC GPE is not enabled while
suspended, the system cannot be woken up by opening the lid or
pressing a key, and that machine doesn't use any of the drivers
mentioned above.
For this reason, always set up the EC GPE for system wakeup from
suspend-to-idle by setting and clearing its wake mask in the ACPI
suspend-to-idle callbacks.
Fixes: 10a08fd65ec1 ("ACPI: PM: Set up EC GPE for system wakeup from drivers that need it")
Reported-by: Kristian Klausen <kristian@klausen.dk>
Tested-by: Kristian Klausen <kristian@klausen.dk>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Add a pm_pr_dbg() debug statement to acpi_ec_dispatch_gpe() to print
a message when the EC GPE has been dispatched (because its status
was set).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
|
|
Move some routines, including acpi_ec_dispatch_gpe(), that are only
used if CONFIG_PM_SLEEP is set to the #ifdef block containing the EC
suspend and resume callbacks, to make the "full EC PM picture" easier
to follow.
While at it, move the header of acpi_ec_dispatch_gpe() in the
header file to a CONFIG_PM_SLEEP #ifdef block.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
|
|
Change acpi_ec_suspend() to use pm_suspend_no_platform() instead of
acpi_sleep_no_ec_events(), which allows the latter to be eliminated
along with the s2idle_in_progress variable which is only used by it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
|
|
Since the ACPI SCI is set up for system wakeup before the "noirq"
suspend of devices, it is better to make suspend-to-idle follow
suspend-to-RAM (S3) and switch over the EC to polling during "noirq"
suspend (and back to interrupt-based flow during "noirq" resume).
The frequency of spurious wakeup interrupts from the EC may be
reduced this way.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
|
|
The EC GPE needs to be set up for system wakeup only if there is a
driver depending on it, either intel-hid or intel-vbtn, bound to a
button device that is expected to wake up the system from sleep (such
as the power button on some Dell systems, like the XPS13 9360). It
doesn't need to be set up for waking up the system from sleep in any
other cases and whether or not it is expected to wake up the system
from sleep doesn't depend on whether or not the LPS0 device is
present in the ACPI namespace.
For this reason, rearrange the ACPI suspend-to-idle code to make the
drivers depending on the EC GPE wakeup take care of setting it up and
decouple that from the LPS0 device handling.
While at it, make intel-hid and intel-vbtn prepare for system wakeup
only if they are allowed to wake up the system from sleep by user
space (via sysfs).
[Note that acpi_ec_mark_gpe_for_wake() and acpi_ec_set_gpe_wake_mask()
are there to prevent the EC GPE from being disabled by the
acpi_enable_all_wakeup_gpes() call in acpi_s2idle_prepare(), so on
systems with either intel-hid or intel-vbtn this change doesn't
affect any interactions with the hardware or platform firmware.]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
|
|
On some systems, if suspend-to-idle is used, the EC may signal system
wakeup events (power button events, for example) as well as events
that should not cause the system to resume and acpi_ec_dispatch_gpe()
needs to be called to determine whether or not the system should
resume then. In particular, if acpi_ec_dispatch_gpe() doesn't detect
any EC events at all, the system should remain suspended, so it is
useful to know when that is the case.
For this reason, make acpi_ec_dispatch_gpe() return a bool value
indicating whether or not any EC events have been detected by it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
|
|
Based on 3 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version this program is distributed in the
hope that it will be useful but without any warranty without even
the implied warranty of merchantability or fitness for a particular
purpose see the gnu general public license for more details
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version [author] [kishon] [vijay] [abraham]
[i] [kishon]@[ti] [com] this program is distributed in the hope that
it will be useful but without any warranty without even the implied
warranty of merchantability or fitness for a particular purpose see
the gnu general public license for more details
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version [author] [graeme] [gregory]
[gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i]
[kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema]
[hk] [hemahk]@[ti] [com] this program is distributed in the hope
that it will be useful but without any warranty without even the
implied warranty of merchantability or fitness for a particular
purpose see the gnu general public license for more details
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 1105 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Richard Fontana <rfontana@redhat.com>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
On some Samsung hardware, it is necessary to clear events accumulated by
the EC during sleep. These ECs stop reporting GPEs until they are manually
polled, if too many events are accumulated.
Thus the CLEAR_ON_RESUME quirk is introduced to send EC query commands
unconditionally after resume to clear all the EC query events on those
platforms.
Later, commit 4c237371f290 ("ACPI / EC: Remove old CLEAR_ON_RESUME quirk")
removes the CLEAR_ON_RESUME quirk because we thought the new EC IRQ
polling logic should handle this case.
Now it has been proved that the EC IRQ Polling logic does not fix the
issue actually because we got regression report on these Samsung
platforms after removing the quirk.
Thus revert commit 4c237371f290 ("ACPI / EC: Remove old CLEAR_ON_RESUME
quirk") to introduce back the Samsung quirk in this patch.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161
Tested-by: Ortwin Glück <odi@odi.ch>
Tested-by: Francisco Cribari <cribari@gmail.com>
Tested-by: Balazs Varga <balazs4web@gmail.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Consolidate boot EC checks in acpi_ec_add(), put the acpi_is_boot_ec()
checks directly into it and drop the latter.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Notice that acpi_ec_add() calls acpi_config_boot_ec() when it finds
that the device object passed to it represents a "boot" EC, but in
that case the ec pointer passed to acpi_config_boot_ec() is guaranteed
to be equal to boot_ec and ec->handle is passed as the handle
argument to it, so acpi_config_boot_ec() really only calls
acpi_ec_setup() and prints a message.
Avoid the pointless checks in acpi_config_boot_ec() by calling
acpi_ec_setup() directly and print the message separately.
With the above changes in place, there are no users of
acpi_config_boot_ec(), so drop it.
No intentional functional impact except for a changed message.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Since acpi_ec_dsdt_probe() returns early if boot_ec is set, it is
always unset when that function calls acpi_config_boot_ec() (passing
ec->handle as the handle argument to it). Thus it is not really
useful to call acpi_config_boot_ec() at that point. It is sufficient to
call acpi_ec_setup() directly and (if that is successful) set boot_ec,
so make acpi_ec_dsdt_probe() do that and avoid some pointless checks
in acpi_config_boot_ec().
No intentional functional impact except for a changed message.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Since acpi_ec_ecdt_probe() is called when boot_ec is not set, it
doesn't neeed to take the other possibility into account.
Accordingly, it only needs to set the handle field in the ec object
to ACPI_ROOT_OBJECT, call acpi_ec_setup() and (if that is successful)
set boot_ec to ec and boot_ec_is_ecdt to 'true'. Make it do so
directly, without calling acpi_config_boot_ec(), and avoid some
pointless checks in the latter.
No intentional functional impact except for a changed message.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The boot_ec variable is not used outside of the file it is defined
in, so declare it as static.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Both acpi_ec_dsdt_probe() and acpi_ec_ecdt_probe() may be void as
their return values are ignored anyway. This allows a couple of
gotos and labels to go away from there.
Moreover, acpi_ec_ecdt_probe() only needs to allocate the ec
object after getting the ECDT pointer and checking it, so the
pointless memory allocation and release on systems without the
ECDT can be avoided by reordering it.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
