On Sat, Oct 10, 2026 at 04:55:28PM +0530, Sumit Garg wrote:
> 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 <[email protected]>
> > > > > ---
> > > > > 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.
As per my understanding, you will only see this issue when you do a start,
shutdown, and then a fresh start again. Normal remoteproc recovery is not
broken?
If it is indeed an issue during rproc_shutdown() where table_ptr is NULLed
while table_sz is not NULLed, should that not be fixed in
rproc_shutdown itself ?
--
-Mukesh Ojha
