On 23.09.26 00:38, David Heidelberg via B4 Relay wrote:
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]>
I've had a similar issue on sm8250. There the downstream devicetree
mapped fastrpc-mem over the whole memory but only used a small part of
it as defined in qcom,iommu-dma-addr-pool. Redefining fastrpc_mem to
only use that range fixed the problem.
commit 946f65f7f3300741a2c0b6eb0248ccd19eca1925
Author: Frieder Hannenheim <[email protected]>
Date: Thu Aug 6 20:04:08 2026 +0200
sm8250.dtsi: correct fastrpc_mem
- fixes spli bringup
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index c490815ee3a2..f3ac307ed1db 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -866,9 +866,8 @@ cdsp_secure_heap: memory@8bf00000 {
fastrpc_mem: fastrpc {
compatible = "shared-dma-pool";
- alloc-ranges = <0x0 0x00000000 0x0 0xffffffff>;
- alignment = <0x0 0x400000>;
- size = <0x0 0x2000000>;
+ alloc-ranges = <0x80000000 0x78000000>;
+ alignment = <0x400000>;
reusable;
};
};
