[PATCH v6 0/2] ufs: fix the abort path of device management commands in MCQ mode

[PATCH v6 0/2] ufs: fix the abort path of device management commands in MCQ mode

[Kiwoong Kim]

This series fixes how a timed-out device management command (query, NOP)
is aborted in MCQ mode.

Patch 1 makes ufshcd_try_to_abort_task() skip the task management path
for device management commands and clear them with ufshcd_clear_cmd()
directly, as the single doorbell path in ufshcd_abort() already does.
Since the conversion to scsi_get_internal_cmd(), ufshcd_mcq_abort() sends
these commands to the QUERY TASK / ABORT TASK path, which is meant for
SCSI I/O commands.

Patch 2 makes ufshcd_mcq_sq_cleanup() wait for the OCS of a device
management command to be updated after SQ cleanup. UFSHCI does not
specify the order between the OCS update and the SQ_CUS update. Without
the wait, a late completion of the cleaned-up query can race with the
retry of that query, which leaves the host with two query contexts and
raises IS.UTPES.

Patch 2 depends on patch 1. Without patch 1, ufshcd_mcq_sq_cleanup() is
reached for a device management command only if the ABORT TASK TMF
succeeds.

Changes since v5:
- Read the OCS under hwq->cq_lock again, as in v4. Without the lock,
  ufshcd_mcq_sq_cleanup() can observe the OCS update and return while
  ufshcd_compl_one_cqe() has not yet called scsi_done(). A retry that
  reuses the reserved request can then be completed by that pending
  scsi_done() call (Sashiko).
- Explain the need for cq_lock in a comment and in the patch 2 commit
  message.

Link: https://lore.kernel.org/linux-scsi/20261104094914.180788-1-kwmad.kim@samsung.com/

Changes since v4:
- Read the OCS in ufshcd_mcq_sq_cleanup() with READ_ONCE() directly and
  drop the cq_lock and the ufshcd_mcq_read_ocs() helper, per review. (Bart)
- Report an error when the OCS poll times out. (Bart)

Link: https://lore.kernel.org/linux-scsi/cover.1793598099.git.kwmad.kim@samsung.com/

Changes since v3:
- Split the v3 patch into two patches: the abort path fix and
  the OCS poll after SQ cleanup (Bean Huo).
- Explain in patch 1 that the problem is only reachable since the
  scsi_get_internal_cmd() conversion and add the corresponding Fixes tag,
  per review.
- Add a Fixes tag to patch 2. (Bean Huo)
- Fix the step numbering of the timeline in the patch 2 commit message.

Link: https://lore.kernel.org/linux-scsi/20261030111045.982094-1-kwmad.kim@samsung.com/

Changes since v2:
- Use read_poll_timeout() for the OCS poll in ufshcd_mcq_sq_cleanup().
  The open-coded loop did not re-read the OCS after the timeout, so it
  could return a false -ETIMEDOUT if the OCS was updated while sleeping
  in the last iteration (Sashiko).

Link: https://lore.kernel.org/linux-scsi/20261030093645.790159-1-kwmad.kim@samsung.com/

Changes since v1:
- Limit the OCS poll in ufshcd_mcq_sq_cleanup() to device management
  commands. ufshcd_compl_one_cqe() copies the OCS from the CQE into the
  UTRD only for them, so for SCSI commands the poll always ran for
  MCQ_POLL_US and then failed with -ETIMEDOUT (Sashiko).
- Return -ETIMEDOUT only if OCS is still OCS_INVALID_COMMAND_STATUS
  after the poll. OCS_ABORTED, which the host controller reports for
  the cleaned-up request, is no longer treated as a cleanup failure
  (Sashiko).
- Update the commit message to match.

Link: https://lore.kernel.org/linux-scsi/20261030083311.602909-1-kwmad.kim@samsung.com/

Kiwoong Kim (2):
  ufs: core: skip ABORT TASK for device management commands
  ufs: mcq: poll OCS after sq cleanup for device management commands

 drivers/ufs/core/ufs-mcq.c | 29 +++++++++++++++++++++++++++++
 drivers/ufs/core/ufshcd.c  |  4 ++++
 2 files changed, 33 insertions(+)

-- 
2.43.0

