Changes in device_pm.c

bca84a7b - PM: sleep: Use DPM_FLAG_SMART_SUSPEND conditionally

Tue, 18 Feb 2025 20:16:48 +0000

PM: sleep: Use DPM_FLAG_SMART_SUSPEND conditionallyA recent discussion has revealed that using DPM_FLAG_SMART_SUSPENDunconditionally is generally problematic because it may lead tosituations in which the device's runtime PM information is internallyinconsistent or does not reflect its real state [1].For this reason, change the handling of DPM_FLAG_SMART_SUSPEND so thatit is only taken into account if it is consistently set by the driversof all devices having any PM callbacks throughout dependency graphs inaccordance 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 onlyset if the above conditions are met and update all DPM_FLAG_SMART_SUSPENDusers to check power.smart_suspend instead of directly checking thelatter.At the same time, drop the power.set_active flage introduced recentlyin commit 3775fc538f53 ("PM: sleep: core: Synchronize runtime PM statusof parents and children") because it is now sufficient to checkpower.smart_suspend along with the dev_pm_skip_resume() return valueto decide whether or not pm_runtime_set_active() needs to be calledfor 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 Reviewed-by: Ulf Hansson Acked-by: Bjorn Helgaas # drivers/pciLink: https://patch.msgid.link/1914558.tdWV9SEqCh@rjwysocki.net List of files: /linux-6.15/drivers/acpi/device_pm.c

37ba91a8 - ACPI: PM: Add acpi_device_fix_up_power_children() function

Sun, 12 Nov 2023 20:36:26 +0000

ACPI: PM: Add acpi_device_fix_up_power_children() functionIn some cases it is necessary to fix-up the power-state of an ACPIdevice's children without touching the ACPI device itself adda new acpi_device_fix_up_power_children() function for this.Signed-off-by: Hans de Goede Cc: 6.6+ # 6.6+Signed-off-by: Rafael J. Wysocki List of files: /linux-6.15/drivers/acpi/device_pm.c

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

