kernel/linux.git/drivers/acpi, branch v5.6.17

ACPI: EC: PM: Avoid flushing EC work when EC GPE is inactive

2020-05-27T15:47:59+00:00

[ Upstream commit 607b9df63057a56f6172d560d5366cca6a030c76 ] 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+ # 5.4+ Signed-off-by: Rafael J. Wysocki Tested-by: Chris Chiu Signed-off-by: Sasha Levin

ACPI: EC: PM: Avoid premature returns from acpi_s2idle_wake()

2020-05-20T06:22:11+00:00

[ Upstream commit 7b301750f7f8f6503e11f1af4a03832525f58c66 ] 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 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 Tested-by: Chris Chiu Cc: 5.4+ # 5.4+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: PM: s2idle: Fix comment in acpi_s2idle_prepare_late()

2020-05-10T08:32:52+00:00

commit 243a98894dc525ad2fbeb608722fcb682be3186d upstream. Fix a comment in acpi_s2idle_prepare_late() that has become outdated after commit f0ac20c3f613 ("ACPI: EC: Fix flushing of pending work"). Fixes: f0ac20c3f613 ("ACPI: EC: Fix flushing of pending work") Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

PM: ACPI: Output correct message on target power state

2020-05-06T06:16:38+00:00

commit a9b760b0266f563b4784f695bbd0e717610dc10a upstream. Transitioned power state logged at the end of setting ACPI power. However, D3cold won't be in the message because state can only be D3hot at most. Use target_state to corretly report when power state is D3cold. Cc: All applicable Signed-off-by: Kai-Heng Feng Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPICA: Fixes for acpiExec namespace init file

2020-04-23T08:38:16+00:00

[ Upstream commit 9a1ae80412dcaa67a29eecf19de44f32b5f1c357 ] This is the result of squashing the following ACPICA commit ID's: 6803997e5b4f3635cea6610b51ff69e29d251de3 f31cdf8bfda22fe265c1a176d0e33d311c82a7f7 This change fixes several problems with the support for the acpi_exec namespace init file (-fi option). Specifically, it fixes AE_ALREADY_EXISTS errors, as well as various seg faults. Link: https://github.com/acpica/acpica/commit/f31cdf8b Link: https://github.com/acpica/acpica/commit/6803997e Signed-off-by: Bob Moore Signed-off-by: Erik Kaneda Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: Update Tiger Lake ACPI device IDs

2020-04-23T08:38:15+00:00

[ Upstream commit b62c770fee699a137359e1f1da9bf14a7f348567 ] Tiger Lake's new unique ACPI device IDs for DPTF and fan drivers are not valid as the IDs are missing 'C'. Fix the IDs by updating them. After the update, the new IDs should now look like INT1047 --> INTC1047 INT1040 --> INTC1040 INT1043 --> INTC1043 INT1044 --> INTC1044 Fixes: 55cfe6a5c582 ("ACPI: DPTF: Add Tiger Lake ACPI device IDs") Fixes: c248dfe7e0ca ("ACPI: fan: Add Tiger Lake ACPI device ID") Suggested-by: Srinivas Pandruvada Signed-off-by: Gayatri Kammela Reviewed-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

x86: ACPI: fix CPU hotplug deadlock

2020-04-23T08:38:14+00:00

