[PATCH ath-current] wifi: ath11k: fix unbalanced IRQ enable/disable during suspend/resume

[Rameshkumar Sundaram]

On 9/28/2026 4:15 PM, Baochen Qiang wrote:
> Commit f7a74e131d3f ("wifi: ath11k: disable interrupts during firmware
> crash recovery") added an unconditional ath11k_hif_irq_disable()/
> ath11k_hif_ce_irq_disable() pair inside
> ath11k_core_reconfigure_on_crash(), guarded by "if (!ab->is_reset)", to
> stop the DP NAPI from touching rings that have just been torn down. That
> fixes AHB device recovery, but breaks PCI device suspend/resume. During
> suspend, IRQs are disabled once in ath11k_core_suspend_late(). Then during
> resume, ath11k_core_reconfigure_on_crash() sees ab->is_reset clear and
> disables them a second time. Those IRQs are enabled only once during
> the following reinitialization, leaving the IRQ lines masked. As a result,
> HTC control responses never arrive, and resume fails:
> 
>    failed to receive control response completion, polling..
>    failed to connect to HTT: -110
>    failed to reconfigure driver on crash recovery
>    failed to resume core: -110
> 
> Fix this by disabling the IRQs unconditionally at the top of
> ath11k_core_reconfigure_on_crash(), and instead drop the disable
> calls from the two places that already disable IRQs before this
> function can run: ath11k_core_suspend_late() and ath11k_core_reset().
> This keeps a single disable per recovery/suspend cycle regardless of
> which path (recovery or suspend) triggers it, so the refcount on
> PCI parts stays balanced while AHB parts keep getting the disable
> that the original commit needed.
> 
> Fixes: f7a74e131d3f ("wifi: ath11k: disable interrupts during firmware crash recovery")
> Reported-by: Marek Szyprowski <m.szyprowski at samsung.com>
> Closes: https://lore.kernel.org/linux-wireless/a068a857-a549-4cc2-ae0f-3ef119d3a859@samsung.com/
> Tested-by: Marek Szyprowski <m.szyprowski at samsung.com>
> Tested-by: Julius Bairaktaris <julius at bairaktaris.de>
> Signed-off-by: Baochen Qiang <baochen.qiang at oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram at oss.qualcomm.com>