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

[Jianping Li <jianping.li@oss.qualcomm.com>]

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@oss.qualcomm.com>
>> ---
>>   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

>