Re: [PATCH v6 10/10] iommu/arm-smmu-v3: Invoke pm_runtime before hw access

[Pranjal Shrivastava <praan@google.com>]

On Tue, May 19, 2026 at 11:31:58AM -0700, Daniel Mentz wrote:
> On Tue, Apr 14, 2026 at 12:47 PM Pranjal Shrivastava <praan@google.com> wrote:
> >  /* IO_PGTABLE API */
> > @@ -2823,7 +2883,16 @@ static void __arm_smmu_domain_inv_range(struct arm_smmu_invs *invs,
> >
> >                 if (cmds.num &&
> >                     (next == end || arm_smmu_invs_end_batch(cur, next))) {
> > -                       arm_smmu_cmdq_batch_submit(smmu, &cmds);
> > +                       bool active = arm_smmu_rpm_get_if_active(smmu);
> > +
> > +                       if (arm_smmu_inv_is_ats(cur))
> > +                               WARN_ON_ONCE(!active);
> > +
> > +                       if (active) {
> > +                               arm_smmu_cmdq_batch_submit(smmu, &cmds);
> > +                               arm_smmu_rpm_put(smmu);
> > +                       }
> > +                       /* Drop this batch to ensure the next one's fresh */
> >                         cmds.num = 0;
> >                 }
> >                 cur = next;
> 
> Correct me if I'm wrong, but I don't think this is safe.
> 
> Let's say arm_smmu_is_active() returns true and
> pm_runtime_get_if_active() returns 0 because dev->power.runtime_status
> != RPM_ACTIVE. In this situation, is it safe to skip
> arm_smmu_cmdq_batch_submit()? I think the answer is no.
> 
> My understanding is that it is only safe to elide invalidations when
> SMMUEN in SMMU_CR0 is cleared. Imagine runtime_status is
> RPM_SUSPENDING. pm_runtime_get_if_active() returns 0, we elide
> invalidations despite SMMU still being enabled.
> 
> I think that to decide whether to elide invalidations, we should
> exclusively rely on the Q_STOP test in arm_smmu_cmdq_issue_cmdlist(),
> not on the RPM framework.

Hmm.. the Q_STOP flag indicates the SMMUEN state 1:1.

Alright, I'll drop reliance on get_if_active everywhere and simply elide
based on Q_STOP. Even if we race with suspend/resume we should be safe
in that case because of the Q_STOP checks within the issue_cmdlist
(point of commitment).

Thanks,
Praan