From 22110faf8c8e980013790e6a5214de32b3303730 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Tue, 26 Apr 2011 11:33:09 +0200 Subject: [PATCH 1/2] PM / Wakeup: Fix initialization of wakeup-related device sysfs files It turns out that some PCI devices are only found to be wakeup-capable during registration, in which case, when device_set_wakeup_capable() is called, device_is_registered() already returns 'true' for the given device, but dpm_sysfs_add() hasn't been called for it yet. This leads to situations in which the device's power.can_wakeup flag is not set as requested because of failing wakeup_sysfs_add() and its wakeup-related sysfs files are not created, although they should be present. This is a post-2.6.38 regression introduced by commit cb8f51bdadb7969139c2e39c2defd4cde98c1 (PM: Do not create wakeup sysfs files for devices that cannot wake up). To work around this problem initialize the device's power.entry field to an empty list head and make device_set_wakeup_capable() check if it is still empty before attempting to add the devices wakeup-related sysfs files with wakeup_sysfs_add(). Namely, if power.entry is still empty at this point, device_pm_add() hasn't been called yet for the device and its wakeup-related files will be created later, so device_set_wakeup_capable() doesn't have to create them. Reported-and-tested-by: Tino Keitel Signed-off-by: Rafael J. Wysocki Acked-by: Greg Kroah-Hartman --- drivers/base/power/main.c | 1 + drivers/base/power/wakeup.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index fbc5b6e7c591..abe3ab709e87 100644 --- a/drivers/base/power/main.c +++ b/drivers/base/power/main.c @@ -63,6 +63,7 @@ void device_pm_init(struct device *dev) dev->power.wakeup = NULL; spin_lock_init(&dev->power.lock); pm_runtime_init(dev); + INIT_LIST_HEAD(&dev->power.entry); } /** diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c index 4573c83df6dd..abbbd33e8d8a 100644 --- a/drivers/base/power/wakeup.c +++ b/drivers/base/power/wakeup.c @@ -258,7 +258,7 @@ void device_set_wakeup_capable(struct device *dev, bool capable) if (!!dev->power.can_wakeup == !!capable) return; - if (device_is_registered(dev)) { + if (device_is_registered(dev) && !list_empty(&dev->power.entry)) { if (capable) { if (wakeup_sysfs_add(dev)) return; From 7bed50c5edf5cba8dd515a31191cbfb6065ddc85 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Tue, 26 Apr 2011 11:33:18 +0200 Subject: [PATCH 2/2] ACPI / PM: Avoid infinite recurrence while registering power resources There is at least one BIOS with a DSDT containing a power resource object with a _PR0 entry pointing back to that power resource. In consequence, while registering that power resource acpi_bus_get_power_flags() sees that it depends on itself and tries to register it again, which leads to an infinitely deep recurrence. This problem was introduced by commit bf325f9538d8c89312be305b9779e (ACPI / PM: Register power resource devices as soon as they are needed). To fix this problem use the observation that power resources cannot be power manageable and prevent acpi_bus_get_power_flags() from being called for power resource objects. References: https://bugzilla.kernel.org/show_bug.cgi?id=31872 Reported-and-tested-by: Pascal Dormeau Signed-off-by: Rafael J. Wysocki Acked-by: Len Brown Cc: stable@kernel.org --- drivers/acpi/scan.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index b136c9c1e531..449c556274c0 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -943,6 +943,10 @@ static int acpi_bus_get_flags(struct acpi_device *device) if (ACPI_SUCCESS(status)) device->flags.lockable = 1; + /* Power resources cannot be power manageable. */ + if (device->device_type == ACPI_BUS_TYPE_POWER) + return 0; + /* Presence of _PS0|_PR0 indicates 'power manageable' */ status = acpi_get_handle(device->handle, "_PS0", &temp); if (ACPI_FAILURE(status))