Re: [PATCH v8 00/23] dma-mapping: Track shared DMA state through direct, pool and swiotlb paths
Jason Gunthorpe <[email protected]> Sat, 25 Jul 2026 11:32:33 -0300
| Newsgroups | dev.linux.lists.linux-coco,dev.linux.lists.iommu,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-s390,org.ozlabs.lists.linuxppc-dev |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Jul 23, 2026 at 10:51:08AM +0300, Leon Romanovsky wrote: > 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. Yeah, but I don't really want to go from phys/virt to page, I'd rather see the other direction that is easier to reason about Maybe some small wrapper that returned phys or whatever would clean this up Jason