kernel.git/drivers/acpi/device_pm.c, branch linux-3.17.y

ACPI / PM: Ignore wakeup setting if the ACPI companion can't wake up

2014-12-06T23:57:28Z

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 Reviewed-by: Dmitry Torokhov Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI: invoke acpi_device_wakeup() with correct parameters

2014-11-14T18:10:32Z

commit 67598a1d3140a66f57aa6bcb8d22c4c2b7e910f5 upstream. Fix a bug that invokes acpi_device_wakeup() with wrong parameters. Fixes: f35cec255557 (ACPI / PM: Always enable wakeup GPEs when enabling device wakeup) Signed-off-by: Zhang Rui Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI / PM: Use ACPI_COMPANION() instead of ACPI_HANDLE()

2014-07-22T23:01:41Z

The ACPI_HANDLE() macro evaluates ACPI_COMPANION() internally to return the handle of the device's ACPI companion, so it is much more straightforward and efficient to use ACPI_COMPANION() directly to obtain the device's ACPI companion object instead of using ACPI_HANDLE() and acpi_bus_get_device() on the returned handle for the same thing. Do that in three places in the ACPI device PM code. Signed-off-by: Rafael J. Wysocki

ACPI / PM: Always enable wakeup GPEs when enabling device wakeup

2014-07-22T23:00:53Z

Wakeup GPEs are currently only enabled when setting up devices for remote wakeup at run time. During system-wide transitions they are enabled by ACPICA at the very last stage of suspend (before asking the BIOS to take over). Of course, that only works for system sleep states supported by ACPI, so in particular it doesn't work for the "freeze" sleep state. For this reason, modify the ACPI core device PM code to enable wakeup GPEs for devices when setting them up for wakeup regardless of whether that is remote wakeup at runtime or system wakeup. That allows the same device wakeup setup routine to be used for both runtime PM and system-wide PM and makes it possible to reduce code size quite a bit. This make ACPI-based PCI Wake-on-LAN work with the "freeze" sleep state on my venerable Toshiba Portege R500 and should help other systems too. Signed-off-by: Rafael J. Wysocki

ACPI / PM: Revork the handling of ACPI device wakeup notifications

2014-07-22T23:00:45Z

Since ACPI wakeup GPEs are going to be enabled during system suspend as well as for runtime wakeup by a subsequent patch and the same notify handlers will be used in both cases, rework the ACPI device wakeup notification framework so that the part specific to physical devices is always run asynchronously from the PM workqueue. This prevents runtime resume callbacks for those devices from being run during system suspend and resume which may not be appropriate, among other things. Also make ACPI device wakeup notification handling a bit more robust agaist subsequent removal of ACPI device objects, whould that ever happen, and create a wakeup source object for each ACPI device configured for wakeup so that wakeup notifications for those devices can wake up the system from the "freeze" sleep state. Signed-off-by: Rafael J. Wysocki

ACPI / PM: Export rest of the subsys PM callbacks

2014-05-20T11:23:07Z

No reason for excluding the remaining ones. Signed-off-by: Heikki Krogerus [rjw: Rebased and exported the new acpi_subsys_complete() too.] Signed-off-by: Rafael J. Wysocki

ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspend

2014-05-20T11:22:48Z

Rework the ACPI PM domain's PM callbacks to avoid resuming devices during system suspend (in order to modify their wakeup settings etc.) if that isn't necessary. Signed-off-by: Rafael J. Wysocki

ACPI / PM: Resume runtime-suspended devices later during system suspend

2014-03-03T23:17:48Z

Runtime-suspended devices are resumed during system suspend by acpi_subsys_prepare() for two reasons: First, because they may need to be reprogrammed in order to change their wakeup settings and, second, because they may need to be operatonal for their children to be successfully suspended. That is a problem, though, if there are many runtime-suspended devices that need to be resumed this way during system suspend, because the .prepare() PM callbacks of devices are executed sequentially and the times taken by them accumulate, which may increase the total system suspend time quite a bit. For this reason, move the resume of runtime-suspended devices up to the next phase of device suspend (during system suspend), except for the ones that have power.ignore_children set. The exception is made, because the devices with power.ignore_children set may still be necessary for their children to be successfully suspended (during system suspend) and they won't be resumed automatically as a result of the runtime resume of their children. Signed-off-by: Rafael J. Wysocki

Merge branches 'acpi-processor', 'acpi-hotplug', 'acpi-init', 'acpi-pm' and 'acpica'

2014-01-29T10:47:18Z

* acpi-processor: ACPI / scan: reduce log level of "ACPI: \_PR_.CPU4: failed to get CPU APIC ID" ACPI / processor: Return specific error value when mapping lapic id * acpi-hotplug: ACPI / scan: Clear match_driver flag in acpi_bus_trim() * acpi-init: ACPI / init: Flag use of ACPI and ACPI idioms for power supplies to regulator API * acpi-pm: ACPI / PM: Use ACPI_COMPANION() to get ACPI companions of devices * acpica: ACPICA: Remove bool usage from ACPICA.

ACPI / PM: Use ACPI_COMPANION() to get ACPI companions of devices

2014-01-27T22:10:24Z

The ACPI device PM code in device_pm.c uses a special function, acpi_dev_pm_get_node(), to obtain an ACPI companion object of a given device. However, that is not necessary any more after recent changes that introduced the ACPI_COMPANION() macro serving exactly the same purpose, but working in a much more straightforward way. For this reason, drop acpi_dev_pm_get_node() and use ACPI_COMPANION() instead of it everywhere. Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg