Re: [PATCH] ACPI: do not fail suspend if unable to configure wakeup

[Rafael J. Wysocki]

On Tuesday, November 18, 2014 04:14:49 PM Dmitry Torokhov wrote:
> On Tue, Nov 18, 2014 at 4:20 PM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote:
> > It goes again below with a changelog, but since technically it is a regression
> > fix, I'd like to push it for "stable" too.  I suppose that the commit that
> > things stopped working after is a76e9bd89ae7 (i2c: attach/detach I2C client
> > device to the ACPI power domain).  Is that correct?
> 
> Yes.

OK

> > --
> > From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> > Subject: ACPI / PM: Ignore wakeup setting if the ACPI companion can't wake up
> >
> > 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
> > rather than by standard ACPI means.
> 
> I think they are using standard ACPI wakeup methods, but in a very perverted
> way: there is "shadow" ACPI sleep button corresponding to the GPIO assigned
> to the trackpad or touchscreen; it is just not tied to touchpad/touchscreen
> device in DSDT.

OK

This:

---
From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
Subject: ACPI / PM: Ignore wakeup setting if the ACPI companion can't wake up

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 <dtor@xxxxxxxxxxxx>
Cc: 3.13+ <stable@xxxxxxxxxxxxxxx>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
---
 drivers/acpi/device_pm.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-pm/drivers/acpi/device_pm.c
===================================================================
--- linux-pm.orig/drivers/acpi/device_pm.c
+++ linux-pm/drivers/acpi/device_pm.c
@@ -878,7 +878,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;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/