[PATCH v6 1/2] ufs: core: skip ABORT TASK for device management commands

[Kiwoong Kim]

In MCQ mode, ufshcd_mcq_abort() falls through to ufshcd_try_to_abort_task()
for all timed-out commands. However, device management commands (query, NOP)
use reserved requests and are not SCSI I/O commands. The ABORT TASK task
management function is designed for SCSI I/O UPIUs and is not applicable to
device management UPIUs.

This is only reachable since device management commands were converted to
scsi_get_internal_cmd(); before that, a timed-out query was handled by
ufshcd_wait_for_dev_cmd() -> ufshcd_clear_cmd() and never reached
ufshcd_try_to_abort_task().

Fix this by checking ufshcd_is_scsi_cmd() in ufshcd_try_to_abort_task(). When
the request is a reserved (device management) command, skip the TM path and
call ufshcd_clear_cmd() directly instead.

Fixes: 08b12cda6c44 ("scsi: ufs: core: Switch to scsi_get_internal_cmd()")
Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reported-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/ufs/core/ufshcd.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index bcc2512bf34b..7fc80926eeec 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -8046,6 +8046,9 @@ int ufshcd_try_to_abort_task(struct ufs_hba *hba, int tag)
 
 	lrbp = scsi_cmd_priv(cmd);
 
+	if (!ufshcd_is_scsi_cmd(cmd))
+		goto clear_cmd;
+
 	for (poll_cnt = 100; poll_cnt; poll_cnt--) {
 		err = ufshcd_issue_tm_cmd(hba, lrbp->lun, tag, UFS_QUERY_TASK,
 					  &resp);
@@ -8091,6 +8094,7 @@ int ufshcd_try_to_abort_task(struct ufs_hba *hba, int tag)
 		return err;
 	}
 
