Mostafa Saleh <[email protected]> writes: > On Wed, Jul 29, 2026 at 02:35:36PM +0530, Aneesh Kumar K.V wrote: >> Mostafa Saleh <[email protected]> writes: >> >> > On Fri, Jul 17, 2026 at 11:34:30PM +0530, Aneesh Kumar K.V (Arm) wrote: >> >> Change swiotlb_tbl_map_single() to take the DMA mapping attributes by >> >> reference and update the direct callers accordingly. >> >> >> >> This is a preparatory change for a follow-up patch which updates the >> >> attributes based on the selected swiotlb pool. Keeping the signature >> >> change >> >> separate makes the follow-up patch easier to review. >> >> >> > >> > I do not understand the point of this, why would >> > swiotlb_tbl_map_single() force attrs over the caller which should >> > already know the context (whether DMA is shared or not) which case >> > would this be useful to force from the SWIOTLB code? >> > >> >> The mapping request was for private memory, but the device could not use >> it because the dma_capable() (force_dma_unencrypted() == true) check >> failed. As a result, dma_direct_map_phys() allocated a swiotlb bounce >> buffer, which is shared. Since the DMA now targets the shared bounce >> buffer rather than the original private memory, the attributes must be >> updated to reflect the new shared mapping. >> >> dma_addr = phys_to_dma(dev, phys); >> if (unlikely(!dma_capable(dev, dma_addr, size, true))) >> if (is_swiotlb_active(dev)) >> return swiotlb_map(dev, phys, size, dir, attrs); >> >> > > But it does not make sense to me to have it in such a low level > function, and it shouldn't change the attrs that was passed. > > dma_direct_map_phys() is the right place to do this it should set > the correct attrs before calling swiotlb_map(). >
There is a possibility that we may support io_tlb_mem with cc_shared = false in the future. As a result, only swiotlb_map() knows which type of bounce buffer was used, making it the only place where the attributes can be updated correctly. -aneesh
