From: Bjorn Andersson <andersson@kernel.org>
To: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Cc: Konrad Dybcio <konradybcio@kernel.org>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Sumit Garg <sumit.garg@oss.qualcomm.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-remoteproc@vger.kernel.org
Subject: Re: [PATCH v5 6/6] firmware: qcom: scm: introduce keep_mdt_buf flag in PAS context
Date: Sat, 1 Aug 2026 23:08:30 -0500 [thread overview]
Message-ID: <am7Aj5UdrrtGUHjA@baldur> (raw)
In-Reply-To: <20260724182858.1868271-7-mukesh.ojha@oss.qualcomm.com>
On Fri, Jul 24, 2026 at 11:58:58PM +0530, Mukesh Ojha wrote:
> The PAS image initialization path always retains the metadata buffer
> when a valid qcom_scm_pas_context is provided, even if the caller does
> not require it. This implicit behavior leads to unclear buffer ownership
> and forces new users of qcom_mdt_pas_load() to manually release
> metadata, which is error‑ prone and incorrect.
>
> Add a keep_mdt_buf flag to struct qcom_scm_pas_context to make metadata
> retention explicit. Metadata buffers are now freed by default and are
> only preserved when this flag is set. qcom_q6v5_pas enables this during
> probe for contexts that require retained metadata for subsequent PAS
> operations, while existing callers continue to work unchanged.
>
I presume given that this was sent together with the remoteproc patches
that this can't be merged until those other changes has made it into the
tree.
Please confirm if there is an actual dependency here.
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/firmware/qcom/qcom_scm.c | 18 +++++++++++++++---
> drivers/remoteproc/qcom_q6v5_pas.c | 3 +++
> include/linux/firmware/qcom/qcom_pas.h | 1 +
> 3 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index 16ae42e6c434..54ffec97cc26 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -625,7 +625,7 @@ static int qcom_scm_pas_prep_and_init_image(struct device *dev,
> mdata_phys = qcom_tzmem_to_phys(mdata_buf);
>
> ret = __qcom_scm_pas_init_image(dev, ctx->pas_id, mdata_phys, &res);
> - if (ret < 0)
> + if (ret < 0 || !ctx->keep_mdt_buf)
> qcom_tzmem_free(mdata_buf);
> else
> ctx->ptr = mdata_buf;
> @@ -664,9 +664,21 @@ static int qcom_scm_pas_init_image(struct device *dev, u32 pas_id,
> memcpy(mdata_buf, metadata, size);
>
> ret = __qcom_scm_pas_init_image(dev, pas_id, mdata_phys, &res);
> - if (ret < 0 || !ctx) {
> +
> + /*
> + * Some clients still pass the PAS context as NULL. Until all clients
> + * switch to qcom_mdt_pas_load() and provide a valid PAS context, check
> + * for NULL before dereferencing it.
Why don't we fix the problematic clients? There's no point in working
around such things.
> + *
> + * When a valid context is provided, keep_mdt_buf controls whether the
> + * metadata buffer is retained after PAS_INIT. PAS remoteproc subsystems
> + * set this flag so metadata persists until auth_and_reset() completes,
> + * as TrustZone keeps the buffers locked until then. Other callers leave
> + * it unset and metadata is freed immediately after the PAS_INIT call.
Please rewrite this to make it more succinct. It seems you could say the
same thing with just the words "free the metadata on error or if client
didn't request us to keep it".
Regards,
Bjorn
> + */
> + if (ret < 0 || !ctx || !ctx->keep_mdt_buf) {
> dma_free_coherent(dev, size, mdata_buf, mdata_phys);
> - } else if (ctx) {
> + } else {
> ctx->ptr = mdata_buf;
> ctx->phys = mdata_phys;
> ctx->size = size;
> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
> index 0391e30f42ba..38e6f6019825 100644
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -722,6 +722,7 @@ static int qcom_pas_alloc_memory_region(struct qcom_pas *pas)
> if (IS_ERR(pas->pas_ctx))
> return PTR_ERR(pas->pas_ctx);
>
> + pas->pas_ctx->keep_mdt_buf = true;
> if (!pas->dtb_pas_id)
> return 0;
>
> @@ -740,6 +741,8 @@ static int qcom_pas_alloc_memory_region(struct qcom_pas *pas)
> if (IS_ERR(pas->dtb_pas_ctx))
> return PTR_ERR(pas->dtb_pas_ctx);
>
> + pas->dtb_pas_ctx->keep_mdt_buf = true;
> +
> return 0;
> }
>
> diff --git a/include/linux/firmware/qcom/qcom_pas.h b/include/linux/firmware/qcom/qcom_pas.h
> index fb2ec3be6a16..1d132e89536e 100644
> --- a/include/linux/firmware/qcom/qcom_pas.h
> +++ b/include/linux/firmware/qcom/qcom_pas.h
> @@ -22,6 +22,7 @@ struct qcom_pas_context {
> dma_addr_t phys;
> ssize_t size;
> bool use_tzmem;
> + bool keep_mdt_buf;
> };
>
> static inline void __iomem *qcom_pas_ctx_map(struct qcom_pas_context *ctx)
> --
> 2.53.0
>
next prev parent reply other threads:[~2026-08-02 4:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-24 18:28 [PATCH v5 0/6] remoteproc: qcom: pas: Misc fixes Mukesh Ojha
2026-07-24 18:28 ` [PATCH v5 1/6] remoteproc: qcom: annotate mem_region fields with __iomem Mukesh Ojha
2026-07-24 18:28 ` [PATCH v5 2/6] remoteproc: qcom: pas: Guard dtb metadata release with dtb_pas_id check Mukesh Ojha
2026-07-24 18:28 ` [PATCH v5 3/6] remoteproc: qcom: pas: Fix the PAS context creation placement Mukesh Ojha
2026-07-24 18:28 ` [PATCH v5 4/6] remoteproc: qcom: pas: Map/unmap subsystem region before auth_and_reset Mukesh Ojha
2026-07-24 18:28 ` [PATCH v5 5/6] remoteproc: qcom: pas: Drop unused dtb_mem_region field Mukesh Ojha
2026-07-24 18:28 ` [PATCH v5 6/6] firmware: qcom: scm: introduce keep_mdt_buf flag in PAS context Mukesh Ojha
2026-08-02 4:08 ` Bjorn Andersson [this message]
2026-07-31 3:26 ` (subset) [PATCH v5 0/6] remoteproc: qcom: pas: Misc fixes Bjorn Andersson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=am7Aj5UdrrtGUHjA@baldur \
--to=andersson@kernel.org \
--cc=konradybcio@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=mukesh.ojha@oss.qualcomm.com \
--cc=neil.armstrong@linaro.org \
--cc=sumit.garg@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox