Re: [PATCH v2 1/2] scsi: ufs: core: Avoid unsafe MMIO reads in ufshcd_mcq_compl_all_cqes_lock()

[Peter Wang <peter.wang@mediatek.com>]

On Fri, 2026-09-18 at 22:38 +0800, Stanley Jhu wrote:
> During MCQ host reset, ufshcd_host_reset_and_restore() stops the host
> controller via ufshcd_hba_stop() (HCE = 0) before calling
> ufshcd_complete_requests(hba, true) ->
> ufshcd_mcq_compl_pending_transfer(hba, true) ->
> ufshcd_mcq_force_compl_one() -> ufshcd_mcq_compl_all_cqes_lock().
> Because ufshcd_mcq_force_compl_one() is its sole caller,
> ufshcd_mcq_compl_all_cqes_lock() always runs with HCE = 0.
> 
> Despite the comment above ufshcd_mcq_compl_all_cqes_lock() stating
> that
> reading CQTPy may not be safe with the controller disabled, the
> function
> still calls ufshcd_mcq_update_cq_tail_slot() at the end of its sweep:
> 
> 1. Unsafe CQTPy MMIO read:
>    Calling ufshcd_mcq_update_cq_tail_slot() at the end of the sweep
>    reads CQTPy over MMIO while HCE = 0, directly contradicting the
>    function's documented contract (commit 1373df88d535 ("scsi: ufs:
>    core: Add a comment block above
> ufshcd_mcq_compl_all_cqes_lock()"))
>    that reading CQTPy may not be safe with the controller disabled.
> 
> 2. Spurious error logs on empty slots:
>    Sweeping all max_entries slots visits empty entries where
>    command_desc_base_addr is 0, causing ufshcd_mcq_process_cqe() to
> log
>    unguarded dev_err(hba->dev, "Abnormal CQ entry!\n") messages.
> 
> Fix both issues in ufshcd_mcq_compl_all_cqes_lock():
> - Synchronize hwq->cq_tail_slot = hwq->cq_head_slot in software after
>   sweeping the ring, avoiding CQTPy MMIO reads while HCE = 0.
> - Extract ufshcd_mcq_compl_cqe() and invoke it only on non-empty
> slots
>   during full-ring sweeps, keeping "Abnormal CQ entry!" logging
> strictly
>   for unexpected empty entries in ufshcd_mcq_poll_cqe_lock().
> 
> Fixes: ab248643d3d6 ("scsi: ufs: core: Add error handling for MCQ
> mode")
> Cc: stable@vger.kernel.org
> Signed-off-by: Stanley Jhu <stanleyjhu@google.com>
> ---

Reviewed-by: Peter Wang <peter.wang@mediatek.com>