Re: [PATCH v2 2/2] scsi: ufs: core: Decouple CQ sweep from request iterator in MCQ

[Stanley Jhu]

On Wed, 2026-09-23 at 14:09 +0800, Peter Wang wrote:
> SCSI reset
> (ufshcd_eh_host_reset_handler) does indeed abort all commands
> by trigger ufshcd_err_handler and call ufshcd_abort_all.
> This shouldn't violate the SCSI API contract. But whether the
> subsequent re-queue (DID_REQUEUE) violates, I haven't seen any
> prohibition?

One detail in ufshcd_err_handler(): ufshcd_eh_host_reset_handler()
sets hba->force_reset, which jumps directly to do_reset and skips
ufshcd_abort_all() (which only aborts commands when no reset is
needed).

On the reset paths, the DID_REQUEUE after ufshcd_hba_stop() does
not describe what happened to those commands. In SDB it is just
the untouched OCS_INVALID_COMMAND_STATUS placeholder from
ufshcd_prepare_req_desc_hdr() that MCQ later mirrored.

Would DID_RESET be a better fit after a controller reset (including
ufshcd_eh_timed_out() right after ufshcd_link_recovery()), similar
to mpi3mr_flush_scmd() and mpt3sas's _scsih_flush_running_cmds()?
It reports what the driver actually knows at that point without
pulling the command into the SCSI error handler.

Thanks,
Stanley