[PATCH v2] scsi: ufs: core: cancel RTC work in active-active suspend

[PATCH v2] scsi: ufs: core: cancel RTC work in active-active suspend

[Guangshuo Li]

UFS RTC support schedules ufs_rtc_update_work to periodically update the
device RTC. The work can issue query commands and access the UFS host
controller.

A previous change moved the RTC work cancellation before the PRE_CHANGE
vendor suspend callback to close a race in the common suspend path.
However, the active-active path jumps directly to vops_suspend after
flushing exception handling work and therefore bypasses the
cancellation.

If the RTC work runs while the vendor suspend callback is gating or
otherwise changing hardware state, it can access the controller during
suspend and trigger an SError.

Cancel the RTC work before entering the vendor suspend callback in the
active-active path. Since this path now cancels the work, move the RTC
work scheduling outside the device and link state restoration block in
the resume path. This restarts RTC updates after an active-active
suspend and resume cycle.

Fixes: b0bd84c39289 ("scsi: ufs: core: Fix SError in ufshcd_rtc_work() during UFS suspend")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
v2:
  - Correct the Fixes tag.
  - Restart the RTC update work from the common resume path.

 drivers/ufs/core/ufshcd.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index d3044a3089b5..c3b105b2678e 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -10269,6 +10269,7 @@ static int __ufshcd_wl_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 			req_link_state == UIC_LINK_ACTIVE_STATE) {
 		ufshcd_disable_auto_bkops(hba);
 		flush_work(&hba->eeh_work);
+		cancel_delayed_work_sync(&hba->ufs_rtc_update_work);
 		goto vops_suspend;
 	}
 
@@ -10478,10 +10479,11 @@ static int __ufshcd_wl_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 		if (ret)
 			goto set_old_link_state;
 		ufshcd_set_timestamp_attr(hba);
-		schedule_delayed_work(&hba->ufs_rtc_update_work,
-				      msecs_to_jiffies(UFS_RTC_UPDATE_INTERVAL_MS));
 	}
 
+	schedule_delayed_work(&hba->ufs_rtc_update_work,
+			      msecs_to_jiffies(UFS_RTC_UPDATE_INTERVAL_MS));
+
 	if (ufshcd_keep_autobkops_enabled_except_suspend(hba))
 		ufshcd_enable_auto_bkops(hba);
 	else
-- 
2.43.0

Re: [PATCH v2] scsi: ufs: core: cancel RTC work in active-active suspend

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `ufs_rtc_update_work` is permanently lost if `__ufshcd_wl_suspend()` fails after cancelling it in the active-active suspend path, stopping periodic UFS RTC updates until the next successful suspend/resume cycle.
--

--- Patch [1]: [PATCH v2] scsi: ufs: core: cancel RTC work in active-active suspend ---
commit 9a4850975ce80edc6032f13153aa50eb19b4cc19
Author: Guangshuo Li <lgs201920130244@gmail.com>

scsi: ufs: core: cancel RTC work in active-active suspend
    
This commit cancels the UFS RTC update work in the active-active suspend
path before calling the vendor suspend callback to prevent an SError.

> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index d3044a3089b53..c3b105b2678e4 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -10269,6 +10269,7 @@ static int __ufshcd_wl_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
>  			req_link_state == UIC_LINK_ACTIVE_STATE) {
>  		ufshcd_disable_auto_bkops(hba);
>  		flush_work(&hba->eeh_work);
> +		cancel_delayed_work_sync(&hba->ufs_rtc_update_work);

[Severity: Medium]
If the active-active suspend path fails after this point, is the
ufs_rtc_update_work permanently lost?

When this jumps to the vops_suspend label, if ufshcd_vops_suspend() returns
an error, the function branches to the error handling path:

__ufshcd_wl_suspend() {
    ...
vops_suspend:
	ret = ufshcd_vops_suspend(hba, pm_op, POST_CHANGE);
	if (ret)
		goto set_link_active;
    ...
out:
	...
	if (ret) {
		ufshcd_update_evt_hist(hba, UFS_EVT_WL_SUSP_ERR, (u32)ret);
		hba->clk_gating.is_suspended = false;
		ufshcd_release(hba);
	}
	hba->pm_op_in_progress = false;
	return ret;
}

The error path doesn't appear to re-arm the canceled RTC update work before
returning the error code. Does this mean periodic UFS RTC updates will stay
stopped until the next successful suspend and resume cycle?

>  		goto vops_suspend;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714172726.1736967-1-lgs201920130244@gmail.com?part=1