From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Tanmay Shah <tanmay.shah@amd.com>
Cc: andersson@kernel.org, linux-remoteproc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] remoteproc: core: full attach detach during recovery
Date: Thu, 16 Oct 2025 09:12:21 -0600 [thread overview]
Message-ID: <aPELVfhkk0qDXqa9@p14s> (raw)
In-Reply-To: <20251002153343.766352-1-tanmay.shah@amd.com>
Good morning,
On Thu, Oct 02, 2025 at 08:33:46AM -0700, Tanmay Shah wrote:
> Current recovery operation does only virtio device reset, but do not
> free and re-allocate all the resources. As third-party is booting the
> remote processor during attach-detach, it is better to free and
> re-allocate resoruces as resource table state might be unknown to linux
> when remote processor boots and reports crash.
1) When referring to "third-party", should I assume boot loader?
2) Function rproc_attach_recovery() calls __rproc_detach(), which in turn calls
rproc_reset_rsc_table_on_detach(). That function deals explicitly with the
resource table.
3) The code in this patch mixes __rproc_detach() with rproc_attach(), something
that is likely not a good idea. We either do __rproc_detach/__rproc_attach or
rproc_detach/rproc_attach but I'd like to avoid the mix-and-match to keep the
amount of possible states to a minimum.
If I understand correctly, the main motivation for this patch is the management
of the resource table. But as noted in (2), this should be taken care of. Am I
missing some information?
Thanks,
Mathieu
>
> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> ---
>
> Note: RFC patch for design discussion. Please do not merge.
>
> drivers/remoteproc/remoteproc_core.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 825672100528..4971508bc5b2 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1786,7 +1786,20 @@ static int rproc_attach_recovery(struct rproc *rproc)
> if (ret)
> return ret;
>
> - return __rproc_attach(rproc);
> + /* clean up all acquired resources */
> + rproc_resource_cleanup(rproc);
> +
> + /* release HW resources if needed */
> + rproc_unprepare_device(rproc);
> +
> + rproc_disable_iommu(rproc);
> +
> + /* Free the copy of the resource table */
> + kfree(rproc->cached_table);
> + rproc->cached_table = NULL;
> + rproc->table_ptr = NULL;
> +
> + return rproc_attach(rproc);
> }
>
> static int rproc_boot_recovery(struct rproc *rproc)
>
> base-commit: 56d030ea3330ab737fe6c05f89d52f56208b07ac
> --
> 2.34.1
>
next prev parent reply other threads:[~2025-10-16 15:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-02 15:33 [RFC PATCH] remoteproc: core: full attach detach during recovery Tanmay Shah
2025-10-16 15:12 ` Mathieu Poirier [this message]
2025-10-16 16:12 ` Tanmay Shah
2025-10-17 15:35 ` Mathieu Poirier
2025-10-17 16:22 ` Tanmay Shah
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=aPELVfhkk0qDXqa9@p14s \
--to=mathieu.poirier@linaro.org \
--cc=andersson@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=tanmay.shah@amd.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 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.