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.