Re: [PATCH] remoteproc: qcom: pas: pass no resource table when the firmware has none

[Sumit Garg <sumit.garg@kernel.org>]

Hey Mukesh,

On Tue, 06 Oct 2026 at 15:33:44 +0530, Mukesh Ojha wrote:
>On Mon, Oct 05, 2026 at 11:01:24PM +0200, 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 <jorge.ramirez@oss.qualcomm.com>
>> > > ---
>> > >  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.
>>
>> did I miss something?
>
>No, you did not miss anything.. I just wanted to highlight that I
>did not keep else statement in my initial implementation
>intentionally and relied table_ptr and size will be NULL on
>failure of rproc_elf_load_rsc_table()..

Looks like you still haven't understood the problem this patch is trying
to solve. It's the PIL restart sequence where the table_ptr is NULL and
size being passed as non-zero which is incorrect from caller point of
view.

The backend will surely error out in this case. On a restart you again
have to pass the table_ptr as NULL with size as 0 to fetch the resource
table again. Surely we don't want the backend to hide errors on client
part here.

-Sumit