From: "Kiwoong Kim" <kwmad.kim@samsung.com>
To: "'Bart Van Assche'" <bvanassche@acm.org>,
<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>
Subject: RE: [PATCH v6 2/2] ufs: mcq: poll OCS after sq cleanup for device management commands
Date: Fri, 6 Nov 2026 10:56:24 +0900 [thread overview]
Message-ID: <000001dd6d92$0787dc60$16979520$@samsung.com> (raw)
In-Reply-To: <ec1d1fd7-b832-4ea8-b3f3-87ff3d361d80@acm.org>
> >> 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.
next prev parent reply other threads:[~2026-11-06 1:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20261105004351epcas2p19e657481834dc8493d926f10cff77d03@epcas2p1.samsung.com>
2026-11-05 0:43 ` [PATCH v6 0/2] ufs: fix the abort path of device management commands in MCQ mode Kiwoong Kim
[not found] ` <CGME20261105004352epcas2p307ea40aadb636015545cee6e79470a03@epcas2p3.samsung.com>
2026-11-05 0:43 ` [PATCH v6 1/2] ufs: core: skip ABORT TASK for device management commands Kiwoong Kim
2026-11-05 1:28 ` Bart Van Assche
2026-11-05 3:34 ` Kiwoong Kim
[not found] ` <CGME20261105004353epcas2p1bd2370dd10156570c69f8f80da3cbcfd@epcas2p1.samsung.com>
2026-11-05 0:43 ` [PATCH v6 2/2] ufs: mcq: poll OCS after sq cleanup " Kiwoong Kim
2026-11-05 1:30 ` Bart Van Assche
2026-11-05 5:59 ` Kiwoong Kim
2026-11-05 17:53 ` Bart Van Assche
2026-11-06 1:56 ` Kiwoong Kim [this message]
2026-11-06 4:39 ` Bart Van Assche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000001dd6d92$0787dc60$16979520$@samsung.com' \
--to=kwmad.kim@samsung.com \
--cc=alim.akhtar@samsung.com \
--cc=bvanassche@acm.org \
--cc=cpgs@samsung.com \
--cc=h10.kim@samsung.com \
--cc=hy50.seo@samsung.com \
--cc=jejb@linux.ibm.com \
--cc=kwangwon.min@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=stable@vger.kernel.org \
--cc=stanleyjhu@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®