summaryrefslogtreecommitdiff
path: root/drivers/acpi/bus.c
diff options
context:
space:
mode:
authorRafael J. Wysocki <rjw@sisk.pl>2012-09-14 02:26:24 +0400
committerRafael J. Wysocki <rjw@sisk.pl>2012-09-14 02:26:24 +0400
commit8f7412a792bc989d1bddd3c802282eec09456d57 (patch)
treec306704c43a01132f7204baed513ee29d70f8c92 /drivers/acpi/bus.c
parent55d512e245bc7699a8800e23df1a24195dd08217 (diff)
downloadlinux-8f7412a792bc989d1bddd3c802282eec09456d57.tar.xz
ACPI / PM: Infer parent power state from child if unknown, v2
It turns out that there are ACPI BIOSes defining device objects with _PSx and without either _PSC or _PRx. For devices corresponding to those ACPI objetcs __acpi_bus_get_power() returns ACPI_STATE_UNKNOWN and their initial power states are regarded as unknown as a result. If such a device is a parent of another power-manageable device, the child cannot be put into a low-power state through ACPI, because __acpi_bus_set_power() refuses to change power states of devices whose parents' power states are unknown. To work around this problem, observe that the ACPI power state of a device cannot be higher-power (lower-number) than the power state of its parent. Thus, if the device's _PSC method or the configuration of its power resources indicates that the device is in D0, the device's parent has to be in D0 as well. Consequently, if the parent's power state is unknown when we've just learned that its child's power state is D0, we can safely set the parent's power.state field to ACPI_STATE_D0. Tested-by: Aaron Lu <aaron.lu@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Diffstat (limited to 'drivers/acpi/bus.c')
-rw-r--r--drivers/acpi/bus.c10
1 files changed, 10 insertions, 0 deletions
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 9628652e080c..e0596954290b 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -237,6 +237,16 @@ static int __acpi_bus_get_power(struct acpi_device *device, int *state)
} else if (result == ACPI_STATE_D3_HOT) {
result = ACPI_STATE_D3;
}
+
+ /*
+ * If we were unsure about the device parent's power state up to this
+ * point, the fact that the device is in D0 implies that the parent has
+ * to be in D0 too.
+ */
+ if (device->parent && device->parent->power.state == ACPI_STATE_UNKNOWN
+ && result == ACPI_STATE_D0)
+ device->parent->power.state = ACPI_STATE_D0;
+
*state = result;
out: