All of lore.kernel.org
 help / color / mirror / Atom feed
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 4/9] iommu/rockchip: skip orphaned-fault banks in rk_iommu_is_stall_active
Date: Fri, 17 Jul 2026 09:11:25 +0000	[thread overview]
Message-ID: <20260717091126.49FCE1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260717085220.3212274-5-gahing@gahingwoo.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] Skipping orphaned-fault banks in `rk_iommu_is_stall_active` causes `rk_iommu_disable_stall` to unconditionally time out if all banks are skipped (e.g., on a single-bank IOMMU).

Pre-existing issues:
- [High] Multi-bank disable operations (`rk_iommu_disable_stall` and `rk_iommu_disable_paging`) prematurely terminate their waits as soon as the first bank completes its operation.
--

--- Patch [4]: [RFC PATCH 4/9] iommu/rockchip: skip orphaned-fault banks in rk_iommu_is_stall_active ---
commit 0709b1254bd6d532239176eba388c28b0ed8ea3c
Author: Jiaxing Hu <gahing@gahingwoo.com>

iommu/rockchip: skip orphaned-fault banks in rk_iommu_is_stall_active

This commit updates rk_iommu_is_stall_active() to detect and skip
orphaned-fault IOMMU banks that were left in a faulted state by boot
firmware. This ensures the driver doesn't treat them as "not stalled"
which would otherwise cause stall wait loops to fail.

> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
> index 87ae036d64145..ad462cee6bd89 100644
> --- a/drivers/iommu/rockchip-iommu.c
> +++ b/drivers/iommu/rockchip-iommu.c
> @@ -380,9 +380,23 @@ static bool rk_iommu_is_stall_active(struct rk_iommu *iommu)
>  	bool active = true;
>  	int i;
>  
> -	for (i = 0; i < iommu->num_mmu; i++)
> -		active &= !!(rk_iommu_read(iommu->bases[i], RK_MMU_STATUS) &
> -					   RK_MMU_STATUS_STALL_ACTIVE);
> +	for (i = 0; i < iommu->num_mmu; i++) {
> +		u32 status = rk_iommu_read(iommu->bases[i], RK_MMU_STATUS);
> +
> +		/*
> +		 * A bank stuck with PAGE_FAULT_ACTIVE but without STALL_ACTIVE
> +		 * and with IDLE set has an orphaned fault left by firmware before
> +		 * paging was configured.  It cannot enter stall mode but has no
> +		 * transaction in flight, so it is already quiescent.  Skip it
> +		 * rather than treating it as "not stalled."
> +		 */
> +		if ((status & RK_MMU_STATUS_PAGE_FAULT_ACTIVE) &&
> +		    !(status & RK_MMU_STATUS_STALL_ACTIVE) &&
> +		    (status & RK_MMU_STATUS_IDLE))
> +			continue;

[Severity: Medium]
Does skipping banks here cause a timeout if all banks are skipped?

If an IOMMU has a single bank (num_mmu == 1) and encounters this orphaned
fault, the loop skips the only bank and the active variable remains true.

When rk_iommu_disable_stall() polls for the stall to complete:

	ret = readx_poll_timeout(rk_iommu_is_stall_active, iommu, val,
				 !val, RK_MMU_POLL_PERIOD_US,
				 RK_MMU_POLL_TIMEOUT_US);

It expects rk_iommu_is_stall_active() to return false, but it will return
true, causing an unconditional timeout and a spurious error log.

> +
> +		active &= !!(status & RK_MMU_STATUS_STALL_ACTIVE);

[Severity: High]
This is a pre-existing issue, but does this bitwise AND reduction cause
multi-bank disable operations to terminate their waits prematurely?

When disabling an IOMMU with multiple banks (num_mmu > 1), returning false
as soon as the first bank drops its STALL_ACTIVE status leaves subsequent
banks still active.

The same logic exists in rk_iommu_is_paging_enabled(), where the bitwise
AND causes readx_poll_timeout() to terminate its wait as soon as one bank
is disabled, rather than waiting for all banks:

	for (i = 0; i < iommu->num_mmu; i++)
		enable &= !!(rk_iommu_read(iommu->bases[i], RK_MMU_STATUS) &
					   RK_MMU_STATUS_PAGING_ENABLED);

Can this lead to modifying register state or disabling hardware clocks while
some MMU banks are still actively processing commands?

> +	}
>  
>  	return active;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260717085220.3212274-1-gahing@gahingwoo.com?part=4

  reply	other threads:[~2026-07-17  9:11 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-17  8:50 [RFC PATCH 0/9] accel/rocket: RK3576 NPU (RKNN) enablement Jiaxing Hu
2026-07-17  8:50 ` Jiaxing Hu
2026-07-17  8:50 ` [RFC PATCH 1/9] dt-bindings: npu: rockchip: add rockchip,rk3576-rknn-core Jiaxing Hu
2026-07-17  8:50   ` Jiaxing Hu
2026-07-17  8:59   ` sashiko-bot
2026-07-17 10:02   ` Chaoyi Chen
2026-07-17 10:02     ` Chaoyi Chen
2026-07-17  8:50 ` [RFC PATCH 2/9] pmdomain/rockchip: add optional per-domain power-on settle delay Jiaxing Hu
2026-07-17  8:50   ` Jiaxing Hu
2026-07-17  9:07   ` sashiko-bot
2026-07-17  8:50 ` [RFC PATCH 3/9] pmdomain/rockchip: cycle optional power-domain resets on power-on Jiaxing Hu
2026-07-17  8:50   ` Jiaxing Hu
2026-07-17  9:04   ` sashiko-bot
2026-07-17  8:50 ` [RFC PATCH 4/9] iommu/rockchip: skip orphaned-fault banks in rk_iommu_is_stall_active Jiaxing Hu
2026-07-17  8:50   ` Jiaxing Hu
2026-07-17  9:11   ` sashiko-bot [this message]
2026-07-17 10:15   ` Chaoyi Chen
2026-07-17 10:15     ` Chaoyi Chen
2026-07-17  8:50 ` [RFC PATCH 5/9] iommu/rockchip: skip orphaned-fault banks in CMD_ENABLE_STALL dispatch Jiaxing Hu
2026-07-17  8:50   ` Jiaxing Hu
2026-07-17  9:23   ` sashiko-bot
2026-07-17  8:50 ` [RFC PATCH 6/9] iommu/rockchip: take all DT clocks Jiaxing Hu
2026-07-17  8:50   ` Jiaxing Hu
2026-07-17 10:19   ` Chaoyi Chen
2026-07-17 10:19     ` Chaoyi Chen
2026-07-17  8:50 ` [RFC PATCH 7/9] accel/rocket: add RK3576 NPU (RKNN) support Jiaxing Hu
2026-07-17  8:50   ` Jiaxing Hu
2026-07-17  9:21   ` sashiko-bot
2026-07-17 10:29   ` Chaoyi Chen
2026-07-17 10:29     ` Chaoyi Chen
2026-07-17  8:50 ` [RFC PATCH 8/9] arm64: dts: rockchip: rk3576: add NPU (RKNN) nodes Jiaxing Hu
2026-07-17  8:50   ` Jiaxing Hu
2026-07-17  9:30   ` sashiko-bot
2026-07-17  8:50 ` [RFC PATCH 9/9] arm64: dts: rockchip: rk3576-rock-4d: enable NPU Jiaxing Hu
2026-07-17  8:50   ` Jiaxing Hu
2026-07-17  9:32   ` 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=20260717091126.49FCE1F00A3A@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.