From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Daniel Baluta <daniel.baluta@gmail.com>
Cc: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
Bjorn Andersson <andersson@kernel.org>,
Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
Iuliana Prodan <iuliana.prodan@nxp.com>,
Daniel Baluta <daniel.baluta@nxp.com>,
Frank Li <frank.li@nxp.com>,
linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Peng Fan <peng.fan@nxp.com>,
stable@vger.kernel.org
Subject: Re: [PATCH v3] remoteproc: imx: Fix invalid loaded resource table detection
Date: Mon, 2 Feb 2026 09:16:41 -0700 [thread overview]
Message-ID: <aYDN6X0WVT9nV8fg@p14s> (raw)
In-Reply-To: <CAEnQRZA-nMai9-CEdMqnr2drqBRXXPOKE3a+_3j4S_=x-bM0pQ@mail.gmail.com>
On Thu, Jan 29, 2026 at 06:02:21PM +0200, Daniel Baluta wrote:
> On Thu, Jan 29, 2026 at 3:45 AM Peng Fan (OSS) <peng.fan@oss.nxp.com> wrote:
> >
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > imx_rproc_elf_find_loaded_rsc_table() may incorrectly report a loaded
> > resource table even when the current firmware does not provide one.
> >
> > When the device tree contains a "rsc-table" entry, priv->rsc_table is
> > non-NULL and denotes where a resource table would be located if one is
> > present in memory. However, when the current firmware has no resource
> > table, rproc->table_ptr is NULL. The function still returns
> > priv->rsc_table, and the remoteproc core interprets this as a valid loaded
> > resource table.
> >
> > Fix this by returning NULL from imx_rproc_elf_find_loaded_rsc_table() when
> > there is no resource table for the current firmware (i.e. when
> > rproc->table_ptr is NULL). This aligns the function's semantics with the
> > remoteproc core: a loaded resource table is only reported when a valid
> > table_ptr exists.
> >
> > With this change, starting firmware without a resource table no longer
> > triggers a crash.
> >
> > Fixes: e954a1bd1610 ("remoteproc: imx_rproc: Use imx specific hook for find_loaded_rsc_table")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
>
> Changes looks good to me >
>
> > --- a/drivers/remoteproc/imx_rproc.c
> > +++ b/drivers/remoteproc/imx_rproc.c
> > @@ -729,6 +729,10 @@ imx_rproc_elf_find_loaded_rsc_table(struct rproc *rproc, const struct firmware *
> > {
> > struct imx_rproc *priv = rproc->priv;
> >
> > + /* No resource table in the firmware */
> > + if (!rproc->table_ptr)
> > + return NULL;
>
> I wonder if we can make this change generic because it should happen
> on other platforms also.
>
> Maybe something like this:
>
> remoteproc: core: Only copy loaded table when valid
>
> Copy resource table in memory only when:
> * the current loaded firmware provides one
> AND
> * there is an explicit request to have the rsc table copied in memory
> via rsc-table
>
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1281,7 +1281,7 @@ static int rproc_start(struct rproc *rproc,
> const struct firmware *fw)
> * that any subsequent changes will be applied to the loaded version.
> */
> loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
> - if (loaded_table) {
> + if (rproc->cached_table && loaded_table) {
But we would be doing the check for rproc->table_ptr twice (->table_ptr and
->cached_table should be the same). The way it is currently writting forces
vendor specific implementation of rproc_elf_find_loaded_rsc_table() to do the
right thing.
The merge window has been pushed by a week, giving me an opportunity to merge
this patch. Should I do that or should we continue discussing the best
approach?
> memcpy(loaded_table, rproc->cached_table, rproc->table_sz);
> rproc->table_ptr = loaded_table;
> }
next prev parent reply other threads:[~2026-02-02 16:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-29 1:44 [PATCH v3] remoteproc: imx: Fix invalid loaded resource table detection Peng Fan (OSS)
2026-01-29 16:02 ` Daniel Baluta
2026-01-30 3:27 ` Peng Fan
2026-02-02 16:16 ` Mathieu Poirier [this message]
2026-02-03 7:53 ` Daniel Baluta
2026-02-03 16:28 ` Mathieu Poirier
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=aYDN6X0WVT9nV8fg@p14s \
--to=mathieu.poirier@linaro.org \
--cc=andersson@kernel.org \
--cc=daniel.baluta@gmail.com \
--cc=daniel.baluta@nxp.com \
--cc=festevam@gmail.com \
--cc=frank.li@nxp.com \
--cc=imx@lists.linux.dev \
--cc=iuliana.prodan@nxp.com \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=peng.fan@nxp.com \
--cc=peng.fan@oss.nxp.com \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=stable@vger.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.