Re: [PATCH 00/13] Don't use GFP_DMA when calling dma_alloc_coherent

[Baoquan He <baoquan.he@linux.dev>]

On 09/28/26 at 05:07pm, Andrew Morton wrote:
> On Mon, 28 Sep 2026 15:36:47 +0800 Baoquan He <baoquan.he@linux.dev> wrote:
> 
> > On 09/03/26 at 07:18pm, Baoquan He wrote:
> > > This series picks up the first part of an earlier cleanup series [1] that
> > > was prepared back in the year of 2022, but for various reasons never made
> > > it merged and has been sitting in a local tree since then. This subset
> > > only touches the call sites where GFP_DMA is passed to dma_alloc_coherent()
> > > (and its dma_alloc_wc()/dmam_alloc_coherent() variants), which is the most
> > > self-contained and least risky slice of that work.
> > > 
> > > That GFP_DMA is simply redundant here: the DMA API derives the allocation
> > > zone from the device's coherent_dma_mask (together with bus_dma_limit) and
> > > ignores the GFP_DMA flag passed by the caller. 
> > > 
> > > Removing the redundant GFP_DMA won't harm anything, while keeps it from
> > > being blindly copied into new code.
> > 
> > Gentle ping!
> > 
> > Wondering if Andrew can help take this, or anyone else I can add this to
> > ask for help.
> 
> oof, mm.git is overflowing and I'm trying to stem the flood.
> 
> But this series is so modest so what the heck.

Thanks a lot for picking this up despite mm.git overflowing — much
appreciated.  I see it's now queued in mm-new.

> 
> I actually kinda prefer that this sort of thing be done in a single
> "treewide: " patch.  It reduces the patch count and reduces the chance
> that a driver maintainer will cherrypick a random patch from mid-series
> instead of saying "ack".  But many disagree with me!

That's true, maintainers have different preference. I got requirements
asking to split patch according to arch-es or components. There's still
one place left because it's in network device driver code. I heard
network people has different patch submitting and reviewing rules, so
leave it to net dev to handle it.

Thanks again!

Baoquan