linux-kernel - Re: [PATCH] New config added to handle 64-bit systems with 32-bit DMA support

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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Wed, 19 Jun 2024 13:46:03 +0100
From: Robin Murphy <robin.murphy@....com>
To: Michael Nazzareno Trimarchi <michael@...rulasolutions.com>
Cc: Alberto Secondi <albertosecondi@...il.com>, hch@....de,
 m.szyprowski@...sung.com, iommu@...ts.linux.dev,
 linux-kernel@...r.kernel.org, alberto.secondi@...nsula.com,
 Davide Salaris <davide.salaris@...nsula.com>
Subject: Re: [PATCH] New config added to handle 64-bit systems with 32-bit DMA
 support


On 2024-06-19 12:43 pm, Michael Nazzareno Trimarchi wrote:
> Hi Robin
> 
> On Wed, Jun 19, 2024 at 12:36 PM Robin Murphy <robin.murphy@....com> wrote:
>>
>> On 2024-06-19 10:17 am, Alberto Secondi wrote:
>>> ------ Tessian Warning ------
>>>
>>> Be careful, the email's sending address "albertosecondi@...il[.]com" has never been seen on your company's network before today
>>>
>>> This warning message will be removed if you reply to or forward this email to a recipient outside of your organization.
>>>
>>> ---- Tessian Warning End ----
>>>
>>> From: Alberto Secondi <alberto.secondi@...nsula.com>
>>>
>>> The kernel assumes that 64-bit systems have 64-bit DMA support through
>>> CONFIG_ARCH_DMA_ADDR_T_64BIT. This is not always true; for example, several
>>> iMX8 systems (verified on iMX8MM and iMX8MP) have DMA with only 32-bit support.
>>> This results in several drivers requesting DMA_BIT_MASK(64), which causes
>>> malfunctions, particularly when systems have more than 3GB of DRAM (verified
>>> with the lan743x driver and iMX8 systems with 4GB of DRAM). Therefore, a new
>>> config ARCH_64BIT_HAS_DMA32_ONLY was added to manage 64-bit systems with 32-bit
>>> DMA, which adjusts DMA_BIT_MASK(n) accordingly.
>>
>> No. If a system has devices naturally capable of >32-bit DMA, and memory
>> at >32-bit system physical addresses, but only a 32-bit interconnect in
>> between, that needs to be described properly in Devicetree/ACPI, not
>> hacked around with completely non-portable kernel bodges.
>>
> 
> commit 4251a3ac4de9625a284a9c046cc915487e9b2a5e
> Author: Lucas Stach <l.stach@...gutronix.de>
> Date:   Tue May 4 10:20:51 2021 +0200
> 
>      arm64: dts: imx8mm: specify dma-ranges
> 
>      DMA addressing capabilities on i.MX8MM are limited by the interconnect,
>      same as on i.MX8MQ. Add dma-ranges to the the peripheral bus to let
>      the kernel know about this.
> 
>      Signed-off-by: Lucas Stach <l.stach@...gutronix.de>
>      Reviewed-by: Frieder Schrempf <frieder.schrempf@...tron.de>
>      Tested-by: Frieder Schrempf <frieder.schrempf@...tron.de>
>      Signed-off-by: Shawn Guo <shawnguo@...nel.org>
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> index 64aa38fd2b6e0..e7648c3b83905 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> @@ -261,6 +261,7 @@ soc@0 {
>                  #address-cells = <1>;
>                  #size-cells = <1>;
>                  ranges = <0x0 0x0 0x0 0x3e000000>;
> +               dma-ranges = <0x40000000 0x0 0x40000000 0xc0000000>;
>                  nvmem-cells = <&imx8mm_uid>;
>                  nvmem-cell-names = "soc_unique_id";
> 
> 
> Somenthing like this should already do it?

Hmm, indeed... so the question to dig into would be why that's 
apparently not getting picked up by of_dma_get_range() for that device.

Thanks,
Robin.