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

[Bart Van Assche <bvanassche@acm.org>]

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.