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 <[email protected]>
---
drivers/misc/fastrpc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
