[GIT PULL] ARM: mvebu: dt64 for v7.2 (#1)

[Arnd Bergmann]

On Tue, Jun 9, 2026, at 19:35, Aleksander Jan Bajkowski wrote:
> On 09/06/2026 18:11, Arnd Bergmann wrote:
>> 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.

> 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.
  
>> - 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