Hi Jorge,
On 06-10-2026 02:31 am, Jorge Ramirez wrote:
> On 05/10/26 21:42:24, Mukesh Ojha wrote:
>> On Mon, Oct 05, 2026 at 02:54:00PM +0200, Jorge Ramirez-Ortiz wrote:
>>> The firmware resource table is passed to the PAS backend even when the
>>> firmware carries none. This only works on the first boot, while the
>>> cached pointer and its size are both zero.
>>>
>>> Stopping the remote processor, or failing to start it, frees the cached
>>> table and clears the pointer but leaves the size set. The next start
>>> then pairs a NULL table with a non-zero size.
>>>
>>> The SCM backend substitutes an empty table and hides the problem. The
>>> TEE backend copies from the NULL pointer:
>>>
>>> remoteproc remoteproc2: powering up cdsp
>>> pc : __pi_memcpy_generic+0x110/0x22c
>>> lr : qcom_pas_tee_get_rsc_table+0xf4/0x25c
>>> Call trace:
>>> __pi_memcpy_generic+0x110/0x22c (P)
>>> qcom_pas_get_rsc_table+0x38/0x60
>>> qcom_pas_parse_firmware+0xa0/0x100
>>> rproc_boot+0x2d4/0x380
>>> state_store+0x40/0x100
>>>
>>> Fixes: a4584bff63c8 ("remoteproc: pas: Extend parse_fw callback to fetch
>>> resources via SMC call")
>>> Signed-off-by: Jorge Ramirez-Ortiz <[email protected]>
Thanks for this patch, I was about to send one myself since I observed
this on IQ10 as well.
>>> ---
>>> drivers/remoteproc/qcom_q6v5_pas.c | 11 ++++++-----
>>> 1 file changed, 6 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c
>>> b/drivers/remoteproc/qcom_q6v5_pas.c
>>> index a005546c265d..e871e03ba794 100644
>>> --- a/drivers/remoteproc/qcom_q6v5_pas.c
>>> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
>>> @@ -463,7 +463,7 @@ static int qcom_pas_parse_firmware(struct rproc *rproc,
>>> const struct firmware *f
>>> struct resource_table *table = NULL;
>>> size_t output_rt_size;
>>> void *output_rt;
>>> - size_t table_sz;
>>> + size_t table_sz = 0;
>>> int ret;
>>>
>>> ret = qcom_register_dump_segments(rproc, fw);
>>> @@ -476,11 +476,12 @@ static int qcom_pas_parse_firmware(struct rproc
>>> *rproc, const struct firmware *f
>>> return 0;
>>>
>>> ret = rproc_elf_load_rsc_table(rproc, fw);
>>> - if (ret)
>>> + if (ret) {
>>> dev_dbg(&rproc->dev, "Failed to load resource table from
>>> firmware\n");
>>> -
>>> - table = rproc->table_ptr;
>>> - table_sz = rproc->table_sz;
>>> + } else {
>>> + table = rproc->table_ptr;
>>> + table_sz = rproc->table_sz;
>>> + }
>>
>>
>> Earlier code was intentional please read the comment below.. /**...*/
>>
>
> AFAICS the comments say that the call might pass NULL and zero as input
> resources. And this patch does exactly that - it doesnt allow NULL and
> non-zero.
>
I agree with this fix, it was strange to see a NULL pointer paired with
non-zero table size.
As the comment itself says, a NULL pointer + 0 size should be passed when the
firmware binary
does not have a resource table. This is also documented here in a separate
comment:
https://elixir.bootlin.com/linux/v7.3-rc5/source/drivers/firmware/qcom/qcom_pas.c#L131
I am validating this fix for Nord, expect a Tested-by tag from me today.
Regards,
Harshal
> did I miss something?
