From: Marek Szyprowski <m.szyprowski@samsung.com>
To: markuss.broks@gmail.com, "Joerg Roedel (AMD)" <joro@8bytes.org>,
Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Krzysztof Kozlowski <krzk@kernel.org>,
Peter Griffin <peter.griffin@linaro.org>,
Alim Akhtar <alim.akhtar@samsung.com>
Cc: iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] IOMMU driver improvements for modern Exynos SysMMUs
Date: Tue, 25 Aug 2026 10:16:54 +0200 [thread overview]
Message-ID: <eb0618b6-f2bc-4ed7-9178-e66ccee4962d@samsung.com> (raw)
In-Reply-To: <20260820-exynos-iommu-fixes-v1-0-6bbcd673bb15@gmail.com>
On 20.08.2026 21:12, Markuss Broks via B4 Relay wrote:
> Newer SysMMU v7+ instances can lack BLOCK mode: CAPA1 bit 15 reports
> that the CTRL_BLOCK function is not implemented, and MMU_STATUS never
> reports a blocked state. The SysMMUs on Exynos 8835 are such
> instances.
>
> The driver currently assumes blocking always works, with two
> consequences on such hardware:
>
> The enable path writes CTRL_BLOCK first, which there acts as a plain
> enable and starts translation before the page table base is programmed.
>
> Worse, both TLB invalidation paths gate the invalidation writes on
> sysmmu_block() succeeding, which it never does - so every unmap silently
> skips the invalidation. A stale TLB entry is a valid entry pointing
> at a freed page, so nothing ever faults: the device reads back garbage
> and its writebacks corrupt whatever the kernel has since reused those pages for.
>
> This was tracked down on Exynos 8835 with the MFC, where the
> first decoder session of a boot worked and later sessions produced
> garbage along with random kernel memory corruption.
> Patches 1-3 add detection of the capability bit and adapt the enable
> sequence and the invalidation paths, matching the vendor driver's
> handling of these parts. Patch 4 is an independent debugging
> improvement: decode the v7 fault transaction info word (AxID/AxLEN),
> which identifies the issuing port when a master containing several
> DMA engines faults.
>
> Tested on the Samsung Galaxy Tab S9 FE (Exynos 8835/Exynos 1380).
>
> Signed-off-by: Markuss Broks <markuss.broks@gmail.com>
For the whole patchset:
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> Markuss Broks (4):
> iommu/exynos: detect SysMMUs without BLOCK mode
> iommu/exynos: fix the enable sequence for no-block SysMMUs
> iommu/exynos: fix TLB invalidation for no-block SysMMUs
> iommu/exynos: decode the v7 fault transaction info
>
> drivers/iommu/exynos-iommu.c | 37 +++++++++++++++++++++++++++++++++----
> 1 file changed, 33 insertions(+), 4 deletions(-)
> ---
> base-commit: 415606a7be939835db9b0d6b711887586646346d
> change-id: 20260820-exynos-iommu-fixes-e0e4d8f0fc06
>
> Best regards,
> --
> Markuss Broks <markuss.broks@gmail.com>
>
>
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
next prev parent reply other threads:[~2026-08-25 8:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20260820191213eucas1p10a8b83c2c6ab0505f80a0b469c7ae487@eucas1p1.samsung.com>
2026-08-20 19:12 ` Markuss Broks via B4 Relay
2026-08-20 19:12 ` [PATCH 1/4] iommu/exynos: detect SysMMUs without BLOCK mode Markuss Broks via B4 Relay
2026-08-20 19:12 ` [PATCH 2/4] iommu/exynos: fix the enable sequence for no-block SysMMUs Markuss Broks via B4 Relay
2026-08-20 19:12 ` [PATCH 3/4] iommu/exynos: fix TLB invalidation " Markuss Broks via B4 Relay
2026-08-20 19:12 ` [PATCH 4/4] iommu/exynos: decode the v7 fault transaction info Markuss Broks via B4 Relay
2026-08-25 8:16 ` Marek Szyprowski [this message]
2026-09-24 11:18 ` [PATCH 0/4] IOMMU driver improvements for modern Exynos SysMMUs Joerg Roedel (AMD)
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=eb0618b6-f2bc-4ed7-9178-e66ccee4962d@samsung.com \
--to=m.szyprowski@samsung.com \
--cc=alim.akhtar@samsung.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=markuss.broks@gmail.com \
--cc=peter.griffin@linaro.org \
--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
all inboxes | Powered by JetHome®