Skip to content

Commit e0f69c5

Browse files
committed
soundwire: intel_auxdevice: Fix system suspend/resume handling
JIRA: https://issues.redhat.com/browse/RHEL-109251 commit 533a8a6 Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Date: Mon Apr 28 21:50:07 2025 +0200 Before commit bca84a7 ("PM: sleep: Use DPM_FLAG_SMART_SUSPEND conditionally") the runtime PM status of the device in intel_resume() had always been RPM_ACTIVE because setting DPM_FLAG_SMART_SUSPEND had caused the core to call pm_runtime_set_active() for that device during the "noirq" resume phase. For this reason, the pm_runtime_suspended() check in intel_resume() had never triggered and the code depending on it had never run. That had not caused any observable functional issues to appear, so effectively the code in question had never been needed. After commit bca84a7 the core does not call pm_runtime_set_active() for all devices with DPM_FLAG_SMART_SUSPEND set any more and the code depending on the pm_runtime_suspended() check in intel_resume() runs if the device is runtime-suspended prior to a system-wide suspend transition. Unfortunately, when it runs, it breaks things due to the attempt to runtime-resume bus->dev which most likely is not ready for a runtime resume at that point. It also does other more-or-less questionable things. Namely, it calls pm_runtime_idle() for a device with a nonzero runtime PM usage counter which has no effect (all devices have nonzero runtime PM usage counters during system-wide suspend and resume). It also calls pm_runtime_mark_last_busy() for the device even though devices cannot runtime-suspend during system-wide suspend and resume (because their runtime PM usage counters are nonzero) and an analogous call is made in the same function later. Moreover, it sets the runtime PM status of the device to RPM_ACTIVE before activating it. For the reasons listed above, remove that code altogether. On top of that, add a pm_runtime_disable() call to intel_suspend() to prevent the device from being runtime-resumed at any point after intel_suspend() has started to manipulate it because the changes made by that function would be undone by a runtime-suspend of the device. Next, once runtime PM has been disabled, the runtime PM status of the device cannot change, so pm_runtime_status_suspended() can be used instead of pm_runtime_suspended() in intel_suspend(). Finally, make intel_resume() call pm_runtime_set_active() at the end to set the runtime PM status of the device to "active" because it has just been activated and re-enable runtime PM for it after that. Additionally, drop the setting of DPM_FLAG_SMART_SUSPEND from the driver because it has no effect on devices handled by it. Fixes: bca84a7 ("PM: sleep: Use DPM_FLAG_SMART_SUSPEND conditionally") Reported-by: Bard Liao <yung-chuan.liao@linux.intel.com> Tested-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://patch.msgid.link/12680420.O9o76ZdvQC@rjwysocki.net Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
1 parent 76089f0 commit e0f69c5

File tree

1 file changed

+13
-23
lines changed

1 file changed

+13
-23
lines changed

drivers/soundwire/intel_auxdevice.c

Lines changed: 13 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -345,9 +345,6 @@ static int intel_link_probe(struct auxiliary_device *auxdev,
345345
/* use generic bandwidth allocation algorithm */
346346
sdw->cdns.bus.compute_params = sdw_compute_params;
347347

348-
/* avoid resuming from pm_runtime suspend if it's not required */
349-
dev_pm_set_driver_flags(dev, DPM_FLAG_SMART_SUSPEND);
350-
351348
ret = sdw_bus_master_add(bus, dev, dev->fwnode);
352349
if (ret) {
353350
dev_err(dev, "sdw_bus_master_add fail: %d\n", ret);
@@ -632,15 +629,18 @@ static int __maybe_unused intel_suspend(struct device *dev)
632629
return 0;
633630
}
634631

635-
if (pm_runtime_suspended(dev)) {
632+
/* Prevent runtime PM from racing with the code below. */
633+
pm_runtime_disable(dev);
634+
635+
if (pm_runtime_status_suspended(dev)) {
636636
dev_dbg(dev, "pm_runtime status: suspended\n");
637637

638638
clock_stop_quirks = sdw->link_res->clock_stop_quirks;
639639

640640
if ((clock_stop_quirks & SDW_INTEL_CLK_STOP_BUS_RESET) ||
641641
!clock_stop_quirks) {
642642

643-
if (pm_runtime_suspended(dev->parent)) {
643+
if (pm_runtime_status_suspended(dev->parent)) {
644644
/*
645645
* paranoia check: this should not happen with the .prepare
646646
* resume to full power
@@ -707,7 +707,6 @@ static int __maybe_unused intel_resume(struct device *dev)
707707
struct sdw_cdns *cdns = dev_get_drvdata(dev);
708708
struct sdw_intel *sdw = cdns_to_intel(cdns);
709709
struct sdw_bus *bus = &cdns->bus;
710-
int link_flags;
711710
int ret;
712711

713712
if (bus->prop.hw_disabled || !sdw->startup_done) {
@@ -716,23 +715,6 @@ static int __maybe_unused intel_resume(struct device *dev)
716715
return 0;
717716
}
718717

719-
if (pm_runtime_suspended(dev)) {
720-
dev_dbg(dev, "pm_runtime status was suspended, forcing active\n");
721-
722-
/* follow required sequence from runtime_pm.rst */
723-
pm_runtime_disable(dev);
724-
pm_runtime_set_active(dev);
725-
pm_runtime_mark_last_busy(dev);
726-
pm_runtime_enable(dev);
727-
728-
pm_runtime_resume(bus->dev);
729-
730-
link_flags = md_flags >> (bus->link_id * 8);
731-
732-
if (!(link_flags & SDW_INTEL_MASTER_DISABLE_PM_RUNTIME_IDLE))
733-
pm_runtime_idle(dev);
734-
}
735-
736718
ret = sdw_intel_link_power_up(sdw);
737719
if (ret) {
738720
dev_err(dev, "%s failed: %d\n", __func__, ret);
@@ -752,6 +734,14 @@ static int __maybe_unused intel_resume(struct device *dev)
752734
return ret;
753735
}
754736

737+
/*
738+
* Runtime PM has been disabled in intel_suspend(), so set the status
739+
* to active because the device has just been resumed and re-enable
740+
* runtime PM.
741+
*/
742+
pm_runtime_set_active(dev);
743+
pm_runtime_enable(dev);
744+
755745
/*
756746
* after system resume, the pm_runtime suspend() may kick in
757747
* during the enumeration, before any children device force the

0 commit comments

Comments
 (0)