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>

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>

Fix /proc/acpi/wakeup for devices without bus or parent

This patch fixes printing the wakeup status for devices without a bus
or parent, such as laptop lid switches and sleep buttons. These devices
have an empty physical_node_list, because acpi_bind_one is never run
for them.

[rjw: White space and coding style.]
Signed-off-by: Andreas Fleig <andreasfleig@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

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>

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>

The most convenient way to expose ACPI power resources lists of a
device is to put symbolic links to sysfs directories representing
those resources into special attribute groups in the device's sysfs
directory.  For this purpose, it is necessary to be able to add
symbolic links to attribute groups.

For this reason, add sysfs helper functions for adding/removing
symbolic links to/from attribute groups, sysfs_add_link_to_group()
and sysfs_remove_link_from_group(), respectively.

This change set includes a build fix from David Rientjes.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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>

Make it possible to retrieve the current power state of a device with
ACPI power management from user space via sysfs by adding two new
attributes, power_state and real_power_state, to the sysfs directory
associated with the struct acpi_device object representing the
device's ACPI node.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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>

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>

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>

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>

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>

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>

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>

CONFIG_PM_SLEEP may be set even if CONFIG_ACPI_SLEEP is unset,
although that is unusual.  For this reason, make the headers of
functions built for both CONFIG_ACPI and CONFIG_PM_SLEEP set
simultaneously depend on that combination of Kconfig options
instead of CONFIG_ACPI_SLEEP.

This fixes a build problem reported by Randy Dunlap.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

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>

Move some suspend-specific and hibernate-specific code from
acpi_sleep_init() into separate functions to get rid of explicit
#ifdefs in acpi_sleep_init().  Use pr_info() to start and pr_cont()
to continue printing the supported ACPI sleep states line.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

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>

The function returning string representations of ACPI device power
states, state_string((), is now static, because it is only used
internally in drivers/acpi/bus.c.  However, it will be used outside
of that file going forward, so rename it to
acpi_power_state_string(), add a kerneldoc comment to it and add its
header to acpi_bus.h.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The function used for retrieving ACPI device power states,
__acpi_bus_get_power(), is now static, because it is only used
internally in drivers/acpi/bus.c.  However, it will be used
outside of that file going forward, so rename it to
acpi_device_get_power(), in analogy with acpi_device_set_power(),
add a kerneldoc comment to it and add its header to acpi_bus.h.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

During power transitions into D3cold from any shallower power states
we are supposed to transition the device into D3hot and remove power
from it afterward, but the current code in acpi_device_set_power()
doesn't work this way.

At the same time, though, we need to be careful enough to preserve
backwards compatibility for systems that don't distinguish between
D3hot and D3cold (e.g. designed before ACPI 4).

Modify acpi_device_set_power() so that it works in accordance with
the expectations in both cases.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

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>

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>

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>

The local variables in acpi_bus_get_power_flags() need not be
initialized upfront, so change the code accordingly.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

To reduce indentation level and improve code readability, move the
initialization code related to device power states from
acpi_bus_get_power_flags() to a new routine,
acpi_bus_init_power_state().

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

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 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 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>

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 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>

Simplify the code preparing struct acpi_device objects for
registration by removing useless code, moving different pieces of
code into the functions they belong to and making a couple of int
functions always returning 0 void.

This also fixes a possible memory leak in ACPI device registration
error code path by making acpi_device_register() detach data from
device->handle if device_register() fails and prepares the scanning
code for special-casing ACPI power resources (next patch).

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

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>

The following commits depend on the 'acpi-scan' material.

Should use acpi_device pointer directly instead of use handle and
get the device pointer again later.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Make acpi_bus_trim() work in analogy with acpi_bus_scan() and carry
out two passes such that ACPI drivers will be detached from device
nodes being removed in the first pass and the device nodes themselves
will be removed in the second pass.

For this purpose split the driver unregistration out of
acpi_bus_remove() into a new routine, acpi_bus_device_detach(), that
will be executed by acpi_bus_trim() in the additional first pass as
a post-order callback.

This is necessary, because some ACPI drivers' .remove() routines
unregister struct device objects associated with the ACPI device
nodes being removed and that needs to happen while the ACPI
device nodes are still around (for example, in case they need to be
used for power management or similar things at that time).

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>

The current acpi_bus_trim() implementation is not really
straightforward and may be simplified significantly by using
acpi_walk_namespace() with acpi_bus_remove() as a post-order
callback.

Observe that acpi_bus_remove(), as called by acpi_bus_trim(), cannot
actually fail, because its first argument is guaranteed not to be
NULL thanks to the acpi_bus_get_device() check in acpi_bus_trim(),
so simply move the acpi_bus_get_device() check to acpi_bus_remove()
and use acpi_walk_namespace() to execute it for every device under
start->handle as a post-order callback.  The, run it directly for
start->handle itself.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>

All callers of acpi_bus_trim() pass 1 (true) as the second argument
of it, so remove that argument entirely and change acpi_bus_trim()
to always behave as though it were 1.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>

Drop the second argument of acpi_device_unregister(), type, which is
not used by that function.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>