linux-kernel - Re: [PATCH v5 4/4] misc: fastrpc: Update 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] [day] [month] [year] [list]

Message-ID: <nkxygm3uyiiiq7jowifpnxl7vqnli7aui6hrnpswrwac3ae6gp@heoqhurmolze>
Date: Wed, 10 Dec 2025 00:55:25 +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 4/4] misc: fastrpc: Update dma_bits for CDSP support
 on Kaanapali SoC

On Mon, Dec 08, 2025 at 12:34:47PM +0530, Kumari Pallavi wrote:
> 
> 
> On 12/6/2025 8:01 AM, Dmitry Baryshkov wrote:
> > On Tue, Dec 02, 2025 at 11:36:28AM +0530, Kumari Pallavi wrote:
> > > DSP currently supports 32-bit IOVA (32-bit PA + 4-bit SID) for
> > > both Q6 and user DMA (uDMA) access. This is being upgraded to
> > > 34-bit PA + 4-bit SID due to a hardware revision in CDSP for
> > > Kaanapali SoC, which expands the DMA addressable range.
> > > Update DMA bits configuration in the driver to support CDSP on
> > > Kaanapali SoC. Set the default `dma_bits` to 32-bit and update
> > > it to 34-bit based on CDSP and OF matching on the fastrpc node.
> > > 
> > > Signed-off-by: Kumari Pallavi <kumari.pallavi@....qualcomm.com>
> > > ---
> > >   drivers/misc/fastrpc.c | 15 +++++++++++++--
> > >   1 file changed, 13 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> > > index 6a67daafeaa1..c5d2c426fcbc 100644
> > > --- a/drivers/misc/fastrpc.c
> > > +++ b/drivers/misc/fastrpc.c
> > > @@ -269,6 +269,8 @@ struct fastrpc_session_ctx {
> > >   struct fastrpc_soc_data {
> > >   	u32 sid_pos;
> > > +	u32 dma_addr_bits_extended;
> > 
> > s/extended/cdsp/
> > 
> 
> Thanks for your feedback.
> Here, i have used extended instead of the cdsp as to replace the
> domain-based naming with functional naming. Currently, CDSP supports an
> extended DMA address width of 34 bits due to specific use cases, but this
> could change in the future for other DSPs as well.
> Using names like "dma_addr_bits_extended" and "dma_addr_bits_default"
> would keep the design flexible and independent of domain.

And then at some point GPDSP will get yet another address width. How
would you name it?

> 
> Reference of the earlier conversation regarding the change of the name
> s/cdsp/extended
> 
> https://lore.kernel.org/all/e0d039e8-8f65-4e2e-9b73-74036dc0bb8d@oss.qualcomm.com/
> 
> Thanks,
> Pallavi
> 
> > > +	u32 dma_addr_bits_default;
> > >   };
> > >   struct fastrpc_channel_ctx {
> > > @@ -2189,6 +2191,7 @@ static int fastrpc_cb_probe(struct platform_device *pdev)
> > >   	int i, sessions = 0;
> > >   	unsigned long flags;
> > >   	int rc;
> > > +	u32 dma_bits;
> > >   	cctx = dev_get_drvdata(dev->parent);
> > >   	if (!cctx)
> > > @@ -2202,12 +2205,16 @@ static int fastrpc_cb_probe(struct platform_device *pdev)
> > >   		spin_unlock_irqrestore(&cctx->lock, flags);
> > >   		return -ENOSPC;
> > >   	}
> > > +	dma_bits = cctx->soc_data->dma_addr_bits_default;
> > >   	sess = &cctx->session[cctx->sesscount++];
> > >   	sess->used = false;
> > >   	sess->valid = true;
> > >   	sess->dev = dev;
> > >   	dev_set_drvdata(dev, sess);
> > > +	if (cctx->domain_id == CDSP_DOMAIN_ID)
> > > +		dma_bits = cctx->soc_data->dma_addr_bits_extended;
> > > +
> > >   	if (of_property_read_u32(dev->of_node, "reg", &sess->sid))
> > >   		dev_info(dev, "FastRPC Session ID not specified in DT\n");
> > > @@ -2222,9 +2229,9 @@ static int fastrpc_cb_probe(struct platform_device *pdev)
> > >   		}
> > >   	}
> > >   	spin_unlock_irqrestore(&cctx->lock, flags);
> > > -	rc = dma_set_mask(dev, DMA_BIT_MASK(32));
> > > +	rc = dma_set_mask(dev, DMA_BIT_MASK(dma_bits));
> > >   	if (rc) {
> > > -		dev_err(dev, "32-bit DMA enable failed\n");
> > > +		dev_err(dev, "%u-bit DMA enable failed\n", dma_bits);
> > >   		return rc;
> > >   	}
> > > @@ -2311,10 +2318,14 @@ static int fastrpc_get_domain_id(const char *domain)
> > >   static const struct fastrpc_soc_data kaanapali_soc_data = {
> > >   	.sid_pos = 56,
> > > +	.dma_addr_bits_extended = 34,
> > > +	.dma_addr_bits_default = 32,
> > >   };
> > >   static const struct fastrpc_soc_data default_soc_data = {
> > >   	.sid_pos = 32,
> > > +	.dma_addr_bits_extended = 32,
> > > +	.dma_addr_bits_default = 32,
> > >   };
> > >   static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev)
> > > -- 
> > > 2.34.1
> > > 
> > 
> 

-- 
With best wishes
Dmitry