From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: ohad@wizery.com, bjorn.andersson@linaro.org
Cc: arnaud.pouliquen@st.com, mcoquelin.stm32@gmail.com,
alexandre.torgue@st.com, linux-remoteproc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 01/17] remoteproc: Remove useless check in rproc_del()
Date: Wed, 10 Mar 2021 14:10:09 -0700 [thread overview]
Message-ID: <20210310211025.1084636-2-mathieu.poirier@linaro.org> (raw)
In-Reply-To: <20210310211025.1084636-1-mathieu.poirier@linaro.org>
Whether started at probe() time or thereafter from the command
line, a remote processor needs to be shut down before the final
cleanup phases can happen. Otherwise the system may be left in
an unpredictable state where the remote processor is expecting
the remoteproc core to be providing services when in fact it
no longer exist.
Invariably calling rproc_shutdown() is fine since it will return
immediately if the remote processor has already been switched
off.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
---
drivers/remoteproc/remoteproc_core.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index ab150765d124..d2704501b653 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -2347,10 +2347,8 @@ int rproc_del(struct rproc *rproc)
if (!rproc)
return -EINVAL;
- /* if rproc is marked always-on, rproc_add() booted it */
/* TODO: make sure this works with rproc->power > 1 */
- if (rproc->auto_boot)
- rproc_shutdown(rproc);
+ rproc_shutdown(rproc);
mutex_lock(&rproc->lock);
rproc->state = RPROC_DELETED;
--
2.25.1
next prev parent reply other threads:[~2021-03-10 21:11 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-10 21:10 [PATCH v7 00/17] remoteproc: Add support for detaching a remote processor Mathieu Poirier
2021-03-10 21:10 ` Mathieu Poirier [this message]
2021-03-10 21:10 ` [PATCH v7 02/17] remoteproc: Rename function rproc_actuate() Mathieu Poirier
2021-03-10 21:10 ` [PATCH v7 03/17] remoteproc: Add new RPROC_ATTACHED state Mathieu Poirier
2021-03-10 21:10 ` [PATCH v7 04/17] remoteproc: Properly represent the attached state Mathieu Poirier
2021-03-10 21:10 ` [PATCH v7 05/17] remoteproc: Add new get_loaded_rsc_table() to rproc_ops Mathieu Poirier
2021-03-10 21:10 ` [PATCH v7 06/17] remoteproc: stm32: Move resource table setup " Mathieu Poirier
2021-03-10 21:10 ` [PATCH v7 07/17] remoteproc: stm32: Move memory parsing " Mathieu Poirier
2021-03-10 21:10 ` [PATCH v7 08/17] remoteproc: Add new detach() remoteproc operation Mathieu Poirier
2021-03-10 21:10 ` [PATCH v7 09/17] remoteproc: Introduce function __rproc_detach() Mathieu Poirier
2021-03-10 21:10 ` [PATCH v7 10/17] remoteproc: Introduce function rproc_detach() Mathieu Poirier
2021-03-10 21:10 ` [PATCH v7 11/17] remoteproc: Properly deal with the resource table when detaching Mathieu Poirier
2021-03-11 9:09 ` Arnaud POULIQUEN
2021-03-10 21:10 ` [PATCH v7 12/17] remoteproc: Properly deal with the resource table when stopping Mathieu Poirier
2021-03-10 23:00 ` kernel test robot
2021-03-10 23:53 ` Bjorn Andersson
2021-03-11 9:14 ` Arnaud POULIQUEN
2021-03-11 17:13 ` Mathieu Poirier
2021-03-10 21:10 ` [PATCH v7 13/17] remoteproc: Properly deal with a kernel panic when attached Mathieu Poirier
2021-03-10 21:10 ` [PATCH v7 14/17] remoteproc: Properly deal with a start request " Mathieu Poirier
2021-03-10 21:10 ` [PATCH v7 15/17] remoteproc: Properly deal with a stop " Mathieu Poirier
2021-03-10 21:10 ` [PATCH v7 16/17] remoteproc: Properly deal with a detach " Mathieu Poirier
2021-03-10 21:10 ` [PATCH v7 17/17] remoteproc: Refactor function rproc_cdev_release() 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=20210310211025.1084636-2-mathieu.poirier@linaro.org \
--to=mathieu.poirier@linaro.org \
--cc=alexandre.torgue@st.com \
--cc=arnaud.pouliquen@st.com \
--cc=bjorn.andersson@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mcoquelin.stm32@gmail.com \
--cc=ohad@wizery.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).