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 <[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().
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
