linux-kernel - Re: [PATCH v2 01/11] firmware: qcom_scm: Introduce PAS context initialization helper

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <91181e2d-e595-42e7-a782-9ee654682036@kernel.org>
Date: Sat, 13 Sep 2025 15:54:26 +0100
From: Bryan O'Donoghue <bod@...nel.org>
To: Mukesh Ojha <mukesh.ojha@....qualcomm.com>,
 Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konradybcio@...nel.org>,
 Vikash Garodia <quic_vgarodia@...cinc.com>,
 Dikshita Agarwal <quic_dikshita@...cinc.com>,
 Mauro Carvalho Chehab <mchehab@...nel.org>,
 Mathieu Poirier <mathieu.poirier@...aro.org>
Cc: Abhinav Kumar <abhinav.kumar@...ux.dev>,
 Bryan O'Donoghue <bryan.odonoghue@...aro.org>, linux-kernel@...r.kernel.org,
 linux-arm-msm@...r.kernel.org, linux-media@...r.kernel.org,
 linux-remoteproc@...r.kernel.org
Subject: Re: [PATCH v2 01/11] firmware: qcom_scm: Introduce PAS context
 initialization helper

On 19/08/2025 17:54, Mukesh Ojha wrote:
> Currently, remoteproc and non-remoteproc subsystems use different
> variants of the MDT loader helper API, primarily due to the handling of
> the metadata context. Remoteproc subsystems retain this context until
> authentication and reset, while non-remoteproc subsystems (e.g., video,
> graphics) do not require it.
> 
> Unify the metadata loading process for both remoteproc and
> non-remoteproc subsystems by introducing a dedicated PAS context
> initialization function.
> 
> By introducing qcom_scm_pas_ctx_init(), we can standardize the API usage
> across subsystems and reduce the number of parameters passed to MDT
> loader functions, improving code clarity and maintainability.
> 
> Signed-off-by: Mukesh Ojha <mukesh.ojha@....qualcomm.com>
> ---
>   drivers/firmware/qcom/qcom_scm.c       | 26 ++++++++++++++++++++++++++
>   include/linux/firmware/qcom/qcom_scm.h | 11 +++++++++++
>   2 files changed, 37 insertions(+)
> 
> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index 96d5cf40a74c..33187d4f4aef 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -558,6 +558,32 @@ static void qcom_scm_set_download_mode(u32 dload_mode)
>   		dev_err(__scm->dev, "failed to set download mode: %d\n", ret);
>   }
> 
> +void *qcom_scm_pas_ctx_init(struct device *dev, u32 peripheral, phys_addr_t mem_phys,
> +			    size_t mem_size, bool save_mdt_ctx)
> +{
> +	struct qcom_scm_pas_ctx *ctx;
> +
> +	ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> +	if (!ctx)
> +		return NULL;
> +
> +	ctx->dev = dev;
> +	ctx->peripheral = peripheral;

One things that is confusing here is renaming this variable to peripheral.

It gets initialised from a thing called "pas_id" and then gets sent into 
other functions which name the incoming variable as pas_id.

i.e. you will want to do
-       ret = qcom_mdt_pas_init(pas->dev, pas->firmware, 
rproc->firmware, pas->pas_id,
-                               pas->mem_phys, &pas->pas_metadata);
-       if (ret)
-               goto disable_px_supply;
-
-       ret = qcom_mdt_load_no_init(pas->dev, pas->firmware, 
rproc->firmware, pas->pas_id,
-                                   pas->mem_region, pas->mem_phys, 
pas->mem_size,
-                                   &pas->mem_reloc);
+       ret = qcom_mdt_pas_load(pas->pas_ctx, pas->firmware, 
rproc->firmware,
  -                              pas->mem_region, &pas->dtb_mem_reloc);
++                              pas->pas_id, pas->mem_region, 
&pas->dtb_mem_reloc);

and

-       return __qcom_mdt_load(ctx->dev, fw, firmware, mem_region, 
ctx->mem_phys,
+       return __qcom_mdt_load(ctx->dev, fw, firmware, ctx->peripheral, 
mem_region, ctx->mem_phys,
                                ctx->mem_size, reloc_base);

But it should be ctx->pas_id to be consistent and make it obvious what 
data is being passed.

Can you stick to the established naming convention and stick with pas_id 
here ?

Even if the above fixups on 6.17 aren't right the point is it only adds 
confusion to randomly change variable names for no reason.

Please stick to the established naming convention.

--
bod