From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
Cc: Bjorn Andersson <andersson@kernel.org>,
Jens Wiklander <jens.wiklander@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
op-tee@lists.trustedfirmware.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v9 4/7] remoteproc: core: Add TEE interface support for firmware release
Date: Mon, 23 Sep 2024 08:53:43 -0600 [thread overview]
Message-ID: <ZvGA9741OV3aexzs@p14s> (raw)
In-Reply-To: <fce2374e-384f-4005-b882-3e0d26897fb7@foss.st.com>
On Tue, Sep 17, 2024 at 06:56:58PM +0200, Arnaud POULIQUEN wrote:
> Hello Mathieu,
>
> On 9/12/24 17:26, Mathieu Poirier wrote:
> > On Fri, Aug 30, 2024 at 11:51:44AM +0200, Arnaud Pouliquen wrote:
> >> Add support for releasing remote processor firmware through
> >> the Trusted Execution Environment (TEE) interface.
> >>
> >> The tee_rproc_release_fw() function is called in the following cases:
> >>
> >> - An error occurs in rproc_start() between the loading of the segments and
> >> the start of the remote processor.
> >> - When rproc_release_fw is called on error or after stopping the remote
> >> processor.
> >>
> >> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> >> ---
> >> drivers/remoteproc/remoteproc_core.c | 10 ++++++++--
> >> 1 file changed, 8 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> >> index 7694817f25d4..32052dedc149 100644
> >> --- a/drivers/remoteproc/remoteproc_core.c
> >> +++ b/drivers/remoteproc/remoteproc_core.c
> >> @@ -29,6 +29,7 @@
> >> #include <linux/debugfs.h>
> >> #include <linux/rculist.h>
> >> #include <linux/remoteproc.h>
> >> +#include <linux/remoteproc_tee.h>
> >> #include <linux/iommu.h>
> >> #include <linux/idr.h>
> >> #include <linux/elf.h>
> >> @@ -1258,6 +1259,9 @@ static int rproc_alloc_registered_carveouts(struct rproc *rproc)
> >>
> >> static void rproc_release_fw(struct rproc *rproc)
> >> {
> >> + if (rproc->state == RPROC_OFFLINE && rproc->tee_interface)
> >> + tee_rproc_release_fw(rproc);
> >
> > Function tee_rproc_release_fw() returns a value that is ignored. I don't know
> > how it passes the Sparse checker but I already see patches coming in my Inbox to
> > deal with that. In this case there is nothing else to do if there is an error
> > releasing the firware. As such I would put a (void) in front and add a comment
> > about the return value being ignore on purpose.
>
> Instead of ignoring the error, I wonder if we should panic in
> tee_rproc_release_fw(). Indeed, we would be in an unexpected state without any
> possible action to return to a normal state.
Nowadays a call to panic() is only used in very dire situations and I don't see
this meeting that requirement. I would just call a dev_err() and let it be.
>
> Regards,
> Arnaud
>
> >
> >> +
> >> /* Free the copy of the resource table */
> >> kfree(rproc->cached_table);
> >> rproc->cached_table = NULL;
> >> @@ -1348,7 +1352,7 @@ static int rproc_start(struct rproc *rproc, const struct firmware *fw)
> >> if (ret) {
> >> dev_err(dev, "failed to prepare subdevices for %s: %d\n",
> >> rproc->name, ret);
> >> - goto reset_table_ptr;
> >> + goto release_fw;
> >> }
> >>
> >> /* power up the remote processor */
> >> @@ -1376,7 +1380,9 @@ static int rproc_start(struct rproc *rproc, const struct firmware *fw)
> >> rproc->ops->stop(rproc);
> >> unprepare_subdevices:
> >> rproc_unprepare_subdevices(rproc);
> >> -reset_table_ptr:
> >> +release_fw:
> >> + if (rproc->tee_interface)
> >> + tee_rproc_release_fw(rproc);
> >
> > Same here.
> >
> >> rproc->table_ptr = rproc->cached_table;
> >>
> >> return ret;
> >> --
> >> 2.25.1
> >>
WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: op-tee@lists.trustedfirmware.org
Subject: Re: [PATCH v9 4/7] remoteproc: core: Add TEE interface support for firmware release
Date: Mon, 23 Sep 2024 08:53:43 -0600 [thread overview]
Message-ID: <ZvGA9741OV3aexzs@p14s> (raw)
In-Reply-To: <fce2374e-384f-4005-b882-3e0d26897fb7@foss.st.com>
[-- Attachment #1: Type: text/plain, Size: 3326 bytes --]
On Tue, Sep 17, 2024 at 06:56:58PM +0200, Arnaud POULIQUEN wrote:
> Hello Mathieu,
>
> On 9/12/24 17:26, Mathieu Poirier wrote:
> > On Fri, Aug 30, 2024 at 11:51:44AM +0200, Arnaud Pouliquen wrote:
> >> Add support for releasing remote processor firmware through
> >> the Trusted Execution Environment (TEE) interface.
> >>
> >> The tee_rproc_release_fw() function is called in the following cases:
> >>
> >> - An error occurs in rproc_start() between the loading of the segments and
> >> the start of the remote processor.
> >> - When rproc_release_fw is called on error or after stopping the remote
> >> processor.
> >>
> >> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> >> ---
> >> drivers/remoteproc/remoteproc_core.c | 10 ++++++++--
> >> 1 file changed, 8 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> >> index 7694817f25d4..32052dedc149 100644
> >> --- a/drivers/remoteproc/remoteproc_core.c
> >> +++ b/drivers/remoteproc/remoteproc_core.c
> >> @@ -29,6 +29,7 @@
> >> #include <linux/debugfs.h>
> >> #include <linux/rculist.h>
> >> #include <linux/remoteproc.h>
> >> +#include <linux/remoteproc_tee.h>
> >> #include <linux/iommu.h>
> >> #include <linux/idr.h>
> >> #include <linux/elf.h>
> >> @@ -1258,6 +1259,9 @@ static int rproc_alloc_registered_carveouts(struct rproc *rproc)
> >>
> >> static void rproc_release_fw(struct rproc *rproc)
> >> {
> >> + if (rproc->state == RPROC_OFFLINE && rproc->tee_interface)
> >> + tee_rproc_release_fw(rproc);
> >
> > Function tee_rproc_release_fw() returns a value that is ignored. I don't know
> > how it passes the Sparse checker but I already see patches coming in my Inbox to
> > deal with that. In this case there is nothing else to do if there is an error
> > releasing the firware. As such I would put a (void) in front and add a comment
> > about the return value being ignore on purpose.
>
> Instead of ignoring the error, I wonder if we should panic in
> tee_rproc_release_fw(). Indeed, we would be in an unexpected state without any
> possible action to return to a normal state.
Nowadays a call to panic() is only used in very dire situations and I don't see
this meeting that requirement. I would just call a dev_err() and let it be.
>
> Regards,
> Arnaud
>
> >
> >> +
> >> /* Free the copy of the resource table */
> >> kfree(rproc->cached_table);
> >> rproc->cached_table = NULL;
> >> @@ -1348,7 +1352,7 @@ static int rproc_start(struct rproc *rproc, const struct firmware *fw)
> >> if (ret) {
> >> dev_err(dev, "failed to prepare subdevices for %s: %d\n",
> >> rproc->name, ret);
> >> - goto reset_table_ptr;
> >> + goto release_fw;
> >> }
> >>
> >> /* power up the remote processor */
> >> @@ -1376,7 +1380,9 @@ static int rproc_start(struct rproc *rproc, const struct firmware *fw)
> >> rproc->ops->stop(rproc);
> >> unprepare_subdevices:
> >> rproc_unprepare_subdevices(rproc);
> >> -reset_table_ptr:
> >> +release_fw:
> >> + if (rproc->tee_interface)
> >> + tee_rproc_release_fw(rproc);
> >
> > Same here.
> >
> >> rproc->table_ptr = rproc->cached_table;
> >>
> >> return ret;
> >> --
> >> 2.25.1
> >>
next prev parent reply other threads:[~2024-09-23 14:53 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-30 9:51 [PATCH v9 0/7] Introduction of a remoteproc tee to load signed firmware Arnaud Pouliquen
2024-08-30 9:51 ` Arnaud Pouliquen
2024-08-30 9:51 ` [PATCH v9 1/7] remoteproc: core: Introduce rproc_pa_to_va helper Arnaud Pouliquen
2024-08-30 9:51 ` Arnaud Pouliquen
2024-08-30 9:51 ` [PATCH v9 2/7] remoteproc: Add TEE support Arnaud Pouliquen
2024-08-30 9:51 ` Arnaud Pouliquen
2024-09-11 15:17 ` Mathieu Poirier
2024-09-11 15:17 ` Mathieu Poirier
2024-09-11 15:25 ` Mathieu Poirier
2024-09-11 15:25 ` Mathieu Poirier
2024-09-13 16:01 ` Mathieu Poirier
2024-09-13 16:01 ` Mathieu Poirier
2024-08-30 9:51 ` [PATCH v9 3/7] remoteproc: core: Refactor resource table cleanup into rproc_release_fw Arnaud Pouliquen
2024-08-30 9:51 ` Arnaud Pouliquen
2024-09-11 15:20 ` Mathieu Poirier
2024-09-11 15:20 ` Mathieu Poirier
2024-08-30 9:51 ` [PATCH v9 4/7] remoteproc: core: Add TEE interface support for firmware release Arnaud Pouliquen
2024-08-30 9:51 ` Arnaud Pouliquen
2024-08-31 16:43 ` kernel test robot
2024-08-31 16:43 ` kernel test robot
2024-09-02 7:18 ` Arnaud POULIQUEN
2024-09-02 7:18 ` Arnaud POULIQUEN
2024-09-11 15:56 ` Mathieu Poirier
2024-09-11 15:56 ` Mathieu Poirier
2024-09-12 15:26 ` Mathieu Poirier
2024-09-12 15:26 ` Mathieu Poirier
2024-09-17 16:56 ` Arnaud POULIQUEN
2024-09-17 16:56 ` Arnaud POULIQUEN
2024-09-23 14:53 ` Mathieu Poirier [this message]
2024-09-23 14:53 ` Mathieu Poirier
2024-09-18 14:43 ` Arnaud POULIQUEN
2024-09-18 14:43 ` Arnaud POULIQUEN
2024-09-23 15:13 ` Mathieu Poirier
2024-09-23 15:13 ` Mathieu Poirier
2024-09-26 3:51 ` Bjorn Andersson
2024-09-26 3:51 ` Bjorn Andersson
2024-09-27 10:01 ` Arnaud POULIQUEN
2024-09-27 10:01 ` Arnaud POULIQUEN
2024-08-30 9:51 ` [PATCH v9 5/7] dt-bindings: remoteproc: Add compatibility for TEE support Arnaud Pouliquen
2024-08-30 9:51 ` Arnaud Pouliquen
2024-08-30 9:51 ` [PATCH v9 6/7] remoteproc: stm32: Create sub-functions to request shutdown and release Arnaud Pouliquen
2024-08-30 9:51 ` Arnaud Pouliquen
2024-09-12 15:41 ` Mathieu Poirier
2024-09-12 15:41 ` Mathieu Poirier
2024-08-30 9:51 ` [PATCH v9 7/7] remoteproc: stm32: Add support of an OP-TEE TA to load the firmware Arnaud Pouliquen
2024-08-30 9:51 ` Arnaud Pouliquen
2024-09-13 16:03 ` Mathieu Poirier
2024-09-13 16:03 ` Mathieu Poirier
2024-09-16 14:08 ` Arnaud POULIQUEN
2024-09-16 14:08 ` Arnaud POULIQUEN
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=ZvGA9741OV3aexzs@p14s \
--to=mathieu.poirier@linaro.org \
--cc=andersson@kernel.org \
--cc=arnaud.pouliquen@foss.st.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jens.wiklander@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=op-tee@lists.trustedfirmware.org \
--cc=robh+dt@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.