[PATCH v6 2/2] ufs: core: requeue aborted request

[Peter Wang (王信友)]

On Wed, 2024-09-11 at 12:37 -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/11/24 2:56 AM, peter.wang at mediatek.com wrote:
> > ufshcd_abort_all forcibly aborts all on-going commands and the host
> > controller will automatically fill in the OCS field of the
> corresponding
> > response with OCS_ABORTED based on different working modes.
> > 
> > MCQ mode: aborts a command using SQ cleanup, The host controller
> > will post a Completion Queue entry with OCS = ABORTED.
> > 
> > SDB mode: aborts a command using UTRLCLR. Task Management response
> > which means a Transfer Request was aborted.
> 
> I think this is incorrect. The UFSHCI specification does not require
> a
> host controller to set the OCS field if a SCSI command is aborted by
> the
> ABORT TMF nor if its resources are freed by writing into the UTRLCLR
> register.
> 

Hi Bart,

I'm thinking of removing the SDB descriptive comment, so that 
it can be applicable in cases with OCS ABORTED, and it won't 
matter if there isn't OCS ABORTED because setting this flag 
won't have any effect. 
Or I add more MCQ check only set this flag in MCQ mode. 
What do you think?



> > @@ -5404,7 +5405,10 @@ ufshcd_transfer_rsp_status(struct ufs_hba
> *hba, struct ufshcd_lrb *lrbp,
> >   }
> >   break;
> >   case OCS_ABORTED:
> > -result |= DID_ABORT << 16;
> > +if (lrbp->abort_initiated_by_eh)
> > +result |= DID_REQUEUE << 16;
> > +else
> > +result |= DID_ABORT << 16;
> >   break;
> 
> Is the above change necessary? ufshcd_abort_one() aborts commands by
> submitting an ABORT TMF. Hence, ufshcd_transfer_rsp_status() won't be
> called if aborting the command succeeds.
> 

Yes, Just becasue ABORT TMF COMPLETE, in spec description:
"A response of FUNCTION COMPLETE shall indicate that the 
command was aborted or was not in the task set. In either case, 
the SCSI target device shall guarantee that no further 
requests or responses are sent from the command."

So at this time, the device will not have a corresponding 
response coming back. The host controller will automatically 
fill in the response for the corresponding command based on 
the results of SQ cleanup (MCQ) or UTRLCLR (DBR, mediatek), 
with the COS content being ABORTED by interrupt.
ISR will handle the response which is from host, not from device.


> > @@ -7561,6 +7551,21 @@ int ufshcd_try_to_abort_task(struct ufs_hba
> *hba, int tag)
> >   goto out;
> >   }
> >   
> > +/*
> > + * When the host software receives a "FUNCTION COMPLETE", set flag
> > + * to requeue command after receive response with OCS_ABORTED
> > + * SDB mode: UTRLCLR Task Management response which means a
> Transfer
> > + *           Request was aborted.
> > + * MCQ mode: Host will post to CQ with OCS_ABORTED after SQ
> cleanup
> > + *
> > + * This flag is set because error handler ufshcd_abort_all
> forcibly
> > + * aborts all commands, and the host controller will automatically
> > + * fill in the OCS field of the corresponding response with
> OCS_ABORTED.
> > + * Therefore, upon receiving this response, it needs to be
> requeued.
> > + */
> > +if (!err && ufshcd_eh_in_progress(hba))
> > +lrbp->abort_initiated_by_eh = true;
> > +
> >   err = ufshcd_clear_cmd(hba, tag);
> >   if (err)
> >   dev_err(hba->dev, "%s: Failed clearing cmd at tag %d, err %d\n",
> 
> The above change will cause lrbp->abort_initiated_by_eh to be set not
> only if the UFS error handler decides to abort a command but also if
> the
> SCSI core decides to abort a command. I think this is wrong.
> 
> Is this patch 2/2 necessary or is patch 1/2 perhaps sufficient?
> 
> Thanks,
> 
> Bart.

Sorry, I might have missed something, but I didn't see 
scsi abort (ufshcd_abort) calling ufshcd_set_eh_in_progress. 
So, during a SCSI abort, ufshcd_eh_in_progress(hba) 
should return false and not set this flag, right?


Additionally, SCSI abort (ufshcd_abort) will have different
return values for MCQ mode and DBR mode when the device 
does not respond with a response.
MCQ mode will receivce OCS_ABORTED (nullify)
	case OCS_ABORTED:
		result |= DID_ABORT << 16;
		break;
But DBR mode, OCS won't change, it is 0x0F
	case OCS_INVALID_COMMAND_STATUS:
		result |= DID_REQUEUE << 16;
		break;
In this case, should we also return DID_ABORT for DBR mode?


Thanks.
Peter