summaryrefslogtreecommitdiffstats
path: root/drivers/acpi/power.c
Commit message (Collapse)AuthorAgeFilesLines
* ACPI: Remove duplicate definitions of PREFIXHanjun Guo2014-03-191-2/+0
| | | | | | | | | We already have a macro for PREFIX of "ACPI: " in drivers/acpi/internal.h, so remove the duplicate ones in ACPI drivers when internal.h is included. Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI: Clean up inclusions of ACPI header filesLv Zheng2013-12-071-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h> inclusions and remove some inclusions of those files that aren't necessary. First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h> should not be included directly from any files that are built for CONFIG_ACPI unset, because that generally leads to build warnings about undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set, <linux/acpi.h> includes those files and for CONFIG_ACPI unset it provides stub ACPI symbols to be used in that case. Second, there are ordering dependencies between those files that always have to be met. Namely, it is required that <acpi/acpi_bus.h> be included prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the latter depends on are always there. And <acpi/acpi.h> which provides basic ACPICA type declarations should always be included prior to any other ACPI headers in CONFIG_ACPI builds. That also is taken care of including <linux/acpi.h> as appropriate. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Tony Luck <tony.luck@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff) Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / power: Drop automaitc resume of power resource dependent devicesRafael J. Wysocki2013-10-161-99/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The mechanism causing devices depending on a given power resource (that is, devices that can be in D0 only if that power resource is on) to be resumed automatically when the power resource is turned on (and their "inferred" power state becomes D0 as a result) is inherently racy and in fact unnecessary. It is racy, because if the power resource is turned on and then immediately off, the device resume triggered by the first transition to "on" may still happen, causing the power resource to be turned on again. That again will trigger the "resume of dependent devices" mechanism, but if the devices in question are not in use, they will be suspended in the meantime causing the power resource to be turned off. However, the "resume of dependent devices" will next resume them again and so on. In some cases (USB port PM in particular) that leads to an endless busy loop of flipping the resource on and off continuously. It is needless, because whoever turns a power resource on will most likely turn it off at some point and the devices that go into "D0" as a result of turning it on will then go back into D3cold (generally, the state they were in before). Moreover, turning on all power resources a device needs to go into D0 is not sufficient for a full transition into D0 in general. Namely, _PS0 may need to be executed in addition to that in some cases. This means that the whole rationale of the "resume of dependent devices" mechanism was incorrect to begin with and it's best to remove it entirely. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / power: Release resource_lock after acpi_power_get_state() return errorLan Tianyu2013-10-161-1/+3
| | | | | | | | | In acpi_resume_power_resources() resource_lock should be released when acpi_power_get_state() fails and before passing to next power resource on the list. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge branch 'acpi-pm'Rafael J. Wysocki2013-08-271-1/+1
|\ | | | | | | | | | | | | | | | | * acpi-pm: ACPI / PM: Add state information to error message in acpi_device_set_power() ACPI / PM: Remove redundant power manageable check from acpi_bus_set_power() ACPI / PM: Use ACPI_STATE_D3_COLD instead of ACPI_STATE_D3 everywhere ACPI / PM: Make messages in acpi_device_set_power() print device names ACPI / PM: Only set power states of devices that are power manageable
| * ACPI / PM: Use ACPI_STATE_D3_COLD instead of ACPI_STATE_D3 everywhereRafael J. Wysocki2013-07-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | There are several places in the tree where ACPI_STATE_D3 is used instead of ACPI_STATE_D3_COLD which should be used instead for clarity. Modify them all to use ACPI_STATE_D3_COLD as appropriate. [The definition of ACPI_STATE_D3 itself cannot go away at this point as it is part of ACPICA.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com>
* | ACPI: introduce helper function acpi_execute_simple_method()Jiang Liu2013-07-151-3/+1
|/ | | | | | | | | Introduce helper function acpi_execute_simple_method() and use it in a number of places to simplify code. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / power: add missing newline to debug messagesMika Westerberg2013-07-051-2/+2
| | | | | | | | | | There are few places in power.c where debug messages have no newline at the end. Reading such debug messages from dmesg is not fun, so fix this by adding the missing newlines. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: All <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Fix error code path for power resources initializationRafael J. Wysocki2013-06-201-0/+1
| | | | | | | | | | | | | | | | | | | | Commit 781d737 (ACPI: Drop power resources driver) introduced a bug in the power resources initialization error code path causing a NULL pointer to be referenced in acpi_release_power_resource() if there's an error triggering a jump to the 'err' label in acpi_add_power_resource(). This happens because the list_node field of struct acpi_power_resource has not been initialized yet at this point and doing a list_del() on it is a bad idea. To prevent this problem from occuring, initialize the list_node field of struct acpi_power_resource upfront. Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 3.9+ <stable@vger.kernel.org> Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* Merge branch 'acpi-pm'Rafael J. Wysocki2013-04-281-19/+39
|\ | | | | | | | | | | * acpi-pm: ACPI / PM: Expose lists of device wakeup power resources to user space ACPI / PM: Fix potential problem in acpi_device_get_power()
| * ACPI / PM: Expose lists of device wakeup power resources to user spaceRafael J. Wysocki2013-04-111-19/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 18a3870 (ACPI / PM: Expose lists of device power resources to user space) exposed the lists of ACPI power resources associated with power states of ACPI devices, but it didn't expose the lists of ACPI wakeup power resources, which also is necessary to get the full picture of dependencies between ACPI devices and power resources. For this reason, for every ACPI device node having a list of ACPI wakeup power resources associated with it, expose that list to user space in analogy with commit 18a3870. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI: Update PNPID set/free interfacesToshi Kani2013-03-241-1/+1
|/ | | | | | | | | | This patch introduces acpi_set_pnp_ids() and acpi_free_pnp_ids(), which are updated from acpi_device_set_id() and acpi_free_ids(), to setup and free acpi_device_pnp for a given acpi_handle. They can be called without acpi_device. Signed-off-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Take unusual configurations of power resources into accountRafael J. Wysocki2013-02-231-27/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device wakeup) moved the initial disabling of system wakeup for PCI devices into a place where it can actually work and that exposed a hidden old issue with crap^Wunusual system designs where the same power resources are used for both wakeup power and device power control at run time. Namely, say there is one power resource such that the ACPI power state D0 of a PCI device depends on that power resource (i.e. the device is in D0 when that power resource is "on") and it is used as a wakeup power resource for the same device. Then, calling acpi_pci_sleep_wake(pci_dev, false) for the device in question will cause the reference counter of that power resource to drop to 0, which in turn will cause it to be turned off. As a result, the device will go into D3cold at that point, although it should have stayed in D0. As it turns out, that happens to USB controllers on some laptops and USB becomes unusable on those machines as a result, which is a major regression from v3.8. To fix this problem, (1) increment the reference counters of wakup power resources during their initialization if they are "on" initially, (2) prevent acpi_disable_wakeup_device_power() from decrementing the reference counters of wakeup power resources that were not enabled for wakeup power previously, and (3) prevent acpi_enable_wakeup_device_power() from incrementing the reference counters of wakeup power resources that already are enabled for wakeup power. In addition to that, if it is impossible to determine the initial states of wakeup power resources, avoid enabling wakeup for devices whose wakeup power depends on those power resources. Reported-by: Dave Jones <davej@redhat.com> Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org> Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Fix consistency check for power resources during resumeRafael J. Wysocki2013-01-251-11/+26
| | | | | | | | | | | | | | | | | During system resume we check if there are power resources that have been turned off by the BIOS, but our reference counters for them are nonzero (they need to be turned on then). It turns out, however, that we also need to check the opposite, i.e. if there are power resources that have been turned on by the BIOS, but our reference counters for them are zero (which means that no devices are going to need them any time soon) and we should turn them off. Make the power resources resume code do the additional check and turn off the unused power resources as appropriate. This change has been tested on HP nx6325. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Expose lists of device power resources to user spaceRafael J. Wysocki2013-01-251-13/+91
| | | | | | | | | | | | | | | | | | Since ACPI power resources are going to be used more extensively on new hardware platforms, it is necessary to allow user space (powertop in particular) to look at the lists of power resources corresponding to different power states of devices for diagnostics and control purposes. For this reason, for each power state of an ACPI device node using power resources create a special attribute group under the device node's directory in sysfs containing links to sysfs directories representing the power resources in that list. The names of the new attribute groups are "power_resources_<state>", where <state> is the state name i.e. "D0", "D1", "D2", or "D3hot". Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ACPI / PM: Expose current status of ACPI power resourcesRafael J. Wysocki2013-01-241-1/+25
| | | | | | | | | | | | | | | Since ACPI power resources are going to be used more extensively on new hardware platforms, it becomes necessary for user space (powertop in particular) to observe some properties of those resources for diagnostics purposes. For this reason, expose the current status of each ACPI power resource to user space via sysfs by adding a new resource_in_use attribute to the sysfs directory representing the given power resource. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ACPI / scan: Prevent device add uevents from racing with user spaceRafael J. Wysocki2013-01-241-1/+2
| | | | | | | | | | | | | | | ACPI core adds sysfs device files after the given devices have been registered with device_register(), which is not appropriate, because it may lead to race conditions with user space tools using those files. Fix the problem by delaying the KOBJ_ADD uevent for ACPI devices until after all of the devices' sysfs files have been created. This also fixes a use-after-free in acpi_device_unregister(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ACPI / PM: Sanitize checks in acpi_power_on_resources()Rafael J. Wysocki2013-01-221-4/+1
| | | | | | | | | | | | After the only user of acpi_power_on_resources(), acpi_bus_init_power(), has been changed to avoid calling it for state equal to ACPI_STATE_D3_COLD, it doesn't have to special case that state any more. For this reason, modify the checks in acpi_power_on_resources() so that it returns -EINVAL for ACPI_STATE_D3_COLD as it should. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI: Use system level attribute of wakeup power resourcesRafael J. Wysocki2013-01-171-0/+14
| | | | | | | | | | | | | | | | The system level attribute of ACPI power resources is the lowest system sleep level (S0, S2 etc.) in which the given resource can be "on" (ACPI 5.0, Section 7.1). On the other hand, wakeup power resources have to be "on" for devices depending on them to be able to signal wakeup. Therefore devices cannot wake up the system from sleep states higher than the minimum of the system level attributes of their wakeup power resources. Use the wakeup power resources' system level values to get the deepest system sleep state (highest system sleep level) the given device can wake up the system from. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI: Take power resource initialization errors into accountRafael J. Wysocki2013-01-171-19/+25
| | | | | | | | | | | | | Some ACPI power resource initialization errors, like memory allocation errors, are not taken into account appropriately in some cases, which may lead to a device having an incomplete list of power resources that one of its power states depends on, for one example. Rework the power resource initialization and namespace scanning code so that power resource initialization errors are treated more seriously. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / scan: Consolidate extraction of power resources listsRafael J. Wysocki2013-01-171-1/+31
| | | | | | | | | | | | | The lists of ACPI power resources are currently extracted in two different ways, one for wakeup power resources and one for power resources that device power states depend on. There is no reason why it should be done differently in those two cases, so introduce a common routine for extracting power resources lists from data returned by AML, acpi_extract_power_resources(), and make the namespace scanning code use it for both wakeup and device power states power resources. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Take order attribute of wakeup power resources into accountRafael J. Wysocki2013-01-171-28/+16
| | | | | | | | | | ACPI power resources have an order attribute that should be taken into account when turning them on and off, but it is not used now. Modify the power resources management code to preserve the spec-compliant ordering of wakeup power resources. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Take order attribute of power resources into accountRafael J. Wysocki2013-01-171-72/+89
| | | | | | | | | | | | ACPI power resources have an order attribute that should be taken into account when turning them on and off, but it is not used now. Modify the power resources management code to preserve the spec-compliant ordering of power resources that power states of devices depend on (analogous changes will be done separately for power resources used for wakeup). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI: Do not use device power states of power resourcesRafael J. Wysocki2013-01-171-20/+3
| | | | | | | | | | | | | | ACPI power resource objects have struct acpi_device components, but they are only used for registering those resources in the device hierarchy. In particular, power state information stored in them is completely useless (amnong other things, because the power resources "devices" are not power manageable), so there is no reason for the power resources management code to keep it up to date. Remove the code updating device power states of power resources from drivers/acpi/power.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI: Drop power resources driverRafael J. Wysocki2013-01-171-58/+33
| | | | | | | | | | | | | | The ACPI power resources driver is not very useful, because the only thing it really does is to restore the state of the power resources that were "on" before system suspend or hibernation, but that may be achieved in a different way. Drop the ACPI power resources driver entirely and add acpi_resume_power_resources() that will walk the list of all registered power resources during system resume and turn on the ones that were "on" before the preceding system suspend or hibernation. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / scan: Treat power resources in a special wayRafael J. Wysocki2013-01-171-85/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | ACPI power resources need to be treated in a special way by the namespace scanning code, because they need to be ready to use as soon as they have been discovered (even before registering ACPI device nodes using them for power management). For this reason, it doesn't make sense to separate the preparation of struct acpi_device objects representing them in the device hierarchy from the creation of struct acpi_power_resource objects actually used for power resource manipulation. Accordingly, it doesn't make sense to define non-empty .add() and .remove() callbacks in the power resources "driver" (in fact, it is questionable whether or not it is useful to register such a "driver" at all). Rearrange the code in scan.c and power.c so that power resources are initialized entirely by one routine, acpi_add_power_resource(), that also prepares their struct acpi_device objects and registers them with the driver core, telling it to use a special release routine, acpi_release_power_resource(), for removing objects that represent power resources from memory. Make the ACPI namespace scanning code in scan.c always use acpi_add_power_resource() for preparing and registering objects that represent power resources. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Rework the handling of devices depending on power resourcesRafael J. Wysocki2013-01-171-137/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ACPI / power: Remove useless message from device registering routineRafael J. Wysocki2013-01-031-9/+2
| | | | | | | | | | | | | | | | | 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 <rafael.j.wysocki@intel.com>
* ACPI: add newline in power.c messageRandy Dunlap2012-11-151-1/+1
| | | | | | | | | 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 <toralf.foerster@gmx.de> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / PM: Use KERN_DEBUG when no power resources are foundAaron Lu2012-09-141-1/+1
| | | | | | | | | | | | | | | 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 <bp@amd64.org> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
* ACPI / PM: Fix resource_lock dead lock in acpi_power_on_deviceLin Ming2012-09-141-11/+23
| | | | | | | | | | | | | | | | | | | | | | | 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 <ming.m.lin@intel.com> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
* ACPI / PM: Fix unused function warnings for CONFIG_PM_SLEEPRafael J. Wysocki2012-08-101-0/+4
| | | | | | | | 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 <rjw@sisk.pl>
* Merge branch 'master' [vanilla Linus master] into libata-dev.git/upstreamJeff Garzik2012-07-251-4/+8
|\ | | | | | | | | | | | | | | | | 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 driverRafael J. Wysocki2012-07-011-4/+8
| | | | | | | | | | | | | | | | 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 <rjw@sisk.pl>
* | libata-acpi: register/unregister device to/from power resourceLin Ming2012-06-291-0/+2
|/ | | | | Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
* ACPI / PM: Make __acpi_bus_get_power() cover D3cold correctlyRafael J. Wysocki2012-05-291-1/+1
| | | | | | | | | | | | | | | | | | | | | 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 <rjw@sisk.pl>
* ACPI / PCI / PM: Fix device PM regression related to D3hot/D3coldRafael J. Wysocki2012-05-171-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <rockorequin@hotmail.com> Reported-by: Cristian Rodríguez <crrodriguez@opensuse.org> Reported-and-tested-by: Peter <lekensteyn@gmail.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* ACPI: Fix D3hot v D3cold confusionLin Ming2012-05-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Before this patch, ACPI_STATE_D3 incorrectly referenced D3hot in some places, but D3cold in other places. After this patch, ACPI_STATE_D3 always means ACPI_STATE_D3_COLD; and all references to D3hot use ACPI_STATE_D3_HOT. ACPI's _PR3 method is used to enter both D3hot and D3cold states. What distinguishes D3hot from D3cold is the presence _PR3 (Power Resources for D3hot) If these resources are all ON, then the state is D3hot. If _PR3 is not present, or all _PR0 resources for the devices are OFF, then the state is D3cold. This patch applies after Linux-3.4-rc1. A future syntax cleanup may remove ACPI_STATE_D3 to emphasize that it always means ACPI_STATE_D3_COLD. Signed-off-by: Lin Ming <ming.m.lin@intel.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Reviewed-by: Aaron Lu <aaron.lu@amd.com> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: Add interface to register/unregister device to/from power resourcesLin Ming2012-03-301-0/+162
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Devices may share same list of power resources in _PR0, for example Device(Dev0) { Name (_PR0, Package (0x01) { P0PR, P1PR }) } Device(Dev1) { Name (_PR0, Package (0x01) { P0PR, P1PR } } Assume Dev0 and Dev1 were runtime suspended. Then Dev0 is resumed first and it goes into D0 state. But Dev1 is left in D0_Uninitialised state. This is wrong. In this case, Dev1 must be resumed too. In order to hand this case, each power resource maintains a list of devices which relies on it. When power resource is ON, it will check if the devices on its list can be resumed. The device can only be resumed when all the power resouces of its _PR0 are ON. Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: Introduce ACPI D3_COLD state supportZhang Rui2012-03-301-2/+2
| | | | | | | | | If a device has _PR3, it means the device supports D3_COLD. Add the ability to validate and enter D3_COLD state in ACPI. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI / PM: Check status of power resources under mutexesRafael J. Wysocki2011-01-121-13/+20
| | | | | | | | | | | It certainly is not a good idea to execute _ON or _OFF and _STA for the same power resource at the same time which may happen in some circumstances in theory. To prevent that from happening, read the power state of each power resource under its mutex, as that will prevent the state from being changed at the same time. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI / PM: Rename acpi_power_off_device()Rafael J. Wysocki2011-01-121-4/+3
| | | | | | | | Rename acpi_power_off_device() to acpi_power_off() in analogy with acpi_power_on(). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI / PM: Drop acpi_power_nocheckRafael J. Wysocki2011-01-121-3/+0
| | | | | | | | | | | | | Since acpi_bus_set_power() should not use __acpi_bus_get_power() to update the device's device->power.state field before changing its power state (this may cause device->power.state to be inconsistent with the device power resources' reference counters), remove this call from it. In consequence, the acpi_power_nocheck variable is not necessary any more, so it can be dropped along with the DMI table used for setting that variable for HP Pavilion 05. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI / PM: Introduce function for refcounting device power resourcesRafael J. Wysocki2011-01-121-0/+8
| | | | | | | | | | | | Introduce function acpi_power_on_resources() that reference counts and possibly turns on ACPI power resources for a given device and a given power state of it. This function will be used for reference counting device power resources during initialization. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI / PM: Add functions for manipulating lists of power resourcesRafael J. Wysocki2011-01-121-29/+38
| | | | | | | | | | | | | | ACPI device power resources should be reference counted during device initialization, so that their reference counters are always up to date. It is convenient to do that with the help of a function that will reference count and possibly turn on power resources in a given list, so introduce that function, acpi_power_on_list(). For symmetry, introduce acpi_power_off_list() for performing the reverse operation and use the both of them to simplify acpi_power_transition(). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI / PM: Prevent acpi_power_get_inferred_state() from making changesRafael J. Wysocki2011-01-121-8/+4
| | | | | | | | | acpi_power_get_inferred_state() should not update device->power.state behind the back of its caller, so make it return the state via a pointer instead. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI / PM: Do not refcount power resources that can't be turned onRafael J. Wysocki2010-12-011-1/+3
| | | | | | | | If turning on a power resource fails, do not reference count it, since it cannot be in use in that case. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI / PM: Check device state before refcounting power resourcesRafael J. Wysocki2010-12-011-5/+3
| | | | | | | | | | | | | | | | | | Commit 3e384ee6c687cb397581ee8f9440fc8220cfac80 (ACPI / PM: Fix reference counting of power resources) introduced a regression by causing fan power resources to be turned on and reference counted unnecessarily during resume, so on some boxes fans are always on after resume. Fix the problem by checking if the current device state is different from the new state before reference counting and turning on power resources in acpi_power_transition(). Addresses https://bugzilla.kernel.org/show_bug.cgi?id=22932 . Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: Maciej Rutecki <maciej.rutecki@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI / PM: Fix reference counting of power resourcesRafael J. Wysocki2010-10-231-97/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The reference counting of ACPI power resources is currently broken for a few reasons. First, instead of using a simple reference counter per power resource it uses a list of objects representing refereces to the given power resource from devices. This leads to the second breakage, because it prevents power resources from being referenced more than once by one device, which is necessary if the device is configured to signal wakeup. Namely, when putting the device into a low power state we first call acpi_enable_wakeup_device_power() that should reference count power resources needed for signaling wakeup and then we call acpi_power_transition() to power off the device. The latter call drops references to the device's power resources, possibly including the ones added by acpi_enable_wakeup_device_power(), so the device can't signal wakeup as a result. Apart from this, the locking in acpi_power_on() and acpi_power_off_device() doesn't prevent all possible races from happening, which may be problematic for runtime PM and asynchronous suspend and resume. Fix the problem by using a counter for power resources reference counting and putting the evaluation of ACPI _ON and _OFF methods under the power resource mutex. Reported-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
* Merge branch 'release' of ↵Linus Torvalds2010-08-151-128/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: gcc-4.6: ACPI: fix unused but set variables in ACPI ACPI thermal: make procfs I/F depend on CONFIG_ACPI_PROCFS ACPI video: make procfs I/F depend on CONFIG_ACPI_PROCFS ACPI processor: remove deprecated ACPI procfs I/F ACPI power_resource: remove unused procfs I/F ACPI: remove deprecated ACPI procfs I/F ACPI: introduce drivers/acpi/sysfs.c ACPI: introduce module parameter acpi.aml_debug_output ACPI: introduce drivers/acpi/debugfs.c ACPI, APEI, ERST debug support ACPI, APEI, Manage GHES as platform devices ACPI, APEI, Rename CPER and GHES severity constants ACPI, APEI, Fix a typo of error path of apei_resources_request ACPI / ACPICA: Fix reference counting problems with GPE handlers ACPI: Add the check of ADR flag in course of finding ACPI handle for PCI device ACPI / Sleep: Drop acpi_suspend_finish() ACPI / Sleep: Consolidate suspend and hibernation routines ACPI / Wakeup: Simplify enabling of wakeup devices ACPI / Sleep: Rework enabling wakeup devices ACPI / Sleep: Free NVS copy if suspending of devices fails Fixed up totally buggered "ACPI: fix unused but set variables in ACPI" patch that doesn't even compile in the merge. Thanks to Sedat Dilek <sedat.dilek@googlemail.com> for noticing the breakage before I even pulled. And a big "Grrr.." at Len for not even bothering to compile the tree before asking me to pull.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-09 10:11:21 +0000