From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: loic pallardy <loic.pallardy@st.com>
Cc: linux-remoteproc@vger.kernel.org,
Ohad Ben-Cohen <ohad@wizery.com>,
linux-kernel@vger.kernel.org, Lee Jones <lee.jones@linaro.org>
Subject: Re: [PATCH 3/4] remoteproc: Move vdev handling to boot/shutdown
Date: Wed, 3 Aug 2016 11:17:12 -0700 [thread overview]
Message-ID: <20160803181712.GE13516@tuxbot> (raw)
In-Reply-To: <57A0B988.50803@st.com>
On Tue 02 Aug 08:17 PDT 2016, loic pallardy wrote:
> Hi Bjorn,
>
Hi Loic,
Thanks for looking at the patches!
[..]
> >diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
[..]
> >@@ -984,23 +990,11 @@ int rproc_trigger_recovery(struct rproc *rproc)
> > /* TODO: make sure this works with rproc->power > 1 */
> > rproc_shutdown(rproc);
> >
> >- /* clean up remote vdev entries */
> >- list_for_each_entry_safe(rvdev, rvtmp, &rproc->rvdevs, node)
> >- rproc_remove_virtio_dev(rvdev);
> >-
> > /* wait until there is no more rproc users */
> > wait_for_completion(&rproc->crash_comp);
> >
> >- /* Free the copy of the resource table */
> >- kfree(rproc->cached_table);
> I think this line should be part of patch 4 "Move handling of cached table
> to boot/shutdown"
>
> Regards,
> Loic
> >-
> >- ret = rproc_add_virtio_devices(rproc);
> >- if (ret)
> >- return ret;
Before this patch this operation will trigger an async firmware load
that will reallocate (kmemdup) cached_table. The rproc_boot() below
would wait for this to finish and there would be a cached_table in
place.
> >-
> > /*
> >- * boot the remote processor up again, waiting for the async fw load to
> >- * finish
> >+ * boot the remote processor up again
> > */
> > rproc_boot(rproc);
> >
Now that we instead directly handle the vdev resources in rproc_boot()
the cached_table is not reallocated in this code path and as such has
the life span of rproc_add() (or rather, the async fw callback) to
rproc_del(). Therefor it should not be freed here anymore.
Please do let me know if you see any concerns based on this life cycle
change.
Regards,
Bjorn
next prev parent reply other threads:[~2016-08-03 18:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-01 18:58 [PATCH 1/4] remoteproc: Introduce always-on flag Bjorn Andersson
2016-08-01 18:58 ` [PATCH 2/4] remoteproc: Calculate max_notifyid during load Bjorn Andersson
2016-08-01 18:58 ` [PATCH 3/4] remoteproc: Move vdev handling to boot/shutdown Bjorn Andersson
2016-08-02 15:17 ` loic pallardy
2016-08-03 18:17 ` Bjorn Andersson [this message]
2016-08-01 18:58 ` [PATCH 4/4] remoteproc: Move handling of cached table " Bjorn Andersson
2016-08-02 15:17 ` [PATCH 1/4] remoteproc: Introduce always-on flag loic pallardy
2016-08-03 22:02 ` Bjorn Andersson
2016-08-04 9:44 ` loic pallardy
2016-08-04 17:23 ` Bjorn Andersson
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=20160803181712.GE13516@tuxbot \
--to=bjorn.andersson@linaro.org \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=loic.pallardy@st.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