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:

quoted

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