This is a note to let you know that I've just added the patch titled
ACPI / PM: Ignore wakeup setting if the ACPI companion can't wake up
to the 3.17-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
acpi-pm-ignore-wakeup-setting-if-the-acpi-companion-can-t-wake-up.patch
and it can be found in the queue-3.17 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.
>From 78579b7c7eb45f0e7ec5e9437087ed21749f9a9c Mon Sep 17 00:00:00 2001
From: "Rafael J. Wysocki" <[email protected]>
Date: Wed, 19 Nov 2014 01:44:11 +0100
Subject: ACPI / PM: Ignore wakeup setting if the ACPI companion can't wake up
From: "Rafael J. Wysocki" <[email protected]>
commit 78579b7c7eb45f0e7ec5e9437087ed21749f9a9c upstream.
As reported by Dmitry, on some Chromebooks there are devices with
corresponding ACPI objects and with unusual system wakeup
configuration. Namely, they technically are wakeup-capable, but the
wakeup is handled via a platform-specific out-of-band mechanism and
the ACPI PM layer has no information on the wakeup capability. As
a result, device_may_wakeup(dev) called from acpi_dev_suspend_late()
returns 'true' for those devices, but the wakeup.flags.valid flag is
unset for the corresponding ACPI device objects, so acpi_device_wakeup()
reproducibly fails for them causing acpi_dev_suspend_late() to return
an error code. The entire system suspend is then aborted and the
machines in question cannot suspend at all.
Address the problem by ignoring the device_may_wakeup(dev) return
value in acpi_dev_suspend_late() if the ACPI companion of the device
being handled has wakeup.flags.valid unset (in which case it is clear
that the wakeup is supposed to be handled by other means).
This fixes a regression introduced by commit a76e9bd89ae7 (i2c:
attach/detach I2C client device to the ACPI power domain) as the
affected systems could suspend and resume successfully before that
commit.
Fixes: a76e9bd89ae7 (i2c: attach/detach I2C client device to the ACPI power
domain)
Reported-by: Dmitry Torokhov <[email protected]>
Reviewed-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/acpi/device_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -877,7 +877,7 @@ int acpi_dev_suspend_late(struct device
return 0;
target_state = acpi_target_system_state();
- wakeup = device_may_wakeup(dev);
+ wakeup = device_may_wakeup(dev) && acpi_device_can_wakeup(adev);
error = acpi_device_wakeup(adev, target_state, wakeup);
if (wakeup && error)
return error;
Patches currently in stable-queue which might be from
[email protected] are
queue-3.17/acpi-pm-ignore-wakeup-setting-if-the-acpi-companion-can-t-wake-up.patch
queue-3.17/acpi-ec-add-support-to-disallow-qr_ec-to-be-issued-before-completing-previous-qr_ec.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