Thu, 12 Jan 2023 20:51:24 +0000

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 _S0Wreturning D2 or a shallower power state, so modify acpi_pci_bridge_d3(() toalways 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 powerstate for the target bridge regardless of its ancestor Root Portproperties. Of course, this also causes 'false' to be returned if the RootPort itself is the target and its _S0W returns D2 or a shallower powerstate.However, still allow bridges without _S0W that are power-manageable viaACPI to enter D3 to retain the current code behavior in that case.This fixes problems where a hotplug notification is missed because a bridgeis in D3. That means hot-added devices such as USB4 docks (and the devicesthey contain) and Thunderbolt 3 devices may not work.Link: https://lore.kernel.org/linux-pci/20221031223356.32570-1-mario.limonciello@amd.com/Link: https://lore.kernel.org/r/12155458.O9o76ZdvQC@kreacherReported-by: Mario Limonciello Signed-off-by: Rafael J. Wysocki Signed-off-by: Bjorn Helgaas List of files: /linux-6.15/drivers/acpi/device_pm.c

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

Thu, 29 Sep 2022 16:19:12 +0000

ACPI: PM: Take wake IRQ into consideration when entering suspend-to-idleThis change adds support for ACPI devices that use ExclusiveAndWake orSharedAndWake in their _CRS GpioInt definition (instead of using _PRW),and also provide power resources. Previously the ACPI subsystem had noidea if the device had a wake capable interrupt armed. This resultedin the ACPI device PM system placing the device into D3Cold, and thuscutting 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 Signed-off-by: Rafael J. Wysocki List of files: /linux-6.15/drivers/acpi/device_pm.c

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

Mon, 29 Aug 2022 15:21:43 +0000

ACPI: PM: Fix NULL argument handling in acpi_device_get/set_power()In principle, it should be valid to pass NULL as the ACPI devicepointer to acpi_device_get_power() and acpi_device_set_power() and theyboth are expected to return -EINVAL in that case, but that has beenbroken recently by commit 62fcb99bdf10 ("ACPI: Drop parent field fromstruct acpi_device") which has caused the ACPI device pointer to bedereferenced in these functions before the NULL check.Fix that and while at it make acpi_device_set_power() only use theparent field if the target ACPI device object's ignore_parent flagin not set.Fixes: 62fcb99bdf10 ("ACPI: Drop parent field from struct acpi_device")Reported-by: Dan Carpenter Signed-off-by: Rafael J. Wysocki List of files: /linux-6.15/drivers/acpi/device_pm.c

62fcb99b - ACPI: Drop parent field from struct acpi_device

Wed, 24 Aug 2022 16:59:48 +0000

ACPI: Drop parent field from struct acpi_deviceThe parent field in struct acpi_device is, in fact, redundant,because the dev.parent field in it effectively points to the sameobject and it is used by the driver core.Accordingly, the parent field can be dropped from struct acpi_deviceand for this purpose define acpi_dev_parent() to retrieve a parentstruct acpi_device pointer from the dev.parent field in structacpi_device. Next, update all of the users of the parent fieldin struct acpi_device to use acpi_dev_parent() instead of it anddrop it.While at it, drop the ACPI_IS_ROOT_DEVICE() macro that is only usedin one place in a confusing way.No intentional functional impact.Signed-off-by: Rafael J. Wysocki Acked-by: Mark Brown Acked-by: Mika Westerberg Acked-by: Wei Liu Reviewed-by: Punit Agrawal List of files: /linux-6.15/drivers/acpi/device_pm.c

0efe92b4 - ACPI: PM: Fix acpi_dev_state_d0() kerneldoc

Thu, 18 Aug 2022 05:51:56 +0000

ACPI: PM: Fix acpi_dev_state_d0() kerneldocThe documentation for acpi_dev_state_d0() referred toDocumentation/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 Signed-off-by: Sakari Ailus [ rjw: Subject edits ]Signed-off-by: Rafael J. Wysocki List of files: /linux-6.15/drivers/acpi/device_pm.c

45e9aa1f - ACPI: Rename acpi_bus_get/put_acpi_device()

Wed, 10 Aug 2022 16:14:22 +0000

ACPI: Rename acpi_bus_get/put_acpi_device()Because acpi_bus_get_acpi_device() is completely analogous toacpi_fetch_acpi_dev(), rename it to acpi_get_acpi_dev() andadd 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 theacpi_get_acpi_dev() header in the header file holding them.Signed-off-by: Rafael J. Wysocki Acked-by: Guenter Roeck Reviewed-by: Punit Agrawal List of files: /linux-6.15/drivers/acpi/device_pm.c

a22f18bd - ACPI / MMC: PM: Unify fixing up device power

Mon, 13 Jun 2022 18:36:06 +0000

ACPI / MMC: PM: Unify fixing up device powerIntroduce acpi_device_fix_up_power_extended() for fixing up power ofa device having an ACPI companion in a manner that takes the device'schildren into account and make the MMC code use it in two placesinstead of walking the list of the device ACPI companion's childrendirectly.This will help to eliminate the children list head from structacpi_device as it is redundant and it is used in questionable waysin some places (in particular, locking is needed for walking thelist pointed to it safely, but it is often missing).Signed-off-by: Rafael J. Wysocki Reviewed-by: Andy Shevchenko Acked-by: Adrian Hunter Acked-by: Ulf Hansson List of files: /linux-6.15/drivers/acpi/device_pm.c

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

Fri, 22 Apr 2022 15:13:48 +0000

ACPI: bus: Avoid non-ACPI device objects in walks over childrenWhen walking the children of an ACPI device, take extra care to avoidusing to_acpi_device() on the ones that are not ACPI devices, becausethat 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 deviceone), so it is more straightforward to use.Fixes: b7dd6298db81 ("ACPI: PM: Introduce acpi_dev_power_up_children_with_adr()")Reported-by: kernel test robot BugLink: https://lore.kernel.org/lkml/20220420064725.GB16310@xsang-OptiPlex-9020/Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg List of files: /linux-6.15/drivers/acpi/device_pm.c

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

Thu, 14 Apr 2022 12:58:42 +0000

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 allcases except when the device whose power state is being changed to D0is in that power state already.Make acpi_device_set_power() print a final debug message in that casetoo and while at it, fix the indentation of the "end" label in thisfunction.Signed-off-by: Rafael J. Wysocki List of files: /linux-6.15/drivers/acpi/device_pm.c

b7dd6298 - ACPI: PM: Introduce acpi_dev_power_up_children_with_adr()

Mon, 04 Apr 2022 15:23:13 +0000

ACPI: PM: Introduce acpi_dev_power_up_children_with_adr()Introduce a function powering up all of the children of a given ACPIdevice object that are power-manageable and hold valid _ADR ACPIobjects 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 Reviewed-by: Mika Westerberg List of files: /linux-6.15/drivers/acpi/device_pm.c

f4f3548d - ACPI: PM: Unify debug messages in acpi_device_set_power()

Mon, 04 Apr 2022 15:03:11 +0000

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 withacpi_device_get_power() and other acpi_device_set_power() debugmessages.Signed-off-by: Rafael J. Wysocki List of files: /linux-6.15/drivers/acpi/device_pm.c

255a04cc - ACPI: PM: Change pr_fmt() in device_pm.c

Mon, 04 Apr 2022 15:02:00 +0000

