Re: [PATCH v8 00/23] dma-mapping: Track shared DMA state through direct, pool and swiotlb paths

On Wed, Jul 22, 2026 at 04:57:09PM -0300, Jason Gunthorpe wrote:
> On Tue, Jul 21, 2026 at 03:40:56PM +0300, Leon Romanovsky wrote:
> 
> > Why don't we continue the effort to remove "struct page" entirely
> > from the DMA API internals?
> > 
> > IMHO, everything not exposed to DMA API users should use
> > phys_addr_t, including the DMA address pool.
> 
> The alloc interfaces return a struct page, that is why this stuff is
> organized like this. Look at dma_alloc_pages()

And I didn't say that we should change dma_alloc_pages(). It is external
API, which needs to be struct *page. I'm talking about internals.

Even dma_alloc_pages() flow shows how convoluted and non-uniform
the code underneath which performs translations all the time.

dma_alloc_pages()
	->  __dma_alloc_pages()
		-> dma_direct_alloc_pages()
....
	ret = page_address(page);             <--- here we need virt address
	if (dma_set_decrypted(dev, ret, size))
		goto out_leak_pages;
	memset(ret, 0, size);
	*dma_handle = phys_to_dma_direct(dev, page_to_phys(page)); <- and here we need phys address
	return page;

So my point is that internal flows should not require struct page
and should not depend on it.

> 
> There is also an API that forms a scatterlist that has to be struct
> page as well
> 
> Jason
>