From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 55DF738C2CB; Mon, 23 Mar 2026 13:13:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774271591; cv=none; b=XLke67aPrnDYp4rSKKCv9qA573/1qQb0KKE3srO7MFE6cm4ESZC83FvopF3Pup9bUQjcBXNX2e67A9/tI437dFUeR1KMY/Lzk1SgKYS2KXo0eVGIImYnq/zvfTZwcINvMZI3T7YhdeRTV3AlOTZ+Zbd+ybxZ6Rze0pIxQCCEOlQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774271591; c=relaxed/simple; bh=74qU1/t986C2nAZ4bavaRViUUE+Cf6yDDXac2agl2dM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CHMvDlSb57iG7Ks+scI7MTWFbETBRWrK5xy+yEQvNfjBiIpnVW7VlsoYBQHSQFV5kRmg1/7nWf6DFS+R6t3Hc5l+WXpSS7dSVCYnnAKF0NUCQ3j2gI/c0SfS4b+wbXrrGf7TQYHOhK+bzEAYAeCiPQM5AttDsKmotKjPkYqXlbY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lRYjEckq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lRYjEckq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE057C4CEF7; Mon, 23 Mar 2026 13:12:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774271591; bh=74qU1/t986C2nAZ4bavaRViUUE+Cf6yDDXac2agl2dM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lRYjEckqteg2OKaK6EkU3qHTed8L/Kuu8nYTDY12LVL7ijOi7qNUOsPD5UHqT54Vd tsznwZRHnAKrJhII5FqZ+AisA4ZWNApAx0Pk/9fTsh3zXc1WzfKrWVr/UCllmug7sg z1bdfdxrvM3rhSxNSQFvwtn2noOGHPItPmrj39sTCgHzr/TqSgg+KOov8ZOGK2Czhe GSelAor5vaAF5iKbd8nV8/Z7LVpo2CLj5uSDSK01vsXJNevwfD5YvOmqIgqwR/0256 DxasYH1b85jyJCFi/cnmD4aK9ryRrVm3XpBckheqMJw6h+O2c17MKqqdPZ3cRw+ufV vUq6ZCOK/41uw== Date: Mon, 23 Mar 2026 18:42:52 +0530 From: Sumit Garg To: Harshal Dev Cc: linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, linux-media@vger.kernel.org, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, ath12k@lists.infradead.org, linux-remoteproc@vger.kernel.org, andersson@kernel.org, konradybcio@kernel.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, robin.clark@oss.qualcomm.com, sean@poorly.run, akhilpo@oss.qualcomm.com, lumag@kernel.org, abhinav.kumar@linux.dev, jesszhan0024@gmail.com, marijn.suijten@somainline.org, airlied@gmail.com, simona@ffwll.ch, vikash.garodia@oss.qualcomm.com, dikshita.agarwal@oss.qualcomm.com, bod@kernel.org, mchehab@kernel.org, elder@kernel.org, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, jjohnson@kernel.org, mathieu.poirier@linaro.org, trilokkumar.soni@oss.qualcomm.com, mukesh.ojha@oss.qualcomm.com, pavan.kondeti@oss.qualcomm.com, jorge.ramirez@oss.qualcomm.com, tonyh@qti.qualcomm.com, vignesh.viswanathan@oss.qualcomm.com, srinivas.kandagatla@oss.qualcomm.com, amirreza.zarrabi@oss.qualcomm.com, jens.wiklander@linaro.org, op-tee@lists.trustedfirmware.org, apurupa@qti.qualcomm.com, skare@qti.qualcomm.com, linux-kernel@vger.kernel.org, Sumit Garg Subject: Re: [PATCH v2 02/15] firmware: qcom: Add a generic PAS service Message-ID: References: <20260312062756.694390-1-sumit.garg@kernel.org> <20260312062756.694390-3-sumit.garg@kernel.org> <124f5a78-a3be-4906-bea0-a82bb74b2f96@oss.qualcomm.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <124f5a78-a3be-4906-bea0-a82bb74b2f96@oss.qualcomm.com> On Sun, Mar 15, 2026 at 10:03:16PM +0530, Harshal Dev wrote: > > > On 3/12/2026 11:57 AM, Sumit Garg wrote: > > From: Sumit Garg > > > > Qcom platforms has the legacy of using non-standard SCM calls > > splintered over the various kernel drivers. These SCM calls aren't > > compliant with the standard SMC calling conventions which is a > > prerequisite to enable migration to the FF-A specifications from Arm. > > > > OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't > > support these non-standard SCM calls. And even for newer architectures > > with S-EL2 and Hafnium support, QTEE won't be able to support SCM > > calls either with FF-A requirements coming in. And with both OP-TEE > > and QTEE drivers well integrated in the TEE subsystem, it makes further > > sense to reuse the TEE bus client drivers infrastructure. > > > > The added benefit of TEE bus infrastructure is that there is support > > for discoverable/enumerable services. With that client drivers don't > > have to manually invoke a special SCM call to know the service status. > > > > So enable the generic Peripheral Authentication Service (PAS) provided > > by the firmware. It acts as the common layer with different TZ > > backends plugged in whether it's an SCM implementation or a proper > > TEE bus based PAS service implementation. > > > > Signed-off-by: Sumit Garg > > --- > > drivers/firmware/qcom/Kconfig | 8 + > > drivers/firmware/qcom/Makefile | 1 + > > drivers/firmware/qcom/qcom_pas.c | 298 +++++++++++++++++++++++++ > > drivers/firmware/qcom/qcom_pas.h | 53 +++++ > > include/linux/firmware/qcom/qcom_pas.h | 41 ++++ > > 5 files changed, 401 insertions(+) > > create mode 100644 drivers/firmware/qcom/qcom_pas.c > > create mode 100644 drivers/firmware/qcom/qcom_pas.h > > create mode 100644 include/linux/firmware/qcom/qcom_pas.h > > > > diff --git a/drivers/firmware/qcom/Kconfig b/drivers/firmware/qcom/Kconfig > > index b477d54b495a..8653639d06db 100644 > > --- a/drivers/firmware/qcom/Kconfig > > +++ b/drivers/firmware/qcom/Kconfig > > @@ -6,6 +6,14 @@ > > > > menu "Qualcomm firmware drivers" > > > > +config QCOM_PAS > > + tristate > > + help > > + Enable the generic Peripheral Authentication Service (PAS) provided > > + by the firmware. It acts as the common layer with different TZ > > + backends plugged in whether it's an SCM implementation or a proper > > + TEE bus based PAS service implementation. > > + > > config QCOM_SCM > > select QCOM_TZMEM > > tristate > > diff --git a/drivers/firmware/qcom/Makefile b/drivers/firmware/qcom/Makefile > > index 0be40a1abc13..dc5ab45f906a 100644 > > --- a/drivers/firmware/qcom/Makefile > > +++ b/drivers/firmware/qcom/Makefile > > @@ -8,3 +8,4 @@ qcom-scm-objs += qcom_scm.o qcom_scm-smc.o qcom_scm-legacy.o > > obj-$(CONFIG_QCOM_TZMEM) += qcom_tzmem.o > > obj-$(CONFIG_QCOM_QSEECOM) += qcom_qseecom.o > > obj-$(CONFIG_QCOM_QSEECOM_UEFISECAPP) += qcom_qseecom_uefisecapp.o > > +obj-$(CONFIG_QCOM_PAS) += qcom_pas.o > > diff --git a/drivers/firmware/qcom/qcom_pas.c b/drivers/firmware/qcom/qcom_pas.c > > new file mode 100644 > > index 000000000000..beb1bae55546 > > --- /dev/null > > +++ b/drivers/firmware/qcom/qcom_pas.c > > @@ -0,0 +1,298 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > + > > +#include "qcom_pas.h" > > + > > +struct qcom_pas_ops *ops_ptr; > > + > > +/** > > + * devm_qcom_pas_context_alloc() - Allocate peripheral authentication service > > + * context for a given peripheral > > + * > > + * PAS context is device-resource managed, so the caller does not need > > + * to worry about freeing the context memory. > > + * > > + * @dev: PAS firmware device > > + * @pas_id: peripheral authentication service id > > + * @mem_phys: Subsystem reserve memory start address > > + * @mem_size: Subsystem reserve memory size > > + * > > + * Return: The new PAS context, or ERR_PTR() on failure. > > + */ > > +struct qcom_pas_context *devm_qcom_pas_context_alloc(struct device *dev, > > + u32 pas_id, > > + phys_addr_t mem_phys, > > + size_t mem_size) > > +{ > > + struct qcom_pas_context *ctx; > > + > > + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL); > > + if (!ctx) > > + return ERR_PTR(-ENOMEM); > > + > > + ctx->dev = dev; > > + ctx->pas_id = pas_id; > > + ctx->mem_phys = mem_phys; > > + ctx->mem_size = mem_size; > > + > > + return ctx; > > +} > > +EXPORT_SYMBOL_GPL(devm_qcom_pas_context_alloc); > > + > > +/** > > + * qcom_pas_init_image() - Initialize peripheral authentication service state > > + * machine for a given peripheral, using the metadata > > + * @pas_id: peripheral authentication service id > > + * @metadata: pointer to memory containing ELF header, program header table > > + * and optional blob of data used for authenticating the metadata > > + * and the rest of the firmware > > + * @size: size of the metadata > > + * @ctx: optional pas context > > + * > > + * Return: 0 on success. > > + * > > + * Upon successful return, the PAS metadata context (@ctx) will be used to > > + * track the metadata allocation, this needs to be released by invoking > > + * qcom_pas_metadata_release() by the caller. > > + */ > > +int qcom_pas_init_image(u32 pas_id, const void *metadata, size_t size, > > + struct qcom_pas_context *ctx) > > +{ > > I think we should check for !ctx everywhere the way we are doing in qcom_pas_metadata_release(). > !ctx->ptr may be checked conditionally based on whether the underlying implementation > uses it. The ctx for this API is optional, that means the backend should check apporpriately for it. I will add that check for TEE backend though. > > > + if (ops_ptr) > > + return ops_ptr->init_image(ops_ptr->dev, pas_id, > > + metadata, size, ctx); > > + > > + return -ENODEV; > > +} > > +EXPORT_SYMBOL_GPL(qcom_pas_init_image); > > + > > +/** > > + * qcom_pas_metadata_release() - release metadata context > > + * @ctx: pas context > > + */ > > +void qcom_pas_metadata_release(struct qcom_pas_context *ctx) > > +{ > > + if (!ctx || !ctx->ptr) > > + return; > > + > > + if (ops_ptr) > > + ops_ptr->metadata_release(ops_ptr->dev, ctx); > > +} > > +EXPORT_SYMBOL_GPL(qcom_pas_metadata_release); > > + > > +/** > > + * qcom_pas_mem_setup() - Prepare the memory related to a given peripheral > > + * for firmware loading > > + * @pas_id: peripheral authentication service id > > + * @addr: start address of memory area to prepare > > + * @size: size of the memory area to prepare > > + * > > + * Return: 0 on success. > > + */ > > +int qcom_pas_mem_setup(u32 pas_id, phys_addr_t addr, phys_addr_t size) > > +{ > > + if (ops_ptr) > > + return ops_ptr->mem_setup(ops_ptr->dev, pas_id, addr, size); > > + > > + return -ENODEV; > > +} > > +EXPORT_SYMBOL_GPL(qcom_pas_mem_setup); > > + > > +/** > > + * qcom_pas_get_rsc_table() - Retrieve the resource table in passed output buffer > > + * for a given peripheral. > > + * > > + * Qualcomm remote processor may rely on both static and dynamic resources for > > + * its functionality. Static resources typically refer to memory-mapped > > + * addresses required by the subsystem and are often embedded within the > > + * firmware binary and dynamic resources, such as shared memory in DDR etc., > > + * are determined at runtime during the boot process. > > + * > > + * On Qualcomm Technologies devices, it's possible that static resources are > > + * not embedded in the firmware binary and instead are provided by TrustZone. > > + * However, dynamic resources are always expected to come from TrustZone. This > > + * indicates that for Qualcomm devices, all resources (static and dynamic) will > > + * be provided by TrustZone PAS service. > > + * > > + * If the remote processor firmware binary does contain static resources, they > > + * should be passed in input_rt. These will be forwarded to TrustZone for > > + * authentication. TrustZone will then append the dynamic resources and return > > + * the complete resource table in output_rt_tzm. > > + * > > + * If the remote processor firmware binary does not include a resource table, > > + * the caller of this function should set input_rt as NULL and input_rt_size > > + * as zero respectively. > > + * > > + * More about documentation on resource table data structures can be found in > > + * include/linux/remoteproc.h > > + * > > + * @ctx: PAS context > > + * @pas_id: peripheral authentication service id > > + * @input_rt: resource table buffer which is present in firmware binary > > + * @input_rt_size: size of the resource table present in firmware binary > > + * @output_rt_size: TrustZone expects caller should pass worst case size for > > + * the output_rt_tzm. > > + * > > + * Return: > > + * On success, returns a pointer to the allocated buffer containing the final > > + * resource table and output_rt_size will have actual resource table size from > > + * TrustZone. The caller is responsible for freeing the buffer. On failure, > > + * returns ERR_PTR(-errno). > > + */ > > +struct resource_table *qcom_pas_get_rsc_table(struct qcom_pas_context *ctx, > > + void *input_rt, > > + size_t input_rt_size, > > + size_t *output_rt_size) > > +{ > > Check for !ctx here as well. Ack. > > > + if (ops_ptr) > > + return ops_ptr->get_rsc_table(ops_ptr->dev, ctx, input_rt, > > + input_rt_size, output_rt_size); > > + > > + return ERR_PTR(-ENODEV); > > +} > > +EXPORT_SYMBOL_GPL(qcom_pas_get_rsc_table); > > + > > +/** > > + * qcom_pas_auth_and_reset() - Authenticate the given peripheral firmware > > + * and reset the remote processor > > + * @pas_id: peripheral authentication service id > > + * > > + * Return: 0 on success. > > + */ > > +int qcom_pas_auth_and_reset(u32 pas_id) > > +{ > > + if (ops_ptr) > > + return ops_ptr->auth_and_reset(ops_ptr->dev, pas_id); > > + > > + return -ENODEV; > > +} > > +EXPORT_SYMBOL_GPL(qcom_pas_auth_and_reset); > > + > > +/** > > + * qcom_pas_prepare_and_auth_reset() - Prepare, authenticate, and reset the > > + * remote processor > > + * > > + * @ctx: Context saved during call to qcom_scm_pas_context_init() > > + * > > + * This function performs the necessary steps to prepare a PAS subsystem, > > + * authenticate it using the provided metadata, and initiate a reset sequence. > > + * > > + * It should be used when Linux is in control setting up the IOMMU hardware > > + * for remote subsystem during secure firmware loading processes. The > > + * preparation step sets up a shmbridge over the firmware memory before > > + * TrustZone accesses the firmware memory region for authentication. The > > + * authentication step verifies the integrity and authenticity of the firmware > > + * or configuration using secure metadata. Finally, the reset step ensures the > > + * subsystem starts in a clean and sane state. > > + * > > + * Return: 0 on success, negative errno on failure. > > + */ > > +int qcom_pas_prepare_and_auth_reset(struct qcom_pas_context *ctx) > > +{ > > Same here. Ack. -Sumit