From: Peter Wang peter.wang@mediatek.com
[ Upstream commit 91cad911edd1612ed28f5cfb2d4c53a8824951a5 ]
Resolve the issue of unbalanced IRQ enablement by setting the 'is_mcq_intr_enabled' flag after the first successful IRQ enablement. Ensure proper tracking of the IRQ state and prevent potential mismatches in IRQ handling.
Signed-off-by: Peter Wang peter.wang@mediatek.com Signed-off-by: Martin K. Petersen martin.petersen@oracle.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES
- What it fixes - Prevents unbalanced IRQ enable calls in the Mediatek UFS MCQ path by ensuring the driver’s internal state flag matches the real IRQ state immediately after the IRQs are requested (and thus enabled by default). Without this, subsequent enable paths may re-enable already-enabled IRQs, triggering “unbalanced enable” warnings and mismatched IRQ depth accounting.
- Precise change - Adds `host->is_mcq_intr_enabled = true;` at the end of `ufs_mtk_config_mcq_irq()` after all IRQ handlers have been successfully registered with `devm_request_irq()` (drivers/ufs/host/ufs-mediatek.c:2193). - This reflects that IRQs are enabled as a result of `request_irq()` and aligns the state flag with reality.
- Why it’s correct - `devm_request_irq()` attaches the handler and leaves the IRQ enabled by default. If the state flag remains false, the first call into the driver’s “enable MCQ IRQs” helper will re-enable an already-enabled IRQ, causing an unbalanced enable. - The driver already guards enable/disable with this flag: - Disable path: sets the flag false after disabling (drivers/ufs/host/ufs-mediatek.c:741). - Enable path: bails out if already enabled and sets the flag true only after enabling (drivers/ufs/host/ufs-mediatek.c:755 and drivers/ufs/host/ufs-mediatek.c:762). - With the new line in `ufs_mtk_config_mcq_irq()` (drivers/ufs/host/ufs-mediatek.c:2193), the initial state is correct, so `ufs_mtk_mcq_enable_irq()` will correctly no-op on the first enable attempt when IRQs are already enabled.
- How the bug manifested - `ufs_mtk_setup_clocks()`’s POST_CHANGE flow calls `ufs_mtk_mcq_enable_irq()` (drivers/ufs/host/ufs-mediatek.c:817). Before this patch, after `devm_request_irq()` the IRQs were already enabled but `is_mcq_intr_enabled` was still false, so the enable path would call `enable_irq()` again, risking “unbalanced IRQ enable” warnings. - The disable path is already consistent: `ufs_mtk_mcq_disable_irq()` uses the list of IRQs and flips the flag to false (drivers/ufs/host/ufs-mediatek.c:741), so subsequent enables are properly balanced.
- Scope and risk - Change is a single-line state fix in one driver function, confined to the Mediatek UFS host driver. - No API, ABI, or architectural changes; no behavioral changes beyond preventing an incorrect extra `enable_irq()`. - The flag is set only after all IRQ requests succeed; if any `devm_request_irq()` fails, the function returns early and does not set the flag, preserving prior behavior.
- Stable backport criteria - Fixes a real correctness issue that can lead to warnings and IRQ depth mismatches. - Small, contained, and low risk. - No feature addition; clear bug fix in a specific subsystem (SCSI UFS Mediatek host).
Given the above, this is a good candidate for stable backporting wherever the Mediatek UFS MCQ driver and `is_mcq_intr_enabled` field exist.
drivers/ufs/host/ufs-mediatek.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c index 188f90e468c41..055b24758ca3d 100644 --- a/drivers/ufs/host/ufs-mediatek.c +++ b/drivers/ufs/host/ufs-mediatek.c @@ -2111,6 +2111,7 @@ static int ufs_mtk_config_mcq_irq(struct ufs_hba *hba) return ret; } } + host->is_mcq_intr_enabled = true;
return 0; }