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: <ace8c85d-6dec-499f-8a8a-35d4672c181d@app.fastmail.com>
Date: Tue, 22 Apr 2025 09:59:42 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Ben Collins" <bcollins@...nel.org>
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: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.

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.

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

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

      Arnd