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

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

On Fri, 4 Sep 2026 20:24:54 -0700
Nicolin Chen <nicolinc@nvidia.com> wrote:

> 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.

It is probably just my mental model that disable_irq() is normally
papering over devices that can't behave well and stop sending irqs
at the source end.  The main difference is whether there is any
potential of the unhandled irq logic kicking in.  I kind of dislike
relying on exactly how that works under the hood (needs a lot of
irqs to trigger) for any path that we expect to actually hit.

Anyhow, I don't feel that strongly about this one.

Jonathan


> 
> Thanks
> Nicolin