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.
