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

[Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>]

On 26-08-2026 14:11, Jianping Li wrote:
> 
> 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.
sounds good to me, thanks!>
> Thanks,
> Jianping
> 
>>