Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] misc: fastrpc: overly broad error suppression for qcom_scm_assign_mem --
commit 14fb4cbe62a25ea5813ad10df366839d89bc56bf Author: David Heidelberg <[email protected]> misc: fastrpc: Don't fail probe when the SDSP memory assign fails This commit modifies the SDSP domain initialization in fastrpc_rpmsg_probe() to warn rather than fail when qcom_scm_assign_mem() returns an error. The intent is to prevent an endless probe failure loop when a subsystem restart triggers a secondary memory assignment attempt. > 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 > @@ -2595,7 +2595,9 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device > *rpdev) > 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); [Severity: High] Does unconditionally bypassing this error risk breaking DSP execution under different failure conditions? If a legitimate failure occurs in qcom_scm_assign_mem() (such as -ENOMEM during SCM communication, rather than an -EINVAL from a redundant assignment), the memory region remains unassigned to the DSP. When the DSP subsequently attempts to access that memory, wouldn't it trigger a fatal SMMU fault and crash the remote processor? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
