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

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: >
> Signed-off-by: Jianping Li <[email protected]>
> ---
>  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