Re: [PATCH 3/4] remoteproc: add helper for optional ELF resource tables

[Ben Levinsky]

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@xxxxxxx>
> *Date: *Tuesday, May 12, 2026 at 7:53 AM
> *To: *Daniel Baluta <daniel.baluta@xxxxxxxxxxx>; Levinsky, Ben 
> <ben.levinsky@xxxxxxx>; Bjorn Andersson <andersson@xxxxxxxxxx>; Mathieu Poirier 
> <mathieu.poirier@xxxxxxxxxx>; linux-remoteproc@xxxxxxxxxxxxxxx <linux- 
> remoteproc@xxxxxxxxxxxxxxx>
> *Cc: *Frank Li <Frank.Li@xxxxxxx>; Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>; 
> Pengutronix Kernel Team <kernel@xxxxxxxxxxxxxx>; Fabio Estevam 
> <festevam@xxxxxxxxx>; Geert Uytterhoeven <geert+renesas@xxxxxxxxx>; Magnus Damm 
> <magnus.damm@xxxxxxxxx>; Patrice Chotard <patrice.chotard@xxxxxxxxxxx>; Maxime 
> Coquelin <mcoquelin.stm32@xxxxxxxxx>; Alexandre Torgue 
> <alexandre.torgue@xxxxxxxxxxx>; imx@xxxxxxxxxxxxxxx <imx@xxxxxxxxxxxxxxx>; 
> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>; 
> linux-kernel@xxxxxxxxxxxxxxx <linux-kernel@xxxxxxxxxxxxxxx>; linux-renesas- 
> soc@xxxxxxxxxxxxxxx <linux-renesas-soc@xxxxxxxxxxxxxxx>; linux-stm32@st-md- 
> mailman.stormreply.com <linux-stm32@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>; Shah, Tanmay 
> <tanmay.shah@xxxxxxx>
> *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@xxxxxxx. 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@xxxxxxx>
>  >> ---
>  >>  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
>  >>
>  >>
>  >
>