[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7734408c-82e0-4b4a-930b-401bfa26161f@acm.org>
Date: Tue, 3 Sep 2024 12:42:34 -0700
From: Bart Van Assche <bvanassche@....org>
To: Kiwoong Kim <kwmad.kim@...sung.com>, linux-scsi@...r.kernel.org,
linux-kernel@...r.kernel.org, huobean@...il.com, alim.akhtar@...sung.com,
avri.altman@....com, jejb@...ux.ibm.com, martin.petersen@...cle.com,
beanhuo@...ron.com, adrian.hunter@...el.com, h10.kim@...sung.com,
hy50.seo@...sung.com, sh425.lee@...sung.com, kwangwon.min@...sung.com,
junwoo80.lee@...sung.com, wkon.kim@...sung.com
Subject: Re: [RESEND PATCH v2 2/2] scsi: ufs: ufs-exynos: implement
override_cqe_ocs
On 9/1/24 9:26 PM, Kiwoong Kim wrote:
> Exynos host reports OCS_ABORT when a command is nullifed
> or cleaned up with MCQ enabled.
That is the behavior that is required by the UFSHCI 4.0 standard. Hence,
handling the OCS_ABORTED response should be the same for all host
controllers and no new callback function should be introduced to handle
nullified commands.
> I think the command in those
> situations should be issued again, rather than fail, because
> when some conditions that caused the nullification or cleaning up
> disppears after recovery, the command could be processed.
ufshcd_mcq_nullify_sqe() is called by ufshcd_mcq_sqe_search() and the
latter function is called by ufshcd_mcq_abort(). It is up to the SCSI
core to decide whether or not commands aborted by ufshcd_mcq_abort()
should be resubmitted. This is not something the host driver should
decide about.
Thanks,
Bart.
Powered by blists - more mailing lists