| Message ID | 1619403878-28330-4-git-send-email-cang@codeaurora.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Three minor fixes w.r.t suspend/resume | expand |
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index 090b654..1fd965f 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -9060,7 +9060,8 @@ int ufshcd_system_suspend(struct ufs_hba *hba) cancel_delayed_work_sync(&hba->rpm_dev_flush_recheck_work); - if ((ufs_get_pm_lvl_to_dev_pwr_mode(hba->spm_lvl) == + if (pm_runtime_suspended(hba->dev) && + (ufs_get_pm_lvl_to_dev_pwr_mode(hba->spm_lvl) == hba->curr_dev_pwr_mode) && (ufs_get_pm_lvl_to_link_pwr_state(hba->spm_lvl) == hba->uic_link_state))
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 pass), leaving other contexts still running, e.g., clock gating and clock scaling. When system resume kicks start, concurrency can happen btw ufshcd_resume() and these contexts, leading to various stability issues. Fix it by adding a check against hba's runtime status and allowing fast pass only if hba is runtime suspended, otherwise let system suspend go ahead call ufshcd_suspend(). This can guarantee that these contexts are stopped by either runtime suspend or system suspend. Fixes: 0b257734344aa ("scsi: ufs: optimize system suspend handling") Signed-off-by: Can Guo <cang@codeaurora.org> --- drivers/scsi/ufs/ufshcd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)