On 11/17/25 12:22 PM, Dmitry Baryshkov wrote:
> On Mon, Nov 17, 2025 at 12:37:33PM +0530, Kumari Pallavi wrote:
>>
>>
>> On 11/14/2025 9:14 PM, Bjorn Andersson wrote:
>>> On Fri, Nov 14, 2025 at 02:11:40PM +0530, Kumari Pallavi 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.
>>>>
>>>> Signed-off-by: Kumari Pallavi <[email protected]>
>>>> ---
>>>>   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 */
>>>>    u64 size;               /* size of contiguous region */
>>>>   };
>>>> @@ -171,7 +171,7 @@ struct fastrpc_msg {
>>>>    u64 ctx;                /* invoke caller context */
>>>>    u32 handle;     /* handle to invoke */
>>>>    u32 sc;         /* scalars structure describing the data */
>>>> -  u64 addr;               /* physical address */
>>>> +  u64 addr;               /* physical or dma address */
>>>
>>> Can you go all the way and make the type dma_addr_t? That way you don't
>>> need to typecast the dma_alloc_coherent() and dma_free_coherent().
>>>
>>> I believe it might complicate the places where you do math on it, but
>>> that is a good thing, as it highlights those places where you do
>>> something unexpected.
>>>
>>
>> While this not strictly limited to holding a dma_addr_t.
>> Based on historical behavior, when the FASTRPC_ATTR_SECUREMAP flag is
>> set, S2 mapping expects a physical address to be passed to the
>> qcom_scm_assign_mem() API.
>> reference-
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/misc/fastrpc.c?id=e90d911906196bf987492c94e38f10ca611dfd7b
>>
>> If you suggest, I can define it as dma_addr_t and perform typecasting to u64
>> wherever required.
> 
> You don't need to typecase dma_addr_t when passing u64.

*on arm anyway

Konrad

Reply via email to