+clear_cmd:
 	err = ufshcd_clear_cmd(hba, tag);
 	if (err)
 		dev_err(hba->dev, "%s: Failed clearing cmd at tag %d, err %d\n",
-- 
2.43.0

Re: [PATCH v6 1/2] ufs: core: skip ABORT TASK for device management commands

[Bart Van Assche]

On 11/4/26 4:43 PM, Kiwoong Kim wrote:
 > @@ -8046,6 +8046,9 @@ int ufshcd_try_to_abort_task(struct ufs_hba 
*hba, int tag)
 >
 >  	lrbp = scsi_cmd_priv(cmd);
 >
 > +	if (!ufshcd_is_scsi_cmd(cmd))
 > +		goto clear_cmd;
 > +

ufshcd_abort() already has the following code for the SDB path:

	if (blk_mq_is_reserved_rq(rq))
		err = ufshcd_clear_cmd(hba, tag);
	else
		err = ufshcd_try_to_abort_task(hba, tag);

and ufshcd_abort_one() skips reserved requests. Hence, ufshcd_mcq_abort()
is the only caller that can pass a device management command to
ufshcd_try_to_abort_task(). Please handle this the same way for both
paths. Either add the check in ufshcd_mcq_abort(), similar to the SDB
path, or keep it in ufshcd_try_to_abort_task() and remove the now
redundant check from ufshcd_abort().

If the check stays in ufshcd_try_to_abort_task(), please also update
its kernel-doc header. That header says that UFS_QUERY_TASK and
UFS_ABORT_TASK are sent unconditionally.

 > Fixes: 08b12cda6c44 ("scsi: ufs: core: Switch to 
scsi_get_internal_cmd()")
 > Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
 > Reviewed-by: Bean Huo <beanhuo@micron.com>
 > Reported-by: Bart Van Assche <bvanassche@acm.org>

Please move the Reported-by: tag above the Signed-off-by: tag.
checkpatch also expects a Closes: tag after Reported-by:.

Thanks,

Bart.

RE: [PATCH v6 1/2] ufs: core: skip ABORT TASK for device management commands

[Kiwoong Kim]

Kiwoong Kim
BRs.

> -----Original Message-----
> From: Bart Van Assche <bvanassche@acm.org>
> Sent: Thursday, November 5, 2026 10:28 AM
> To: Kiwoong Kim <kwmad.kim@samsung.com>; linux-scsi@vger.kernel.org;
> linux-kernel@vger.kernel.org; alim.akhtar@samsung.com; jejb@linux.ibm.com;
> martin.petersen@oracle.com; kwangwon.min@samsung.com; hy50.seo@samsung.com;
> cpgs@samsung.com; h10.kim@samsung.com
> Cc: stable@vger.kernel.org; stanleyjhu@google.com; Bean Huo
> <beanhuo@micron.com>
> Subject: Re: [PATCH v6 1/2] ufs: core: skip ABORT TASK for device
> management commands
> 
> On 11/4/26 4:43 PM, Kiwoong Kim wrote:
>  > @@ -8046,6 +8046,9 @@ int ufshcd_try_to_abort_task(struct ufs_hba *hba,
> int tag)  >
>  >  	lrbp = scsi_cmd_priv(cmd);
>  >
>  > +	if (!ufshcd_is_scsi_cmd(cmd))
>  > +		goto clear_cmd;
>  > +
> 
> ufshcd_abort() already has the following code for the SDB path:
> 
> 	if (blk_mq_is_reserved_rq(rq))
> 		err = ufshcd_clear_cmd(hba, tag);
> 	else
> 		err = ufshcd_try_to_abort_task(hba, tag);
> 
> and ufshcd_abort_one() skips reserved requests. Hence, ufshcd_mcq_abort()
> is the only caller that can pass a device management command to
> ufshcd_try_to_abort_task(). Please handle this the same way for both paths.
> Either add the check in ufshcd_mcq_abort(), similar to the SDB path, or
> keep it in ufshcd_try_to_abort_task() and remove the now redundant check
> from ufshcd_abort().
> 
> If the check stays in ufshcd_try_to_abort_task(), please also update its
> kernel-doc header. That header says that UFS_QUERY_TASK and UFS_ABORT_TASK
> are sent unconditionally.
> 
>  > Fixes: 08b12cda6c44 ("scsi: ufs: core: Switch to
> scsi_get_internal_cmd()")
>  > Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>  > Reviewed-by: Bean
> Huo <beanhuo@micron.com>  > Reported-by: Bart Van Assche
> <bvanassche@acm.org>
> 
> Please move the Reported-by: tag above the Signed-off-by: tag.
> checkpatch also expects a Closes: tag after Reported-by:.
> 
> Thanks,
> 
> Bart.

RE: [PATCH v6 1/2] ufs: core: skip ABORT TASK for device management commands

[Kiwoong Kim]

>  > @@ -8046,6 +8046,9 @@ int ufshcd_try_to_abort_task(struct ufs_hba *hba,
> int tag)  >
>  >  	lrbp = scsi_cmd_priv(cmd);
>  >
>  > +	if (!ufshcd_is_scsi_cmd(cmd))
>  > +		goto clear_cmd;
>  > +
> 
> ufshcd_abort() already has the following code for the SDB path:
> 
> 	if (blk_mq_is_reserved_rq(rq))
> 		err = ufshcd_clear_cmd(hba, tag);
> 	else
> 		err = ufshcd_try_to_abort_task(hba, tag);
> 
> and ufshcd_abort_one() skips reserved requests. Hence, ufshcd_mcq_abort()
> is the only caller that can pass a device management command to
> ufshcd_try_to_abort_task(). Please handle this the same way for both paths.
> Either add the check in ufshcd_mcq_abort(), similar to the SDB path, or
> keep it in ufshcd_try_to_abort_task() and remove the now redundant check
> from ufshcd_abort().
> 
> If the check stays in ufshcd_try_to_abort_task(), please also update its
> kernel-doc header. That header says that UFS_QUERY_TASK and UFS_ABORT_TASK
> are sent unconditionally.
> 
>  > Fixes: 08b12cda6c44 ("scsi: ufs: core: Switch to
> scsi_get_internal_cmd()")
>  > Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>  > Reviewed-by: Bean
> Huo <beanhuo@micron.com>  > Reported-by: Bart Van Assche
> <bvanassche@acm.org>
> 
> Please move the Reported-by: tag above the Signed-off-by: tag.
> checkpatch also expects a Closes: tag after Reported-by:.
> 
> Thanks,
> 
> Bart.

Got it.

Kiwoong Kim
BRs.

[PATCH v6 2/2] ufs: mcq: poll OCS after sq cleanup for device management commands

[Kiwoong Kim]

Extend ufshcd_mcq_sq_cleanup() to poll the OCS field in the UTRD of a
device management command after a successful SQ_CUS poll. UFSHCI does not
specify the order between the OCS update and the SQ_CUS update, so OCS may
still be stale when cleanup returns. Without this poll, a late response to
a timed-out query can arrive while a retry is already in flight, leaving
the host with two query contexts and raising IS.UTPES.

The poll is limited to device management commands because
ufshcd_compl_one_cqe() copies the OCS from the CQE into the UTRD only for
them. For SCSI commands, the OCS in the UTRD stays
OCS_INVALID_COMMAND_STATUS, so polling it would always time out.

The poll waits until OCS is no longer OCS_INVALID_COMMAND_STATUS or
MCQ_POLL_US elapses. -ETIMEDOUT is returned only if OCS is still
OCS_INVALID_COMMAND_STATUS after the poll. Any other value, such as
OCS_ABORTED reported by the host controller for the cleaned-up request,
means the cleanup has completed.

The OCS is read under hwq->cq_lock. ufshcd_compl_one_cqe() updates the
OCS under that lock before it sets cmd->result and calls scsi_done().
Without the lock, cleanup could observe the new OCS and return while the
completion is still running. The abort could then finish the command and
a retry could reuse the same reserved request before the pending
scsi_done() call, which would then complete the retry prematurely.

Here is the timeline of an actual case for this that happened with kernel 6.18.
1. The host sent a query but the device didn't respond with it for a long time.

[ 7384.156142] [4:  kworker/u40:5:10671] exynos-ufs 38300000.ufs: ufshcd_mcq_sq_cleanup, hwq 0: cleanup return code (RTC) 0
[ 7384.156154] [4:  kworker/u40:5:10671] exynos-ufs 38300000.ufs: ufshcd_query_flag: Sending flag query for idn 14 failed, err = -11

2. So after the query was timed out, the driver did SQ cleanup.
Then the host updated CQ update and raised IS.CQES,
Unfortunately, complete() was called the driver's ISR afterward.

3. The driver started to retried the query. In the meantime, it set OCS to 0xF.
Then the driver didn't wait for completion due to the previous complete() call,
and just checked OCS.

[ 7384.156163] [4:  kworker/u40:5:10671] exynos-ufs 38300000.ufs: ufshcd_query_flag: Sending flag query for idn 14 failed, err = 15

4. The driver retried the query again, but the device didn't return anything,
so the query was also timed-out.

[ 7385.660108] [3:  kworker/u40:5:10671] exynos-ufs 38300000.ufs: ufshcd_query_flag: Sending flag query for idn 14 failed, err = -11

5. A few seconds later, the device returned the response of the 1st query,
but since the host was holding two query contexts and couldn't handle it,
it raised IS.UTPES.

Fixes: 8d7290348992 ("scsi: ufs: mcq: Add supporting functions for MCQ abort")
Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
---
 drivers/ufs/core/ufs-mcq.c | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/drivers/ufs/core/ufs-mcq.c b/drivers/ufs/core/ufs-mcq.c
index 8106d55f4041..44214616d9db 100644
--- a/drivers/ufs/core/ufs-mcq.c
+++ b/drivers/ufs/core/ufs-mcq.c
@@ -550,6 +550,18 @@ static int ufshcd_mcq_sq_start(struct ufs_hba *hba, struct ufs_hw_queue *hwq)
 	return err;
 }
 
+/*
+ * ufshcd_compl_one_cqe() updates the OCS under cq_lock before calling
+ * scsi_done(). Holding cq_lock here makes sure that the completion has
+ * finished once the updated OCS is observed.
+ */
+static enum utp_ocs ufshcd_mcq_read_ocs(struct ufs_hw_queue *hwq,
+					struct ufshcd_lrb *lrbp)
+{
+	guard(spinlock_irqsave)(&hwq->cq_lock);
+	return READ_ONCE(lrbp->utr_descriptor_ptr->header.ocs);
+}
+
 /**
  * ufshcd_mcq_sq_cleanup - Clean up submission queue resources
  * associated with the pending command.
@@ -609,6 +621,23 @@ int ufshcd_mcq_sq_cleanup(struct ufs_hba *hba, int task_tag)
 			 __func__, id,
 			 FIELD_GET(SQ_ICU_ERR_CODE_MASK, readl(reg)));
 
+	/*
+	 * For device management commands, there is no order guaranteed between
+	 * OCS update and CUS update, which is why we need to wait here. SCSI
+	 * commands are excluded because the OCS in their UTRD is not updated
+	 * from the CQE.
+	 */
+	if (!err && blk_mq_is_reserved_rq(rq)) {
+		enum utp_ocs ocs;
+
+		err = read_poll_timeout(ufshcd_mcq_read_ocs, ocs,
+					ocs != OCS_INVALID_COMMAND_STATUS, 20,
+					MCQ_POLL_US, false, hwq, lrbp);
+		if (err)
+			dev_err(hba->dev, "%s: OCS not updated. hwq=%d, tag=%d err=%d\n",
+				__func__, id, task_tag, err);
+	}
+
 	if (ufshcd_mcq_sq_start(hba, hwq))
 		err = -ETIMEDOUT;
 
-- 
2.43.0

Re: [PATCH v6 2/2] ufs: mcq: poll OCS after sq cleanup for device management commands

[Bart Van Assche]

On 11/4/26 4:43 PM, Kiwoong Kim wrote:
 > Here is the timeline of an actual case for this that happened with 
kernel 6.18.
 > [ ... ]
 > 2. So after the query was timed out, the driver did SQ cleanup.
 > Then the host updated CQ update and raised IS.CQES,
 > Unfortunately, complete() was called the driver's ISR afterward.

This timeline describes code that no longer exists upstream. Since
commit 08b12cda6c44 ("scsi: ufs: core: Switch to
scsi_get_internal_cmd()"), the device management path no longer calls
complete(). Please describe the race in terms of the current code:
the query times out, the SCSI error handler calls ufshcd_abort() ->
ufshcd_mcq_abort() -> ufshcd_mcq_sq_cleanup(), the request is finished,
and the retry reuses the same reserved tag, struct scsi_cmnd and devman
UCD. A late CQE for the first query then maps to hba->dev_cmd.tag via
devman_ucd_dma_addr and completes the retry too early. That is why
cq_lock matters here. Please also keep lines in the patch description
at 75 columns or less.

 > +static enum utp_ocs ufshcd_mcq_read_ocs(struct ufs_hw_queue *hwq,
 > +					struct ufshcd_lrb *lrbp)
 > +{
 > +	guard(spinlock_irqsave)(&hwq->cq_lock);
 > +	return READ_ONCE(lrbp->utr_descriptor_ptr->header.ocs);
 > +}

READ_ONCE() is not necessary since the OCS is read with cq_lock held.

 > +	if (!err && blk_mq_is_reserved_rq(rq)) {
 > +		enum utp_ocs ocs;
 > +
 > +		err = read_poll_timeout(ufshcd_mcq_read_ocs, ocs,
 > +					ocs != OCS_INVALID_COMMAND_STATUS, 20,
 > +					MCQ_POLL_US, false, hwq, lrbp);
 > +		if (err)
 > +			dev_err(hba->dev, "%s: OCS not updated. hwq=%d, tag=%d err=%d\n",
 > +				__func__, id, task_tag, err);
 > +	}
 > +
 >  	if (ufshcd_mcq_sq_start(hba, hwq))
 >  		err = -ETIMEDOUT;

The SQ is still stopped at this point, so this loop can stop fetching
from the hardware queue for up to MCQ_POLL_US (500 ms). Please move the
OCS poll after the ufshcd_mcq_sq_start() call.

This code also waits for the interrupt handler to process the CQE. Why
not reap the CQE from this function? ufshcd_clear_lu_cmds() already
does that by calling ufshcd_mcq_poll_cqe_lock(hba, hwq) after
ufshcd_clear_cmd(). Calling ufshcd_mcq_poll_cqe_lock() before reading
the OCS would remove the dependency on interrupt delivery and match
the existing code.

Additionally, does the UFSHCI specification guarantee that the host
controller posts a CQE (e.g. with OCS = ABORTED) for every command
that has been cleaned up? If not, this patch turns cases that are
harmless today into a host reset. Please cite the relevant section of
the UFSHCI specification in the patch description or in a source code
comment.

Thanks,

Bart.

RE: [PATCH v6 2/2] ufs: mcq: poll OCS after sq cleanup for device management commands

[Kiwoong Kim]

>  > Here is the timeline of an actual case for this that happened with
> kernel 6.18.
>  > [ ... ]
>  > 2. So after the query was timed out, the driver did SQ cleanup.
>  > Then the host updated CQ update and raised IS.CQES,  > Unfortunately,
> complete() was called the driver's ISR afterward.
> 
> This timeline describes code that no longer exists upstream. Since commit
> 08b12cda6c44 ("scsi: ufs: core: Switch to scsi_get_internal_cmd()"), the
> device management path no longer calls complete(). Please describe the
> race in terms of the current code:

Let me add it below the timeline described previously.

> the query times out, the SCSI error handler calls ufshcd_abort() ->
> ufshcd_mcq_abort() -> ufshcd_mcq_sq_cleanup(), the request is finished,
> and the retry reuses the same reserved tag, struct scsi_cmnd and devman
> UCD. A late CQE for the first query then maps to hba->dev_cmd.tag via
> devman_ucd_dma_addr and completes the retry too early. That is why cq_lock
> matters here. Please also keep lines in the patch description at 75
> columns or less.
> 
>  > +static enum utp_ocs ufshcd_mcq_read_ocs(struct ufs_hw_queue *hwq,
>  > +					struct ufshcd_lrb *lrbp)
>  > +{
>  > +	guard(spinlock_irqsave)(&hwq->cq_lock);
>  > +	return READ_ONCE(lrbp->utr_descriptor_ptr->header.ocs);
>  > +}
> 
> READ_ONCE() is not necessary since the OCS is read with cq_lock held.

Got it.

> 
>  > +	if (!err && blk_mq_is_reserved_rq(rq)) {
>  > +		enum utp_ocs ocs;
>  > +
>  > +		err = read_poll_timeout(ufshcd_mcq_read_ocs, ocs,
>  > +					ocs != OCS_INVALID_COMMAND_STATUS, 20,
>  > +					MCQ_POLL_US, false, hwq, lrbp);
>  > +		if (err)
>  > +			dev_err(hba->dev, "%s: OCS not updated. hwq=%d, tag=%d
> err=%d\n",
>  > +				__func__, id, task_tag, err);
>  > +	}
>  > +
>  >  	if (ufshcd_mcq_sq_start(hba, hwq))
>  >  		err = -ETIMEDOUT;
> 
> The SQ is still stopped at this point, so this loop can stop fetching from
> the hardware queue for up to MCQ_POLL_US (500 ms). Please move the OCS
> poll after the ufshcd_mcq_sq_start() call.

I didn't get what you meant. The loop just reads updated OCS periodically
and from what I know, it's based on the assumption that when a task is cleaned up by setting SQRTCy.ICU to one
and it's successfully done, the host updates OCS, even if SQ is stopped.
If you feel I get your comment wrong, please let me know.

> 
> This code also waits for the interrupt handler to process the CQE. Why not
> reap the CQE from this function? ufshcd_clear_lu_cmds() already does that
> by calling ufshcd_mcq_poll_cqe_lock(hba, hwq) after ufshcd_clear_cmd().
> Calling ufshcd_mcq_poll_cqe_lock() before reading the OCS would remove the
> dependency on interrupt delivery and match the existing code.

Because a successful SQ cleanup leads to OCS update,
which subsequently leads to raising IS.CQES when MCQ is enabled.
I understand your idea with ufshcd_clear_lu_cmds, then do you intend
Ignoring IS.CQES event in this case?

> 
> Additionally, does the UFSHCI specification guarantee that the host
> controller posts a CQE (e.g. with OCS = ABORTED) for every command that
> has been cleaned up? If not, this patch turns cases that are harmless
> today into a host reset. Please cite the relevant section of the UFSHCI
> specification in the patch description or in a source code comment.

This is the sentence that I referred to:
"The host controller shall free up any resources associated to the nexus,
and shall post a Completion Queue entry with OCS = ABORTED if clean up successful."


> Thanks,
> 
> Bart.

Thanks
Kiwoong Kim
BRs.

Re: [PATCH v6 2/2] ufs: mcq: poll OCS after sq cleanup for device management commands

[Bart Van Assche]

On 11/4/26 9:59 PM, Kiwoong Kim wrote:
>> The SQ is still stopped at this point, so this loop can stop fetching from
>> the hardware queue for up to MCQ_POLL_US (500 ms). Please move the OCS
>> poll after the ufshcd_mcq_sq_start() call.
> 
> I didn't get what you meant. The loop just reads updated OCS periodically
> and from what I know, it's based on the assumption that when a task
> is cleaned up by setting SQRTCy.ICU to one and it's successfully
> done, the host updates OCS, even if SQ is stopped. If you feel I get
> your comment wrong, please let me know.
Let's start with the approach that you proposed. Making the change I
proposed is probably unnecessary.

>> This code also waits for the interrupt handler to process the CQE. Why not
>> reap the CQE from this function? ufshcd_clear_lu_cmds() already does that
>> by calling ufshcd_mcq_poll_cqe_lock(hba, hwq) after ufshcd_clear_cmd().
>> Calling ufshcd_mcq_poll_cqe_lock() before reading the OCS would remove the
>> dependency on interrupt delivery and match the existing code.
> 
> Because a successful SQ cleanup leads to OCS update,
> which subsequently leads to raising IS.CQES when MCQ is enabled. I
> understand your idea with ufshcd_clear_lu_cmds, then do you intend 
> Ignoring IS.CQES event in this case?
That's not what I meant. An interrupt is generated after the status has 
been changed to OCS_ABORTED, isn't it? Has it been considered to wait 
for that interrupt instead of polling the OCS status?

Thanks,

Bart.

RE: [PATCH v6 2/2] ufs: mcq: poll OCS after sq cleanup for device management commands

[Kiwoong Kim]

> >> This code also waits for the interrupt handler to process the CQE.
> >> Why not reap the CQE from this function? ufshcd_clear_lu_cmds()
> >> already does that by calling ufshcd_mcq_poll_cqe_lock(hba, hwq) after
> ufshcd_clear_cmd().
> >> Calling ufshcd_mcq_poll_cqe_lock() before reading the OCS would
> >> remove the dependency on interrupt delivery and match the existing code.
> >
> > Because a successful SQ cleanup leads to OCS update, which
> > subsequently leads to raising IS.CQES when MCQ is enabled. I
> > understand your idea with ufshcd_clear_lu_cmds, then do you intend
> > Ignoring IS.CQES event in this case?
> That's not what I meant. An interrupt is generated after the status has
> been changed to OCS_ABORTED, isn't it? Has it been considered to wait for
> that interrupt instead of polling the OCS status?
> 
> Thanks,
> 
> Bart.

Okay, got it. From what I understand, it's a loop to call ufshcd_mcq_poll_cqe_lock and check OCS.
If I get yours wrong, please let me know.

Thanks

Kiwoong Kim
BRs.

Re: [PATCH v6 2/2] ufs: mcq: poll OCS after sq cleanup for device management commands

[Bart Van Assche]

On 11/5/26 5:56 PM, Kiwoong Kim wrote:
 >> That's not what I meant. An interrupt is generated after the status has
 >> been changed to OCS_ABORTED, isn't it? Has it been considered to 
wait for
 >> that interrupt instead of polling the OCS status?
 >
 > Okay, got it. From what I understand, it's a loop to call
 > ufshcd_mcq_poll_cqe_lock and check OCS. If I get yours wrong, please
 > let me know.

That's fine with me. Waiting for the interrupt is not possible without
introducing a new completion mechanism: scsi_timeout() sets
SCMD_STATE_COMPLETE before ufshcd_abort() is called, so the scsi_done()
call from the interrupt handler has no effect on the command that is
being aborted. Calling ufshcd_mcq_poll_cqe_lock() from the polling loop
instead processes the CQE with OCS = ABORTED as soon as it has been
posted. It does not depend on interrupt delivery, and it is serialized
against the interrupt handler via hwq->cq_lock. Please introduce a
helper function that calls ufshcd_mcq_poll_cqe_lock() and then returns
the OCS value, and pass that helper to read_poll_timeout().

Thanks,

Bart.