[ Upstream commit 696ac2e3bf267f5a2b2ed7d34e64131f2287d0ad ] Similar to commit 0266d81e9bf5 ("acpi/processor: Prevent cpu hotplug deadlock") except this is for acpi_processor_ffh_cstate_probe(): "The problem is that the work is scheduled on the current CPU from the hotplug thread associated with that CPU. It's not required to invoke these functions via the workqueue because the hotplug thread runs on the target CPU already. Check whether current is a per cpu thread pinned on the target CPU and invoke the function directly to avoid the workqueue." WARNING: possible circular locking dependency detected ------------------------------------------------------ cpuhp/1/15 is trying to acquire lock: ffffc90003447a28 ((work_completion)(&wfc.work)){+.+.}-{0:0}, at: __flush_work+0x4c6/0x630 but task is already holding lock: ffffffffafa1c0e8 (cpuidle_lock){+.+.}-{3:3}, at: cpuidle_pause_and_lock+0x17/0x20 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x3e/0xc0 irq_calc_affinity_vectors+0x5f/0x91 __pci_enable_msix_range+0x10f/0x9a0 pci_alloc_irq_vectors_affinity+0x13e/0x1f0 pci_alloc_irq_vectors_affinity at drivers/pci/msi.c:1208 pqi_ctrl_init+0x72f/0x1618 [smartpqi] pqi_pci_probe.cold.63+0x882/0x892 [smartpqi] local_pci_probe+0x7a/0xc0 work_for_cpu_fn+0x2e/0x50 process_one_work+0x57e/0xb90 worker_thread+0x363/0x5b0 kthread+0x1f4/0x220 ret_from_fork+0x27/0x50 -> #0 ((work_completion)(&wfc.work)){+.+.}-{0:0}: __lock_acquire+0x2244/0x32a0 lock_acquire+0x1a2/0x680 __flush_work+0x4e6/0x630 work_on_cpu+0x114/0x160 acpi_processor_ffh_cstate_probe+0x129/0x250 acpi_processor_evaluate_cst+0x4c8/0x580 acpi_processor_get_power_info+0x86/0x740 acpi_processor_hotplug+0xc3/0x140 acpi_soft_cpu_online+0x102/0x1d0 cpuhp_invoke_callback+0x197/0x1120 cpuhp_thread_fun+0x252/0x2f0 smpboot_thread_fn+0x255/0x440 kthread+0x1f4/0x220 ret_from_fork+0x27/0x50 other info that might help us debug this: Chain exists of: (work_completion)(&wfc.work) --> cpuhp_state-up --> cpuidle_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(cpuidle_lock); lock(cpuhp_state-up); lock(cpuidle_lock); lock((work_completion)(&wfc.work)); *** DEADLOCK *** 3 locks held by cpuhp/1/15: #0: ffffffffaf51ab10 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x69/0x2f0 #1: ffffffffaf51ad40 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x69/0x2f0 #2: ffffffffafa1c0e8 (cpuidle_lock){+.+.}-{3:3}, at: cpuidle_pause_and_lock+0x17/0x20 Call Trace: dump_stack+0xa0/0xea print_circular_bug.cold.52+0x147/0x14c check_noncircular+0x295/0x2d0 __lock_acquire+0x2244/0x32a0 lock_acquire+0x1a2/0x680 __flush_work+0x4e6/0x630 work_on_cpu+0x114/0x160 acpi_processor_ffh_cstate_probe+0x129/0x250 acpi_processor_evaluate_cst+0x4c8/0x580 acpi_processor_get_power_info+0x86/0x740 acpi_processor_hotplug+0xc3/0x140 acpi_soft_cpu_online+0x102/0x1d0 cpuhp_invoke_callback+0x197/0x1120 cpuhp_thread_fun+0x252/0x2f0 smpboot_thread_fn+0x255/0x440 kthread+0x1f4/0x220 ret_from_fork+0x27/0x50 Signed-off-by: Qian Cai Tested-by: Borislav Petkov [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

acpi/nfit: improve bounds checking for 'func'

2020-04-21T07:08:01+00:00

commit 01091c496f920e634ea84b689f480c39016752a8 upstream. The 'func' variable can come from the user in the __nd_ioctl(). If it's too high then the (1 << func) shift in acpi_nfit_clear_to_send() is undefined. In acpi_nfit_ctl() we pass 'func' to test_bit(func, &dsm_mask) which could result in an out of bounds access. To fix these issues, I introduced the NVDIMM_CMD_MAX (31) define and updated nfit_dsm_revid() to use that define as well instead of magic numbers. Fixes: 11189c1089da ("acpi/nfit: Fix command-supported detection") Signed-off-by: Dan Carpenter Reviewed-by: Dan Williams Link: https://lore.kernel.org/r/20200225161927.hvftuq7kjn547fyj@kili.mountain Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman

Revert "ACPI: EC: Do not clear boot_ec_is_ecdt in acpi_ec_add()"

2020-04-21T07:07:59+00:00

This reverts commit 281e612b4b9587c0c72e30c49ec279587b20da0f which is commit 65a691f5f8f0bb63d6a82eec7b0ffd193d8d8a5f upstream. Rafael writes: It has not been marked for -stable or otherwise requested to be included AFAICS. Also it depends on other mainline commits that have not been included into 5.6.5. Reported-by: Toralf Förster Reported-by: Rafael J. Wysocki Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ACPI: PM: s2idle: Refine active GPEs check

2020-04-17T14:13:27+00:00

commit d5406284ff803a578ca503373624312770319054 upstream. 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 Tested-by: Ondřej Caletka Cc: 5.4+ # 5.4+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman