[PATCH v1] ufs: core: Avoid IRQ thread wakeup during active UIC command

[PATCH v1] ufs: core: Avoid IRQ thread wakeup during active UIC command

[peter.wang]

From: Peter Wang <peter.wang@mediatek.com>

Only return IRQ_WAKE_THREAD when MCQ and ESI are not enabled
and no UIC command is active. Since the default UIC command
timeout is 500ms, handling IRQs in a thread during an active UIC
command can easily lead to timeouts due to delayed processing.

Signed-off-by: Peter Wang <peter.wang@mediatek.com>
---
 drivers/ufs/core/ufshcd.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index 9908375b2f98..3f18c1a39f27 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -7201,8 +7201,11 @@ static irqreturn_t ufshcd_intr(int irq, void *__hba)
 	u32 intr_status, enabled_intr_status;
 
 	/* Move interrupt handling to thread when MCQ & ESI are not enabled */
-	if (!hba->mcq_enabled || !hba->mcq_esi_enabled)
-		return IRQ_WAKE_THREAD;
+	if (!hba->mcq_enabled || !hba->mcq_esi_enabled) {
+		/* UIC commands should be processed promptly */
+		if (!hba->active_uic_cmd)
+			return IRQ_WAKE_THREAD;
+	}
 
 	intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
 	enabled_intr_status = intr_status & ufshcd_readl(hba, REG_INTERRUPT_ENABLE);
-- 
2.45.2

Re: [PATCH v1] ufs: core: Avoid IRQ thread wakeup during active UIC command

[Bart Van Assche]

On 3/4/26 1:12 AM, peter.wang@mediatek.com wrote:
> Only return IRQ_WAKE_THREAD when MCQ and ESI are not enabled
> and no UIC command is active. Since the default UIC command
> timeout is 500ms, handling IRQs in a thread during an active UIC
> command can easily lead to timeouts due to delayed processing.

A context switch takes somewhere between 1 and 10 microseconds.
That is several orders of magnitude below the UIC command timeout.
Something else must be causing the observed UIC timeouts.

Thanks,

Bart.

Re: [PATCH v1] ufs: core: Avoid IRQ thread wakeup during active UIC command

[Peter Wang (王信友)]

On Wed, 2026-03-04 at 08:43 -0600, Bart Van Assche wrote:
> A context switch takes somewhere between 1 and 10 microseconds.
> That is several orders of magnitude below the UIC command timeout.
> Something else must be causing the observed UIC timeouts.
> 
> Thanks,
> 
> Bart.

Hi Bart,

The main reason is not context switch time.
The problem is that a threaded IRQ handler can be preempted
by a regular IRQ.
When the system is busy, for example during kernel boot,
there are many other module IRQs present in the system.

Thanks
Peter

Re: [PATCH v1] ufs: core: Avoid IRQ thread wakeup during active UIC command

[Bart Van Assche]

On 3/4/26 9:27 PM, Peter Wang (王信友) wrote:
> The main reason is not context switch time.
> The problem is that a threaded IRQ handler can be preempted
> by a regular IRQ.
> When the system is busy, for example during kernel boot,
> there are many other module IRQs present in the system.

Spending 500 ms in interrupts without giving the CPU a chance to run is
excessive, isn't it? Anyway, if you really need this patch, please
mention the above information in the patch description and combine the
two if-statements into a single if-statement, e.g. as follows:

if ((!hba->mcq_enabled || !hba->mcq_esi_enabled) &&
     !hba->active_uic_cmd)
	...

Thanks,

Bart.

Re: [PATCH v1] ufs: core: Avoid IRQ thread wakeup during active UIC command

[Peter Wang (王信友)]

On Thu, 2026-03-05 at 06:17 -0600, Bart Van Assche wrote:
> Spending 500 ms in interrupts without giving the CPU a chance to run
> is
> excessive, isn't it? Anyway, if you really need this patch, please
> mention the above information in the patch description and combine
> the
> two if-statements into a single if-statement, e.g. as follows:
> 
> if ((!hba->mcq_enabled || !hba->mcq_esi_enabled) &&
>      !hba->active_uic_cmd)
>         ...
> 
> Thanks,
> 
> Bart.
> 

Yes, I will add more description in the next version.

Thanks
Peter