From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Cc: Bjorn Andersson <andersson@kernel.org>,
linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [PATCH v5 4/7] remoteproc: core introduce rproc_set_rsc_table_on_start function
Date: Tue, 28 May 2024 15:03:55 -0600 [thread overview]
Message-ID: <ZlZGu16h1xsM3es5@p14s> (raw)
In-Reply-To: <20240521081001.2989417-5-arnaud.pouliquen@foss.st.com>
On Tue, May 21, 2024 at 10:09:58AM +0200, Arnaud Pouliquen wrote:
> Split rproc_start()to prepare the update of the management of
I don't see any "splitting" for rproc_start() in this patch. Please consider
rewording or removing.
> the cache table on start, for the support of the firmware loading
> by the TEE interface.
> - create rproc_set_rsc_table_on_start() to address the management of
> the cache table in a specific function, as done in
> rproc_reset_rsc_table_on_stop().
> - rename rproc_set_rsc_table in rproc_set_rsc_table_on_attach()
> - move rproc_reset_rsc_table_on_stop() to be close to the
> rproc_set_rsc_table_on_start() function
This patch is really hard to read due to all 3 operations happening at the same
time. Please split in 3 smaller patches.
>
> Suggested-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> ---
> drivers/remoteproc/remoteproc_core.c | 116 ++++++++++++++-------------
> 1 file changed, 62 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index f276956f2c5c..42bca01f3bde 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1264,18 +1264,9 @@ void rproc_resource_cleanup(struct rproc *rproc)
> }
> EXPORT_SYMBOL(rproc_resource_cleanup);
>
> -static int rproc_start(struct rproc *rproc, const struct firmware *fw)
> +static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct firmware *fw)
> {
> struct resource_table *loaded_table;
> - struct device *dev = &rproc->dev;
> - int ret;
> -
> - /* load the ELF segments to memory */
> - ret = rproc_load_segments(rproc, fw);
> - if (ret) {
> - dev_err(dev, "Failed to load program segments: %d\n", ret);
> - return ret;
> - }
>
> /*
> * The starting device has been given the rproc->cached_table as the
> @@ -1291,6 +1282,64 @@ static int rproc_start(struct rproc *rproc, const struct firmware *fw)
> rproc->table_ptr = loaded_table;
> }
>
> + return 0;
> +}
> +
> +static int rproc_reset_rsc_table_on_stop(struct rproc *rproc)
> +{
> + /* A resource table was never retrieved, nothing to do here */
> + if (!rproc->table_ptr)
> + return 0;
> +
> + /*
> + * If a cache table exists the remote processor was started by
> + * the remoteproc core. That cache table should be used for
> + * the rest of the shutdown process.
> + */
> + if (rproc->cached_table)
> + goto out;
> +
> + /*
> + * If we made it here the remote processor was started by another
> + * entity and a cache table doesn't exist. As such make a copy of
> + * the resource table currently used by the remote processor and
> + * use that for the rest of the shutdown process. The memory
> + * allocated here is free'd in rproc_shutdown().
> + */
> + rproc->cached_table = kmemdup(rproc->table_ptr,
> + rproc->table_sz, GFP_KERNEL);
> + if (!rproc->cached_table)
> + return -ENOMEM;
> +
> + /*
> + * Since the remote processor is being switched off the clean table
> + * won't be needed. Allocated in rproc_set_rsc_table_on_start().
> + */
> + kfree(rproc->clean_table);
> +
> +out:
> + /*
> + * Use a copy of the resource table for the remainder of the
> + * shutdown process.
> + */
> + rproc->table_ptr = rproc->cached_table;
> + return 0;
> +}
> +
> +static int rproc_start(struct rproc *rproc, const struct firmware *fw)
> +{
> + struct device *dev = &rproc->dev;
> + int ret;
> +
> + /* load the ELF segments to memory */
> + ret = rproc_load_segments(rproc, fw);
> + if (ret) {
> + dev_err(dev, "Failed to load program segments: %d\n", ret);
> + return ret;
> + }
> +
> + rproc_set_rsc_table_on_start(rproc, fw);
> +
> ret = rproc_prepare_subdevices(rproc);
> if (ret) {
> dev_err(dev, "failed to prepare subdevices for %s: %d\n",
> @@ -1450,7 +1499,7 @@ static int rproc_fw_boot(struct rproc *rproc, const struct firmware *fw)
> return ret;
> }
>
> -static int rproc_set_rsc_table(struct rproc *rproc)
> +static int rproc_set_rsc_table_on_attach(struct rproc *rproc)
> {
> struct resource_table *table_ptr;
> struct device *dev = &rproc->dev;
> @@ -1540,54 +1589,13 @@ static int rproc_reset_rsc_table_on_detach(struct rproc *rproc)
>
> /*
> * The clean resource table is no longer needed. Allocated in
> - * rproc_set_rsc_table().
> + * rproc_set_rsc_table_on_attach().
> */
> kfree(rproc->clean_table);
>
> return 0;
> }
>
> -static int rproc_reset_rsc_table_on_stop(struct rproc *rproc)
> -{
> - /* A resource table was never retrieved, nothing to do here */
> - if (!rproc->table_ptr)
> - return 0;
> -
> - /*
> - * If a cache table exists the remote processor was started by
> - * the remoteproc core. That cache table should be used for
> - * the rest of the shutdown process.
> - */
> - if (rproc->cached_table)
> - goto out;
> -
> - /*
> - * If we made it here the remote processor was started by another
> - * entity and a cache table doesn't exist. As such make a copy of
> - * the resource table currently used by the remote processor and
> - * use that for the rest of the shutdown process. The memory
> - * allocated here is free'd in rproc_shutdown().
> - */
> - rproc->cached_table = kmemdup(rproc->table_ptr,
> - rproc->table_sz, GFP_KERNEL);
> - if (!rproc->cached_table)
> - return -ENOMEM;
> -
> - /*
> - * Since the remote processor is being switched off the clean table
> - * won't be needed. Allocated in rproc_set_rsc_table().
> - */
> - kfree(rproc->clean_table);
> -
> -out:
> - /*
> - * Use a copy of the resource table for the remainder of the
> - * shutdown process.
> - */
> - rproc->table_ptr = rproc->cached_table;
> - return 0;
> -}
> -
> /*
> * Attach to remote processor - similar to rproc_fw_boot() but without
> * the steps that deal with the firmware image.
> @@ -1614,7 +1622,7 @@ static int rproc_attach(struct rproc *rproc)
> goto disable_iommu;
> }
>
> - ret = rproc_set_rsc_table(rproc);
> + ret = rproc_set_rsc_table_on_attach(rproc);
> if (ret) {
> dev_err(dev, "can't load resource table: %d\n", ret);
> goto unprepare_device;
> --
> 2.25.1
>
next prev parent reply other threads:[~2024-05-28 21:03 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-21 8:09 [PATCH v5 0/7] Introduction of a remoteproc tee to load signed firmware Arnaud Pouliquen
2024-05-21 8:09 ` [PATCH v5 1/7] remoteproc: Add TEE support Arnaud Pouliquen
2024-05-21 8:09 ` [PATCH v5 2/7] dt-bindings: remoteproc: Add compatibility for " Arnaud Pouliquen
2024-05-21 9:24 ` Krzysztof Kozlowski
2024-05-21 12:16 ` Arnaud POULIQUEN
2024-05-28 20:08 ` Mathieu Poirier
2024-05-21 8:09 ` [PATCH v5 3/7] dt-bindings: remoteproc: Add processor identifier property Arnaud Pouliquen
2024-05-21 8:09 ` [PATCH v5 4/7] remoteproc: core introduce rproc_set_rsc_table_on_start function Arnaud Pouliquen
2024-05-28 21:03 ` Mathieu Poirier [this message]
2024-05-21 8:09 ` [PATCH v5 5/7] remoteproc: core: support of the tee interface Arnaud Pouliquen
2024-05-28 21:30 ` Mathieu Poirier
2024-05-29 7:13 ` Arnaud POULIQUEN
2024-05-29 20:35 ` Mathieu Poirier
2024-05-30 7:42 ` Arnaud POULIQUEN
2024-05-30 16:14 ` Mathieu Poirier
2024-05-31 17:28 ` Mathieu Poirier
2024-06-03 8:21 ` Arnaud POULIQUEN
2024-06-03 14:24 ` Mathieu Poirier
2024-05-21 8:10 ` [PATCH v5 6/7] remoteproc: stm32: Create sub-functions to request shutdown and release Arnaud Pouliquen
2024-05-21 8:10 ` [PATCH v5 7/7] remoteproc: stm32: Add support of an OP-TEE TA to load the firmware 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=ZlZGu16h1xsM3es5@p14s \
--to=mathieu.poirier@linaro.org \
--cc=andersson@kernel.org \
--cc=arnaud.pouliquen@foss.st.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.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