[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3d509c4b-d66d-2a4a-5fbd-a50a0610ad31@acm.org>
Date: Sun, 12 Jul 2020 18:39:26 -0700
From: Bart Van Assche <bvanassche@....org>
To: Stanley Chu <stanley.chu@...iatek.com>, linux-scsi@...r.kernel.org,
martin.petersen@...cle.com, avri.altman@....com,
alim.akhtar@...sung.com, jejb@...ux.ibm.com
Cc: beanhuo@...ron.com, asutoshd@...eaurora.org, cang@...eaurora.org,
matthias.bgg@...il.com, linux-mediatek@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
kuohong.wang@...iatek.com, peter.wang@...iatek.com,
chun-hung.wu@...iatek.com, andy.teng@...iatek.com,
chaotian.jing@...iatek.com, cc.chou@...iatek.com
Subject: Re: [PATCH v3] scsi: ufs: Cleanup completed request without interrupt
notification
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?
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.
Powered by blists - more mailing lists