On 9/25/2025 11:54 AM, Arnd Bergmann wrote:
On Thu, Sep 25, 2025, at 01:46, Jingyi Wang wrote:

        dma_free_coherent(buf->dev, buf->size, buf->virt,
-                         FASTRPC_PHYS(buf->phys));
+                         IOVA_TO_PHYS(buf->phys, sid_pos));
        kfree(buf);
  }

I understand what you are doing, but the naming of the macros
seems a bit confusing: dma_free_coherent() and the related
functions are designed to take an IOVA argument, not a physical
address, so calling IOVA_TO_PHYS() before passing the
address sounds wrong. This is made worse by the naming
of 'buf->phys' that is not a physical address at all
but already transformed twice into a dma_addr_t and
from there into a dma_addr+sid tuple.

Ideally the SID handling would be abstracted behind a custom
dma_map_ops implementation that treats this as a custom
iommu, but if the fastrpc device is the only user of this
address format, I can understand you want to keep this as
a local hack in this driver.

Can you try to come up with some better naming here, and
replace the 'phys' bits with something that is more fitting
for an iova/dma_addr_t?


I will improve the naming for better clarity:

- Replace buf->phys with buf->dma_addr throughout the code.
- Rename the macro IOVA_TO_PHYS() to something more appropriate, like IPA_TO_DMA_ADDR()
      Arnd

Thanks,
Pallavi

Reply via email to