Re: [PATCH v2] riscv: mm: fix SWIOTLB initialization for systems with DRAM above 4GB

[Anirudh Srinivasan]

Hi Paul,

On Sun, Jul 19, 2026 at 7:55 PM Paul Walmsley <pjw@xxxxxxxxxx> wrote:
>
> Hi Troy, Anirudh,
>
> a few questions -
>
> On Tue, 14 Jul 2026, Anirudh Srinivasan wrote:
>
> > 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.
>
> Is this primarily for the SpacemiT K3?  Or are there other
> platforms that this fixes?

Blackhole has this similar issue with no DMA32 ranges. This fix
applies to that too.

>
> > > 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.
>
> I'm not sure I'm parsing this correctly.  Shouldn't this read "for
> *non*-cache-aligned kmalloc()" ?  Or am I missing the point?
>
>
> - Paul