On Fri, Nov 07, 2025 at 11:47:02AM +0100, Konrad Dybcio wrote:
> On 11/4/25 8:35 AM, Mukesh Ojha wrote:
> > Qualcomm remote processor may rely on static and dynamic resources for
> > it to be functional. For most of the Qualcomm SoCs, when run with Gunyah
> > or older QHEE hypervisor, all the resources whether it is static or
> > dynamic, is managed by the hypervisor. Dynamic resources if it is
> > present for a remote processor will always be coming from secure world
> > via SMC call while static resources may be present in remote processor
> > firmware binary or it may be coming from SMC call along with dynamic
> > resources.
>
> [...]
>
> > + /*
> > + * Qualcomm remote processor may rely on static and dynamic resources
> > for
> > + * it to be functional. For most of the Qualcomm SoCs, when run with
> > Gunyah
> > + * or older QHEE hypervisor, all the resources whether it is static or
> > dynamic,
> > + * is managed by present hypervisor. Dynamic resources if it is present
> > for
> > + * a remote processor will always be coming from secure world via SMC
> > call
> > + * while static resources may be present in remote processor firmware
> > binary
> > + * or it may be coming from SMC call along with dynamic resources.
>
> How about:
>
> """
> The resources consumed by Qualcomm remote processors fall into two categories:
> static (such as the memory carveouts for the rproc firmware) and dynamic (like
> shared memory pools).
>
> Both are managed by a Qualcomm hypervisor (such as QHEE or Gunyah), if one is
> present.
>
> Otherwise, a resource table must be retrieved via an SCM call. That table will
> list all dynamic resources (if any) and possibly the static ones.
> The static resources may also come from a resource table embedded in the rproc
> firmware instead.
> """
>
> ?
Concise, thanks for the effort.
>
> > + *
> > + * Here, we call rproc_elf_load_rsc_table() to check firmware binary
> > has resources
> > + * or not and if it is not having then we pass NULL and zero as input
> > resource
> > + * table pointer and size respectively to the argument of
> > qcom_scm_pas_get_rsc_table()
> > + * and this is even true for Qualcomm remote processor who does follow
> > remoteproc
> > + * framework.
> > + */
> > + ret = qcom_scm_pas_get_rsc_table(pas->pas_ctx, table, table_sz,
> > &output_rt,
> > + &output_rt_size);
> > + if (ret) {
> > + dev_err(pas->dev, "Error in getting resource table: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + kfree(rproc->cached_table);
>
> Would this not simply discard the firmware binary table in the "split case"?
>
For split case, it will have resource table from remote processor firmware,
which we are passing as part of qcom_scm_pas_get_rsc_table(), TZ firmware
will append dynamic one after authentication the static one and will copy
the final table in output_rt and its total size in output_rt_size.
> Konrad
>
> > + rproc->cached_table = output_rt;
> > + rproc->table_ptr = rproc->cached_table;
> > + rproc->table_sz = output_rt_size;
> > +
> > + return ret;
> > +}
> > +
> > static unsigned long qcom_pas_panic(struct rproc *rproc)
> > {
> > struct qcom_pas *pas = rproc->priv;
> > @@ -425,7 +481,7 @@ static const struct rproc_ops qcom_pas_ops = {
> > .start = qcom_pas_start,
> > .stop = qcom_pas_stop,
> > .da_to_va = qcom_pas_da_to_va,
> > - .parse_fw = qcom_register_dump_segments,
> > + .parse_fw = qcom_pas_parse_firmware,
> > .load = qcom_pas_load,
> > .panic = qcom_pas_panic,
> > };
> > @@ -435,7 +491,7 @@ static const struct rproc_ops qcom_pas_minidump_ops = {
> > .start = qcom_pas_start,
> > .stop = qcom_pas_stop,
> > .da_to_va = qcom_pas_da_to_va,
> > - .parse_fw = qcom_register_dump_segments,
> > + .parse_fw = qcom_pas_parse_firmware,
> > .load = qcom_pas_load,
> > .panic = qcom_pas_panic,
> > .coredump = qcom_pas_minidump,
> >
--
-Mukesh Ojha
