Messages in this thread | | | From | Laurentiu Tudor <> | Subject | Re: [RFC PATCH 1/3] dma-mapping: introduce a new dma api dma_addr_to_phys_addr() | Date | Thu, 24 Oct 2019 07:49:03 +0000 |
| |
On 24.10.2019 05:01, hch@lst.de wrote: > On Wed, Oct 23, 2019 at 11:53:41AM +0000, Laurentiu Tudor wrote: >> We had an internal discussion over these points you are raising and >> Madalin (cc-ed) came up with another idea: instead of adding this prone >> to misuse api how about experimenting with a new dma unmap and dma sync >> variants that would return the physical address by calling the newly >> introduced dma map op. Something along these lines: >> * phys_addr_t dma_unmap_page_ret_phys(...) >> * phys_addr_t dma_unmap_single_ret_phys(...) >> * phys_addr_t dma_sync_single_for_cpu_ret_phys(...) >> I'm thinking that this proposal should reduce the risks opened by the >> initial variant. >> Please let me know what you think. > > I'm not sure what the ret is supposed to mean, but I generally like > that idea better.
It was supposed to be short for "return" but given that I'm not good at naming stuff I'll just drop it.
> We also need to make sure there is an easy way > to figure out if these APIs are available, as they generally aren't > for any non-IOMMU API IOMMU drivers.
I was really hoping to manage making them as generic as possible but anyway, I'll start working on a PoC and see how it turns out. This will probably happen sometime next next week as the following week I'll be traveling to a conference.
--- Best Regards, Laurentiu
| |