On 06/10/26 10:53:31, Harshal Dev wrote:
> 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.
hi Harshal,
I have just sent a different fix that handles this case on the tee
backend instead (so that SCM backend is unaffected and can continue
implementing its underlying "null input pointer with a non-zero input
size 'protocol'"...the fact that a comment is needed should have meant
that a better more explicit abstraction should have been put in place
IMO ).
In any case, I have validated both patches on hardware with the TEE
backend. Probably safer to drop this one in favour of the other one.
Jorge
