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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox