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
