summaryrefslogtreecommitdiff
path: root/drivers/acpi/device_pm.c
AgeCommit message (Collapse)Author
2013-10-17ACPI / PM: Drop two functions that are not used any moreRafael J. Wysocki
Two functions defined in device_pm.c, acpi_dev_pm_add_dependent() and acpi_dev_pm_remove_dependent(), have no callers and may be dropped, so drop them. Moreover, they are the only functions adding entries to and removing entries from the power_dependent list in struct acpi_device, so drop that list too. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-08-03ACPI / PM: Add state information to error message in acpi_device_set_power()Aaron Lu
The state information can be useful to know what the problem is when an error message about a device can not being set to a higher power state than its parent appeared, so this patch adds such state information for both the target state of the device and the current state of its parent. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-31ACPI / PM: Remove redundant power manageable check from acpi_bus_set_power()Aaron Lu
Now that acpi_device_set_power() checks whether or not the given device is power manageable, it is not necessary to do this check in acpi_bus_set_power() any more, so remove it. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-30ACPI / PM: Make messages in acpi_device_set_power() print device namesRafael J. Wysocki
Modify acpi_device_set_power() so that diagnostic messages printed by it to the kernel log always contain the name of the device concerned to make it possible to identify the device that triggered the message if need be. Also replace printk(KERN_WARNING ) with dev_warn() everywhere in that function. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com>
2013-07-30ACPI / PM: Only set power states of devices that are power manageableRafael J. Wysocki
Make acpi_device_set_power() check if the given device is power manageable before checking if the given power state is valid for that device. Otherwise it will print that "Device does not support" that power state into the kernel log, which may not make sense for some power states (D0 and D3cold are supported by all devices by definition). Tested-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-04ACPI / PM: Fix corner case in acpi_bus_update_power()Rafael J. Wysocki
The role of acpi_bus_update_power() is to update the given ACPI device object's power.state field to reflect the current physical state of the device (as inferred from the configuration of power resources and _PSC, if available). For this purpose it calls acpi_device_set_power() that should update the power resources' reference counters and set power.state as appropriate. However, that doesn't work if the "new" state is D1, D2 or D3hot and the the current value of power.state means D3cold, because in that case acpi_device_set_power() will refuse to transition the device from D3cold to non-D0. To address this problem, make acpi_bus_update_power() call acpi_power_transition() directly to update the power resources' reference counters and only use acpi_device_set_power() to put the device into D0 if the current physical state of it cannot be determined. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 3.9+ <stable@vger.kernel.org>
2013-06-29Merge branch 'acpi-pm'Rafael J. Wysocki
* acpi-pm: ACPI / PM: Fix possible NULL pointer deref in acpi_pm_device_sleep_state()
2013-06-28Merge branch 'pm-assorted'Rafael J. Wysocki
* pm-assorted: PM / QoS: Add pm_qos and dev_pm_qos to events-power.txt PM / QoS: Add dev_pm_qos_request tracepoints PM / QoS: Add pm_qos_request tracepoints PM / QoS: Add pm_qos_update_target/flags tracepoints PM / QoS: Update Documentation/power/pm_qos_interface.txt PM / Sleep: Print last wakeup source on failed wakeup_count write PM / QoS: correct the valid range of pm_qos_class PM / wakeup: Adjust messaging for wake events during suspend PM / Runtime: Update .runtime_idle() callback documentation PM / Runtime: Rework the "runtime idle" helper routine PM / Hibernate: print physical addresses consistently with other parts of kernel
2013-06-28Merge branch 'acpi-pm'Rafael J. Wysocki
* acpi-pm: ACPI / PM: Rework and clean up acpi_dev_pm_get_state() ACPI / PM: Replace ACPI_STATE_D3 with ACPI_STATE_D3_COLD in device_pm.c ACPI / PM: Rename function acpi_device_power_state() and make it static ACPI / PM: acpi_processor_suspend() can be static xen / ACPI / sleep: Register an acpi_suspend_lowlevel callback. x86 / ACPI / sleep: Provide registration for acpi_suspend_lowlevel.
2013-06-28ACPI / PM: Fix possible NULL pointer deref in acpi_pm_device_sleep_state()Rafael J. Wysocki
After commit fa1675b (ACPI / PM: Rework and clean up acpi_dev_pm_get_state()) a NULL pointer dereference will take place if NULL is passed to acpi_pm_device_sleep_state() as the second argument. Fix that by avoiding to use the pointer that may be NULL until it's necessary to store a return value at the location pointed to by it (if not NULL). Reported-and-tested-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-19ACPI / LPSS: Power up LPSS devices during enumerationRafael J. Wysocki
Commit 7cd8407 (ACPI / PM: Do not execute _PS0 for devices without _PSC during initialization) introduced a regression on some systems with Intel Lynxpoint Low-Power Subsystem (LPSS) where some devices need to be powered up during initialization, but their device objects in the ACPI namespace have _PS0 and _PS3 only (without _PSC or power resources). To work around this problem, make the ACPI LPSS driver power up devices it knows about by using a new helper function acpi_device_fix_up_power() that does all of the necessary sanity checks and calls acpi_dev_pm_explicit_set() to put the device into D0. Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-19ACPI / PM: Rework and clean up acpi_dev_pm_get_state()Rafael J. Wysocki
The acpi_dev_pm_get_state() function defined in device_pm.c is quite convoluted, which isn't really necessary, and it doesn't validate the values returned by the ACPI methods executed by it appropriately. To address these shortcomings modify it in the following way. (1) Make its return value only mean whether or not it succeeded and pass the device power states determined by it through pointers. (2) Drop the d_max_in argument, used by only one of its callers, from it, and move the code related to d_max_in into that caller, acpi_pm_device_sleep_state(). (3) Make it always check the return value of acpi_evaluate_integer() and handle failures as appropriate. Moreover, make it check if the values returned by the executed ACPI methods are not out of range. (4) Make it check if the values returned by the executed ACPI methods represent valid power states of the given device and handle situations in which that's not the case gracefully. Also update the kerneldoc comments of acpi_dev_pm_get_state() and acpi_pm_device_sleep_state() to reflect the code changes. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-19ACPI / PM: Replace ACPI_STATE_D3 with ACPI_STATE_D3_COLD in device_pm.cRafael J. Wysocki
The two symbols ACPI_STATE_D3 and ACPI_STATE_D3_COLD actually represent the same number (4), but ACPI_STATE_D3 is slightly ambigugous, because it may not be clear that it really means D3cold and not D3hot at first sight. Remove that ambiguity from drivers/acpi/device_pm.c by making it use ACPI_STATE_D3_COLD everywhere instead of ACPI_STATE_D3. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-19ACPI / PM: Rename function acpi_device_power_state() and make it staticRafael J. Wysocki
There is a name clash between function acpi_device_power_state() defined in drivers/acpi/device_pm.c and structure type acpi_device_power_state defined in include/acpi/acpi_bus.h, which may be resolved by renaming the function. Additionally, that funtion may be made static, because it is not used anywhere outside of the file it is defined in. Rename acpi_device_power_state() to acpi_dev_pm_get_state(), which better reflects its purpose, and make it static. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-07ACPI / PM: Do not execute _PS0 for devices without _PSC during initializationRafael J. Wysocki
Commit b378549 (ACPI / PM: Do not power manage devices in unknown initial states) added code to force devices without _PSC, but having _PS0 defined in the ACPI namespace, into ACPI power state D0 by executing _PS0 for them. That turned out to break Toshiba P870-303, however, so revert that code. References: https://bugzilla.kernel.org/show_bug.cgi?id=58201 Reported-and-tested-by: Jerome Cantenot <jerome.cantenot@gmail.com> Tracked-down-by: Lan Tianyu <tianyu.lan@intel.com> Cc: 3.9+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-03PM / Runtime: Rework the "runtime idle" helper routineRafael J. Wysocki
The "runtime idle" helper routine, rpm_idle(), currently ignores return values from .runtime_idle() callbacks executed by it. However, it turns out that many subsystems use pm_generic_runtime_idle() which checks the return value of the driver's callback and executes pm_runtime_suspend() for the device unless that value is not 0. If that logic is moved to rpm_idle() instead, pm_generic_runtime_idle() can be dropped and its users will not need any .runtime_idle() callbacks any more. Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle() routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and ata_port_runtime_idle(), respectively, as well as a few drivers' ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has been returned by the .runtime_idle() callback executed by it. To reduce overall code bloat, make the changes described above. Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Kevin Hilman <khilman@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Alan Stern <stern@rowland.harvard.edu>
2013-05-21ACPI / PM: Allow device power states to be used for CONFIG_PM unsetRafael J. Wysocki
Currently, drivers/acpi/device_pm.c depends on CONFIG_PM and all of the functions defined in there are replaced with static inline stubs if that option is unset. However, CONFIG_PM means, roughly, "runtime PM or suspend/hibernation support" and some of those functions are useful regardless of that. For example, they are used by the ACPI fan driver for controlling fans and acpi_device_set_power() is called during device removal. Moreover, device initialization may depend on setting device power states properly. For these reasons, make the routines manipulating ACPI device power states defined in drivers/acpi/device_pm.c available for CONFIG_PM unset too. Reported-by: Zhang Rui <rui.zhang@intel.com> Reported-and-tested-by: Michel Lespinasse <walken@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 3.9+ <stable@vger.kernel.org>
2013-03-25ACPI / PM: Fix potential problem in acpi_device_get_power()Rafael J. Wysocki
Theoretically, in some situations acpi_device_get_power() may return an incorrect result, because the settings of the power resources depended on by the device may indicate a power state shallower than the actual power state of the device. Say that two devices, A and B, depend on two power resources, X and Y, in such a way that _PR0 for both A and B list both X and Y and _PR3 for both A and B list power resource Y alone. Also suppose that _PS0 and _PS3 are present for both A and B. Then, if devices A and B are initially in D0, power resources X and Y are initially "on" and their reference counters are equal to 2. To put device A into power state D3hot the kernel will decrement the reference counter of power resource X, but that power resource won't be turned off, because it is still in use by device B (its reference counter is equal to 1). Next, _PS3 will be executed for device A. Afterward the configuration of the power resources will indicate that device A is in power state D0 (both X and Y are "on"), but in fact it is in D3hot (because _PS3 has been executed for it). In that situation, if acpi_device_get_power() is called to get the power state of device A, it will first execute _PSC for it which should return 3. That will cause acpi_device_get_power() to run acpi_power_get_inferred_state() for device A and the resultant power state will be D0, which is incorrect. To fix that change acpi_device_get_power() to first execute acpi_power_get_inferred_state() for the given device (if it depends on power resources) and to evaluate _PSC for it subsequently, so that the result inferred from the power resources configuration can be amended by the _PSC return value. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com>
2013-02-03ACPI / PM: Handle missing _PSC in acpi_bus_update_power()Rafael J. Wysocki
If _PS0 is defined for an ACPI device node, but _PSC isn't and the device node doesn't use power resources for power management, acpi_bus_update_power() will fail to update the power state of it, because acpi_device_get_power() returns ACPI_STATE_UNKNOWN in that case. To handle that situation make acpi_bus_update_power() follow acpi_bus_init_power() and try to force the given device node into power state D0. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-02-01ACPI / PM: Do not power manage devices in unknown initial statesRafael J. Wysocki
In general, for ACPI device power management to work, the initial power states of devices must be known (otherwise, we wouldn't be able to keep track of power resources, for example). Hence, if it is impossible to determine the initial ACPI power states of some devices, they can't be regarded as power-manageable using ACPI. For this reason, modify acpi_bus_get_power_flags() to clear the power_manageable flag if acpi_bus_init_power() fails and add some extra fallback code to acpi_bus_init_power() to cover broken BIOSes that provide _PS0/_PS3 without _PSC for some devices. Verified to work on my HP nx6325 that has this problem. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Peter Wu <lekensteyn@gmail.com>
2013-01-31ACPI / PM: Fix acpi_bus_get_device() check in drivers/acpi/device_pm.cYasuaki Ishimatsu
acpi_bus_get_device() returns int not acpi_status. The patch change not to apply ACPI_FAILURE() to the return value of acpi_bus_get_device(). Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-01-22ACPI / PM: Fix device power state value after transitions to D3coldRafael J. Wysocki
When a transition to the D3cold power state is requested, acpi_device_set_power() first carries out a transition to D3hot and then turns off the device's power resources. However, it fails to update the device's power.state field appropriately and D3hot is stored in it as a result. Fix this, but make sure that the device's power state will be D3hot if its power resources cannot be turned off in the final step. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-01-22ACPI / PM: Use string "D3cold" to represent ACPI_STATE_D3_COLDRafael J. Wysocki
Make acpi_power_state_string() return "D3cold" as the string representation of ACPI power state D3cold instead of "D3" returned currently, which is confusing. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-01-22ACPI / PM: Always evaluate _PSn after setting power resourcesRafael J. Wysocki
The ACPI specitication (ACPI 5, Sections 7.2.8 - 7.2.11) requires that the _PSn (n = 0..3) method, if present, be executed after the power resources for the given device power state have been set appropriately. However, acpi_device_set_power() does that only if the new power state is going to be higher-power (lower-number) than the power state the device is in already. Otherwise, the ordering is reverse to protect against situations in which _PSn might access device registers unavailable after configuring the power resources for power state Dn (D3 meaning D3hot). Such situations are very unlikely to happen, though, and _PSn may actually be implemented with the assumption that power resources have been configured for power state Dn in advance, so change the code to follow the specification literally. This change was previously porposed in a different form by Lv Zheng. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-01-22ACPI / PM: Introduce helper for executing _PSn methodsRafael J. Wysocki
To reduce code duplication between acpi_device_set_power() and acpi_bus_init_power(), introduce a new helper function for executing ACPI devices' _PSn (n = 0..3) methods, acpi_dev_pm_explicit_set(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-01-22ACPI / PM: Make acpi_bus_init_power() more robustRafael J. Wysocki
The ACPI specification requires the _PSC method to be present under a device object if its power state cannot be inferred from the states of power resources used by it (ACPI 5, Section 7.6.2). However, it also requires that (for power states D0-D2 and D3hot) if the _PSn (n = 0, 1, 2, 3) method is present under the device object, it also must be executed after the power resources have been set appropriately for the device to go into power state Dn (D3 means D3hot in this case). Thus it is not clear from the specification whether or not the _PSn method should be executed if the initial configuraion of power resources used by the device indicates power state Dn and the _PSC method is not present. The current implementation of acpi_bus_init_power() is based on the assumption that it should not be necessary to execute _PSn in the above situation, but experience shows that in fact that assumption need not be satisfied. For this reason, make acpi_bus_init_power() always execute _PSn if the initial configuration of device power resources indicates power state Dn. Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-01-19ACPI / PM: remove leading whitespace from #ifdefMika Westerberg
It is there probably due to an accident, get rid of it so that the format is consistent across the file. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-01-19ACPI / PM: Move device power management functions to device_pm.cRafael J. Wysocki
Move ACPI device power management functions from drivers/acpi/bus.c to drivers/acpi/device_pm.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-01-17ACPI / PM: Rework the handling of devices depending on power resourcesRafael J. Wysocki
Commit 0090def6 (ACPI: Add interface to register/unregister device to/from power resources) made it possible to indicate to the ACPI core that if the given device depends on any power resources, then it should be resumed as soon as all of the power resources required by it to transition to the D0 power state have been turned on. Unfortunately, however, this was a mistake, because all devices depending on power resources should be treated this way (i.e. they should be resumed when all power resources required by their D0 state have been turned on) and for the majority of those devices the ACPI core can figure out by itself which (physical) devices depend on what power resources. For this reason, replace the code added by commit 0090def6 with a new, much more straightforward, mechanism that will be used internally by the ACPI core and remove all references to that code from kernel subsystems using ACPI. For the cases when there are (physical) devices that should be resumed whenever a not directly related ACPI device node goes into D0 as a result of power resources configuration changes, like in the SATA case, add two new routines, acpi_dev_pm_add_dependent() and acpi_dev_pm_remove_dependent(), allowing subsystems to manage such dependencies. Convert the SATA subsystem to use the new functions accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-01-17Merge branch 'acpi-scan' into acpi-pmRafael J. Wysocki
The following commits depend on the 'acpi-scan' material.
2013-01-03ACPI / PM: Do not apply ACPI_SUCCESS() to acpi_bus_get_device() resultRafael J. Wysocki
Since the return value of acpi_bus_get_device() is not of type acpi_status, ACPI_SUCCESS() should not be used for checking its return value. Fix that. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-01-03ACPI / PCI: Rework the setup and cleanup of device wakeupRafael J. Wysocki
Currently, the ACPI wakeup capability of PCI devices is set up in two different places, partially in acpi_pci_bind() where runtime wakeup is initialized and partially in platform_pci_wakeup_init(), where system wakeup is initialized. The cleanup is only done in acpi_pci_unbind() and it only covers runtime wakeup. Use the new .setup() and .cleanup() callbacks in struct acpi_bus_type to consolidate that code and do the setup and the cleanup each in one place. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Toshi Kani <toshi.kani@hp.com>
2012-11-26ACPI / PM: Allow attach/detach routines to change device power statesRafael J. Wysocki
Make it possible to ask the routines used for adding/removing devices to/from the general ACPI PM domain, acpi_dev_pm_attach() and acpi_dev_pm_detach(), respectively, to change the power states of devices so that they are put into the full-power state automatically by acpi_dev_pm_attach() and into the lowest-power state available automatically by acpi_dev_pm_detach(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2012-11-14ACPI / PM: Provide ACPI PM callback routines for subsystemsRafael J. Wysocki
Some bus types don't support power management natively, but generally there may be device nodes in ACPI tables corresponding to the devices whose bus types they are (under ACPI 5 those bus types may be SPI, I2C and platform). If that is the case, standard ACPI power management may be applied to those devices, although currently the kernel has no means for that. For this reason, provide a set of routines that may be used as power management callbacks for such devices. This may be done in three different ways. (1) Device drivers handling the devices in question may run acpi_dev_pm_attach() in their .probe() routines, which (on success) will cause the devices to be added to the general ACPI PM domain and ACPI power management will be used for them going forward. Then, acpi_dev_pm_detach() may be used to remove the devices from the general ACPI PM domain if ACPI power management is not necessary for them any more. (2) The devices' subsystems may use acpi_subsys_runtime_suspend(), acpi_subsys_runtime_resume(), acpi_subsys_prepare(), acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their power management callbacks in the same way as the general ACPI PM domain does that. (3) The devices' drivers may execute acpi_dev_suspend_late(), acpi_dev_resume_early(), acpi_dev_runtime_suspend(), acpi_dev_runtime_resume() from their power management callbacks as appropriate, if that's absolutely necessary, but it is not recommended to do that, because such drivers may not work without ACPI support as a result. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-14ACPI / PM: Move device PM functions related to sleep statesRafael J. Wysocki
Introduce helper function returning the target sleep state of the system and use it to move the remaining device power management functions from sleep.c to device_pm.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-14ACPI / PM: Split device wakeup management routinesRafael J. Wysocki
Two device wakeup management routines in device_pm.c and sleep.c, acpi_pm_device_run_wake() and acpi_pm_device_sleep_wake(), take a device pointer argument and use it to obtain the ACPI handle of the corresponding ACPI namespace node. That handle is then used to get the address of the struct acpi_device object corresponding to the struct device passed as the argument. Unfortunately, that last operation may be costly, because it involves taking the global ACPI namespace mutex, so it shouldn't be carried out too often. However, the callers of those routines usually call them in a row with acpi_pm_device_sleep_state() which also takes that mutex for the same reason, so it would be more efficient if they ran acpi_bus_get_device() themselves to obtain a pointer to the struct acpi_device object in question and then passed that pointer to the appropriate PM routines. To make that possible, split each of the PM routines mentioned above in two parts, one taking a struct acpi_device pointer argument and the other implementing the current interface for compatibility. Additionally, change acpi_pm_device_run_wake() to actually return an error code if there is an error while setting up runtime remote wakeup for the device. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-14ACPI / PM: Move runtime remote wakeup setup routine to device_pm.cRafael J. Wysocki
The ACPI function for setting up devices to do runtime remote wakeup is now located in drivers/acpi/sleep.c, but drivers/acpi/device_pm.c is a more logical place for it, so move it there. No functional changes should result from this modification. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-14ACPI / PM: Move device power state selection routine to device_pm.cRafael J. Wysocki
The ACPI function for choosing device power state is now located in drivers/acpi/sleep.c, but drivers/acpi/device_pm.c is a more logical place for it, so move it there. However, instead of moving the function entirely, move its core only under a different name and with a different list of arguments, so that it is more flexible, and leave a wrapper around it in the original location. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-14ACPI / PM: Move routines for adding/removing device wakeup notifiersRafael J. Wysocki
ACPI routines for adding and removing device wakeup notifiers are currently defined in a PCI-specific file, but they will be necessary for non-PCI devices too, so move them to a separate file under drivers/acpi and rename them to indicate their ACPI origins. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>