[PATCH 1/1] scsi: ufs: core: Schedule EH on WLUN resume failure

[PATCH 1/1] scsi: ufs: core: Schedule EH on WLUN resume failure

[Po-Wen Kao]

From: Brian Kao <powenkao@google.com>

On WLUN resume failed, core driver leaves wlun dev in error runtime
PM state without taking further action. To ensure the driver can recover
from such errors, this patch schedules the error handler to perform
a full reset when error occurs during WLUN resume.

Signed-off-by: Brian Kao <powenkao@google.com>
---
 drivers/ufs/core/ufshcd.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index 057678f4c50a..ac4db8484ee5 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -10236,6 +10236,15 @@ static int __ufshcd_wl_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	hba->clk_gating.is_suspended = false;
 	ufshcd_release(hba);
 	hba->pm_op_in_progress = false;
+
+	if (ret) {
+		/* ufshcd_reset_and_restore() might set host to UFSHCD_STATE_ERROR */
+		scoped_guard(spinlock_irqsave, hba->host->host_lock)
+			hba->ufshcd_state = UFSHCD_STATE_RESET;
+
+		ufshcd_force_error_recovery(hba);
+	}
+
 	return ret;
 }
 

base-commit: a9e03ec01ef2633288fd1b506980f54ae41c5a85
-- 
2.52.0.457.g6b5491de43-goog

Re: [PATCH 1/1] scsi: ufs: core: Schedule EH on WLUN resume failure

[Peter Wang (王信友)]

On Fri, 2026-01-23 at 04:54 +0000, Po-Wen Kao wrote:
> From: Brian Kao <powenkao@google.com>
> 
> On WLUN resume failed, core driver leaves wlun dev in error runtime
> PM state without taking further action. To ensure the driver can
> recover
> from such errors, this patch schedules the error handler to perform
> a full reset when error occurs during WLUN resume.
> 

Hi Powen,

May I know at which step in __ufshcd_wl_resume the error occurred?


> Signed-off-by: Brian Kao <powenkao@google.com>
> ---
>  drivers/ufs/core/ufshcd.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index 057678f4c50a..ac4db8484ee5 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -10236,6 +10236,15 @@ static int __ufshcd_wl_resume(struct ufs_hba
> *hba, enum ufs_pm_op pm_op)
>  	hba->clk_gating.is_suspended = false;
>  	ufshcd_release(hba);
>  	hba->pm_op_in_progress = false;
> +
> +	if (ret) {
> +		/* ufshcd_reset_and_restore() might set host to
> UFSHCD_STATE_ERROR */
> +		scoped_guard(spinlock_irqsave, hba->host->host_lock)
> +			hba->ufshcd_state = UFSHCD_STATE_RESET;
> +
> +		ufshcd_force_error_recovery(hba);
> +	}
> +
>  	return ret;
> 

After recovery, is the return value still an error?

Thanks.
Peter


>  }
>  
> 
> base-commit: a9e03ec01ef2633288fd1b506980f54ae41c5a85

Re: [PATCH 1/1] scsi: ufs: core: Schedule EH on WLUN resume failure

[Brian Kao]

[RESEND in plaintext]
Hi Peter,

> May I know at which step in __ufshcd_wl_resume the error occurred?
In our case, ufshcd_reset_and_restore() may return errors due to Link
Startup (LSS) failure.

> After recovery, is the return value still an error?
Since the error handler is scheduled to run asynchronously, the error
still propagates to the runtime PM framework when __ufshcd_wl_resume()
returns. If LSS succeeds during the error handler's execution, the
runtime PM error should be cleared in ufshcd_recover_pm_error(),
returning the host to an operational state.

Best regards,
Brian Kao


On Tue, Jan 27, 2026 at 2:41 PM Brian Kao <powenkao@google.com> wrote:
>
> Hi Peter,
>
> > May I know at which step in __ufshcd_wl_resume the error occurred?
> In our case, ufshcd_reset_and_restore() may return errors due to Link Startup (LSS) failure.
>
> > After recovery, is the return value still an error?
> Since the error handler is scheduled to run asynchronously, the error still propagates to the runtime PM framework when __ufshcd_wl_resume() returns. If LSS succeeds during the error handler's execution, the runtime PM error should be cleared in ufshcd_recover_pm_error(), returning the host to an operational state.
>
> Best regards,
> Brian Kao

Re: [PATCH 1/1] scsi: ufs: core: Schedule EH on WLUN resume failure

[Peter Wang (王信友)]

On Fri, 2026-01-23 at 04:54 +0000, Po-Wen Kao wrote:
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index 057678f4c50a..ac4db8484ee5 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -10236,6 +10236,15 @@ static int __ufshcd_wl_resume(struct ufs_hba
> *hba, enum ufs_pm_op pm_op)
>  	hba->clk_gating.is_suspended = false;
>  	ufshcd_release(hba);
>  	hba->pm_op_in_progress = false;
> +
> +	if (ret) {
> +		/* ufshcd_reset_and_restore() might set host to
> UFSHCD_STATE_ERROR */
> +		scoped_guard(spinlock_irqsave, hba->host->host_lock)
> +			hba->ufshcd_state = UFSHCD_STATE_RESET;
> +
> +		ufshcd_force_error_recovery(hba);
> +	}
> +
>  	return ret;
>  }
>  

Reviewed-by: Peter Wang <peter.wang@mediatek.com>

Re: [PATCH 1/1] scsi: ufs: core: Schedule EH on WLUN resume failure

[Bart Van Assche]

On 1/22/26 8:54 PM, Po-Wen Kao wrote:
> From: Brian Kao <powenkao@google.com>
> 
> On WLUN resume failed, core driver leaves wlun dev in error runtime
> PM state without taking further action. To ensure the driver can recover
> from such errors, this patch schedules the error handler to perform
> a full reset when error occurs during WLUN resume.
> 
> Signed-off-by: Brian Kao <powenkao@google.com>
> ---
>   drivers/ufs/core/ufshcd.c | 9 +++++++++
>   1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index 057678f4c50a..ac4db8484ee5 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -10236,6 +10236,15 @@ static int __ufshcd_wl_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
>   	hba->clk_gating.is_suspended = false;
>   	ufshcd_release(hba);
>   	hba->pm_op_in_progress = false;
> +
> +	if (ret) {
> +		/* ufshcd_reset_and_restore() might set host to UFSHCD_STATE_ERROR */
> +		scoped_guard(spinlock_irqsave, hba->host->host_lock)
> +			hba->ufshcd_state = UFSHCD_STATE_RESET;
> +
> +		ufshcd_force_error_recovery(hba);
> +	}
> +
>   	return ret;
>   }
Isn't the hba->ufshcd_state assignment needed for all
ufshcd_force_error_recovery() callers? I'm wondering whether that
assignment should be moved into ufshcd_force_error_recovery().

Thanks,

Bart.