Re: [PATCH 1/2] scsi: ufs: core: Release command resources instead of force-completing

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

On Mon, 2026-09-21 at 09:51 -0700, Bart Van Assche wrote:
> > Agreed for the path where SCSI EH drove the reset. The case I am
> > unsure
> > about is the other caller: ufshcd_err_handler() also runs from
> > hba->eh_work, scheduled by ufshcd_check_errors() on UIC and
> > controller
> > errors. Those commands have not timed out and are not on
> > shost->eh_cmd_q, so SCSI EH never finishes them, and the handler
> > leaves
> > them to the reset path on purpose:
> > 
> >       /*
> >        * if host reset is required then skip clearing the pending
> >        * transfers forcefully because they will get cleared during
> >        * host reset and restore
> >        */
> > 
> > Should those simply wait for the block layer timeout and come back
> > through SCSI EH?
> 
> That sounds good to me.
> 
> Thanks,
> 
> Bart.

Hi Bart,

It appears unreasonable to wait for the entire 30 second timeout,
as many UIC errors recover promptly. The resulting 30 second stall
would manifest as a noticeable UI freeze. Maybe we shouldn’t let 
eh_host_reset_handler call the EH handler at all?

Thanks
Peter