ACPI: PM: Change pr_fmt() in device_pm.cAll messages printed by functions in this file either containthe "ACPI" or "acpi" string regardless of the format, or they don'tneed to contain it at all.In the former case, the "ACPI:" string added by the format isredundant, so drop it from there.Signed-off-by: Rafael J. Wysocki List of files: /linux-6.15/drivers/acpi/device_pm.c

198ee437 - ACPI: PM: Convert debug message in acpi_device_get_power()

Mon, 04 Apr 2022 15:00:45 +0000

ACPI: PM: Convert debug message in acpi_device_get_power()Convert the debug message printed by acpi_device_get_power() toacpi_handle_debug(), because that function is also called whenthe 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 List of files: /linux-6.15/drivers/acpi/device_pm.c

99ece713 - ACPI: Use acpi_fetch_acpi_dev() instead of acpi_bus_get_device()

Fri, 03 Dec 2021 16:37:10 +0000

ACPI: Use acpi_fetch_acpi_dev() instead of acpi_bus_get_device()Modify the ACPI code to use acpi_fetch_acpi_dev() instead ofacpi_bus_get_device() where applicable.Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg Reviewed-by: Hans de Goede List of files: /linux-6.15/drivers/acpi/device_pm.c

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

Mon, 18 Oct 2021 12:17:27 +0000

ACPI: Add a convenience function to tell a device is in D0 stateAdd a convenience function to tell whether a device is in D0 state,primarily for use in drivers' probe or remove functions on busses wherethe custom is to power on the device for the duration of both.Returns false on non-ACPI systems.Suggested-by: Mika Westerberg Signed-off-by: Sakari Ailus Reviewed-by: Tomasz Figa Signed-off-by: Rafael J. Wysocki List of files: /linux-6.15/drivers/acpi/device_pm.c

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

Tue, 22 Jun 2021 21:39:39 +0000

ACPI: PM: postpone bringing devices to D0 unless we need themCurrently ACPI power domain brings devices into D0 state in the "resumeearly" phase. Normally this does not cause any issues, as powering uphappens quickly. However there are peripherals that have certain timingrequirements for powering on, for example some models of Elantouchscreens need 300msec after powering up/releasing reset line beforethey can accept commands from the host. Such devices will dominatethe time spent in early resume phase and cause increase in overallresume time as we wait for early resume to complete before we canproceed to the normal resume stage.There are ways for a driver to indicate that it can tolerate devicebeing in the low power mode and that it knows how to power the deviceback up when resuming, bit that requires changes to individual driversthat may not really care about details of ACPI controlled powermanagement.This change attempts to solve this issue at ACPI power domain level, bypostponing powering up device until we get to the normal resume stage,unless there is early resume handler defined for the device, or devicedoes not declare any resume handlers, in which case we continue poweringup such devices early. This allows us to shave off several hundredmilliseconds of resume time on affected systems.Signed-off-by: Dmitry Torokhov Signed-off-by: Rafael J. Wysocki List of files: /linux-6.15/drivers/acpi/device_pm.c

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

Wed, 09 Jun 2021 18:40:18 +0000

ACPI: Add quirks for AMD Renoir/Lucienne CPUs to force the D3 hintAMD systems from Renoir and Lucienne require that the NVME controlleris put into D3 over a Modern Standby / suspend-to-idlecycle. This is "typically" accomplished using the `StorageD3Enable`property in the _DSD, but this property was introduced after manyof these systems launched and most OEM systems don't have it intheir BIOS.On AMD Renoir without these drives going into D3 over suspend-to-idlethe resume will fail with the NVME controller being reset and a tracelike 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 hasa 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 andnewer APU's have adopted this property, and quirks like this should not benecessary.CC: Shyam-sundar S-k CC: Alexander Deucher CC: Prike Liang Link: https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/power-management-for-storage-hardware-devices-introSigned-off-by: Mario Limonciello Acked-by: Rafael J. Wysocki Tested-by: Julian Sikorski Signed-off-by: Christoph Hellwig List of files: /linux-6.15/drivers/acpi/device_pm.c

2744d7a0 - ACPI: Check StorageD3Enable _DSD property in ACPI code

Wed, 09 Jun 2021 18:40:17 +0000

ACPI: Check StorageD3Enable _DSD property in ACPI codeAlthough first implemented for NVME, this check may be usable byother drivers as well. Microsoft's specification explicitly mentionsthat is may be usable by SATA and AHCI devices. Google also indicatesthat they have used this with SDHCI in a downstream kernel tree thata 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-introSuggested-by: Keith Busch CC: Shyam-sundar S-k CC: Alexander Deucher CC: Rafael J. Wysocki CC: Prike Liang Signed-off-by: Mario Limonciello Reviewed-by: Rafael J. Wysocki Signed-off-by: Christoph Hellwig List of files: /linux-6.15/drivers/acpi/device_pm.c