RE: [PATCH v7 3/3] scsi: ufs: core: Limit early link recovery in the error handler to runtime PM

["hoyoung seo" <hy50.seo@samsung.com>]

Hi Bart,

Thank you for the review and for the Reviewed-by on patch 2.

> Has it been considered to use the runtime PM status maintained by the
> PM core instead of introducing a new member variable?

I had not, and it is a good idea. In v8 the error handler checks
whether the runtime status of the WLUN is RPM_SUSPENDING or
RPM_RESUMING, read with READ_ONCE() without power.lock, and the new
member and its updates in ufshcd_wl_runtime_suspend() and
ufshcd_wl_runtime_resume() are gone. runtime_status only exists with
CONFIG_PM and pm_runtime.h has no helper for these two states, so I put
the check into a small helper next to the other ufshcd_rpm_*() helpers
in ufshcd-priv.h that returns false without CONFIG_PM.

Thanks,
Hoyoung

> -----Original Message-----
> From: Bart Van Assche <bvanassche@acm.org>
> Sent: Saturday, November 7, 2026 6:58 AM
> To: HOYOUNG SEO <hy50.seo@samsung.com>; linux-scsi@vger.kernel.org; linux-
> kernel@vger.kernel.org; mkp@kernel.org; martin.petersen@oracle.com;
> stanleyjhu@google.com; alim.akhtar@samsung.com; kwangwon.min@samsung.com;
> kwmad.kim@samsung.com; cpgs@samsung.com; h10.kim@samsung.com
> Subject: Re: [PATCH v7 3/3] scsi: ufs: core: Limit early link recovery in
> the error handler to runtime PM
> 
> On 11/5/26 10:11 PM, HOYOUNG SEO wrote:
>  >  		ufshcd_rpm_get_noresume(hba);
>  > -		if (hba->pm_op_in_progress) {
>  > +		if (READ_ONCE(hba->runtime_pm_in_progress)) {
>  >  			ufshcd_link_recovery(hba);
>  >  			ufshcd_rpm_put(hba);
>  >  			return;
> 
> Has it been considered to use the runtime PM status maintained by the PM
> core instead of introducing a new member variable? While
> ufshcd_wl_runtime_suspend() or ufshcd_wl_runtime_resume() is running,
> hba->ufs_device_wlun->sdev_gendev.power.runtime_status is either
> RPM_SUSPENDING or RPM_RESUMING. During system PM it is either RPM_ACTIVE
> or RPM_SUSPENDED. Reading runtime_status without holding power.lock is not
> more racy than reading the new flag.
> 
> Thanks,
> 
> Bart.