linux-kernel - Re: [PATCH v3 2/4] misc: fastrpc: Rename phys to dma

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <lxa5lomfvjf6e4jxt7c67cj7q6blflvc3lpmclybag3cumxtxb@xnte42junlmc>
Date: Mon, 17 Nov 2025 13:22:46 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Kumari Pallavi <kumari.pallavi@....qualcomm.com>
Cc: Bjorn Andersson <andersson@...nel.org>, 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 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 <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 */
> > >   	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.


-- 
With best wishes
Dmitry