Re: [PATCH] ufs: core: Fix the UFSHCD_QUIRK_MCQ_BROKEN_RTC implementation

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

On 10/28/25 6:05 AM, Peter Wang (王信友) wrote:
> On Mon, 2025-10-27 at 08:44 -0700, Bart Van Assche wrote:
>> ufshcd_mcq_sq_cleanup() must return 0 if the command with tag
>> 'task_tag'
>> is no longer in a submission queue. Check whether or not a command is
>> still pending by calling ufshcd_mcq_sqe_search().
> 
> Hi Bart,
> 
> What if the tag is not in the submission queue, but the
> completion queue is still waiting for the tag's response?
> If we return 0, it may cause ufshcd_abort to think it
> succeeded, even though the tag is still in an error state?

ufshcd_mcq_sqe_search() only searches the submission queue. Examining
completion queues is not something ufshcd_mcq_sqe_search() must do.

The UFSHCI driver is based on the assumption that the UFSHCI controller
works correctly and hence passes completions quickly to the host. The
SCSI core only tries to abort a SCSI command after the SCSI timeout has
expired. The smallest SCSI timeout that can be configured is one second.
This is several orders of magnitude larger than the typical time for
passing a completion from the UFSHCI to the host. Hence, I think it is
very unlikely that a completion is present in the host controller and
has not yet reached the host by the time the SCSI core aborts a SCSI
command.

Bart.