Re: [PATCH v2] riscv: mm: fix SWIOTLB initialization for systems with DRAM above 4GB
Anirudh Srinivasan <[email protected]> Tue, 14 Jul 2026 10:37:31 -0500
| Newsgroups | dev.linux.lists.spacemit,org.infradead.lists.linux-riscv,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <k55h7j5qnn3dryqro2oof7kgjcdhyoarvg7uvtm6sbrgdtnfzy@br6areeqp4ng> |
Hi Paul, On Wed, Apr 29, 2026 at 07:41:54PM +0800, Troy Mitchell wrote: > On RISC-V platforms where the entire physical memory (DRAM) resides > above the 32-bit address space (i.e., above dma32_phys_limit), the > current SWIOTLB initialization logic fails. > > This patch addresses two interconnected issues on such platforms: > > 1. Incorrect 32-bit DMA bounce assumption: > The existing condition `max_pfn > PFN_DOWN(dma32_phys_limit)` assumes > that a 32-bit DMA bounce buffer is required simply because the maximum > PFN exceeds the 32-bit limit. However, if all DRAM starts above 4GB, > no memory exists below the limit to satisfy this allocation. Fix > this by adding a check to ensure `memblock_start_of_DRAM()` is actually > below the 32-bit limit before enforcing 32-bit SWIOTLB. > > 2. kmalloc() bounce buffer allocation failure on non-coherent systems: > For non-coherent hardware, a bounce buffer is still mandatory for > cache-line-aligned kmalloc(), even if 32-bit DMA bouncing is skipped. > Without the `SWIOTLB_ANY` flag, swiotlb_init() defaults to allocating > from low memory, which fails completely when DRAM only exists in high > memory. By appending `SWIOTLB_ANY` to swiotlb_flags, the allocator is > permitted to allocate this alignment buffer from high memory. > > With this patch, systems with non-coherent DMA and DRAM entirely above > 4GB can successfully map the software IO TLB in high memory and boot > normally. > > Tested-by: Anirudh Srinivasan <[email protected]> > Signed-off-by: Troy Mitchell <[email protected]> Do you think you can take this patch in? Regards Anirudh Srinivasan