On 5/12/26 17:53, Shah, Tanmay wrote: > > > 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 [email protected]. Learn why this is >>> important at 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 <[email protected]> >>> --- >>> 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.
Agree, this is the best way to go.
