Stopping a remoteproc that has entered a crash loop can be problematic,
as shutdown is only allowed while the instance is in its running state.

One effect of this is that a remoteproc which has entered a crash state,
with `recovery_disabled` can not be stopped, without first attempting
the recovery.

This becomes of particular interest if the user rmmod a remoteproc
driver in such state, since the return value of rproc_shutdown() and
rproc_del() are ignored, which means that the remoteproc is left running
while the remoteproc driver will unmap memory and shut down critical
resources under its feet.

Another variant of this issue comes from the lack of synchronization
between rproc_del() and the crash handler worker, which might be
scheduled concurrently with the removal. Mutual exclusion does ensure
that concurrent progress isn't made, but nothing prevent rproc_del()
from returning to the remoteproc driver and have all the resources
freed/unmapped while the worker is still running.

Lastly, another way to trigger this faulty state is to bump the refcount
for the remoteproc, in which case rproc_shutdown() becomes a nop,
again leaving the remoteproc running while the remoteproc driver removes
critical resources.

There's certainly more work needed in these code paths, but this settles
a few obvious issues.

Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
---
Bjorn Andersson (3):
      remoteproc: Allow shutdown of crashed processors
      remoteproc: Prevent crash handling to race with rproc_del()
      remoteproc: Force shutdown during device removal

 drivers/remoteproc/remoteproc_core.c  | 104 ++++++++++++++++++++++------------
 drivers/remoteproc/remoteproc_sysfs.c |   1 -
 include/linux/remoteproc.h            |  13 +++--
 3 files changed, 76 insertions(+), 42 deletions(-)
---
base-commit: 290aaf24a551d5a0dce037e3fab30820f9113a10
change-id: 20260723-rproc-rmmod-not-crashing-d92388aa47aa

Best regards,
--  
Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>