Re: [PATCH v3 07/13] iommu/arm-smmu-v3: Disable the queue IRQs before disabling the SMMU

[Nicolin Chen <nicolinc@nvidia.com>]

On Thu, Sep 03, 2026 at 12:18:33PM -0700, Jonathan Cameron 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.
> 
> Why this soluton rather than a flag to stop them queuing new work + a
> synchronize_irq() to deal with threads in flight.
> 
> irq disables always worry me a little as they tend to be patching over
> something nastier.  I think this works though so I'm not going to
> strongly object.

Well, I don't see a reason to add extra flags: each irq here only
has one single source, so disable_irq() is fundamentally similar
to a flag + synchronize_irq(), but also masks the irq line, which
makes sense in the probe-revert and shutdown paths. Above all, it
is cleaner.

If there is a solid reason for not using disable_irq() here, I'd
not mind changing that though.

Thanks
Nicolin