From: sashiko-bot@kernel.org
To: "Jiaxing Hu" <gahing@gahingwoo.com>
Cc: devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org,
conor+dt@kernel.org, robh@kernel.org
Subject: Re: [RFC PATCH v2 5/8] iommu/rockchip: clear stale page faults before enabling stall
Date: Sat, 18 Jul 2026 03:26:16 +0000 [thread overview]
Message-ID: <20260718032616.B47901F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260718031146.3368811-6-gahing@gahingwoo.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Clearing the stale page fault state without clearing the associated interrupt status leads to a spurious IOMMU interrupt upon unmasking if the MMU reset is disabled.
--
--- Patch [5]: [RFC PATCH v2 5/8] iommu/rockchip: clear stale page faults before enabling stall ---
commit 6445c2bf287495e424096d491a8245a58e126724
Author: Jiaxing Hu <gahing@gahingwoo.com>
iommu/rockchip: clear stale page faults before enabling stall
Boot firmware can leave an IOMMU bank in PAGE_FAULT_ACTIVE before the
driver has configured paging. This commit acknowledges these stale faults
with CMD_PAGE_FAULT_DONE before enabling stall so all banks start clean
and avoid timing out.
> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
> index 2ac65c0c5c0b4..e477fe79ca4a3 100644
> --- a/drivers/iommu/rockchip-iommu.c
> +++ b/drivers/iommu/rockchip-iommu.c
> @@ -417,6 +417,19 @@ static int rk_iommu_enable_stall(struct rk_iommu *iommu)
> if (!rk_iommu_is_paging_enabled(iommu))
> return 0;
>
> + /*
> + * Boot firmware can leave a bank in PAGE_FAULT_ACTIVE with no handler
> + * (PAGE_FAULT_ACTIVE & !STALL_ACTIVE & IDLE). Such a bank ignores
> + * CMD_ENABLE_STALL and never reaches STALL_ACTIVE, timing out the poll
> + * below. Acknowledge any stale fault first so every bank starts clean.
> + */
> + for (i = 0; i < iommu->num_mmu; i++) {
> + if (rk_iommu_read(iommu->bases[i], RK_MMU_STATUS) &
> + RK_MMU_STATUS_PAGE_FAULT_ACTIVE)
> + writel(RK_MMU_CMD_PAGE_FAULT_DONE,
> + iommu->bases[i] + RK_MMU_COMMAND);
[Severity: High]
Does clearing the page fault state here also require clearing the associated
interrupt status in RK_MMU_INT_CLEAR?
If a device uses rockchip,disable-mmu-reset, the hardware reset during
rk_iommu_enable() is skipped. When interrupts are subsequently unmasked
by writing to RK_MMU_INT_MASK, an uncleared raw interrupt bit would
immediately trigger a spurious interrupt.
Could this spurious interrupt lead to report_iommu_fault() being called
prematurely, potentially panicking the system or failing device attachment?
> + }
> +
> rk_iommu_command(iommu, RK_MMU_CMD_ENABLE_STALL);
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260718031146.3368811-1-gahing@gahingwoo.com?part=5
next prev parent reply other threads:[~2026-07-18 3:26 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-18 3:11 [RFC PATCH v2 0/8] accel/rocket: RK3576 NPU (RKNN) enablement Jiaxing Hu
2026-07-18 3:11 ` Jiaxing Hu
2026-07-18 3:11 ` [RFC PATCH v2 1/8] dt-bindings: npu: rockchip: add rockchip,rk3576-rknn-core Jiaxing Hu
2026-07-18 3:11 ` Jiaxing Hu
2026-07-18 3:19 ` sashiko-bot
2026-07-18 7:49 ` Krzysztof Kozlowski
2026-07-18 7:49 ` Krzysztof Kozlowski
2026-07-18 3:11 ` [RFC PATCH v2 2/8] pmdomain/rockchip: add optional per-domain power-on settle delay Jiaxing Hu
2026-07-18 3:11 ` Jiaxing Hu
2026-07-18 3:20 ` sashiko-bot
2026-07-18 3:11 ` [RFC PATCH v2 3/8] pmdomain/rockchip: cycle optional power-domain resets on power-on Jiaxing Hu
2026-07-18 3:11 ` Jiaxing Hu
2026-07-18 3:22 ` sashiko-bot
2026-07-18 3:11 ` [RFC PATCH v2 4/8] iommu/rockchip: take all DT clocks Jiaxing Hu
2026-07-18 3:11 ` Jiaxing Hu
2026-07-18 3:22 ` sashiko-bot
2026-07-18 3:11 ` [RFC PATCH v2 5/8] iommu/rockchip: clear stale page faults before enabling stall Jiaxing Hu
2026-07-18 3:11 ` Jiaxing Hu
2026-07-18 3:26 ` sashiko-bot [this message]
2026-07-18 3:11 ` [RFC PATCH v2 6/8] accel/rocket: add RK3576 NPU (RKNN) support Jiaxing Hu
2026-07-18 3:11 ` Jiaxing Hu
2026-07-18 3:27 ` sashiko-bot
2026-07-18 3:11 ` [RFC PATCH v2 7/8] arm64: dts: rockchip: rk3576: add NPU (RKNN) nodes Jiaxing Hu
2026-07-18 3:11 ` Jiaxing Hu
2026-07-18 3:26 ` sashiko-bot
2026-07-18 3:11 ` [RFC PATCH v2 8/8] arm64: dts: rockchip: rk3576-rock-4d: enable NPU Jiaxing Hu
2026-07-18 3:11 ` Jiaxing Hu
2026-07-18 3:24 ` sashiko-bot
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=20260718032616.B47901F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gahing@gahingwoo.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.