Re: [PATCH v1 06/10] ufs: host: mediatek: Enable interrupts for MCQ mode

["Peter Wang (王信友)" <peter.wang@mediatek.com>]

On Fri, 2025-09-19 at 14:09 -0700, Bart Van Assche wrote:
> 
> Having taken a closer look at this patch, the only reason I can think
> of
> why interrupts are re-enabled from a .resume callback is a workaround
> for a controller bug. Please consider adding a quirk and moving the
> code
> that reenables interrupts into the UFSHCI core instead of exporting
> the
> ufshcd_enable_intr() function. I'm concerned that exporting
> ufshcd_enable_intr() would make the UFSHCI driver much harder to
> maintain than necessary, especially if this would lead to concurrent
> writes to the REG_INTERRUPT_ENABLE register.
> 
> Thanks,
> 
> Bart.

Hi Bart,

If it were a bug, I would say it’s a MediaTek SoC limitation :)
But it’s definitely not a bug or a limitation.
Honestly, it’s our low power technology, which requires a 
software flow to re-enable IRQ after resume.

So, maybe re-enabling MCQ IRQs the same way as legacy IRQs 
in ufshcd_make_hba_operational would be better.
What do you think? like below patch

@@ -355,9 +355,15 @@ EXPORT_SYMBOL_GPL(ufshcd_mcq_poll_cqe_lock);
 void ufshcd_mcq_make_queues_operational(struct ufs_hba *hba)
 {
        struct ufs_hw_queue *hwq;
+       u32 intrs;
        u16 qsize;
        int i;

+       intrs = UFSHCD_ENABLE_MCQ_INTRS;
+       if (hba->quirks & UFSHCD_QUIRK_MCQ_BROKEN_INTR)
+               intrs &= ~MCQ_CQ_EVENT_STATUS;
+       ufshcd_enable_intr(hba, intrs);
+
        for (i = 0; i < hba->nr_hw_queues; i++) {

Thansk.
Peter