linux-kernel - Re: [PATCH] fsldma: Support 40 bit DMA addresses where capable

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]

Message-ID: <2025042216-hungry-hound-77ecae@boujee-and-buff>
Date: Tue, 22 Apr 2025 17:10:32 -0400
From: Ben Collins <bcollins@...nel.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: dmaengine@...r.kernel.org, Vinod Koul <vkoul@...nel.org>, 
	linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fsldma: Support 40 bit DMA addresses where capable

On Tue, Apr 22, 2025 at 11:25:40AM -0500, Arnd Bergmann wrote:
> On Tue, Apr 22, 2025, at 10:56, Ben Collins wrote:
> > On Tue, Apr 22, 2025 at 09:59:42AM -0500, Arnd Bergmann wrote:
> >> 
> >> Right, but this could just mean that they end up using SWIOTLB
> >> to bounce the high DMA pages or use an IOMMU rather than actually
> >> translating the physical address to a dma address.
> >
> > There's a few things going on. The Local Address Window can shift
> > anywhere in the 64-bit address space and be as wide as the physical
> > address (40-bit on T4240, 36-bit on P4080). I think this is mainly for
> > IO to PCIe and RapidIO, though.
> 
> There are usually two sets of registers, not sure which one the Local
> Address Window refers to:
> 
> - Translation of MMIO addresses (PCI BAR and device registers) when
>   accessed from CPU and possibly from P2P DMA, these are represented
>   by the 'ranges' property in DT.
> 
> - Translation of physical memory when accessed from a DMA bus master,
>   represented by the 'dma-ranges' property.
> 
> The latter is what the dma-mapping API needs. This code has changed
> a lot over the years, but in the current version the idea is that
> the limit enforced by the driver through dma_set_mask() is independent
> of the limit enforced by the platform bus based on the dma-ranges
> property. 

LAWs translate physical addresses to IOVA (PCIe/RapidIO/SoC resources)
and are used for all master level translations (CPU, DMA, PCIe, DDR,
RapidIO). This is at the interconnect level.

I believe LAWs cover both of these cases.

> >> > I'll check on this, but I think it's a seperate issue. The main thing is
> >> > just to configure the dma hw correctly.
> >> 
> >> I think it's still important to check this before changing the
> >> driver: if the larger mask doesn't actually have any effect now
> >> because the DT caps the DMA at 4GB, then it might break later
> >> when someone adds the correct dma-ranges properties.
> >
> > I'm adding dma-ranges to my dt for testing.
> 
> Ok. The other thing you can try is to printk() the dev->bus_dma_limit
> to see if it even tries to use >32bit addressing.

Did that. Every combination of IOMMU on/off and dma-ranges in my dt always
showed bus_dma_limit as 0x0.

As an aside, if you could give this a quick check, I can send the revised
patch. Appreciate the feedback.

https://github.com/benmcollins/linux/commit/2f2946b33294ebff2fdaae6d1eadc976147470d6

-- 
 Ben Collins
 https://libjwt.io
 https://github.com/benmcollins
 --
 3EC9 7598 1672 961A 1139  173A 5D5A 57C7 242B 22CF

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)