Re: [PATCH v5 08/15] iommu/arm-smmu-v3: Disable the queue IRQs before disabling the SMMU

[Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>]

On Tue, 15 Sep 2026 09:38:20 -0700
Nicolin Chen <nicolinc@nvidia.com> wrote:

> The EVTQ, PRIQ and combined IRQ handlers are threaded and issue commands of
> their own, e.g. a CMDQ_OP_PRI_RESP for a page request. Disabling the SMMU
> while one is in flight hands that command to a queue consuming nothing, so
> its poll waits out a full timeout.
> 
> Two paths disable the SMMU while those IRQs are still requested: a failing
> arm_smmu_device_reset() returns to a probe that disables the device itself,
> and arm_smmu_disable_action() covers an unbind or any later probe failure.
> Both can run after arm_smmu_setup_irqs() requested the IRQs.
> 
> Disable those IRQs first in both paths, so that no handler is left running
> once the SMMU goes down. arm_smmu_device_shutdown() needs no change of its
> own here, since it already just calls arm_smmu_disable_action().
> 
> Also clear an IRQ number when its request fails or is skipped for a missing
> ARM_SMMU_FEAT_PRI, keeping disable_irq() to the IRQs that this driver truly
> owns.
> 
> Note that the IOPF queue needs no such care of its own, as devres frees the
> IRQs before running the release action of that queue, which came earlier in
> arm_smmu_init_queues().
> 
> Assisted-by: LLM
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
I'm still not loving the disable_irq() in here just because to me it
feels like it may end up masking stuff we ought to handle more carefully but
I don't mind that much

Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>