summaryrefslogtreecommitdiffstats
path: root/drivers/scsi
diff options
context:
space:
mode:
authorCan Guo <cang@codeaurora.org>2021-04-26 05:48:40 +0200
committerMartin K. Petersen <martin.petersen@oracle.com>2021-04-29 05:15:18 +0200
commitce4f62f9dd8cf43ac044045ed598a0b80ef33890 (patch)
tree523db6cfaa6cc77d8e91de675f68b2d853cb91bc /drivers/scsi
parentscsi: ufs: core: Cancel rpm_dev_flush_recheck_work during system suspend (diff)
downloadlinux-ce4f62f9dd8cf43ac044045ed598a0b80ef33890.tar.xz
linux-ce4f62f9dd8cf43ac044045ed598a0b80ef33890.zip
scsi: ufs: core: Narrow down fast path in system suspend path
If spm_lvl is set to 0 or 1, when system suspend kicks start and HBA is runtime active, system suspend may just bail without doing anything (the fast path), leaving other contexts still running, e.g., clock gating and clock scaling. When system resume kicks start, concurrency can happen between ufshcd_resume() and these contexts, leading to various stability issues. Add a check against HBA's runtime state and allowing fast path only if HBA is runtime suspended, otherwise let system suspend go ahead call ufshcd_suspend(). This will guarantee that these contexts are stopped by either runtime suspend or system suspend. Link: https://lore.kernel.org/r/1619408921-30426-4-git-send-email-cang@codeaurora.org Fixes: 0b257734344a ("scsi: ufs: optimize system suspend handling") Reviewed-by: Daejun Park <daejun7.park@samsung.com> Signed-off-by: Can Guo <cang@codeaurora.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Diffstat (limited to 'drivers/scsi')
-rw-r--r--drivers/scsi/ufs/ufshcd.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index f65f2dc92029..3eb54937f1d8 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8981,6 +8981,7 @@ int ufshcd_system_suspend(struct ufs_hba *hba)
hba->curr_dev_pwr_mode) &&
(ufs_get_pm_lvl_to_link_pwr_state(hba->spm_lvl) ==
hba->uic_link_state) &&
+ pm_runtime_suspended(hba->dev) &&
!hba->dev_info.b_rpm_dev_flush_capable)
goto out;