PM: sleep: Use DPM_FLAG_SMART_SUSPEND conditionally

A recent discussion has revealed that using DPM_FLAG_SMART_SUSPEND
unconditionally is generally problematic because it may lead to
situations in w

PM: sleep: Use DPM_FLAG_SMART_SUSPEND conditionally

A recent discussion has revealed that using DPM_FLAG_SMART_SUSPEND
unconditionally is generally problematic because it may lead to
situations in which the device's runtime PM information is internally
inconsistent or does not reflect its real state [1].

For this reason, change the handling of DPM_FLAG_SMART_SUSPEND so that
it is only taken into account if it is consistently set by the drivers
of all devices having any PM callbacks throughout dependency graphs in
accordance with the following rules:

- The "smart suspend" feature is only enabled for devices whose drivers
ask for it (that is, set DPM_FLAG_SMART_SUSPEND) and for devices
without PM callbacks unless they have never had runtime PM enabled.

- The "smart suspend" feature is not enabled for a device if it has not
been enabled for the device's parent unless the parent does not take
children into account or it has never had runtime PM enabled.

- The "smart suspend" feature is not enabled for a device if it has not
been enabled for one of the device's suppliers taking runtime PM into
account unless that supplier has never had runtime PM enabled.

Namely, introduce a new device PM flag called smart_suspend that is only
set if the above conditions are met and update all DPM_FLAG_SMART_SUSPEND
users to check power.smart_suspend instead of directly checking the
latter.

At the same time, drop the power.set_active flage introduced recently
in commit 3775fc538f53 ("PM: sleep: core: Synchronize runtime PM status
of parents and children") because it is now sufficient to check
power.smart_suspend along with the dev_pm_skip_resume() return value
to decide whether or not pm_runtime_set_active() needs to be called
for the device.

Link: https://lore.kernel.org/linux-pm/CAPDyKFroyU3YDSfw_Y6k3giVfajg3NQGwNWeteJWqpW29BojhQ@mail.gmail.com/ [1]
Fixes: 7585946243d6 ("PM: sleep: core: Restrict power.set_active propagation")
Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]> # drivers/pci
Link: https://patch.msgid.link/[email protected]

show more ...

ACPI: PM: Add acpi_device_fix_up_power_children() function

In some cases it is necessary to fix-up the power-state of an ACPI
device's children without touching the ACPI device itself add
a new acpi

ACPI: PM: Add acpi_device_fix_up_power_children() function

In some cases it is necessary to fix-up the power-state of an ACPI
device's children without touching the ACPI device itself add
a new acpi_device_fix_up_power_children() function for this.

Signed-off-by: Hans de Goede <[email protected]>
Cc: 6.6+ <[email protected]> # 6.6+
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

PCI/ACPI: Account for _S0W of the target bridge in acpi_pci_bridge_d3()

It is questionable to allow a PCI bridge to go into D3 if it has _S0W
returning D2 or a shallower power state, so modify acpi_

PCI/ACPI: Account for _S0W of the target bridge in acpi_pci_bridge_d3()

