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

On Wed, Sep 23, 2026 at 03:37:05PM -0300, Jason Gunthorpe wrote:

quoted

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.

This seems like a sashiko hallucination?

There are no PRIs during probe. The initial STE table does not permit
it.

Checked my long rework history. Yes... my bad..

quoted

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.

That's fscking devm again. Do not mix devm and non devm CALLS. It
doesn't work:

	ret = arm_smmu_device_reset(smmu);
	if (ret) {
		arm_smmu_device_disable(smmu);   <-------------------
		return ret;
	}

	/* Register last so it unwinds first, while the CMDQ is still up. */
	ret = devm_add_action_or_reset(smmu->dev, arm_smmu_disable_action, smmu);
	if (ret)
		return ret;

This seems requiring a reorder.

When devm is devm'ing properly the existing devm irq handlers will be
torn down before disable_action and we don't need to open code a
disable_irq

I see. Yes.

That just leaves shutdown, and I'm not sure how that is supposed to
work, we can't just halt the SMMU while there are any threads running
around still poking at it. I forget the context shutdown runs in, but
if concurrency is shut down already then its fine to not disable the
irqs.

If not, it doesn't work safely for lots of reasons, and disable_irq is
not going to fix it enough.

Maybe that is something to tackle after the power management series as
shutdown is sort of like power down.

OK. Let's leave it.

Thanks
Nicolin