linux-kernel - Re: [PATCH v1 5/9] mmc: sdhci: add Black Sesame Technologies BST C1200 controller driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <5c0909b4-f3f6-401d-9a17-8560c5a1d7c0@app.fastmail.com>
Date: Fri, 27 Jun 2025 15:43:50 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Adrian Hunter" <adrian.hunter@...el.com>,
 "yangzh0906@...ndersoft.com" <yangzh0906@...ndersoft.com>,
 "Ulf Hansson" <ulf.hansson@...aro.org>, "gordon.ge" <gordon.ge@....ai>
Cc: bst-upstream <bst-upstream@...ai.top>,
 "linux-mmc @ vger . kernel . org" <linux-mmc@...r.kernel.org>,
 linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
 linux-kernel <linux-kernel@...r.kernel.org>,
 "Geert Uytterhoeven" <geert+renesas@...der.be>,
 "Victor Shih" <victor.shih@...esyslogic.com.tw>,
 "Shan-Chun Hung" <shanchun1218@...il.com>,
 "AngeloGioacchino Del Regno" <angelogioacchino.delregno@...labora.com>,
 "Peter Robinson" <pbrobinson@...il.com>,
 "Ben Chuang" <ben.chuang@...esyslogic.com.tw>
Subject: Re: [PATCH v1 5/9] mmc: sdhci: add Black Sesame Technologies BST C1200
 controller driver

On Fri, Jun 27, 2025, at 15:19, Adrian Hunter wrote:
> On 27/06/2025 13:22, yangzh0906@...ndersoft.com wrote:
>> Dear Mr. Hunter,
>> 
>> Our platform supports 64-bit physical addressing, but the eMMC controller's SRAM-based DMA engine is constrained to a 32-bit address space. 
>> When using the standard SDHCI interface, which allocates DDR-based DMA buffers with 64-bit addresses, thedma_map_single() operation fails 
>> because the DMA engine cannot handle addresses beyond 32 bits.

dma_map_single() should always succeed on arm64 even if the buffer
is outside of the dma mask: On most modern SoCs there is an SMMU/IOMMU
that implements the actual mapping, and in the absence of that
there is a fallback to SWIOTLB, which is always built-in on arm64.

> SDHCI controllers can use 32-bit DMA or 64-bit DMA, however even with
> 64-bit DMA it is possible to restrict the DMA addresses to 32-bits
> by setting a 32-bit DMA mask.
>
> If the host controller capabilities indicate support for 64-bit DMA
> but you want the driver to use 32-bit DMA, set SDHCI_QUIRK2_BROKEN_64_BIT_DMA.
>
> However, if you want to use 64-bit DMA with only 32-bit DMA addresses 
> you can instead implement sdhci host op ->set_dma_mask() and in that
> function dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))

I would not expect an standard SDHCI to be broken like this any more,
and if it is, I think the SDHCI_QUIRK2_BROKEN_64_BIT_DMA quirk is
more appropriate than overriding the dma_set_mask() operation.

What sometimes happens though is that the SoC integration itself is
broken, and a 64-bit capable DMA master like SDHCI is connected
to a 32-bit bus. In this case the DMA limitation should be
described in the device tree, using the "dma-ranges" property
of the broken bus node. The SDHCI code then still sets the correct
64-bit DMA mask according for the device, but the dma_map_single()
still uses an swiotlb bounce buffer or the IOMMU to work around
the bus restriction.

>>  To resolve this hardware limitation, we implement a bounce buffer allocated via >> dma_alloc_coherent() to satisfy DMA addressing constraints.
>
> The bounce buffer should not be needed to satisfy DMA addressing
> constraints.  It is used when SDHCI ADMA (scatter/gather) is broken.

I wonder if the actual problem here is not the addressing limit
but instead the coherency protocol. If the DMA master is cache
coherent but listed as non-coherent in DT, or vice versa, there will
be data corruption for all addresses, and using a dma_alloc_coherent()
bounce buffer may hide this.

       Arnd