From: Pranjal Shrivastava <praan@google.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Prakash Gupta <prakash.gupta@oss.qualcomm.com>,
Will Deacon <will@kernel.org>, Joerg Roedel <joro@8bytes.org>,
Rob Clark <robin.clark@oss.qualcomm.com>,
Connor Abbott <cwabbott0@gmail.com>,
linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org,
Akhil P Oommen <akhilpo@oss.qualcomm.com>,
Pratyush Brahma <pratyush.brahma@oss.qualcomm.com>
Subject: Re: [PATCH] iommu/arm-smmu: Use pm_runtime in fault handlers
Date: Mon, 2 Feb 2026 20:14:26 +0000 [thread overview]
Message-ID: <aYEFop8CJiLYzhLw@google.com> (raw)
In-Reply-To: <d6bc7f38-b41d-4e89-b484-0e699981b8b4@arm.com>
On Wed, Jan 28, 2026 at 06:44:35PM +0000, Robin Murphy wrote:
> [ +Pranjal as this might matter for v3 too... ]
>
Hi Robin,
To weigh in from the arm-smmu-v3 side, we’ve attempted to address the
"can of worms" regarding power races by leaning on these differences:
- Threaded IRQs for PRI/Events: In the recent series[1], the PRI and
event handlers are fully threaded. This allows us to call
arm_smmu_rpm_get() safely, as the handler can sleep while waiting for
the hardware to resume.
- GERROR Handling: Since GERROR remains a hard IRQ, we handle any
pending gerrors in the suspend callback before the SMMU actually
powers down. Any GERROR interrupts received while the device was
suspended are treated as spurious and ignored.
Thanks,
Praan
[1] https://lore.kernel.org/all/20260126151157.3418145-1-praan@google.com/
[...]
>
> Hmm, but then how *do* we actually guarantee that autosuspend doesn't happen
> to kick in and power down the SMMU just as a hardirq handler runs, when
> there's some unexpected event? I fear there's a horrible can of worms
> here...
>
> Thanks,
> Robin.
next prev parent reply other threads:[~2026-02-02 20:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-27 12:11 [PATCH] iommu/arm-smmu: Use pm_runtime in fault handlers Prakash Gupta
2026-01-27 12:52 ` Akhil P Oommen
2026-01-27 16:05 ` Robin Murphy
2026-01-28 5:56 ` Prakash Gupta
2026-01-28 18:44 ` Robin Murphy
2026-01-29 16:03 ` Prakash Gupta
2026-02-02 20:14 ` Pranjal Shrivastava [this message]
2026-02-10 11:09 ` Prakash Gupta
2026-02-10 13:15 ` Pranjal Shrivastava
2026-02-11 16:10 ` Prakash Gupta
2026-02-11 16:59 ` Pranjal Shrivastava
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aYEFop8CJiLYzhLw@google.com \
--to=praan@google.com \
--cc=akhilpo@oss.qualcomm.com \
--cc=cwabbott0@gmail.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=prakash.gupta@oss.qualcomm.com \
--cc=pratyush.brahma@oss.qualcomm.com \
--cc=robin.clark@oss.qualcomm.com \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox