On Wed, Apr 20, 2022 at 10:47:46AM +0200, Christoph Hellwig wrote: > I can't really comment on the dma-ranges exlcusion for P2P mappings, > as that predates my involvedment, however: My example wasn't specific to the PCIe P2P transfers, but about PCIe devices reaching some platform devices over the system interconnect bus. > > On Wed, Apr 20, 2022 at 11:32:07AM +0300, Serge Semin wrote: > > See, if I get to map a virtual memory address to be accessible by any > > PCIe peripheral device, then the dma_map_sg/dma_map_page/etc > > procedures will take the PCIe host controller dma-ranges into account. > > It will work as expected and the PCIe devices will see the memory what > > I specified. But if I get to pass the physical address of the same > > page or a physical address of some device of the DEVs space to the > > dma_map_resource(), then the PCIe dma-ranges won't be taken into > > account, and the result mapping will be incorrect. That's why the > > current dma_map_resource() implementation seems very confusing to me. > > As I see it phys_addr_t is the type of the Interconnect address space, > > meanwhile dma_addr_t describes the PCIe, DEVs address spaces. > > > > Based on what I said here and in my previous email could you explain > > what do I get wrong? > > You simply must not use dma_map_resource for normal kernel memory. > So while the exclusion might be somewhat confusing, that confusion > really should not matter for any proper use of the API. What if I get to have a physical address of a platform device and want have that device being accessed by a PCIe peripheral device? The dma_map_resource() seemed very much suitable for that. But considering what you say it isn't. -Sergey
