From: David Heidelberg <[email protected]> A failed qcom_scm_assign_mem() aborts fastrpc_rpmsg_probe(). On SDM845 this turns every SLPI subsystem restart into an endless probe failure loop:
remoteproc3: crash detected in slpi: type fatal error remoteproc3: remote processor slpi is now up qcom_scm firmware:scm: Assign memory protection call failed -22 qcom,fastrpc 5c00000.remoteproc:glink-edge.fastrpcglink-apps-dsp.-1.-1: probe with driver qcom,fastrpc failed with error -22 qcom,fastrpc 5c00000.remoteproc:glink-edge.fastrpcglink-apps-dsp.-1.-1: rpmsg_dev_probe: failed: -22 The first assign succeeds and hands the reserved region to the VMIDs described in qcom,vmids. qcom_scm_assign_mem() reports the resulting owner set back through @srcvm, but the driver discards it, and nothing reverses the assignment in fastrpc_rpmsg_remove(). When the glink channel is re-announced after a subsystem restart, probe passes src_perms = BIT(QCOM_SCM_VMID_HLOS) again, which no longer describes the region, and the firmware rejects the call with -EINVAL. At that point the region is already assigned, and HLOS is part of the destination VMID list, so both the host and the DSP keep access. Failing the probe only removes /dev/fastrpc-sdsp and makes the remote reopen the channel, repeating the cycle indefinitely. Warn and continue instead Assisted-by: LLM Cc: [email protected] Fixes: 6a502776f4a4 ("misc: fastrpc: check qcom_scm_assign_mem() return in rpmsg_probe") Signed-off-by: David Heidelberg <[email protected]> --- Tracking the current owner set so the re-assign is issued with the correct source VMIDs is a separate fix, but I assume it would make sense to keep that to someone with more knowledge of fastrpc. I aim here to reverting into usable state again which can be also backported. Tested on Pixel 3 and 3 XL. --- drivers/misc/fastrpc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c index 90fd669636ec1..41943a3d496af 100644 --- a/drivers/misc/fastrpc.c +++ b/drivers/misc/fastrpc.c @@ -2590,17 +2590,19 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev) err = of_reserved_mem_region_to_resource(rdev->of_node, 0, &res); if (!err) { src_perms = BIT(QCOM_SCM_VMID_HLOS); err = qcom_scm_assign_mem(res.start, resource_size(&res), &src_perms, data->vmperms, data->vmcount); if (err) - goto err_free_data; + dev_warn(rdev, + "assign memory to SDSP failed: %d\n", + err); } } secure_dsp = !(of_property_read_bool(rdev->of_node, "qcom,non-secure-domain")); data->secure = secure_dsp; data->soc_data = soc_data; data->poll_mode_supported = soc_data->poll_mode_supported || --- base-commit: 7079a12d7506b07fb53b54a664bfad5fa9b16d70 change-id: 20260923-fastrpc-fail-slow-4dc839c1685c Best regards, -- David Heidelberg <[email protected]>
