commit 91bdad0b6237c25a7bf8fd4604d0cc64a2005a23 upstream.

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>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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>

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>

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>

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>

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>

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>

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>