ARM: mvebu: dt64 for v7.2 (#1)
Hi,
Here is the first pull request for dt64 for mvebu for v7.2.
Gregory
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git tags/mvebu-dt64-7.2-1
for you to fetch changes up to 5dd98e0389545b302b0c46cef2264b5b09c01677:
arm64: dts: marvell: armada-37xx: mark EIP97 as dma-coherent (2026-06-01 10:04:36 +0200)
----------------------------------------------------------------
mvebu dt64 for 7.2 (part 1)
Mark EIP97 as dma-coherent for Armada 3720
----------------------------------------------------------------
Aleksander Jan Bajkowski (1):
arm64: dts: marvell: armada-37xx: mark EIP97 as dma-coherent
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 1 + 1 file changed, 1 insertion(+)
Quoted 9 lines · Gregory CLEMENT
----------------------------------------------------------------
mvebu dt64 for 7.2 (part 1)Mark EIP97 as dma-coherent for Armada 3720
----------------------------------------------------------------
Aleksander Jan Bajkowski (1):
arm64: dts: marvell: armada-37xx: mark EIP97 as dma-coherent
Hi Gregory and Aleksander,
I'm a bit surprised by this oneline change. Since you successfully tested this, I assume the change is correct, but I have two questions that I would like to have an answer for before I pull it.
- I would expect a missing 'dma-coherent' property to cause data corruption, as the DMA master may write directly into the L2 cache, which is then invalidated before the CPU accesses it. Do you have any idea how this one ends up working even when the property is missing?
- I see that the Product Brief for Armada 37xx mentions that it has a "High-bandwidth, low-latency IO Cache Coherency" interconnect, which also indicates that the patch is correct. However I don't see why it's only the crypto engine that needs it. What about the other high-speed DMA masters (neta, xhci, pcie, sata, ...)?
Arnd
Hi Arnd,
Quoted 6 lines · Arnd Bergmann
Quoted 5 lines · Gregory CLEMENT
----------------------------------------------------------------
mvebu dt64 for 7.2 (part 1)Mark EIP97 as dma-coherent for Armada 3720
Quoted 8 lines
Quoted 3 lines
----------------------------------------------------------------
Aleksander Jan Bajkowski (1):
arm64: dts: marvell: armada-37xx: mark EIP97 as dma-coherentHi Gregory and Aleksander,
I'm a bit surprised by this oneline change. Since you successfully tested this, I assume the change is correct, but I have two questions that I would like to have an answer for before I pull it.
By the way, the upstream safexcel driver works correctly only on coherent
platforms. On non-coherent platforms (MediaTek), the SHA-384 and SHA-512
selftests fail. Since the selftests pass on Armada's SoC, I assume I'm right.
I have a plan to send a patch upstream, which has long been maintained
downstream in OpenWRT[1]. But I need to think a bit more about how to do
this properly.
[1] https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/patches-6.18/401-crypto-fix-eip97-cache-incoherent.patch
Quoted 6 lines
- I would expect a missing 'dma-coherent' property to cause data corruption, as the DMA master may write directly into the L2 cache, which is then invalidated before the CPU accesses it. Do you have any idea how this one ends up working even when the property is missing?
No idea. Don't have access the Armada SoC TRM. Maybe the folks at Marvel will be able to explain it.
Quoted 6 lines
- I see that the Product Brief for Armada 37xx mentions that it has a "High-bandwidth, low-latency IO Cache Coherency" interconnect, which also indicates that the patch is correct. However I don't see why it's only the crypto engine that needs it. What about the other high-speed DMA masters (neta, xhci, pcie, sata, ...)?
I didn't test to determine whether the other DMA masters are coherent. But I'm assuming you're correct and they are also coherent. My recent work has been focused on improving the Rambus/Verimatrix/Safenet crypto drivers :)
Best regards,
Aleksander
Quoted 9 lines · Aleksander Jan Bajkowski
Quoted 3 lines · Arnd Bergmann
I'm a bit surprised by this oneline change. Since you successfully tested this, I assume the change is correct, but I have two questions that I would like to have an answer for before I pull it.
By the way, the upstream safexcel driver works correctly only on coherent
platforms. On non-coherent platforms (MediaTek), the SHA-384 and SHA-512 selftests fail. Since the selftests pass on Armada's SoC, I assume I'm right.
It's not necessarily proof that this is correct, but it is quite likely.
After checking the datasheet some more and finding that this should indeed be coherent everywhere, I remembered that even the old 32-bit Armada 370 had a coherency manager. At the time, we used a hack in arch/arm/mach-mvebu/coherency.c to mark all device nodes as coherent, since the original DTB did not contain the correct annotations.
I suspect that the Armada 37xx started out with a copy of the old DT files and also never had the annotation, but then never had the same hack because arch/arm64 does not have platform specific code.
Quoted 5 lines
I have a plan to send a patch upstream, which has long been maintained downstream in OpenWRT[1]. But I need to think a bit more about how to do this properly.
[1]
https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/patches-6.18/401-crypto-fix-eip97-cache-incoherent.patch
The patch is basically correct, I think you should just change two details:
- instead of defining your own SYSTEM_CACHELINE_SIZE macro, just use the existing CRYPTO_DMA_ALIGN macro that is used in crypto_dma_align
- move the 'state[]' and 'cache[]' arrays to the beginning of safexcel_ahash_req so you don't have to manually align them.
Quoted 7 lines
Quoted 5 lines
- I would expect a missing 'dma-coherent' property to cause data corruption, as the DMA master may write directly into the L2 cache, which is then invalidated before the CPU accesses it. Do you have any idea how this one ends up working even when the property is missing?
No idea. Don't have access the Armada SoC TRM. Maybe the folks at Marvel will be able to explain it.
ok
Arnd
Quoted 19 lines · Arnd Bergmann
Quoted 9 lines · Aleksander Jan Bajkowski
Quoted 3 lines · Arnd Bergmann
I'm a bit surprised by this oneline change. Since you successfully tested this, I assume the change is correct, but I have two questions that I would like to have an answer for before I pull it.
By the way, the upstream safexcel driver works correctly only on coherent
platforms. On non-coherent platforms (MediaTek), the SHA-384 and SHA-512 selftests fail. Since the selftests pass on Armada's SoC, I assume I'm right.It's not necessarily proof that this is correct, but it is quite likely.
After checking the datasheet some more and finding that this should indeed be coherent everywhere, I remembered that even the old 32-bit Armada 370 had a coherency manager. At the time, we used a hack in
arch/arm/mach-mvebu/coherency.cto mark all device nodes as coherent, since the original DTB did not contain the correct annotations.
Quoted 4 lines
I suspect that the Armada 37xx started out with a copy of the old DT files and also never had the annotation, but then never had the same hack because
arch/arm64does not have platform specific code.
After investigating a little more, I think the correct fix here will be to mark all DMA masters in this SoC as dma-coherent. I thought there was a way to do this for an entire system, but I could not find that, so this likely has to be done for each DMA master separately.
Not sure who still has the hardware and has time to test this properly. Given that the incorrect DT has existed for over 10 years now, I assume this is not urgent and I will skip the pull request for 7.2.
Arnd
Hello Arnd,
Quoted 25 lines · Arnd Bergmann
Quoted 19 lines · Aleksander Jan Bajkowski
Quoted 9 lines · Arnd Bergmann
Quoted 3 lines
I'm a bit surprised by this oneline change. Since you successfully tested this, I assume the change is correct, but I have two questions that I would like to have an answer for before I pull it.
By the way, the upstream safexcel driver works correctly only on coherent
platforms. On non-coherent platforms (MediaTek), the SHA-384 and SHA-512 selftests fail. Since the selftests pass on Armada's SoC, I assume I'm right.It's not necessarily proof that this is correct, but it is quite likely.
After checking the datasheet some more and finding that this should indeed be coherent everywhere, I remembered that even the old 32-bit Armada 370 had a coherency manager. At the time, we used a hack in
arch/arm/mach-mvebu/coherency.cto mark all device nodes as coherent, since the original DTB did not contain the correct annotations.Quoted 4 lines
I suspect that the Armada 37xx started out with a copy of the old DT files and also never had the annotation, but then never had the same hack because
arch/arm64does not have platform specific code.
Quoted 5 lines
After investigating a little more, I think the correct fix here will be to mark all DMA masters in this SoC as dma-coherent. I thought there was a way to do this for an entire system, but I could not find that, so this likely has to be done for each DMA master separately.
Thanks for doing this research. I also checked the data in the datasheet before applying the patch, and it appears the platform is coherent. I was surprised that when we initially submitted the support request, Marvel didn't mention this; usually, SoC vendors like to have good performance numbers. However, they also didn't say anything about a coherence issue. The fact that the test succeeded is a good indicator that the SoC is indeed coherent.
Quoted 5 lines
Not sure who still has the hardware and has time to test this properly. Given that the incorrect DT has existed for over 10 years now, I assume this is not urgent and I will skip the pull request for 7.2.
I believe I still have a board based on an Armada 3700, and I should be able to find time to do some tests.
Gregory
Quoted 2 lines
Arnd
Signature · 3 lines
Grégory CLEMENT, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Hi Arnd,
Quoted 28 lines · Arnd Bergmann
Quoted 9 lines · Aleksander Jan Bajkowski
Quoted 3 lines · Arnd Bergmann
I'm a bit surprised by this oneline change. Since you successfully tested this, I assume the change is correct, but I have two questions that I would like to have an answer for before I pull it.
By the way, the upstream safexcel driver works correctly only on coherent
platforms. On non-coherent platforms (MediaTek), the SHA-384 and SHA-512 selftests fail. Since the selftests pass on Armada's SoC, I assume I'm right.It's not necessarily proof that this is correct, but it is quite likely.
After checking the datasheet some more and finding that this should indeed be coherent everywhere, I remembered that even the old 32-bit Armada 370 had a coherency manager. At the time, we used a hack in
arch/arm/mach-mvebu/coherency.cto mark all device nodes as coherent, since the original DTB did not contain the correct annotations.I suspect that the Armada 37xx started out with a copy of the old DT files and also never had the annotation, but then never had the same hack because
arch/arm64does not have platform specific code.Quoted 5 lines
I have a plan to send a patch upstream, which has long been maintained downstream in OpenWRT[1]. But I need to think a bit more about how to do this properly.
[1]
https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/patches-6.18/401-crypto-fix-eip97-cache-incoherent.patch
Quoted 8 lines
The patch is basically correct, I think you should just change two details:
- instead of defining your own
SYSTEM_CACHELINE_SIZEmacro, just use the existingCRYPTO_DMA_ALIGNmacro that is used incrypto_dma_align- move the 'state[]' and 'cache[]' arrays to the beginning of
safexcel_ahash_reqso you don't have to manually align them.
My biggest concern is the increased memory overhead. On Marvell platforms, this increases the structure size by 150 bytes. I’ve checked, and both CRYPTO_DMA_ALIGN and ARCH_DMA_MINALIGN always have a value of 128. On MIPS platforms, ARCH_DMA_MINALIGN is set per SoC in the mach files. I assume that on a Marvell platform with coherent DMA, I should set the value to 4, and on a non-coherent MediaTek platform, to 64. How should this be handled on an ARM platform?
Best Regards,
Aleksander