On Wed 11 Mar 03:54 PDT 2020, Loic Pallardy wrote: > When an error occurs during recovery procedure, internal rproc > variables may be unaligned: > - state is set to RPROC_OFFLINE > - power atomic not equal to 0 > which is normal as only rproc_stop() has been executed and not > rproc_shutdown() > > In such case, rproc_boot() can be re-executed by client to > reboot co-processor. > > This patch proposes to keep rproc in RPROC_CRASHED state in case > of recovery failure to be coherent with recovery disabled mode. > > Signed-off-by: Loic Pallardy <loic.pallardy@xxxxxx> > --- > drivers/remoteproc/remoteproc_core.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c > index 7ac87a75cd1b..def4f9fc881d 100644 > --- a/drivers/remoteproc/remoteproc_core.c > +++ b/drivers/remoteproc/remoteproc_core.c > @@ -1679,6 +1679,12 @@ int rproc_trigger_recovery(struct rproc *rproc) > release_firmware(firmware_p); > > unlock_mutex: > + /* > + * In case of error during recovery sequence restore rproc > + * state in CRASHED > + */ > + if (ret) > + rproc->state = RPROC_CRASHED; Got back to this after looking at Mathieu's synchronization series, I think it would be cleaner if we move the rproc->state update out of rproc_start() and rproc_stop(). That way we would leave the state in CRASHED state throughout the recovery process, which I think makes it easier to reason about the various states and their transitions. Regards, Bjorn > mutex_unlock(&rproc->lock); > return ret; > } > -- > 2.7.4 >
