Re: [RFC PATCH v1 4/4] ufs: mcq: Added ufshcd_mcq_abort()

[Bao D. Nguyen]

On 3/8/2023 3:25 PM, Bart Van Assche wrote:
> On 3/8/23 14:37, Bao D. Nguyen wrote:
> > On 3/8/2023 11:02 AM, Bart Van Assche wrote:
> > > On 3/7/23 20:01, Bao D. Nguyen wrote:
> > > > +    if (ufshcd_mcq_cqe_search(hba, hwq, tag)) {
> > > > +        dev_err(hba->dev, "%s: cmd found in cq. hwq=%d, tag=%d\n",
> > > > +                __func__, hwq->id, tag);
> > > > +        /*
> > > > +         * The command should not be 'stuck' in the CQ for such a 
> > > > long time.
> > > > +         * Is interrupt missing? Process the CQEs here. If the 
> > > > interrupt is
> > > > +         * invoked at a later time, the CQ will be empty because 
> > > > the CQEs
> > > > +         * are already processed here.
> > > > +         */
> > > > +        ufshcd_mcq_poll_cqe_lock(hba, hwq);
> > > > +        err = SUCCESS;
> > > > +        goto out;
> > > > +    }
> > >
> > > Please remove the above code and also the definition of the 
> > > ufshcd_mcq_cqe_search() function. The SCSI error handler submits an 
> > > abort to deal with command processing timeouts. 
> > > ufshcd_mcq_cqe_search() can only return true in case of a software 
> > > bug at the host side. Addressing such bugs is out of scope for the 
> > > SCSI error handler.
> >
> > This is an attempt to handle the error case similar to SDB mode where 
> > it prints "%s: cmd was completed, but without a notifying intr, tag = 
> > %d" in the ufshcd_abort() function.
> >
> > In this case the command has been completed by the hardware, but some 
> > reasons the software has not processed it. We have seen this print 
> > happened during debug sessions, so the error case does happen in SBL 
> > mode.
> >
> > Are you suggesting we should return error in this case without 
> > calling ufshcd_mcq_poll_cqe_lock()?
>
> What I am asking is to remove ufshcd_mcq_poll_cqe_lock() and all code 
> that depends on that function returning true. Although such code might 
> be useful for SoC debugging, helping with SoC debugging is out of 
> scope for Linux kernel drivers.
I will remove it. In that case, we don't need the first patch of this 
series, so I will remove the first patch as well. Thanks.
> Thanks,
>
> Bart.