[PATCH 3/4] remoteproc: add helper for optional ELF resource tables
Ben Levinsky
blevinsk at amd.com
Tue May 12 10:19:35 PDT 2026
Hi Daniel, Arnaud, Tanmay,
Please see my reply below
On 5/12/26 10:04 AM, Levinsky, Ben wrote:
> AMD General
>
>
>
>
> *From: *Shah, Tanmay <tanmays at amd.com>
> *Date: *Tuesday, May 12, 2026 at 7:53 AM
> *To: *Daniel Baluta <daniel.baluta at oss.nxp.com>; Levinsky, Ben
> <ben.levinsky at amd.com>; Bjorn Andersson <andersson at kernel.org>; Mathieu Poirier
> <mathieu.poirier at linaro.org>; linux-remoteproc at vger.kernel.org <linux-
> remoteproc at vger.kernel.org>
> *Cc: *Frank Li <Frank.Li at nxp.com>; Sascha Hauer <s.hauer at pengutronix.de>;
> Pengutronix Kernel Team <kernel at pengutronix.de>; Fabio Estevam
> <festevam at gmail.com>; Geert Uytterhoeven <geert+renesas at glider.be>; Magnus Damm
> <magnus.damm at gmail.com>; Patrice Chotard <patrice.chotard at foss.st.com>; Maxime
> Coquelin <mcoquelin.stm32 at gmail.com>; Alexandre Torgue
> <alexandre.torgue at foss.st.com>; imx at lists.linux.dev <imx at lists.linux.dev>;
> linux-arm-kernel at lists.infradead.org <linux-arm-kernel at lists.infradead.org>;
> linux-kernel at vger.kernel.org <linux-kernel at vger.kernel.org>; linux-renesas-
> soc at vger.kernel.org <linux-renesas-soc at vger.kernel.org>; linux-stm32 at st-md-
> mailman.stormreply.com <linux-stm32 at st-md-mailman.stormreply.com>; Shah, Tanmay
> <tanmay.shah at amd.com>
> *Subject: *Re: [PATCH 3/4] remoteproc: add helper for optional ELF resource tables
>
>
>
> On 5/12/2026 2:55 AM, Daniel Baluta wrote:
> > On 5/12/26 00:18, Ben Levinsky wrote:
> >> [You don't often get email from ben.levinsky at amd.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification <https://aka.ms/
> LearnAboutSenderIdentification> ]
> >>
> >> Add a small helper around rproc_elf_load_rsc_table() for remoteproc
> >> drivers that treat a missing ELF resource table as optional. The helper
> >> returns success on -EINVAL and propagates other failures unchanged.
> >>
> >> Signed-off-by: Ben Levinsky <ben.levinsky at amd.com>
> >> ---
> >> drivers/remoteproc/remoteproc_internal.h | 12 ++++++++++++
> >> 1 file changed, 12 insertions(+)
> >>
> >> diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/
> remoteproc_internal.h
> >> index 3724a47a9748..dff87e468837 100644
> >> --- a/drivers/remoteproc/remoteproc_internal.h
> >> +++ b/drivers/remoteproc/remoteproc_internal.h
> >> @@ -146,6 +146,18 @@ static inline int rproc_mem_entry_iounmap(struct rproc
> *rproc,
> >> return 0;
> >> }
> >>
> >> +static inline int rproc_elf_load_rsc_table_optional(struct rproc *rproc,
> >> + const struct firmware *fw)
> >> +{
> >> + int ret;
> >> +
> >> + ret = rproc_elf_load_rsc_table(rproc, fw);
> >> + if (ret == -EINVAL)
> >> + dev_dbg(&rproc->dev, "no resource table found\n");
> >
> > You are changing loglevel here. Initial drivers use dev_info or dev_warn. At
> least I'm used
> > with seeing this messages in the logs.
> >
> > So, what do you think on adding at least dev_info to this instead of dev_dbg?
> >
>
> Actually can we leave that choice to the platform driver ? There are
> many use cases where the remoteproc subsystem is used to load and start
> the remote core and the firmware doesn't have the resource table. We
> don't want to make info level log for such use cases, as the resource
> table is not expected in the first place there.
Thanks for the feedback.
I agree the helper should not impose a common log level. Some platforms intentionally run firmware without a resource table, so forcing a shared dev_info/dev_warn message from the helper would add
noise in those cases.
I'll rework this in v2 so the helper only handles the return-value behavior, while platform drivers keep control over whether the missing-table case is logged and at what level.
Thanks,
Ben
>
> >> +
> >> + return ret == -EINVAL ? 0 : ret;
> >> +}
> >> +
> >> static inline int rproc_prepare_device(struct rproc *rproc)
> >> {
> >> if (rproc->ops->prepare)
> >> --
> >> 2.34.1
> >>
> >>
> >
>
More information about the linux-arm-kernel
mailing list