mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  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®