From: sashiko-bot@kernel.org
To: "Aleksander Jan Bajkowski" <olek2@wp.pl>
Cc: conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH] arm64: dts: marvell: armada-37xx: mark EIP97 as dma-coherent
Date: Sun, 24 May 2026 13:04:21 +0000 [thread overview]
Message-ID: <20260524130421.E78481F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260524124456.350659-1-olek2@wp.pl>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Incorrectly marking the crypto engine as `dma-coherent` on the non-coherent Armada 37xx SoC bypasses necessary software cache maintenance, leading to silent data corruption.
--
commit cb353bcdff0077f7b4e65e2e644ffb6462f3946f
Author: Aleksander Jan Bajkowski <olek2@wp.pl>
Subject: arm64: dts: marvell: armada-37xx: mark EIP97 as dma-coherent
This commit marks the crypto engine (EIP97) on the Armada 37xx SoC as
dma-coherent to skip software cache synchronization.
> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> index 360fc24fdde22..8418777042b85 100644
> --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> @@ -437,6 +437,7 @@ crypto: crypto@90000 {
> interrupt-names = "ring0", "ring1", "ring2",
> "ring3", "eip", "mem";
> clocks = <&nb_periph_clk 15>;
> + dma-coherent;
[Severity: Critical]
Could this bypass necessary software cache maintenance on the non-coherent
Armada 37xx SoC?
Unlike the Armada 7k/8k, the Armada 37xx SoC does not appear to support
hardware I/O cache coherency for its peripheral interconnect.
Adding the dma-coherent property to the crypto node instructs the DMA API to
skip software cache maintenance, such as cleaning dirty CPU cache lines to
RAM before DMA transmission and invalidating them before CPU reads.
The observed performance improvement likely comes from bypassing these
essential CPU operations.
Without cache maintenance, could the crypto engine read stale data from
memory, and the CPU read stale data from its caches, resulting in silent
cryptographic data corruption?
Passing testmgr selftests is a common false positive for this regression,
as small test payloads often happen to be clean in the cache or benefit
from incidental cache states during early boot.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260524124456.350659-1-olek2@wp.pl?part=1
prev parent reply other threads:[~2026-05-24 13:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-24 12:44 [PATCH] arm64: dts: marvell: armada-37xx: mark EIP97 as dma-coherent Aleksander Jan Bajkowski
2026-05-24 13:04 ` sashiko-bot [this message]
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=20260524130421.E78481F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=olek2@wp.pl \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox