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