Re: [PATCH v4 2/2] ufs: core: requeue aborted request

["Peter Wang (王信友)" <peter.wang@mediatek.com>]

On Fri, 2024-09-20 at 11:39 -0700, Bart Van Assche wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On 9/19/24 7:02 PM, Peter Wang (王信友) wrote:
> > On Thu, 2024-09-19 at 11:49 -0700, Bart Van Assche wrote:
> >> For legacy and MCQ mode, I prefer the following behavior for
> >> ufshcd_abort_all():
> >> * ufshcd_compl_one_cqe() ignores commands with status OCS_ABORTED.
> >> * ufshcd_release_scsi_cmd() is called either by ufshcd_abort_one()
> or
> >>     by ufshcd_abort_all().
> >>
> >> Do you agree with making the changes proposed above?
> > 
> > This might not work, as SDB mode doesn't ignore
> > OCS: INVALID_OCS_VALUE but rather notifies SCSI to requeue.
> 
> cmd->result should be ignored for aborted commands. Hence,
> how OCS_INVALID_COMMAND_STATUS is translated by
> ufshcd_transfer_rsp_status() is not relevant for aborted commands.
> 

Hi Bart,

Okay, I will not handle it and let it remain as it is.


> > So what we need to correct is to notify SCSI to requeue
> > when MCQ mode receives OCS: ABORTED as well.
> 
> Unless the host controller violates the UFSHCI specification, the
> command status is not set for aborted commands in legacy mode. Let's
> keep the code uniform for legacy mode, MCQ mode, compliant and non-
> ompliant controllers and not rely on the command status for aborted
> commands.
> 
> Thanks,
> 
> Bart.
> 

Okay, but under SDB mode, MediaTek might still need a quirk 
to keep the behavior of OCS_ABORTED consistent with 
OCS_INVALID_COMMAND_STATUS.

Thanks.
Peter