linux-kernel - Re: [PATCH v5 3/4] misc: fastrpc: Add support for new DSP IOVA formatting

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 for Android: free password hash cracker in your pocket

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

Message-ID: <ro7g7m42ostyc5xirx53zp7fvyobzr6zfm3huy5thlf6kwocmo@etqhbev43nfk>
Date: Wed, 10 Dec 2025 00:52:28 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Kumari Pallavi <kumari.pallavi@....qualcomm.com>
Cc: kpallavi@....qualcomm.com, srini@...nel.org, amahesh@....qualcomm.com,
        arnd@...db.de, gregkh@...uxfoundation.org, robh@...nel.org,
        krzk+dt@...nel.org, conor+dt@...nel.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, devicetree@...r.kernel.org,
        jingyi.wang@....qualcomm.com, aiqun.yu@....qualcomm.com,
        ktadakam@....qualcomm.com
Subject: Re: [PATCH v5 3/4] misc: fastrpc: Add support for new DSP IOVA
 formatting

On Mon, Dec 08, 2025 at 12:56:18PM +0530, Kumari Pallavi wrote:
> 
> 
> On 12/6/2025 8:00 AM, Dmitry Baryshkov wrote:
> > On Tue, Dec 02, 2025 at 11:36:27AM +0530, Kumari Pallavi wrote:
> > > Implement the new IOVA formatting required by the DSP architecture change
> > > on Kaanapali SoC. Place the SID for DSP DMA transactions at bit 56 in the
> > > physical address. This placement is necessary for the DSPs to correctly
> > > identify streams and operate as intended.
> > > To address this, set SID position to bit 56 via OF matching on the fastrpc
> > > node; otherwise, default to legacy 32-bit placement.
> > > This change ensures consistent SID placement across DSPs.
> > > 
> > > Signed-off-by: Kumari Pallavi <kumari.pallavi@....qualcomm.com>
> > > ---
> > >   drivers/misc/fastrpc.c | 48 ++++++++++++++++++++++++++++++++++++------
> > >   1 file changed, 41 insertions(+), 7 deletions(-)
> > > 
> > > @@ -789,7 +807,8 @@ static int fastrpc_map_attach(struct fastrpc_user *fl, int fd,
> > >   		map->dma_addr = sg_phys(map->table->sgl);
> > >   	} else {
> > >   		map->dma_addr = sg_dma_address(map->table->sgl);
> > > -		map->dma_addr += ((u64)fl->sctx->sid << 32);
> > > +		map->dma_addr += fastrpc_compute_sid_offset((u64)fl->sctx->sid,
> > 
> > Drop type conversion. Hmm. Looking at it, would it be better:
> > 
> > map->dma_addr = fastrpc_compute_dma_addr(fl->sctx, sg_dma_address(map->table->sgl))
> > 
> 
> Thanks for the suggestion. To confirm: you’re proposing that the call site
> use a single helper returning the final DMA address, i.e.
> 
> map->dma_addr = fastrpc_compute_dma_addr(fl,
>                                          sg_dma_address(map->table->sgl));
> I can implement fastrpc_compute_dma_addr() as a thin wrapper that internally
> calls our existing fastrpc_compute_sid_offset() and composes the
> consolidated IOVA (SID in upper bits, base DMA/PA in lower bits)
> ?

Yes

> 
> 
> > > +				 fl->cctx->soc_data->sid_pos);
> > >   	}
> > >   	for_each_sg(map->table->sgl, sgl, map->table->nents,
> > >   		sgl_index)

-- 
With best wishes
Dmitry