On Tue, 2024-09-24 at 12:36 -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 9/24/24 1:51 AM, Peter Wang (王信友) wrote: > > Is there any corner case that I might have overlooked? > > Maybe I misunderstood how MediaTek controllers work. Anyway, if a > MediaTek controller reports the completion status OCS_ABORTED, is > there any chance that this status will be reported after > ufshcd_release_scsi_cmd() has been called? Is there any chance that > the controller writing OCS_ABORTED into the status field will race > with the host software overwriting that status field while submitting > a new command? > > Thanks, > > Bart. > Hi Bart, Okay, I may not have clearly explained the behavior of the MediaTek UFS controller. In the UFSHCI specification, under the description of UTRLCLR. After writing to UTRLCLR, when UTRLDBR is cleared to 0, the MediaTek UFS controller will simultaneously change the OCS to ABORTED. So, OCS: ABORTED is filled at the moment when ufshcd_clear_cmd successfully waits for DBR to clear. That's why I wrote it like this: ufshcd_try_to_abort_task() // triggers MediaTek controller to fill OCS: ABORTED Therefore, the status should already be ABORTED before ufshcd_release_scsi_cmd, so there shouldn't be a racing issue. Thanks. Peter
