Patch "soundwire: bus: pm_runtime_request_resume on peripheral attachment" has been added to the 5.10-stable tree

[Sasha Levin <sashal@xxxxxxxxxx>]

This is a note to let you know that I've just added the patch titled

    soundwire: bus: pm_runtime_request_resume on peripheral attachment

to the 5.10-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     soundwire-bus-pm_runtime_request_resume-on-periphera.patch
and it can be found in the queue-5.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 5ffae591a68f43d3eb9e9d356ca00f0d5913a430
Author: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx>
Date:   Wed Apr 20 10:32:41 2022 +0800

    soundwire: bus: pm_runtime_request_resume on peripheral attachment
    
    [ Upstream commit e557bca49b812908f380c56b5b4b2f273848b676 ]
    
    In typical use cases, the peripheral becomes pm_runtime active as a
    result of the ALSA/ASoC framework starting up a DAI. The parent/child
    hierarchy guarantees that the manager device will be fully resumed
    beforehand.
    
    There is however a corner case where the manager device may become
    pm_runtime active, but without ALSA/ASoC requesting any functionality
    from the peripherals. In this case, the hardware peripheral device
    will report as ATTACHED and its initialization routine will be
    executed. If this initialization routine initiates any sort of
    deferred processing, there is a possibility that the manager could
    suspend without the peripheral suspend sequence being invoked: from
    the pm_runtime framework perspective, the peripheral is *already*
    suspended.
    
    To avoid such disconnects between hardware state and pm_runtime state,
    this patch adds an asynchronous pm_request_resume() upon successful
    attach/initialization which will result in the proper resume/suspend
    sequence to be followed on the peripheral side.
    
    BugLink: https://github.com/thesofproject/linux/issues/3459
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@xxxxxxxxxxxxxxx>
    Reviewed-by: Rander Wang <rander.wang@xxxxxxxxx>
    Signed-off-by: Bard Liao <yung-chuan.liao@xxxxxxxxxxxxxxx>
    Link: https://lore.kernel.org/r/20220420023241.14335-4-yung-chuan.liao@xxxxxxxxxxxxxxx
    Signed-off-by: Vinod Koul <vkoul@xxxxxxxxxx>
    Stable-dep-of: c40d6b3249b1 ("soundwire: fix enumeration completion")
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index 9c7c8fa7f53e4..831d2d751d5de 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -1740,6 +1740,18 @@ int sdw_handle_slave_status(struct sdw_bus *bus,
 				__func__, slave->dev_num);
 
 			complete(&slave->initialization_complete);
+
+			/*
+			 * If the manager became pm_runtime active, the peripherals will be
+			 * restarted and attach, but their pm_runtime status may remain
+			 * suspended. If the 'update_slave_status' callback initiates
+			 * any sort of deferred processing, this processing would not be
+			 * cancelled on pm_runtime suspend.
+			 * To avoid such zombie states, we queue a request to resume.
+			 * This would be a no-op in case the peripheral was being resumed
+			 * by e.g. the ALSA/ASoC framework.
+			 */
+			pm_request_resume(&slave->dev);
 		}
 	}