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: <2025042204-apricot-tarsier-b7f5a1@boujee-and-buff>
Date: Tue, 22 Apr 2025 04:56:01 -0400
From: Ben Collins <bcollins@...nel.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: dmaengine@...r.kernel.org, Zhang Wei <zw@...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 09:59:42AM -0500, Arnd Bergmann wrote:
> On Tue, Apr 22, 2025, at 09:12, Ben Collins wrote:
> > On Tue, Apr 22, 2025 at 08:34:55AM -0500, Arnd Bergmann wrote:
> >> 
> >> - SoCs that don't set a dma-ranges property in the parent bus
> >>   are normally still capped to 32 bit DMA. I don't see those
> >>   properties, so unless there is a special hack on those chips,
> >>   you get 32 bit DMA regardless of what DMA mask the driver
> >>   requests
> >
> > I've yet to see a dma-ranges property in any of the Freescale PowerPC
> > device trees.
> 
> 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.

> The only special case I see for freescale powerpc chips is the
> PCI dma_set_mask() handler that does
> 
> static void fsl_pci_dma_set_mask(struct device *dev, u64 dma_mask)
> {
>         /*
>          * Fix up PCI devices that are able to DMA to the large inbound
>          * mapping that allows addressing any RAM address from across PCI.
>          */
>         if (dev_is_pci(dev) && dma_mask >= pci64_dma_offset * 2 - 1) {
>                 dev->bus_dma_limit = 0;
>                 dev->archdata.dma_offset = pci64_dma_offset;
>         }
> }
> 
> but that should not apply here because this is not a PCI device.

Right.

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

> > So a little research shows that these 3 compatible strings in
> > the fsldma are:
> >
> > fsl,elo3-dma:		40-bit
> > fsl,eloplus-dma:	36-bit
> > fsl,elo-dma:		32-bit
> >
> > I'll rework it so addressing is based on the compatible string.
> 
> Sounds good, yes. Just to clarify: where did you find those
> limits? Are you sure those are not just the maximum addressable
> amounts of physical RAM on the chips that use the respective
> controllers?

This is where things might be more interesting. The P4080RM and T4240RM
is where I got this information. Register "cdar" in the fsldma code. This
makes up 0x08 and 0x0c registers.

In the RM 0x08 is the extended address register. On P4080 it says this
holds the top 4 bits of the 36-bit address, and on T4240 it says the top
8 bits of the 40-bit address. So the asynx_tx physical address needs to
be masked to the 36-bit or 40-bit.

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