Messages in this thread |  | | Subject | Re: [PATCH v3] scsi: ufs: Cleanup completed request without interrupt notification | From | Stanley Chu <> | Date | Mon, 13 Jul 2020 10:27:25 +0800 |
| |
Hi Bart and Avri,
On Sun, 2020-07-12 at 18:39 -0700, Bart Van Assche wrote: > On 2020-07-06 06:21, Stanley Chu wrote: > > If somehow no interrupt notification is raised for a completed request > > and its doorbell bit is cleared by host, UFS driver needs to cleanup > > its outstanding bit in ufshcd_abort(). > > How is it possible that no interrupt notification is raised for a completed > request? Is this the result of a hardware shortcoming or rather the result > of how the UFS driver works? In the latter case, is this patch perhaps a > workaround? If so, has it been considered to fix the root cause instead of > implementing a workaround?
Actually this fail is triggered by "error injection" to produce a command timeout event for checking if anything can be improved or fixed.
I agree that "no interrupt notification" may be something wrong in hardware and the root cause shall be fixed in the highest priority. However from this injection, we found ufshcd_abort() indeed has a defect flow for a corner case, so we are looking for the solution to fix the "hole".
What would you think if Linux driver shall consider this case? If this is not necessary, I would drop this patch : )
Thanks a lot, Stanley Chu
> > In section 7.2.3 of the UFS specification I found the following about how > to process request completions: "Software determines if new TRs have > completed since step #2, by repeating one of the two methods described in > step #2. If new TRs have completed, software repeats the sequence from step > #3." Is such a loop perhaps missing from the Linux UFS driver? > > Thanks, > > Bart.
|  |