[PATCH] misc: fastrpc: Don't fail probe when the SDSP memory assign fails

[PATCH] misc: fastrpc: Don't fail probe when the SDSP memory assign fails

[David Heidelberg via B4 Relay]

From: David Heidelberg <david@ixit.cz>

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: stable@vger.kernel.org
Fixes: 6a502776f4a4 ("misc: fastrpc: check qcom_scm_assign_mem() return in rpmsg_probe")
Signed-off-by: David Heidelberg <david@ixit.cz>
---
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 <david@ixit.cz>

Re: [PATCH] misc: fastrpc: Don't fail probe when the SDSP memory assign fails

[Konrad Dybcio]

On 9/23/26 12:38 AM, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
> 
> 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().

Making it do so there sounds like a better fix!

Konrad

Re: [PATCH] misc: fastrpc: Don't fail probe when the SDSP memory assign fails

[David Heidelberg]

On 23/09/2026 10:49, Konrad Dybcio wrote:
> On 9/23/26 12:38 AM, David Heidelberg via B4 Relay wrote:
>> From: David Heidelberg <david@ixit.cz>
>>
>> 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().
> 
> Making it do so there sounds like a better fix!

Please consider this patch more like a bug report and "disaster recovery" into 
acceptable error being provided.

The original patch states:

   No hardware testing was performed.

Thus after the patch fixing the potential issue it breaks kernel even more, 
while intentions was probably good.

I can clank "better" fix for this and test it, but I cannot dive into fastrpc 
right now, so quality will be limited.

David

> 
> Konrad

Re: [PATCH] misc: fastrpc: Don't fail probe when the SDSP memory assign fails

[Frieder Hannenheim]

On 23.09.26 00:38, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
> 
> 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: stable@vger.kernel.org
> Fixes: 6a502776f4a4 ("misc: fastrpc: check qcom_scm_assign_mem() return in rpmsg_probe")
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> 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 <david@ixit.cz>

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 <git@fhannenheim.net>
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;
  		};
  	};