Hello,
k3_dsp_rproc_remove() in drivers/remoteproc/ti_k3_dsp_remoteproc.c looks
as follows:
static int k3_dsp_rproc_remove(struct platform_device *pdev)
{
struct k3_dsp_rproc *kproc = platform_get_drvdata(pdev);
struct rproc *rproc = kproc->rproc;
struct device *dev = &pdev->dev;
int ret;
if (rproc->state == RPROC_ATTACHED) {
ret = rproc_detach(rproc);
if (ret) {
dev_err(dev, "failed to detach proc, ret = %d\n", ret);
return ret;
}
}
rproc_del(kproc->rproc);
ret = ti_sci_proc_release(kproc->tsp);
if (ret)
dev_err(dev, "failed to release proc, ret = %d\n", ret);
kfree(kproc->tsp);
ret = ti_sci_put_handle(kproc->ti_sci);
if (ret)
dev_err(dev, "failed to put ti_sci handle, ret = %d\n", ret);
k3_dsp_reserved_mem_exit(kproc);
rproc_free(kproc->rproc);
return 0;
}
The error return in the first if block is dangerous: If rproc_detach()
fails, rproc_del() is skipped and so the rproc structure is kept in
rproc_list, with the pointers in rproc->ops leading into nirvana if the
ti_k3_dsp_remoteproc module is unloaded.
I don't know enough about rproc to directly see the right fix for that
issue. Maybe it's just to drop "return ret;", but I guess that's not
safe either?! As I don't have a suggestion to fix this, there is no
patch included here in this bug report :-\
Another minor issue here is: return 0 instead of return ret in the error
path would be an improvement. Returning a non-zero value in a remove
callback is useless. The only effect is that the core will emit
dev_warn(_dev, "remove callback returned a non-zero value. This will be ignored.\n");
(see platform_remove()) and then it will continue to remove the device.
I want to change the prototype of remove callbacks to
void (*)(struct platform_device *)
to prevent this type of bug. To progress here I'd like to propose:
--->8---
Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
The non-zero return value of the first exit point of
k3_dsp_rproc_remove() is ignored by the core, so the only semantical
change here is that an additional warning by the core is suppressed if
rproc_detach() fails. This is even an improvement because
k3_dsp_rproc_remove() already emitted a more useful message.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>
diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
index ef8415a7cd54..8207439e4927 100644
--- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
@@ -825,7 +825,7 @@ static int k3_dsp_rproc_probe(struct platform_device *pdev)
return ret;
}
-static int k3_dsp_rproc_remove(struct platform_device *pdev)
+static void k3_dsp_rproc_remove(struct platform_device *pdev)
{
struct k3_dsp_rproc *kproc = platform_get_drvdata(pdev);
struct rproc *rproc = kproc->rproc;
@@ -836,7 +836,7 @@ static int k3_dsp_rproc_remove(struct platform_device *pdev)
ret = rproc_detach(rproc);
if (ret) {
dev_err(dev, "failed to detach proc, ret = %d\n", ret);
- return ret;
+ return;
}
}
@@ -854,8 +854,6 @@ static int k3_dsp_rproc_remove(struct platform_device *pdev)
k3_dsp_reserved_mem_exit(kproc);
rproc_free(kproc->rproc);
-
- return 0;
}
static const struct k3_dsp_mem_data c66_mems[] = {
--->8---
But if you want to address the graver bug first, I can wait to prevent
patch conflicts.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature
