On Fri, 2024-08-23 at 09:20 -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 8/23/24 3:07 AM, peter.wang@xxxxxxxxxxxx wrote:
> > diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> > index 0b3d0c8e0dda..4bcd4e5b62bd 100644
> > --- a/drivers/ufs/core/ufshcd.c
> > +++ b/drivers/ufs/core/ufshcd.c
> > @@ -6482,8 +6482,12 @@ static bool ufshcd_abort_one(struct request
> *rq, void *priv)
> > if (!hwq)
> > return 0;
> > spin_lock_irqsave(&hwq->cq_lock, flags);
> > -if (ufshcd_cmd_inflight(lrbp->cmd))
> > +if (ufshcd_cmd_inflight(lrbp->cmd)) {
> > +struct scsi_cmnd *cmd = lrbp->cmd;
> > +set_host_byte(cmd, DID_REQUEUE);
> > ufshcd_release_scsi_cmd(hba, lrbp);
> > +scsi_done(cmd);
> > +}
> > spin_unlock_irqrestore(&hwq->cq_lock, flags);
> > }
>
> Hmm ... isn't the ufshcd_complete_requests() call in
> ufshcd_abort_all()
> expected to complete these commands? Can the above change lead to
> scsi_done() being called twice, something that is not allowed?
>
> Bart.
>
Hi Bart,
ufshcd_complete_requests call in ufshcd_abort_all() with
force_compl = false in mcq mode, which only check cq is empty or not.
For already abort cmd, no response will come back and no cq
slot insert by hardware, which we need release this cmd and scsi done,
same as force_compl = true does.
Thanks
Peter
