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

[sashiko-bot@kernel.org]

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 <david@ixit.cz>

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/20260923-fastrpc-fail-slow-v1-1-f3f6fabba6e3@ixit.cz?part=1