[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5fc9b289-2578-44fc-aa87-61b27aee49da@oss.qualcomm.com>
Date: Mon, 17 Nov 2025 12:33:37 +0530
From: Kumari Pallavi <kumari.pallavi@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: kpallavi@....qualcomm.com, srini@...nel.org, amahesh@....qualcomm.com,
arnd@...db.de, gregkh@...uxfoundation.org, quic_bkumar@...cinc.com,
ekansh.gupta@....qualcomm.com, linux-kernel@...r.kernel.org,
quic_chennak@...cinc.com, dri-devel@...ts.freedesktop.org,
linux-arm-msm@...r.kernel.org, jingyi.wang@....qualcomm.com,
aiqun.yu@....qualcomm.com, ktadakam@....qualcomm.com
Subject: Re: [PATCH v3 2/4] misc: fastrpc: Rename phys to dma_addr for clarity
On 11/14/2025 5:45 PM, Dmitry Baryshkov wrote:
>> Update all references of buf->phys and map->phys to buf->dma_addr and
>> map->dma_addr to accurately represent that these fields store DMA
>> addresses, not physical addresses. This change improves code clarity
>> and aligns with kernel conventions for dma_addr_t usage.
> Why do you mention dma_addr_t here?
>
I mentioned dma_addr_t in the commit message because of the earlier
feedback highlighted about the confusing use of phys for fields that
actually store an IOVA-like address ('phys' with something more fitting
for an IOVA or DMA address).
https://lore.kernel.org/all/969bdb49-0682-4345-98f7-523404bb4213@app.fastmail.com/
>> Signed-off-by: Kumari Pallavi<kumari.pallavi@....qualcomm.com>
>> ---
>> drivers/misc/fastrpc.c | 76 ++++++++++++++++++++++--------------------
>> 1 file changed, 40 insertions(+), 36 deletions(-)
>>
>> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
>> index ee652ef01534..d6a7960fe716 100644
>> --- a/drivers/misc/fastrpc.c
>> +++ b/drivers/misc/fastrpc.c
>> @@ -106,7 +106,7 @@
>> #define miscdev_to_fdevice(d) container_of(d, struct fastrpc_device, miscdev)
>>
>> struct fastrpc_phy_page {
>> - u64 addr; /* physical address */
>> + u64 addr; /* physical or dma address */
> What is the difference here? Aren't all of them DMA addresses?
Yes, correct—both represent DMA addresses, just typed differently
depending on whether it originate from a physical or DMA mapping context.
ACK, I will update this in the next patch series.
Thanks,
Pallavi
Powered by blists - more mailing lists