Hi Mathieu, Uwe, On 11/30/23 11:19, Mathieu Poirier wrote:
--- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c +++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c @@ -835,8 +835,9 @@ static int k3_dsp_rproc_remove(struct platform_device *pdev) if (rproc->state == RPROC_ATTACHED) { ret = rproc_detach(rproc); if (ret) { + /* Note this error path leaks resources */the dev_err(dev, "failed to detach proc, ret = %d\n", ret); - return ret; + return 0;Please have a look at this error path. As with the scenario where the remote processor is controlled by the remoteproc core, nothing can be done in .remove() to prevent the driver from going away. As such and even if rproc_detach() fails, other resources associated with this remote processor should be cleaned-up.
Since, anyway the driver goes away we probably need a force cleanup of the resources even if 'rproc_detach' fails. Looking a bit into the remote core driver, the detach can fail if it fails to get mutex lock or unable to reset resource table. It appears to me failure of reset resource table is remote IMO, we can throw an error message when 'rproc_detach' fails in 'dsp_rproc_remove' and proceed with the rest of the resource clean up,i.e call 'rproc_del()', followed by calls to ti device manager to relinquish the remote dsp processor.
Best, Hari Nagalla
