redonkable
/
alistair23-linux
1
0
Fork 0
Code Releases Activity

scsi: ufs: Make sure clk scaling happens only when HBA is runtime ACTIVE 

[ Upstream commit 73cc291c27 ]

If someone plays with the UFS clk scaling devfreq governor through sysfs,
ufshcd_devfreq_scale may be called even when HBA is not runtime ACTIVE.
This can lead to unexpected error. We cannot just protect it by calling
pm_runtime_get_sync() because that may cause a race condition since HBA
runtime suspend ops need to suspend clk scaling. To fix this call
pm_runtime_get_noresume() and check HBA's runtime status. Only proceed if
HBA is runtime ACTIVE, otherwise just bail.

governor_store
 devfreq_performance_handler
  update_devfreq
   devfreq_set_target
    ufshcd_devfreq_target
     ufshcd_devfreq_scale

Link: https://lore.kernel.org/r/1600758548-28576-1-git-send-email-cang@codeaurora.org
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
5.4-rM2-2.2.x-imx-squashed
Can Guo 2020-09-22 00:09:04 -07:00 committed by Greg Kroah-Hartman
parent b184e98008
commit adad2bc9f3
1 changed files with 7 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
drivers/scsi/ufs/ufshcd.c
View File

@ -1257,8 +1257,15 @@ static int ufshcd_devfreq_target(struct device *dev,
}
spin_unlock_irqrestore(hba->host->host_lock, irq_flags);
pm_runtime_get_noresume(hba->dev);
if (!pm_runtime_active(hba->dev)) {
pm_runtime_put_noidle(hba->dev);
ret = -EAGAIN;
goto out;
}
start = ktime_get();
ret = ufshcd_devfreq_scale(hba, scale_up);
pm_runtime_put(hba->dev);
trace_ufshcd_profile_clk_scaling(dev_name(hba->dev),
(scale_up ? "up" : "down"),