> > 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 : ) Artificially injecting errors is a very common validation mechanism, Provided that you are not breaking anything of the upper-layers, Which I don't think you are doing. Can you refer please to my last comment? > > 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? Could not find that citation. What version of the spec are you using? Thanks, Avri > > > > Thanks, > > > > Bart.
