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

[Bart Van Assche <bvanassche@acm.org>]

On 9/20/26 6:49 AM, Stanley Jhu wrote:
> On 9/18/26 9:06 AM, Bart Van Assche wrote:
>> Forcibly completing SCSI commands from inside the UFS SCSI host reset
>> error handling callback is incompatible with the SCSI core error
>> handler. The "force_compl" behavior should be removed instead of
>> reworking it. If you take a look at the SDB (single doorbell) code you
>> will see that forcibly completing requests doesn't happen for SDB mode.
> 
> Note that ufshcd_mcq_force_compl_one() already checks
> !test_bit(SCMD_STATE_COMPLETE, &cmd->state), so it only completes non-EH
> commands (e.g. during an autonomous ufshcd_err_handler() reset);

What are "non-EH" commands? The SCSI error handler only starts its
error handling strategy after all pending commands have either timed
out or completed.

I think that you are misunderstanding the code. The purpose of the
SCMD_STATE_COMPLETE check is to prevent double completions of SCSI
commands.

> in SDB mode, ufshcd_hba_stop() (HCE = 0) clears UTRLDBR to 0, so
> ufshcd_poll() similarly treats all outstanding_reqs as completed
> right after ufshcd_hba_stop().
> 
> That said, doing this inside ufshcd_host_reset_and_restore() right after
> ufshcd_hba_stop() is indeed the wrong place: at controller stop time we
> should only release LLD resources (ufshcd_release_scsi_cmd()), and
> requeue any remaining non-EH (!SCMD_STATE_COMPLETE) commands with
> DID_REQUEUE only after host/link recovery finishes (so autonomous resets
> neither wake callers mid-reset nor leave in-flight I/O stalled for the
> 30s block layer timeout, similar to autonomous reset handling in
> hisi_sas, megaraid_sas, and smartpqi).

In SDB mode, clearing UTRLDBR will cause all pending commands to be
requeued because the OCS member is initialized to 
OCS_INVALID_COMMAND_STATUS and because ufshcd_transfer_rsp_status()
translates this status value into DID_REQUEUE << 16. I'm concerned
that this approach may cause the deadlines for SCSI commands to be
exceeded. Hence my proposal for MCQ mode not to requeue pending SCSI
commands but instead to let the SCSI error handler decide what to do
with these commands.

Thanks,

Bart.