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@xxxxxxx>
> >
> > 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