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
