kernel/git/stable/linux.git/drivers/acpi/power.c, branch linux-3.8.y

ACPI / power: Remove useless message from device registering routine

2013-01-03T12:10:22+00:00

After commit 71fbad6 (PCI/ACPI: Notify PCI devices when their power resource is turned on) made acpi_pci_bind() call acpi_power_resource_register_device(), the debug message at the end of the latter appears in the kernel log for every PCI device that doesn't happen to have power resources assigned (which is the vast majority of them). However, this message is totally useless, because it doesn't even say which device it is about. Moreover, it is misleading, because it only means that the given device has no power resources, which isn't exceptional at all. Remove that useless message altogether and simplify acpi_power_resource_register_device() slightly. Signed-off-by: Rafael J. Wysocki

ACPI: add newline in power.c message

2012-11-14T23:18:21+00:00

Add newline to printk so that the message is on a line by itself and not merged with something unrelated to it. Reported-by: Toralf Förster Signed-off-by: Randy Dunlap Signed-off-by: Rafael J. Wysocki

ACPI / PM: Use KERN_DEBUG when no power resources are found

2012-09-14T18:54:44+00:00

commit a606dac368eed5696fb38e16b1394f1d049c09e9 adds support to link devices which have _PRx, if a device does not have _PRx, a warning message will be printed. This commit is for ZPODD on Intel ZPODD capable platforms, on other platforms, it has no problem if there is no power resource for this device, so a warning here is not appropriate, change it to debug. Reported-by: Borislav Petkov Signed-off-by: Aaron Lu Cc: stable@vger.kernel.org Signed-off-by: Rafael J. Wysocki

ACPI / PM: Fix resource_lock dead lock in acpi_power_on_device

2012-09-13T22:26:33+00:00

Commit 0090def("ACPI: Add interface to register/unregister device to/from power resources") used resource_lock to protect the devices list that relies on power resource. It caused a mutex dead lock, as below acpi_power_on ---> lock resource_lock __acpi_power_on acpi_power_on_device acpi_power_get_inferred_state acpi_power_get_list_state ---> lock resource_lock This patch adds a new mutex "devices_lock" to protect the devices list and calls acpi_power_on_device in acpi_power_on, instead of __acpi_power_on, after the resource_lock is released. [rjw: Changed data type of a boolean variable to bool.] Signed-off-by: Lin Ming Signed-off-by: Aaron Lu Cc: stable@vger.kernel.org Signed-off-by: Rafael J. Wysocki

ACPI / PM: Fix unused function warnings for CONFIG_PM_SLEEP

2012-08-10T11:35:32+00:00

According to compiler warnings, several suspend/resume functions in ACPI drivers are not used for CONFIG_PM_SLEEP unset, so add #ifdefs to prevent them from being built in that case. Signed-off-by: Rafael J. Wysocki

Merge branch 'master' [vanilla Linus master] into libata-dev.git/upstream

2012-07-25T19:58:48+00:00

Two bits were appended to the end of the bitfield list in struct scsi_device. Resolve that conflict by including both bits. Conflicts: include/scsi/scsi_device.h

ACPI: Use struct dev_pm_ops for power management in the power driver

2012-07-01T11:31:01+00:00

Make the ACPI power resource driver define its PM callbacks through a struct dev_pm_ops object rather than by using legacy PM hooks in struct acpi_device_ops. Signed-off-by: Rafael J. Wysocki

libata-acpi: register/unregister device to/from power resource

2012-06-29T15:38:15+00:00

Signed-off-by: Lin Ming Signed-off-by: Jeff Garzik

ACPI / PM: Make __acpi_bus_get_power() cover D3cold correctly

2012-05-29T19:20:24+00:00

After recent changes of the ACPI device power states definitions, if power resources are not used for the device's power management, the state returned by __acpi_bus_get_power() cannot exceed D3hot, because the return values of _PSC are 0 through 3. However, if the _PR3 method is not present for the device and _PS3 returns 3, we have to assume that the device is in D3cold, so the value returned by __acpi_bus_get_power() in that case should be 4. Similarly, acpi_power_get_inferred_state() should take the power resources for the D3hot state into account in general, so that it can return 3 if those resources are "on" or 4 (D3cold) otherwise. Fix the the above two issues and make sure that if both _PSC and _PR3 are present for the device, the power resources listed by _PR3 will be used to determine if the number 3 returned by _PSC is meant to represent D3cold or D3hot. Signed-off-by: Rafael J. Wysocki

ACPI / PCI / PM: Fix device PM regression related to D3hot/D3cold

2012-05-17T23:16:16+00:00

Commit 1cc0c998fdf2 ("ACPI: Fix D3hot v D3cold confusion") introduced a bug in __acpi_bus_set_power() and changed the behavior of acpi_pci_set_power_state() in such a way that it generally doesn't work as expected if PCI_D3hot is passed to it as the second argument. First off, if ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) is passed to __acpi_bus_set_power() and the explicit_set flag is set for the D3cold state, the function will try to execute AML method called "_PS4", which doesn't exist. Fix this by adding a check to ensure that the name of the AML method to execute for transitions to ACPI_STATE_D3_COLD is correct in __acpi_bus_set_power(). Also make sure that the explicit_set flag for ACPI_STATE_D3_COLD will be set if _PS3 is present and modify acpi_power_transition() to avoid accessing power resources for ACPI_STATE_D3_COLD, because they don't exist. Second, if PCI_D3hot is passed to acpi_pci_set_power_state() as the target state, the function will request a transition to ACPI_STATE_D3_HOT instead of ACPI_STATE_D3. However, ACPI_STATE_D3_HOT is now only marked as supported if the _PR3 AML method is defined for the given device, which is rare. This causes problems to happen on systems where devices were successfully put into ACPI D3 by pci_set_power_state(PCI_D3hot) which doesn't work now. In particular, some unused graphics adapters are not turned off as a result. To fix this issue restore the old behavior of acpi_pci_set_power_state(), which is to request a transition to ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) if either PCI_D3hot or PCI_D3cold is passed to it as the argument. This approach is not ideal, because generally power should not be removed from devices if PCI_D3hot is the target power state, but since this behavior is relied on, we have no choice but to restore it at the moment and spend more time on designing a better solution in the future. References: https://bugzilla.kernel.org/show_bug.cgi?id=43228 Reported-by: rocko Reported-by: Cristian Rodríguez Reported-and-tested-by: Peter Signed-off-by: Rafael J. Wysocki Signed-off-by: Linus Torvalds