Re: [PATCH v11 15/16] iommu/arm-smmu-v3: Invoke pm_runtime before hw access

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] pm: power domain leak in arm_smmu_disable_action()
- [High] irq: CPU livelock in threaded queues due to uncleared events
--

commit 13dd005a8c8b5e0160d4c5b2b42bd2a26eae301e
Author: Pranjal Shrivastava <praan@google.com>

iommu/arm-smmu-v3: Invoke pm_runtime before hw access

This commit introduces pm_runtime helpers before accessing hardware across
the driver to avoid sleeping and deadlocking during transient power states.
It uses lockless checks and non-sleeping runtime PM gets in threaded
interrupts, and explicitly manages PM state around device disable paths.

> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index 2a1b5ce6ff1cf..89ffa83464780 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
[ ... ]
> @@ -2460,6 +2478,40 @@ static irqreturn_t arm_smmu_evtq_thread(int irq, void *dev)
[ ... ]
> +	if (!arm_smmu_rpm_get_if_active(smmu)) {
> +		dev_warn_ratelimited(smmu->dev, "client device is suspended, dropping event\n");
> +		return IRQ_HANDLED;
> +	}

[Severity: High]
Can this cause an interrupt livelock?

If arm_smmu_rpm_get_if_active() observes the RPM_SUSPENDING state, it returns
false, which means this returns IRQ_HANDLED without dequeueing the event or
updating the hardware CONS pointer. 

Because the event is left in the queue, won't the SMMU hardware continue to
assert the level-triggered wired interrupt line, resulting in an infinite CPU
loop that deadlocks the suspend sequence?

>  	do {
>  		while (!queue_remove_raw(q, evt)) {
[ ... ]
> @@ -2518,6 +2571,18 @@ static irqreturn_t arm_smmu_priq_thread(int irq, void *dev)
[ ... ]
> +	if (!arm_smmu_rpm_get_if_active(smmu)) {
> +		dev_warn_ratelimited(smmu->dev, "client device is suspended, dropping page request\n");
> +		return IRQ_HANDLED;
> +	}

[Severity: High]
Similar to the evtq thread above, does returning IRQ_HANDLED here without
consuming the hardware queue entries leave the interrupt line asserted?
Could this lead to a CPU livelock during transient power states?

>  	do {
>  		while (!queue_remove_raw(q, evt))
[ ... ]
> @@ -5116,14 +5227,37 @@ static int arm_smmu_device_disable(struct arm_smmu_device *smmu)
>  static void arm_smmu_disable_action(void *data)
>  {
>  	struct arm_smmu_device *smmu = data;
> +	int ret;
>  
>  	/* If the SMMU is already suspended, nothing to do */
>  	if (!pm_runtime_suspended(smmu->dev)) {
[ ... ]
>  		arm_smmu_device_disable(smmu);
> +
> +		/*
> +		 * A PM ref was only acquired via arm_smmu_rpm_get() to
> +		 * guarantee power for the MMIO register writes in
> +		 * arm_smmu_device_disable().
> +		 *
> +		 * Drop the PM ref, we intentionally do NOT invoke a
> +		 * synchronous put/suspend here since the HW was already
> +		 * disabled above. Calling put_sync would invoke
> +		 * arm_smmu_runtime_suspend(), redundantly attempting to
> +		 * do the same. Any pending autosuspend timer is cleanly
> +		 * cancelled by pm_runtime_disable() immediately below.
> +		 * The core code ensures the power management here.
> +		 */
> +		arm_smmu_rpm_put(smmu);
>  	}
>  
> +disable_pm:
>  	if (pm_runtime_enabled(smmu->dev)) {
>  		pm_runtime_dont_use_autosuspend(smmu->dev);
>  		pm_runtime_disable(smmu->dev);
>  	}

[Severity: High]
Does this sequence strand the attached PM domain in the ON state?

The code calls an asynchronous put (arm_smmu_rpm_put() invokes
pm_runtime_put_autosuspend()) immediately before calling
pm_runtime_disable(). Disabling runtime PM while a device is active cancels
any pending autosuspend work and freezes the power state as RPM_ACTIVE.

Subsequent driver core calls to pm_runtime_put_sync() would then see
disable_depth > 0 and fail with -EACCES without suspending the device,
resulting in a permanent PM domain power leak preventing deep SOC idle states.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260929034510.2023173-1-praan@google.com?part=15