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

[Jason Gunthorpe]

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

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

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

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.

-- 
Jason