On Tue, Apr 22, 2025, at 23:10, Ben Collins wrote: > On Tue, Apr 22, 2025 at 11:25:40AM -0500, Arnd Bergmann wrote: >> On Tue, Apr 22, 2025, at 10:56, Ben Collins wrote: >> >> >> > 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.
Strange, either something changed since I last looked at this code, or there is something on Freescale SoCs that avoids the default logic. There was originally a hack for powerpc that allowed DMA to be done in the absence of a dma-ranges property in the bus node, but limit it to 32-bit addressing for backwards compatibility, while all other architectures should require either an empty dma-ranges to allow full addressing or a specific translation if there is a bus specific limit and/or offset. Looking at the current code I don't see that any more, so it's possible that now any DMA is allowed even if there is no dma-ranges property at all. > 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 This looks correct to me, but I would change two things: - remove the debug message, which you probably left by accident - instead of the explicit of_device_is_compatible(), change it to use the .data field of the of_device_id table instead. Arnd
