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

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

[Jianping Li]

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.

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);
-- 
2.43.0

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

[Dmitry Baryshkov]

On Thu, May 14, 2026 at 02:28:25PM +0800, Jianping Li wrote:
> On some platforms (e.g. QCS615 Talos), fastrpc may temporarily fail
> to retrieve DSP attributes during boot, resulting in repeated

temporarily? What does it mean? Should there be any sync with the DSP,
letting the FastRPC driver know when it's safe to retrieve the
information?

> "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.
> 
> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
> ---
>  drivers/misc/fastrpc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
-- 
With best wishes
Dmitry

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

[Jianping Li]

On 5/18/2026 7:08 AM, Dmitry Baryshkov wrote:
> On Thu, May 14, 2026 at 02:28:25PM +0800, Jianping Li wrote:
>> On some platforms (e.g. QCS615 Talos), fastrpc may temporarily fail
>> to retrieve DSP attributes during boot, resulting in repeated
> temporarily? What does it mean? Should there be any sync with the DSP,
> letting the FastRPC driver know when it's safe to retrieve the
> information?

Hi Dmitry,

Thanks for the review — "temporarily" was a poor word choice on
my part, sorry for the confusion. There is no boot-time race
that eventually resolves; let me walk through the code to make
the actual scenario clearer.

The FastRPC misc device is only registered after the rpmsg
channel to the DSP is up (fastrpc_rpmsg_probe ->
fastrpc_device_register), so the transport-level sync between
the driver and the DSP is already in place before userspace can
issue any ioctl. And fastrpc_get_info_from_kernel() already
caches the result the first time it succeeds:

     if (cctx->valid_attributes) {
         spin_unlock_irqrestore(&cctx->lock, flags);
         goto done;
     }
     ...
     err = fastrpc_get_info_from_dsp(...);
     if (err == DSP_UNSUPPORTED_API) {
         dev_info(... "DSP capabilities not supported\n");
         return -EOPNOTSUPP;
     } else if (err) {
         dev_err(... "dsp information is incorrect err: %d\n", err);
         return err;
     }
     ...
     cctx->valid_attributes = true;

So on platforms where the DSP firmware implements the attribute
RPC, the message is not printed and the query happens exactly
once for the lifetime of the channel.

On this SoC the DSP firmware returns a non-zero error that is not
DSP_UNSUPPORTED_API, so the else-if (err) branch is taken every
time: valid_attributes is never set, the next open re-queries
the DSP, and the same dev_err line is printed again. On RC
builds with metadata flashing enabled, several such clients come
up at boot and the console gets flooded.

I think lowering the kernel log level is the least invasive fix.

I'll respin v2 with the commit message reworded to drop
"temporarily" and describe the above accurately. No functional
change beyond the log-level downgrade.

Thanks,
Jianping

>
>> "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.
>>
>> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
>> ---
>>   drivers/misc/fastrpc.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>

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

[Dmitry Baryshkov]

On Fri, Jul 03, 2026 at 04:31:43PM +0800, Jianping Li wrote:
> 
> On 5/18/2026 7:08 AM, Dmitry Baryshkov wrote:
> > On Thu, May 14, 2026 at 02:28:25PM +0800, Jianping Li wrote:
> > > On some platforms (e.g. QCS615 Talos), fastrpc may temporarily fail
> > > to retrieve DSP attributes during boot, resulting in repeated
> > temporarily? What does it mean? Should there be any sync with the DSP,
> > letting the FastRPC driver know when it's safe to retrieve the
> > information?
> 
> Hi Dmitry,
> 
> Thanks for the review — "temporarily" was a poor word choice on
> my part, sorry for the confusion. There is no boot-time race
> that eventually resolves; let me walk through the code to make
> the actual scenario clearer.
> 
> The FastRPC misc device is only registered after the rpmsg
> channel to the DSP is up (fastrpc_rpmsg_probe ->
> fastrpc_device_register), so the transport-level sync between
> the driver and the DSP is already in place before userspace can
> issue any ioctl. And fastrpc_get_info_from_kernel() already
> caches the result the first time it succeeds:
> 
>     if (cctx->valid_attributes) {
>         spin_unlock_irqrestore(&cctx->lock, flags);
>         goto done;
>     }
>     ...
>     err = fastrpc_get_info_from_dsp(...);
>     if (err == DSP_UNSUPPORTED_API) {
>         dev_info(... "DSP capabilities not supported\n");
>         return -EOPNOTSUPP;
>     } else if (err) {
>         dev_err(... "dsp information is incorrect err: %d\n", err);
>         return err;
>     }
>     ...
>     cctx->valid_attributes = true;
> 
> So on platforms where the DSP firmware implements the attribute
> RPC, the message is not printed and the query happens exactly
> once for the lifetime of the channel.
> 
> On this SoC the DSP firmware returns a non-zero error that is not
> DSP_UNSUPPORTED_API,

Why? Which error is returned?

> so the else-if (err) branch is taken every
> time: valid_attributes is never set, the next open re-queries
> the DSP, and the same dev_err line is printed again. On RC
> builds with metadata flashing enabled, several such clients come
> up at boot and the console gets flooded.
> 
> I think lowering the kernel log level is the least invasive fix.
> 
> I'll respin v2 with the commit message reworded to drop
> "temporarily" and describe the above accurately. No functional
> change beyond the log-level downgrade.
> 

-- 
With best wishes
Dmitry

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

[Jianping]

在 2026/5/18 7:08, Dmitry Baryshkov 写道:
> On Thu, May 14, 2026 at 02:28:25PM +0800, Jianping Li wrote:
>> On some platforms (e.g. QCS615 Talos), fastrpc may temporarily fail
>> to retrieve DSP attributes during boot, resulting in repeated
> 
> temporarily? What does it mean? Should there be any sync with the DSP,
> letting the FastRPC driver know when it's safe to retrieve the
> information?
Hi Dmitry,

Thanks for the review.

You are right, "temporarily during boot" is not an accurate description.

After further investigation, the message is not tied specifically to 
boot timing.
I can reproduce it at any time by manually starting adsprpcd on QCS615 
Talos:

     # adsprpcd

which results in repeated:

     Error: dsp information is incorrect err: -1

The failure originates from the DSP capability query path, where the DSP 
side returns an error while handling the request.
This feature is not currently available on Talos adsp.

Therefore my intention is not to hide a boot synchronization problem, 
but to reduce console noise for a condition that appears to be 
platform-specific and non-fatal.

I'll update the commit message to describe the issue more accurately in 
the next version.

Thanks,
Jianping
> 
>> "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.
>>
>> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
>> ---
>>   drivers/misc/fastrpc.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>

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

[Ekansh Gupta]

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 <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

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@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

>

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

[Ekansh Gupta]

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
> 
>>