LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Loic Pallardy <loic.pallardy@st.com>
Cc: ohad@wizery.com, mathieu.poirier@linaro.org,
	linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
	arnaud.pouliquen@st.com, benjamin.gaignard@linaro.org,
	fabien.dessenne@st.com, s-anna@ti.com
Subject: Re: [RFC 2/2] remoteproc: core: keep rproc in crash state in case of recovery failure
Date: Tue, 5 May 2020 19:05:40 -0700	[thread overview]
Message-ID: <20200506020540.GI2329931@builder.lan> (raw)
In-Reply-To: <1583924072-20648-3-git-send-email-loic.pallardy@st.com>

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@st.com>
> ---
>  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
> 

  reply	other threads:[~2020-05-06  2:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-11 10:54 [RFC 0/2] Allow client to recover crashed processor Loic Pallardy
2020-03-11 10:54 ` [RFC 1/2] remoteproc: sysfs: authorize rproc shutdown when rproc is crashed Loic Pallardy
2020-03-11 21:45   ` Mathieu Poirier
2020-03-12  8:00     ` Loic PALLARDY
2020-03-11 23:27   ` Bjorn Andersson
2020-03-12  8:12     ` Loic PALLARDY
2020-03-25 17:57   ` Mathieu Poirier
2020-03-25 18:30     ` Loic PALLARDY
2020-03-25 21:42       ` Mathieu Poirier
2020-03-11 10:54 ` [RFC 2/2] remoteproc: core: keep rproc in crash state in case of recovery failure Loic Pallardy
2020-05-06  2:05   ` Bjorn Andersson [this message]
2020-03-11 14:56 ` [RFC 0/2] Allow client to recover crashed processor Mathieu Poirier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200506020540.GI2329931@builder.lan \
    --to=bjorn.andersson@linaro.org \
    --cc=arnaud.pouliquen@st.com \
    --cc=benjamin.gaignard@linaro.org \
    --cc=fabien.dessenne@st.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=loic.pallardy@st.com \
    --cc=mathieu.poirier@linaro.org \
    --cc=ohad@wizery.com \
    --cc=s-anna@ti.com \
    --subject='Re: [RFC 2/2] remoteproc: core: keep rproc in crash state in case of recovery failure' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).