Re: [PATCH] fastrpc: Reduce log level for DSP info and reserved memory messages

[Jianping Li]

On 8/25/2026 2:47 PM, Ekansh Gupta wrote:
> On 14-05-2026 11:58, Jianping Li wrote:
> > On some platforms (e.g. QCS615 Talos), fastrpc may temporarily fail
> > to retrieve DSP attributes during boot, resulting in repeated
> > "Error: dsp information is incorrect" messages printed on the
> > console.
> >
> > These messages are observed continuously during boot when metadata
> > flashing is enabled as part of RC releases, causing unnecessary
> > log noise.
> >
> > Similarly, the absence of reserved DMA memory is a valid
> > configuration and does not represent an error condition.
> >
> > Since these scenarios are expected and do not indicate a failure,
> > downgrade the log level from dev_err/dev_info to dev_dbg to avoid
> > flooding the console.
> >
> > No functional change intended.
> misc: fastrpc: >

ACK.

> > Signed-off-by: Jianping Li <jianping.li@xxxxxxxxxxxxxxxx>
> > ---
> >   drivers/misc/fastrpc.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> > index 1080f9acf70a..05ec14c07fd0 100644
> > --- a/drivers/misc/fastrpc.c
> > +++ b/drivers/misc/fastrpc.c
> > @@ -1802,7 +1802,7 @@ static int fastrpc_get_info_from_kernel(struct fastrpc_ioctl_capability *cap,
> >   		kfree(dsp_attributes);
> >   		return -EOPNOTSUPP;
> >   	} else if (err) {
> > -		dev_err(&cctx->rpdev->dev, "Error: dsp information is incorrect err: %d\n", err);
> > +		dev_dbg(&cctx->rpdev->dev, "Error: dsp information is incorrect err: %d\n", err);
> >   		kfree(dsp_attributes);
> >   		return err;
> >   	}
> > @@ -2361,7 +2361,7 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev)
> >   	}
> >   
> >   	if (of_reserved_mem_device_init_by_idx(rdev, rdev->of_node, 0))
> > -		dev_info(rdev, "no reserved DMA memory for FASTRPC\n");
> > +		dev_dbg(rdev, "no reserved DMA memory for FASTRPC\n");
> >   
> >   	vmcount = of_property_read_variable_u32_array(rdev->of_node,
> >   				"qcom,vmids", &vmids[0], 0, FASTRPC_MAX_VMIDS);
> Can you also move this log[1] to debug level/rate-limit? This can cause
> dmesg flooding in case all the session are already getting used by
> processes. Some discussion around the same happened here[2].
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1786
> [2] https://github.com/qualcomm/fastrpc/issues/383

Thanks for the pointer.

Agreed, that log can flood dmesg when the session pool is exhausted.
However, unlike the two messages in this patch, "No session available"
reflects a real failure — fastrpc_device_open() returns -EBUSY to
userspace on that path. Lowering it all the way to dev_dbg would hide a
genuine session-exhaustion condition from the default log, making such
issues harder to diagnose in the field.

So I'd prefer dev_err_ratelimited() here: it caps the flooding while
still surfacing the error. I'll fold this into the same series in v2.

Thanks,
Jianping

>