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.
>> +
>> + return ret == -EINVAL ? 0 : ret;
>> +}
>> +
>> static inline int rproc_prepare_device(struct rproc *rproc)
>> {
>> if (rproc->ops->prepare)
>> --
>> 2.34.1
>>
>>
>