It is questionable to allow a PCI bridge to go into D3 if it has _S0W
returning D2 or a shallower power state, so modify acpi_pci_bridge_d3(() to
always take the return value of _S0W for the target bridge into account.
That is, make it return 'false' if _S0W returns D2 or a shallower power
state for the target bridge regardless of its ancestor Root Port
properties. Of course, this also causes 'false' to be returned if the Root
Port itself is the target and its _S0W returns D2 or a shallower power
state.

However, still allow bridges without _S0W that are power-manageable via
ACPI to enter D3 to retain the current code behavior in that case.

This fixes problems where a hotplug notification is missed because a bridge
is in D3. That means hot-added devices such as USB4 docks (and the devices
they contain) and Thunderbolt 3 devices may not work.

Link: https://lore.kernel.org/linux-pci/[email protected]/
Link: https://lore.kernel.org/r/12155458.O9o76ZdvQC@kreacher
Reported-by: Mario Limonciello <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

show more ...

ACPI: PM: Take wake IRQ into consideration when entering suspend-to-idle

This change adds support for ACPI devices that use ExclusiveAndWake or
SharedAndWake in their _CRS GpioInt definition (instea

ACPI: PM: Take wake IRQ into consideration when entering suspend-to-idle

This change adds support for ACPI devices that use ExclusiveAndWake or
SharedAndWake in their _CRS GpioInt definition (instead of using _PRW),
and also provide power resources. Previously the ACPI subsystem had no
idea if the device had a wake capable interrupt armed. This resulted
in the ACPI device PM system placing the device into D3Cold, and thus
cutting power to the device. With this change we will now query the
_S0W method to figure out the appropriate wake capable D-state.

Signed-off-by: Raul E Rangel <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: PM: Fix NULL argument handling in acpi_device_get/set_power()

In principle, it should be valid to pass NULL as the ACPI device
pointer to acpi_device_get_power() and acpi_device_set_power() an

ACPI: PM: Fix NULL argument handling in acpi_device_get/set_power()

In principle, it should be valid to pass NULL as the ACPI device
pointer to acpi_device_get_power() and acpi_device_set_power() and they
both are expected to return -EINVAL in that case, but that has been
broken recently by commit 62fcb99bdf10 ("ACPI: Drop parent field from
struct acpi_device") which has caused the ACPI device pointer to be
dereferenced in these functions before the NULL check.

Fix that and while at it make acpi_device_set_power() only use the
parent field if the target ACPI device object's ignore_parent flag
in not set.

Fixes: 62fcb99bdf10 ("ACPI: Drop parent field from struct acpi_device")
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: Drop parent field from struct acpi_device

The parent field in struct acpi_device is, in fact, redundant,
because the dev.parent field in it effectively points to the same
object and it is used

ACPI: Drop parent field from struct acpi_device

The parent field in struct acpi_device is, in fact, redundant,
because the dev.parent field in it effectively points to the same
object and it is used by the driver core.

Accordingly, the parent field can be dropped from struct acpi_device
and for this purpose define acpi_dev_parent() to retrieve a parent
struct acpi_device pointer from the dev.parent field in struct
acpi_device. Next, update all of the users of the parent field
in struct acpi_device to use acpi_dev_parent() instead of it and
drop it.

While at it, drop the ACPI_IS_ROOT_DEVICE() macro that is only used
in one place in a confusing way.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Acked-by: Mark Brown <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
Acked-by: Wei Liu <[email protected]>
Reviewed-by: Punit Agrawal <[email protected]>

show more ...

ACPI: PM: Fix acpi_dev_state_d0() kerneldoc

The documentation for acpi_dev_state_d0() referred to
Documentation/firmware-guide/acpi/low-power-probe.rst that does not exist,
the right file name is Do

ACPI: PM: Fix acpi_dev_state_d0() kerneldoc

The documentation for acpi_dev_state_d0() referred to
Documentation/firmware-guide/acpi/low-power-probe.rst that does not exist,
the right file name is Documentation/firmware-guide/acpi/non-d0-probe.rst.
Fix this.

Reported-by: kernel test robot <[email protected]>
Signed-off-by: Sakari Ailus <[email protected]>
[ rjw: Subject edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: Rename acpi_bus_get/put_acpi_device()

Because acpi_bus_get_acpi_device() is completely analogous to
acpi_fetch_acpi_dev(), rename it to acpi_get_acpi_dev() and
add a kerneldoc comment to it.

ACPI: Rename acpi_bus_get/put_acpi_device()

Because acpi_bus_get_acpi_device() is completely analogous to
acpi_fetch_acpi_dev(), rename it to acpi_get_acpi_dev() and
add a kerneldoc comment to it.

Accordingly, rename acpi_bus_put_acpi_device() to acpi_put_acpi_dev()
and update all of the users of these two functions.

While at it, move the acpi_fetch_acpi_dev() header next to the
acpi_get_acpi_dev() header in the header file holding them.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Acked-by: Guenter Roeck <[email protected]>
Reviewed-by: Punit Agrawal <[email protected]>

show more ...

ACPI / MMC: PM: Unify fixing up device power

Introduce acpi_device_fix_up_power_extended() for fixing up power of
a device having an ACPI companion in a manner that takes the device's
children into

ACPI / MMC: PM: Unify fixing up device power

Introduce acpi_device_fix_up_power_extended() for fixing up power of
a device having an ACPI companion in a manner that takes the device's
children into account and make the MMC code use it in two places
instead of walking the list of the device ACPI companion's children
directly.

This will help to eliminate the children list head from struct
acpi_device as it is redundant and it is used in questionable ways
in some places (in particular, locking is needed for walking the
list pointed to it safely, but it is often missing).

Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Acked-by: Adrian Hunter <[email protected]>
Acked-by: Ulf Hansson <[email protected]>

show more ...

ACPI: bus: Avoid non-ACPI device objects in walks over children

When walking the children of an ACPI device, take extra care to avoid
using to_acpi_device() on the ones that are not ACPI devices, be

ACPI: bus: Avoid non-ACPI device objects in walks over children

When walking the children of an ACPI device, take extra care to avoid
using to_acpi_device() on the ones that are not ACPI devices, because
that may lead to out-of-bounds access and memory corruption.

While at it, make the function passed to acpi_dev_for_each_child()
take a struct acpi_device pointer argument (instead of a struct device
one), so it is more straightforward to use.

Fixes: b7dd6298db81 ("ACPI: PM: Introduce acpi_dev_power_up_children_with_adr()")
Reported-by: kernel test robot <[email protected]>
BugLink: https://lore.kernel.org/lkml/20220420064725.GB16310@xsang-OptiPlex-9020/
Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>

show more ...

ACPI: PM: Always print final debug message in acpi_device_set_power()

acpi_device_set_power() prints debug messages regarding its outcome
(whether or not the power state has been changed and how) in

ACPI: PM: Always print final debug message in acpi_device_set_power()

acpi_device_set_power() prints debug messages regarding its outcome
(whether or not the power state has been changed and how) in all
cases except when the device whose power state is being changed to D0
is in that power state already.

Make acpi_device_set_power() print a final debug message in that case
too and while at it, fix the indentation of the "end" label in this
function.

Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: PM: Introduce acpi_dev_power_up_children_with_adr()

Introduce a function powering up all of the children of a given ACPI
device object that are power-manageable and hold valid _ADR ACPI
object

ACPI: PM: Introduce acpi_dev_power_up_children_with_adr()

Introduce a function powering up all of the children of a given ACPI
device object that are power-manageable and hold valid _ADR ACPI
objects so as to make it possible to prepare the corresponding
"physical" devices for enumeration carried out by a bus type driver,
like PCI.

This function will be used in a subsequent change set.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>

show more ...

ACPI: PM: Unify debug messages in acpi_device_set_power()

Convert all of the debug messages printed by acpi_device_set_power()
to acpi_handle_debug() and adjust them slightly for consistency with
ac

ACPI: PM: Unify debug messages in acpi_device_set_power()

Convert all of the debug messages printed by acpi_device_set_power()
to acpi_handle_debug() and adjust them slightly for consistency with
acpi_device_get_power() and other acpi_device_set_power() debug
messages.

Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: PM: Change pr_fmt() in device_pm.c

All messages printed by functions in this file either contain
the "ACPI" or "acpi" string regardless of the format, or they don't
need to contain it at all.

ACPI: PM: Change pr_fmt() in device_pm.c

All messages printed by functions in this file either contain
the "ACPI" or "acpi" string regardless of the format, or they don't
need to contain it at all.

In the former case, the "ACPI:" string added by the format is
redundant, so drop it from there.

Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: PM: Convert debug message in acpi_device_get_power()

Convert the debug message printed by acpi_device_get_power() to
acpi_handle_debug(), because that function is also called when
the ACPI dev

ACPI: PM: Convert debug message in acpi_device_get_power()

Convert the debug message printed by acpi_device_get_power() to
acpi_handle_debug(), because that function is also called when
the ACPI device object name has not been set yet and the dev_dbg()
message printed by it at that time is not useful.

Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: Use acpi_fetch_acpi_dev() instead of acpi_bus_get_device()

Modify the ACPI code to use acpi_fetch_acpi_dev() instead of
acpi_bus_get_device() where applicable.

Signed-off-by: Rafael J. Wysock

ACPI: Use acpi_fetch_acpi_dev() instead of acpi_bus_get_device()

Modify the ACPI code to use acpi_fetch_acpi_dev() instead of
acpi_bus_get_device() where applicable.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>

show more ...

ACPI: Add a convenience function to tell a device is in D0 state

Add a convenience function to tell whether a device is in D0 state,
primarily for use in drivers' probe or remove functions on busses

ACPI: Add a convenience function to tell a device is in D0 state

Add a convenience function to tell whether a device is in D0 state,
primarily for use in drivers' probe or remove functions on busses where
the custom is to power on the device for the duration of both.

Returns false on non-ACPI systems.

Suggested-by: Mika Westerberg <[email protected]>
Signed-off-by: Sakari Ailus <[email protected]>
Reviewed-by: Tomasz Figa <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: PM: postpone bringing devices to D0 unless we need them

Currently ACPI power domain brings devices into D0 state in the "resume
early" phase. Normally this does not cause any issues, as poweri

ACPI: PM: postpone bringing devices to D0 unless we need them

Currently ACPI power domain brings devices into D0 state in the "resume
early" phase. Normally this does not cause any issues, as powering up
happens quickly. However there are peripherals that have certain timing
requirements for powering on, for example some models of Elan
touchscreens need 300msec after powering up/releasing reset line before
they can accept commands from the host. Such devices will dominate
the time spent in early resume phase and cause increase in overall
resume time as we wait for early resume to complete before we can
proceed to the normal resume stage.

There are ways for a driver to indicate that it can tolerate device
being in the low power mode and that it knows how to power the device
back up when resuming, bit that requires changes to individual drivers
that may not really care about details of ACPI controlled power
management.

This change attempts to solve this issue at ACPI power domain level, by
postponing powering up device until we get to the normal resume stage,
unless there is early resume handler defined for the device, or device
does not declare any resume handlers, in which case we continue powering
up such devices early. This allows us to shave off several hundred
milliseconds of resume time on affected systems.

Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: Add quirks for AMD Renoir/Lucienne CPUs to force the D3 hint

AMD systems from Renoir and Lucienne require that the NVME controller
is put into D3 over a Modern Standby / suspend-to-idle
cycle.

ACPI: Add quirks for AMD Renoir/Lucienne CPUs to force the D3 hint

AMD systems from Renoir and Lucienne require that the NVME controller
is put into D3 over a Modern Standby / suspend-to-idle
cycle. This is "typically" accomplished using the `StorageD3Enable`
property in the _DSD, but this property was introduced after many
of these systems launched and most OEM systems don't have it in
their BIOS.

On AMD Renoir without these drives going into D3 over suspend-to-idle
the resume will fail with the NVME controller being reset and a trace
like this in the kernel logs:
```
[ 83.556118] nvme nvme0: I/O 161 QID 2 timeout, aborting
[ 83.556178] nvme nvme0: I/O 162 QID 2 timeout, aborting
[ 83.556187] nvme nvme0: I/O 163 QID 2 timeout, aborting
[ 83.556196] nvme nvme0: I/O 164 QID 2 timeout, aborting
[ 95.332114] nvme nvme0: I/O 25 QID 0 timeout, reset controller
[ 95.332843] nvme nvme0: Abort status: 0x371
[ 95.332852] nvme nvme0: Abort status: 0x371
[ 95.332856] nvme nvme0: Abort status: 0x371
[ 95.332859] nvme nvme0: Abort status: 0x371
[ 95.332909] PM: dpm_run_callback(): pci_pm_resume+0x0/0xe0 returns -16
[ 95.332936] nvme 0000:03:00.0: PM: failed to resume async: error -16
```

The Microsoft documentation for StorageD3Enable mentioned that Windows has
a hardcoded allowlist for D3 support, which was used for these platforms.
Introduce quirks to hardcode them for Linux as well.

As this property is now "standardized", OEM systems using AMD Cezanne and
newer APU's have adopted this property, and quirks like this should not be
necessary.

CC: Shyam-sundar S-k <[email protected]>
CC: Alexander Deucher <[email protected]>
CC: Prike Liang <[email protected]>
Link: https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/power-management-for-storage-hardware-devices-intro
Signed-off-by: Mario Limonciello <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Tested-by: Julian Sikorski <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>

show more ...

ACPI: Check StorageD3Enable _DSD property in ACPI code

Although first implemented for NVME, this check may be usable by
other drivers as well. Microsoft's specification explicitly mentions
that is m

ACPI: Check StorageD3Enable _DSD property in ACPI code

Although first implemented for NVME, this check may be usable by
other drivers as well. Microsoft's specification explicitly mentions
that is may be usable by SATA and AHCI devices. Google also indicates
that they have used this with SDHCI in a downstream kernel tree that
a user can plug a storage device into.

Link: https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/power-management-for-storage-hardware-devices-intro
Suggested-by: Keith Busch <[email protected]>
CC: Shyam-sundar S-k <[email protected]>
CC: Alexander Deucher <[email protected]>
CC: Rafael J. Wysocki <[email protected]>
CC: Prike Liang <[email protected]>
Signed-off-by: Mario Limonciello <[email protected]>
Reviewed-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>

show more ...

ACPI: PM / fan: Put fan device IDs into separate header file

The ACPI fan device IDs are shared between the fan driver and the
device power management code. The former is modular, so it needs
to in

ACPI: PM / fan: Put fan device IDs into separate header file

The ACPI fan device IDs are shared between the fan driver and the
device power management code. The former is modular, so it needs
to include the table of device IDs for module autoloading and the
latter needs that list to avoid attaching the generic ACPI PM domain
to fan devices (which doesn't make sense) possibly before the fan
driver module is loaded.

Unfortunately, that requires the list of fan device IDs to be
updated in two places which is prone to mistakes, so put it into
a symbol definition in a separate header file so there is only one
copy of it in case it needs to be updated again in the future.

Fixes: b9ea0bae260f ("ACPI: PM: Avoid attaching ACPI PM domain to certain devices")
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: PM: Add ACPI ID of Alder Lake Fan

Add a new unique fan ACPI device ID for Alder Lake to
support it in acpi_dev_pm_attach() function.

Fixes: 38748bcb940e ("ACPI: DPTF: Support Alder Lake")
Sig

ACPI: PM: Add ACPI ID of Alder Lake Fan

Add a new unique fan ACPI device ID for Alder Lake to
support it in acpi_dev_pm_attach() function.

Fixes: 38748bcb940e ("ACPI: DPTF: Support Alder Lake")
Signed-off-by: Sumeet Pawnikar <[email protected]>
Acked-by: Zhang Rui <[email protected]>
Cc: 5.10+ <[email protected]> # 5.10+
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: PM: add a missed blank line after declarations

Add a missed blank line after declarations, reported by checkpatch.pl.

Signed-off-by: Xiaofei Tan <[email protected]>
Signed-off-by: Rafael

ACPI: PM: add a missed blank line after declarations

Add a missed blank line after declarations, reported by checkpatch.pl.

Signed-off-by: Xiaofei Tan <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI: PM: Clean up printing messages

Replace the remaining ACPI_DEBUG_PRINT() instances in device_pm.c
with dev_dbg() invocations, drop the _COMPONENT and ACPI_MODULE_NAME()
definitions that are not

ACPI: PM: Clean up printing messages

Replace the remaining ACPI_DEBUG_PRINT() instances in device_pm.c
with dev_dbg() invocations, drop the _COMPONENT and ACPI_MODULE_NAME()
definitions that are not used any more, and drop the no longer needed
ACPI_POWER_COMPONENT definition from the headers and documentation.

Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

PM: ACPI: Refresh wakeup device power configuration every time

When wakeup signaling is enabled for a bridge for the second (or every
next) time in a row, its existing device wakeup power configurat

PM: ACPI: Refresh wakeup device power configuration every time

When wakeup signaling is enabled for a bridge for the second (or every
next) time in a row, its existing device wakeup power configuration
may not match the new conditions. For example, some devices below
it may have been put into low-power states and that changes the
device wakeup power conditions or similar. This causes functional
problems to appear on some systems (for example, because of it the
Thunderbolt port on Dell Precision 5550 cannot detect devices plugged
in after it has been suspended).

For this reason, modify __acpi_device_wakeup_enable() to refresh the
device wakeup power configuration of the target device on every
invocation, not just when it is called for that device first time
in a row.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Reported-by: Kai-Heng Feng <[email protected]>
Tested-by: Kai-Heng Feng <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>

show more ...