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

[Peter Wang <peter.wang@mediatek.com>]

On Fri, 2026-11-06 at 11:15 -0800, Bart Van Assche wrote:
> Hi Peter,
> 
> I don't think that's guaranteed. ufshcd_err_handler() tests
> hba->pm_op_in_progress only once, when it starts, and without holding
> any lock. An error handler that started before that flag was set
> skips
> the early path. For runtime PM it then blocks in
> ufshcd_rpm_get_sync()
> in ufshcd_err_handling_prepare(), waiting for the runtime resume that
> is in progress. If __ufshcd_wl_resume() waits for that error handler
> with flush_work(), neither can proceed. This is the deadlock that
> commit 35dabf4503b9 addressed and that the comment in
> ufshcd_eh_timed_out() describes.

Hi Bart, 

Agreed, there is still a race window. But in practice, the
issue happens when wl suspend/resume sends a command.
But we cannot guarantee that there are no issues with 
power/clock on/off.

> 
> System PM has a similar problem. __ufshcd_wl_suspend() clears
> hba->pm_op_in_progress before it returns, but host_sem stays held
> until ufshcd_wl_resume() returns. An error handler that runs between
> system suspend and system resume therefore takes the regular path and
> blocks in down(&hba->host_sem). A flush_work() call from
> __ufshcd_wl_resume() would then never return.
> 

Yes, unless we refine the system PM flow.

> Additionally, ufshcd_schedule_eh_work() does not queue the error
> handler if the HBA state is UFSHCD_STATE_ERROR. In that case
> queue_work() + flush_work() would not perform any recovery, and
> __ufshcd_wl_resume() would have no way to find out whether recovery
> succeeded.
> 

Agreed, it looks like there are still more scenarios to
consider. And it is also complex too.

> Yes. The cover letter mentions this. That issue predates this series,
> and I think it should be addressed separately instead of holding up
> these fixes.
> 
> Hence, I prefer the approach of v7 of this series.
> 

Sorry, I missed the cover letter. Thanks for the reminder.
Let’s move this patch series forward.

Thanks
Peter