Re: [PATCH] mm: export cma alloc and release

[Mark Salyzyn]

On 10/7/19 9:53 AM, Christoph Hellwig wrote:
> On Mon, Oct 07, 2019 at 09:50:31AM -0700, Mark Salyzyn wrote:
> > On 10/5/19 1:37 AM, Christoph Hellwig wrote:
> > > On Thu, Oct 03, 2019 at 09:55:28AM +0100, Catalin Marinas wrote:
> > > > Aren't drivers supposed to use the DMA API for such allocations rather
> > > > than invoking cma_*() directly?
> > > Yes, they are.
> > We have an engineer assigned to rewriting the ion memory driver to use
> > dma_buf interfaces. Hopefully that effort will solve the problem of
> > requiring these interfaces to be exported so that that driver (and others)
> > can be modularized.
> >
> > Thanks for the reviews, drop this patch from the list and we will regroup,
> > and accept that standing code in the kernel can not be modularized for the
> > moment.
> How is that different from the "DMA-BUF Heaps (destaging ION)" series
> floating around?

IDK, I am asking around because I am only superficially aware of that 
effort. Please view this as the left hand does not know what the right 
hand is doing. My issue was with a series of out-of-tree drivers that 
use the calls, and noted that currently the ion driver is using them as 
well, as rationalization for a 'user' for the export. I am pushing back 
on those out-of-tree drivers to switch their CMA interfaces to a modern 
approach as a result of these reviews; the result of this review had a 
positive effect because I was considering exporting them in the Android 
distro as a minimum, and now I am soundly rejecting that approach.

Sincerely -- Mark Salyzyn