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

[sashiko-bot@kernel.org]

> 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: Claude:claude-opus-5
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1789081084.git.nicolinc@nvidia.com?part=8