[PATCH v8 11/12] iommu/arm-smmu-v3: Invoke pm_runtime before hw access
Daniel Mentz
danielmentz at google.com
Wed Jun 3 13:28:19 PDT 2026
On Mon, Jun 1, 2026 at 2:59 PM Pranjal Shrivastava <praan at google.com> wrote:
> @@ -2361,8 +2394,33 @@ static irqreturn_t arm_smmu_handle_gerror(struct arm_smmu_device *smmu)
> static irqreturn_t arm_smmu_gerror_handler(int irq, void *dev)
> {
> struct arm_smmu_device *smmu = dev;
> + irqreturn_t ret;
> +
> + /*
> + * Global Errors are only processed if the SMMU is active.
> + *
> + * If the STOP_FLAG is set (can_elide == true), the hardware is
> + * either already disabled or in the process of being disabled.
> + * Any errors captured during the quiesce/drain phase will be
> + * handled by the explicit arm_smmu_handle_gerror() call at the
> + * end of arm_smmu_runtime_suspend() callback. On resume, the
> + * STOP_FLAG is cleared before interrupts are re-enabled, ensuring
> + * no valid errors are missed.
> + *
> + * A lockless check is favoured here over a dynamic PM core check
> + * since the runtime_pm_get_if_active would return false during
> + * transient states like RPM_RESUMING & ignore level-triggered
> + * interrupts.
> + */
> + if (arm_smmu_cmdq_can_elide(smmu)) {
> + dev_err(smmu->dev,
> + "Ignoring gerror interrupt because the SMMU is suspended\n");
> + return IRQ_NONE;
> + }
Have you considered using arm_smmu_rpm_get() here instead?
I can see two issues with the currenlty proposal:
* Returning IRQ_NONE when an interrupt is indeed active and needs to
be handled. This might be interpreted as a spurious interrupt
* Nothing is preventing the suspend handler from running while
arm_smmu_gerror_handler is in the middle of handling an interrupt
I understand that using arm_smmu_rpm_get() also has downsides,
including an unnecessary resume operation when the SMMU is already in
RPM_SUSPENDING state. However, using arm_smmu_rpm_get() would make it
easier to ensure correctness.
> +
> + ret = arm_smmu_handle_gerror(smmu);
>
> - return arm_smmu_handle_gerror(smmu);
> + return ret;
> }
More information about the linux-arm-kernel
mailing list