- OP-TEE - lists.trustedfirmware.org

Re: [PATCH v2 2/3] dt-bindings: firmware: add mbedtee,tee binding

by Krzysztof Kozlowski

On 02/07/2026 17:11, Xing Loong wrote: > + > + On RISC-V the TEE signals the REE via IMSIC MSI; the REE submits > + commands via r2t-ring that the TEE polls. No REE-to-TEE interrupt > + is used. No SBI ecall is involved. > + > +properties: > + compatible: > + const: mbedtee,tee No, you need to respond to feedback instead of sending the same code called v2. You received comments for a reason. Sending v2 now hides all this comments and people might think discussion is resolved. This is very bad practice. Also, Do not attach (thread) your patchsets to some other threads (unrelated or older versions). This buries them deep in the mailbox and might interfere with applying entire sets. See also: https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/sub… ... > + > +examples: > + - | > + /* ARM TrustZone (SMC) */ > + #include <dt-bindings/interrupt-controller/arm-gic.h> > + > + firmware { > + mbedtee { > + compatible = "mbedtee,tee"; > + interrupts = <GIC_SPI 72 IRQ_TYPE_EDGE_RISING>; > + memory-region = <&mbedtee_t2r_ring>, <&mbedtee_t2r_shm>; > + memory-region-names = "t2r-ring", "t2r-shm"; > + }; > + }; > + > + /* memory-region phandle targets */ > + mbedtee_t2r_ring: t2r-ring {}; > + mbedtee_t2r_shm: t2r-shm {}; I asked you to drop all these irrelevant entries. > + > + - | > + /* RISC-V IMSIC (ring-buffer polling REE->TEE, MSI TEE->REE) */ > + > + firmware { > + mbedtee { > + compatible = "mbedtee,tee"; > + msi-parent = <&imsic>; > + memory-region = <&rv_t2r_ring>, <&rv_t2r_shm>, > + <&rv_r2t_ring>; > + memory-region-names = "t2r-ring", "t2r-shm", > + "r2t-ring"; > + }; > + }; > + > + /* msi-parent phandle target */ > + imsic: imsic { > + msi-controller; > + #msi-cells = <0>; > + }; Also drop. > + > + /* memory-region phandle targets */ > + rv_t2r_ring: t2r-ring {}; > + rv_t2r_shm: t2r-shm {}; > + rv_r2t_ring: r2t-ring {}; Also not relevant. I will not continue the review. Please go back to v1 and continue the discussion. I consider this version NAKed. Best regards, Krzysztof

47 minutes

1
0
0 0

[PATCH v9 00/14] firmware: qcom: Add OP-TEE PAS service support

by Sumit Garg

From: Sumit Garg <sumit.garg(a)oss.qualcomm.com> 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 using S-EL2 with 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. The TEE PAS service ABI is designed to be extensible with additional API as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future extensions of the PAS service needed while still maintaining backwards compatibility. Currently OP-TEE support is being added to provide the backend PAS service implementation which can be found as part of this PR [1]. This implementation has been tested on Kodiak/RB3Gen2 and lemans EVK boards. In addition to that WIN/IPQ targets tested OP-TEE with this service too. Surely the backwards compatibility is maintained and tested for SCM backend. Note that kernel PAS service support while running in EL2 is at parity among OP-TEE vs QTEE. Especially the media (venus/iris) support depends on proper IOMMU support being worked out on the PAS client end. Patch summary: - Patch #1: adds generic PAS service. - Patch #2: migrates SCM backend to generic PAS service. - Patch #3: adds TEE/OP-TEE backend for generic PAS service. - Patch #4-#12: migrates all client drivers to generic PAS service. - Patch #13: drops legacy PAS SCM exported APIs. The patch-set is based on v7.2-rc1 and can be found in git tree here [2]. Merge strategy: It is expected due to APIs dependency, the entire patch-set to go via the Qcom tree. All other subsystem maintainers, it will be great if I can get acks for the corresponding subsystem patches. [1] https://github.com/OP-TEE/optee_os/pull/7721 (already merged) [2] https://git.kernel.org/pub/scm/linux/kernel/git/sumit.garg/linux.git/log/?h… --- Changes in v9: - Rebased to 7.2-rc1. - Enable SCM backend similar to TEE if ARCH_QCOM is set. - Address misc. comments from Konrad. - Add checks for corner cases (although not reachable as per OP-TEE ABI) reported by Shashiko on patch #3. - Picked up review tags from Konrad. Changes in v8: - Rebased on mainline tip (no functional changes). - Now Lemans EVK is also tested to support OP-TEE PAS here: https://github.com/OP-TEE/optee_os/pull/7845 - Drop Kodiak DT patch as it is carried independently by Mukesh here: https://lore.kernel.org/lkml/20260624063952.2242702-1-mukesh.ojha@oss.qualc… - Regarding Sashiko comments, I have already replied in v6 the ones that don't apply but in v7 I got the same comments again. Specific context reasoning which Shashiko ignores: - ABI contract between Linux and TZ - No support for multiple concurrent backends - The TZ backend doesn’t detach during the entire boot cycle Changes in v7: - Rebased to qcom tree (for-next branch) tip. - Merged patch #5 and #7 due to build dependency. - Disabled modem for kodiak EL2 as it isn't tested yet. - Fix an issue found out by sashiko-bot for patch #4. Changes in v6: - Rebased to v7.1-rc4 tag. - Patch #14: fixed ret error print. - Add Kconfig descriptions for PAS symbols such that they are visible in menuconfig to update. Changes in v5: - Incorporated misc. comments from Mukesh. - Split up patch #11 into 2 to add an independent commit for passing proper PAS ID to set_remote_state API. - Picked up tags. Changes in v4: - Incorporate misc. comments on patch #4. - Picked up an ack for patch #10. - Clarify in cover letter about state of media support. Changes in v3: - Incorporated some style and misc. comments for patch #2, #3 and #4. - Add QCOM_PAS Kconfig dependency for various subsystems. - Switch from pseudo TA to proper TA invoke commands. Changes in v2: - Fixed kernel doc warnings. - Polish commit message and comments for patch #2. - Pass proper PAS ID in set_remote_state API for media firmware drivers. - Added Maintainer entry and dropped MODULE_AUTHOR. Sumit Garg (14): firmware: qcom: Add a generic PAS service firmware: qcom_scm: Migrate to generic PAS service firmware: qcom: Add a PAS TEE service remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs remoteproc: qcom_wcnss: Switch to generic PAS TZ APIs remoteproc: qcom: Select QCOM_PAS generic service drm/msm: Switch to generic PAS TZ APIs media: qcom: Switch to generic PAS TZ APIs media: qcom: Pass proper PAS ID to set_remote_state API net: ipa: Switch to generic PAS TZ APIs wifi: ath12k: Switch to generic PAS TZ APIs firmware: qcom_scm: Remove SCM PAS wrappers MAINTAINERS: Add maintainer entry for Qualcomm PAS TZ service MAINTAINERS | 9 + drivers/firmware/qcom/Kconfig | 22 +- drivers/firmware/qcom/Makefile | 2 + drivers/firmware/qcom/qcom_pas.c | 299 +++++++++++ drivers/firmware/qcom/qcom_pas.h | 50 ++ drivers/firmware/qcom/qcom_pas_tee.c | 479 ++++++++++++++++++ drivers/firmware/qcom/qcom_scm.c | 302 ++++------- drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 +- drivers/media/platform/qcom/iris/Kconfig | 27 +- .../media/platform/qcom/iris/iris_firmware.c | 9 +- drivers/media/platform/qcom/venus/Kconfig | 1 + drivers/media/platform/qcom/venus/firmware.c | 11 +- drivers/net/ipa/Kconfig | 2 +- drivers/net/ipa/ipa_main.c | 13 +- drivers/net/wireless/ath/ath12k/Kconfig | 2 +- drivers/net/wireless/ath/ath12k/ahb.c | 10 +- drivers/remoteproc/Kconfig | 4 +- drivers/remoteproc/qcom_q6v5_mss.c | 5 +- drivers/remoteproc/qcom_q6v5_pas.c | 51 +- drivers/remoteproc/qcom_wcnss.c | 12 +- drivers/soc/qcom/mdt_loader.c | 12 +- include/linux/firmware/qcom/qcom_pas.h | 43 ++ include/linux/firmware/qcom/qcom_scm.h | 29 -- include/linux/soc/qcom/mdt_loader.h | 6 +- 26 files changed, 1095 insertions(+), 321 deletions(-) create mode 100644 drivers/firmware/qcom/qcom_pas.c create mode 100644 drivers/firmware/qcom/qcom_pas.h create mode 100644 drivers/firmware/qcom/qcom_pas_tee.c create mode 100644 include/linux/firmware/qcom/qcom_pas.h -- 2.53.0

3 hours, 40 minutes

2
16
0 0

[PATCH v9 0/6] arm_ffa, KVM: Fix FF-A emad offset calculations

by Sebastian Ene

Hi all, This series fixes the Endpoint Memory Access Descriptor (EMAD) offset calculations and adds the necessary bounds checks for both the core FF-A driver and the pKVM hypervisor. Prior to FF-A version 1.1, the memory region header didn't specify an explicit offset for the EMADs, leading to the assumption that they immediately follow the header. However, from v1.1 onwards, the specification dictates using the ep_mem_offset` field to determine the start of the memory access array. The patches in this series address this by: 1. Updating the core `arm_ffa` firmware driver to correctly calculate the descriptor offset using `ep_mem_offset` rather than defaulting to `sizeof(struct ffa_mem_region)`. It also introduces bounds checking against `max_fragsize`. 2. Enhancing the pKVM hypervisor validation logic to no longer strictly enforce that the descriptor strictly follows the header, aligning it with the driver behavior and the FF-A specification, while also ensuring the offset falls within the mailbox buffer bounds. While addressing these bugs, Sashiko uncovered other issues that were fixed in the same series. All the patches aside from the first one in optee are urgent fixes as they either impact the hypervisor security or kernel stability. Changelog ######### v8->v9: - addressed Sashiko double ffa_rx_release in "KVM: arm64: Fix bounds checking in do_ffa_mem_reclaim()" v7->v8: - dropped the patch "optee: ffa: Add NULL check in optee_ffa_lend_protmem" from the series as it was queued by Jens - rephrased the commit message for "KVM: arm64: Ensure FFA ranges are page aligned" - introduced a helper macro to get the size of the ffa memory region based on the used version. v6->v7: - taking the patches from Mostafa and sending a new version with the collected tags - Added overflow checks when doing `ep_offset + emad_size` in the arm ff-a driver - Move the length check before the ffa_mem_reclaim - fix compatibility break with ff-a version 1.0 reported by Sashiko - add one more patch to fix an issue with the FFA_VERSION call that can lead to leaking pKVM stack un-initialized data to a host when -ftrivial-auto-var-init=zero is not used. v5->v6: - Add fixes tag - Small clean up make variable declaration reverse christmas tree. v4->v5: - Collect Sudeep Rbs - Add extra patch to check base address alignment. - Remove WARN_ONs in KVM code - Use ffa_emad_size_get() instead of hardcoded size in KVM code. v3 -> v4: - Address review comments and fix Sashiko bugs v2 -> v3: - Fixed typo in nvhe/ffa.c (missing sizeof) v1 -> v2: - For pKVM, removed the strict placement enforcement for `ep_mem_offset` as it is not compliant with the spec, and avoids making assumptions about the driver's memory layout. Link to: ######## v8: https://lore.kernel.org/all/20260630102058.3219867-2-sebastianene@google.co… v7: https://lore.kernel.org/all/20260617145130.3729015-1-sebastianene@google.co… v6: https://lore.kernel.org/all/20260527150236.1978655-1-smostafa@google.com/ v5: https://lore.kernel.org/all/20260526151934.3783707-1-smostafa@google.com/ v4: https://lore.kernel.org/all/20260520204948.2440882-1-smostafa@google.com/ v3: https://lore.kernel.org/all/20260512124442.1899107-1-sebastianene@google.co… v2: https://lore.kernel.org/all/20260430160241.1934777-1-sebastianene@google.co… v1: https://lore.kernel.org/all/ae9KN9nkOgDYJcGP@google.com/T/#t Mostafa Saleh (3): firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() KVM: arm64: Fix bounds checking in do_ffa_mem_reclaim() KVM: arm64: Ensure FFA ranges are page aligned Sebastian Ene (3): firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation KVM: arm64: Validate the offset to the mem access descriptor KVM: arm64: Zero out the stack initialized data in the FFA handler arch/arm64/kvm/hyp/nvhe/ffa.c | 44 +++++++++++++++++++++---------- drivers/firmware/arm_ffa/driver.c | 25 ++++++++++++------ include/linux/arm_ffa.h | 9 ++++++- 3 files changed, 55 insertions(+), 23 deletions(-) -- 2.55.0.rc0.799.gd6f94ed593-goog

5 hours, 36 minutes

1
6
0 0

Re: [PATCH 2/3] dt-bindings: firmware: add mbedtee,rpc binding

by Rob Herring (Arm)

On Wed, 01 Jul 2026 21:25:13 +0800, Xing Loong wrote: > Add YAML devicetree binding for the MbedTEE Trusted Execution > Environment driver. > > The binding covers two platform configurations: > - ARM/AArch64 (TrustZone, SMC): two reserved-memory regions > (rpc-t2r-ring and rpc-t2r-shm) plus a GIC SPI edge interrupt > for TEE-to-REE notifications. > - RISC-V (IMSIC): three reserved-memory regions, adding > rpc-r2t-ring for REE-to-TEE command submissions; no interrupts > property (T2R notifications use IMSIC MSI allocated at runtime). > > Signed-off-by: Xing Loong <xing.xl.loong(a)gmail.com> > --- > .../bindings/firmware/mbedtee,rpc.yaml | 221 ++++++++++++++++++ > 1 file changed, 221 insertions(+) > create mode 100644 Documentation/devicetree/bindings/firmware/mbedtee,rpc.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/firmware/mbedtee,rpc.example.dtb: /: 'compatible' is a required property from schema $id: http://devicetree.org/schemas/root-node.yaml /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/firmware/mbedtee,rpc.example.dtb: /: 'model' is a required property from schema $id: http://devicetree.org/schemas/root-node.yaml doc reference errors (make refcheckdocs): See https://patchwork.kernel.org/project/devicetree/patch/20260701132514.186953… The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.

23 hours, 35 minutes

1
0
0 0

Re: [PATCH 2/3] dt-bindings: firmware: add mbedtee,rpc binding

by Krzysztof Kozlowski

On 01/07/2026 15:25, Xing Loong wrote: > Add YAML devicetree binding for the MbedTEE Trusted Execution Drop YAML, there is no such thing as YAML binding. > Environment driver. We don't take bindings for drivers but for hardware or firmware. Please describe these instead. > > The binding covers two platform configurations: > - ARM/AArch64 (TrustZone, SMC): two reserved-memory regions > (rpc-t2r-ring and rpc-t2r-shm) plus a GIC SPI edge interrupt > for TEE-to-REE notifications. > - RISC-V (IMSIC): three reserved-memory regions, adding > rpc-r2t-ring for REE-to-TEE command submissions; no interrupts > property (T2R notifications use IMSIC MSI allocated at runtime). > > Signed-off-by: Xing Loong <xing.xl.loong(a)gmail.com> > --- > .../bindings/firmware/mbedtee,rpc.yaml | 221 ++++++++++++++++++ > 1 file changed, 221 insertions(+) > create mode 100644 Documentation/devicetree/bindings/firmware/mbedtee,rpc.yaml > > diff --git a/Documentation/devicetree/bindings/firmware/mbedtee,rpc.yaml b/Documentation/devicetree/bindings/firmware/mbedtee,rpc.yaml > new file mode 100644 > index 0000000..08ae255 > --- /dev/null > +++ b/Documentation/devicetree/bindings/firmware/mbedtee,rpc.yaml > @@ -0,0 +1,221 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/firmware/mbedtee,rpc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: MbedTEE Trusted Execution Environment > + > +maintainers: > + - Xing Loong <xing.xl.loong(a)gmail.com> > + > +description: | > + MbedTEE is a Trusted Execution Environment for embedded systems. > + This binding describes the shared-memory regions used for RPC Describe firmware, not the binding. It's redundant to say what the binding is about, just say what is the hardware. > + communication between the Linux REE driver and MbedTEE OS. > + > + The REE and TEE CPUs sharing the RPC memory must be in a > + hardware-coherent domain (same CPU cluster, coherent caches). > + > + Two or three reserved-memory regions are required: > + > + rpc-t2r-ring ring buffer for TEE-to-REE notifications (all platforms) > + rpc-t2r-shm shared memory for TEE-to-REE RPC payloads (all platforms) > + rpc-r2t-ring ring buffer for REE-to-TEE command submissions (RISC-V only) > + > + On ARM/AArch64 the transport uses SMC calls; TEE-to-REE > + notifications use a GIC SPI edge interrupt. > + > + On RISC-V the TEE notifies the REE via IMSIC MSI; the REE submits > + commands via shared-memory rpc-r2t-ring that the TEE polls. No > + REE-to-TEE interrupt is used. No SBI ecall is involved. > + > +properties: > + $nodename: > + const: mbedtee Drop, why would it be relevant? > + > + compatible: > + const: mbedtee,rpc Feels way too generic. First, Google results on mbedtee are basically non-existing, so what sort of company is that? Second, rpc is just not specific enough. Please carefully read writing bindings doc. > + > + interrupts: > + description: > + GIC interrupt used by the TEE to notify the REE of pending RPC > + responses (ARM/AArch64 only). Not present on RISC-V platforms which > + use IMSIC platform MSI interrupts allocated dynamically at runtime. Please read writing bindings doc. > + > + msi-parent: > + maxItems: 1 > + description: > + IMSIC MSI controller used by the Linux driver to allocate the Again drivers... > + TEE-to-REE notification interrupt on RISC-V platforms. Not present on > + ARM/AArch64 platforms, which use the interrupts property. > + > + memory-region: > + minItems: 2 > + maxItems: 3 > + description: > + References to reserved-memory regions for REE<->TEE communication. > + Entries must match memory-region-names order. Obvious. Please do not come with your own style of bindings. > + > + memory-region-names: > + minItems: 2 > + maxItems: 3 Why is this flexible? > + items: > + enum: > + - rpc-t2r-ring rpc is redundant, drop > + - rpc-t2r-shm > + - rpc-r2t-ring > + > +required: > + - compatible > + > +allOf: > + - if: > + required: > + - interrupts > + then: > + required: > + - interrupts > + - memory-region > + - memory-region-names > + properties: > + msi-parent: false > + memory-region: > + minItems: 2 > + maxItems: 2 > + memory-region-names: > + items: > + - const: rpc-t2r-ring > + - const: rpc-t2r-shm > + else: > + required: > + - msi-parent > + - memory-region > + - memory-region-names So memory-region is always required? > + properties: > + memory-region: > + minItems: 3 > + maxItems: 3 > + memory-region-names: > + items: > + - const: rpc-t2r-ring > + - const: rpc-t2r-shm > + - const: rpc-r2t-ring Your top level schema said that. You only need minItems. > + > +additionalProperties: false > + > +examples: > + - | > + /* ARM TrustZone (SMC) */ > + #include <dt-bindings/interrupt-controller/arm-gic.h> > + / { > + #address-cells = <2>; > + #size-cells = <2>; > + > + gic: interrupt-controller@2f000000 { > + compatible = "arm,gic-v3"; > + reg = <0 0x2f000000 0 0x10000>, > + <0 0x2f100000 0 0x200000>; > + interrupt-controller; > + #interrupt-cells = <3>; > + }; > + > + reserved-memory { > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + > + mbedtee_t2r_ring: rpc-t2r-ring@85f10000 { > + reg = <0 0x85f10000 0 0x20000>; > + no-map; > + }; > + > + mbedtee_t2r_shm: rpc-t2r-shm@85f30000 { > + reg = <0 0x85f30000 0 0x40000>; > + no-map; > + }; > + }; None of the above is relevant, drop. > + > + firmware { > + mbedtee { > + compatible = "mbedtee,rpc"; > + interrupt-parent = <&gic>; > + interrupts = <GIC_SPI 72 IRQ_TYPE_EDGE_RISING>; > + memory-region = <&mbedtee_t2r_ring>, <&mbedtee_t2r_shm>; > + memory-region-names = "rpc-t2r-ring", "rpc-t2r-shm"; > + }; > + }; > + }; > + Best regards, Krzysztof

1 day, 2 hours

1
0
0 0

[PATCH v8 00/14] firmware: qcom: Add OP-TEE PAS service support

by Sumit Garg

From: Sumit Garg <sumit.garg(a)oss.qualcomm.com> 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 using S-EL2 with 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. The TEE PAS service ABI is designed to be extensible with additional API as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future extensions of the PAS service needed while still maintaining backwards compatibility. Currently OP-TEE support is being added to provide the backend PAS service implementation which can be found as part of this PR [1]. This implementation has been tested on Kodiak/RB3Gen2 and lemans EVK boards. In addition to that WIN/IPQ targets tested OP-TEE with this service too. Surely the backwards compatibility is maintained and tested for SCM backend. Note that kernel PAS service support while running in EL2 is at parity among OP-TEE vs QTEE. Especially the media (venus/iris) support depends on proper IOMMU support being worked out on the PAS client end. Patch summary: - Patch #1: adds generic PAS service. - Patch #2: migrates SCM backend to generic PAS service. - Patch #3: adds TEE/OP-TEE backend for generic PAS service. - Patch #4-#12: migrates all client drivers to generic PAS service. - Patch #13: drops legacy PAS SCM exported APIs. The patch-set is based on qcom tree tip [2] and can be found in git tree here [3]. Merge strategy: It is expected due to APIs dependency, the entire patch-set to go via the Qcom tree. All other subsystem maintainers, it will be great if I can get acks for the corresponding subsystem patches. [1] https://github.com/OP-TEE/optee_os/pull/7721 (already merged) [2] https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/log/?h=for-n… [3] https://git.kernel.org/pub/scm/linux/kernel/git/sumit.garg/linux.git/log/?h… --- Changes in v8: - Rebased on mainline tip (no functional changes). - Now Lemans EVK is also tested to support OP-TEE PAS here: https://github.com/OP-TEE/optee_os/pull/7845 - Drop Kodiak DT patch as it is carried independently by Mukesh here: https://lore.kernel.org/lkml/20260624063952.2242702-1-mukesh.ojha@oss.qualc… - Regarding Sashiko comments, I have already replied in v6 the ones that don't apply but in v7 I got the same comments again. Specific context reasoning which Shashiko ignores: - ABI contract between Linux and TZ - No support for multiple concurrent backends - The TZ backend doesn’t detach during the entire boot cycle Changes in v7: - Rebased to qcom tree (for-next branch) tip. - Merged patch #5 and #7 due to build dependency. - Disabled modem for kodiak EL2 as it isn't tested yet. - Fix an issue found out by sashiko-bot for patch #4. Changes in v6: - Rebased to v7.1-rc4 tag. - Patch #14: fixed ret error print. - Add Kconfig descriptions for PAS symbols such that they are visible in menuconfig to update. Changes in v5: - Incorporated misc. comments from Mukesh. - Split up patch #11 into 2 to add an independent commit for passing proper PAS ID to set_remote_state API. - Picked up tags. Changes in v4: - Incorporate misc. comments on patch #4. - Picked up an ack for patch #10. - Clarify in cover letter about state of media support. Changes in v3: - Incorporated some style and misc. comments for patch #2, #3 and #4. - Add QCOM_PAS Kconfig dependency for various subsystems. - Switch from pseudo TA to proper TA invoke commands. Changes in v2: - Fixed kernel doc warnings. - Polish commit message and comments for patch #2. - Pass proper PAS ID in set_remote_state API for media firmware drivers. - Added Maintainer entry and dropped MODULE_AUTHOR. Sumit Garg (14): firmware: qcom: Add a generic PAS service firmware: qcom_scm: Migrate to generic PAS service firmware: qcom: Add a PAS TEE service remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs remoteproc: qcom_wcnss: Switch to generic PAS TZ APIs remoteproc: qcom: Select QCOM_PAS generic service drm/msm: Switch to generic PAS TZ APIs media: qcom: Switch to generic PAS TZ APIs media: qcom: Pass proper PAS ID to set_remote_state API net: ipa: Switch to generic PAS TZ APIs wifi: ath12k: Switch to generic PAS TZ APIs firmware: qcom_scm: Remove SCM PAS wrappers MAINTAINERS: Add maintainer entry for Qualcomm PAS TZ service MAINTAINERS | 9 + drivers/firmware/qcom/Kconfig | 21 +- drivers/firmware/qcom/Makefile | 2 + drivers/firmware/qcom/qcom_pas.c | 291 +++++++++++ drivers/firmware/qcom/qcom_pas.h | 50 ++ drivers/firmware/qcom/qcom_pas_tee.c | 477 ++++++++++++++++++ drivers/firmware/qcom/qcom_scm.c | 302 ++++------- drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 +- drivers/media/platform/qcom/iris/Kconfig | 27 +- .../media/platform/qcom/iris/iris_firmware.c | 9 +- drivers/media/platform/qcom/venus/Kconfig | 1 + drivers/media/platform/qcom/venus/firmware.c | 11 +- drivers/net/ipa/Kconfig | 2 +- drivers/net/ipa/ipa_main.c | 13 +- drivers/net/wireless/ath/ath12k/Kconfig | 2 +- drivers/net/wireless/ath/ath12k/ahb.c | 10 +- drivers/remoteproc/Kconfig | 4 +- drivers/remoteproc/qcom_q6v5_mss.c | 5 +- drivers/remoteproc/qcom_q6v5_pas.c | 51 +- drivers/remoteproc/qcom_wcnss.c | 12 +- drivers/soc/qcom/mdt_loader.c | 12 +- include/linux/firmware/qcom/qcom_pas.h | 43 ++ include/linux/firmware/qcom/qcom_scm.h | 29 -- include/linux/soc/qcom/mdt_loader.h | 6 +- 26 files changed, 1084 insertions(+), 321 deletions(-) create mode 100644 drivers/firmware/qcom/qcom_pas.c create mode 100644 drivers/firmware/qcom/qcom_pas.h create mode 100644 drivers/firmware/qcom/qcom_pas_tee.c create mode 100644 include/linux/firmware/qcom/qcom_pas.h -- 2.53.0

1 day, 3 hours

3
35
0 0

Re: [PATCH] firmware: qcom: scm: add missing IRQ_DOMAIN select to QCOM_SCM

by Konrad Dybcio

On 7/1/26 1:03 PM, Julian Braha wrote: > 'drivers/firmware/qcom/qcom_scm.c' calls 'irq_create_fwspec_mapping' > so it will fail to compile if IRQ_DOMAIN is disabled: > > drivers/firmware/qcom/qcom_scm.c: In function ‘qcom_scm_get_waitq_irq’: > drivers/firmware/qcom/qcom_scm.c:2512:16: error: implicit declaration > of function ‘irq_create_fwspec_mapping’; did you mean > ‘irq_create_of_mapping’? [-Wimplicit-function-declaration] > 2512 | return irq_create_fwspec_mapping(&fwspec); > | ^~~~~~~~~~~~~~~~~~~~~~~~~ > | irq_create_of_mapping > > A patch-set in review proposes making QCOM_SCM visible in the kconfig > frontend, so let's ensure that it's safe for users to enable: > https://lore.kernel.org/lkml/akS_6izxrhgK-I22@sumit-xelite/ > > Signed-off-by: Julian Braha <julianbraha(a)gmail.com> > --- Reviewed-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> Konrad

1 day, 5 hours

1
0
0 0

[PATCH v7 0/7] arm_ffa, KVM: Fix FF-A emad offset calculations

by Sebastian Ene

Hi all, This series fixes the Endpoint Memory Access Descriptor (EMAD) offset calculations and adds the necessary bounds checks for both the core FF-A driver and the pKVM hypervisor. Prior to FF-A version 1.1, the memory region header didn't specify an explicit offset for the EMADs, leading to the assumption that they immediately follow the header. However, from v1.1 onwards, the specification dictates using the ep_mem_offset` field to determine the start of the memory access array. The patches in this series address this by: 1. Updating the core `arm_ffa` firmware driver to correctly calculate the descriptor offset using `ep_mem_offset` rather than defaulting to `sizeof(struct ffa_mem_region)`. It also introduces bounds checking against `max_fragsize`. 2. Enhancing the pKVM hypervisor validation logic to no longer strictly enforce that the descriptor strictly follows the header, aligning it with the driver behavior and the FF-A specification, while also ensuring the offset falls within the mailbox buffer bounds. While addressing these bugs, Sashiko uncovered other issues that were fixed in the same series. All the patches aside from the first one in optee are urgent fixes as they either impact the hypervisor security or kernel stability. Changelog ######### v6->v7: - taking the patches from Mostafa and sending a new version with the collected tags - Added overflow checks when doing `ep_offset + emad_size` in the arm ff-a driver - Move the length check before the ffa_mem_reclaim - fix compatibility break with ff-a version 1.0 reported by Sashiko - add one more patch to fix an issue with the FFA_VERSION call that can lead to leaking pKVM stack un-initialized data to a host when -ftrivial-auto-var-init=zero is not used. v5->v6: - Add fixes tag - Small clean up make variable declaration reverse christmas tree. v4->v5: - Collect Sudeep Rbs - Add extra patch to check base address alignment. - Remove WARN_ONs in KVM code - Use ffa_emad_size_get() instead of hardcoded size in KVM code. v3 -> v4: - Address review comments and fix Sashiko bugs v2 -> v3: - Fixed typo in nvhe/ffa.c (missing sizeof) v1 -> v2: - For pKVM, removed the strict placement enforcement for `ep_mem_offset` as it is not compliant with the spec, and avoids making assumptions about the driver's memory layout. Link to: ######## v6: https://lore.kernel.org/all/20260527150236.1978655-1-smostafa@google.com/ v5: https://lore.kernel.org/all/20260526151934.3783707-1-smostafa@google.com/ v4: https://lore.kernel.org/all/20260520204948.2440882-1-smostafa@google.com/ v3: https://lore.kernel.org/all/20260512124442.1899107-1-sebastianene@google.co… v2: https://lore.kernel.org/all/20260430160241.1934777-1-sebastianene@google.co… v1: https://lore.kernel.org/all/ae9KN9nkOgDYJcGP@google.com/T/#t Mostafa Saleh (4): optee: ffa: Add NULL check in optee_ffa_lend_protmem firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() KVM: arm64: Fix bounds checking in do_ffa_mem_reclaim() KVM: arm64: Ensure FFA ranges are page aligned Sebastian Ene (3): firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation KVM: arm64: Validate the offset to the mem access descriptor KVM: arm64: Zero out the stack initialized data in the FFA handler arch/arm64/kvm/hyp/nvhe/ffa.c | 47 ++++++++++++++++++++++--------- drivers/firmware/arm_ffa/driver.c | 25 ++++++++++------ drivers/tee/optee/ffa_abi.c | 3 ++ include/linux/arm_ffa.h | 2 +- 4 files changed, 54 insertions(+), 23 deletions(-) -- 2.54.0.1136.gdb2ca164c4-goog

2 days, 5 hours

4
17
0 0

[PATCH v8 0/6] arm_ffa, KVM: Fix FF-A emad offset calculations

by Sebastian Ene

Hi all, This series fixes the Endpoint Memory Access Descriptor (EMAD) offset calculations and adds the necessary bounds checks for both the core FF-A driver and the pKVM hypervisor. Prior to FF-A version 1.1, the memory region header didn't specify an explicit offset for the EMADs, leading to the assumption that they immediately follow the header. However, from v1.1 onwards, the specification dictates using the ep_mem_offset` field to determine the start of the memory access array. The patches in this series address this by: 1. Updating the core `arm_ffa` firmware driver to correctly calculate the descriptor offset using `ep_mem_offset` rather than defaulting to `sizeof(struct ffa_mem_region)`. It also introduces bounds checking against `max_fragsize`. 2. Enhancing the pKVM hypervisor validation logic to no longer strictly enforce that the descriptor strictly follows the header, aligning it with the driver behavior and the FF-A specification, while also ensuring the offset falls within the mailbox buffer bounds. While addressing these bugs, Sashiko uncovered other issues that were fixed in the same series. All the patches aside from the first one in optee are urgent fixes as they either impact the hypervisor security or kernel stability. Changelog ######### v7->v8: - dropped the patch "optee: ffa: Add NULL check in optee_ffa_lend_protmem" from the series as it was queued by Jens - rephrased the commit message for "KVM: arm64: Ensure FFA ranges are page aligned" - introduced a helper macro to get the size of the ffa memory region based on the used version. v6->v7: - taking the patches from Mostafa and sending a new version with the collected tags - Added overflow checks when doing `ep_offset + emad_size` in the arm ff-a driver - Move the length check before the ffa_mem_reclaim - fix compatibility break with ff-a version 1.0 reported by Sashiko - add one more patch to fix an issue with the FFA_VERSION call that can lead to leaking pKVM stack un-initialized data to a host when -ftrivial-auto-var-init=zero is not used. v5->v6: - Add fixes tag - Small clean up make variable declaration reverse christmas tree. v4->v5: - Collect Sudeep Rbs - Add extra patch to check base address alignment. - Remove WARN_ONs in KVM code - Use ffa_emad_size_get() instead of hardcoded size in KVM code. v3 -> v4: - Address review comments and fix Sashiko bugs v2 -> v3: - Fixed typo in nvhe/ffa.c (missing sizeof) v1 -> v2: - For pKVM, removed the strict placement enforcement for `ep_mem_offset` as it is not compliant with the spec, and avoids making assumptions about the driver's memory layout. Link to: ######## v6: https://lore.kernel.org/all/20260527150236.1978655-1-smostafa@google.com/ v5: https://lore.kernel.org/all/20260526151934.3783707-1-smostafa@google.com/ v4: https://lore.kernel.org/all/20260520204948.2440882-1-smostafa@google.com/ v3: https://lore.kernel.org/all/20260512124442.1899107-1-sebastianene@google.co… v2: https://lore.kernel.org/all/20260430160241.1934777-1-sebastianene@google.co… v1: https://lore.kernel.org/all/ae9KN9nkOgDYJcGP@google.com/T/#t *** BLURB HERE *** Mostafa Saleh (3): firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() KVM: arm64: Fix bounds checking in do_ffa_mem_reclaim() KVM: arm64: Ensure FFA ranges are page aligned Sebastian Ene (3): firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation KVM: arm64: Validate the offset to the mem access descriptor KVM: arm64: Zero out the stack initialized data in the FFA handler arch/arm64/kvm/hyp/nvhe/ffa.c | 45 +++++++++++++++++++++---------- drivers/firmware/arm_ffa/driver.c | 25 +++++++++++------ include/linux/arm_ffa.h | 9 ++++++- 3 files changed, 56 insertions(+), 23 deletions(-) -- 2.55.0.rc0.799.gd6f94ed593-goog

2 days, 5 hours

1
6
0 0

[PATCH v1] tee: qcomtee: Drop unused assignment of platform_device_id driver data

by Uwe Kleine-König (The Capable Hub)

The driver explicitly sets the .driver_data member of struct platform_device_id to zero without relying on that value. Drop this unused assignment. While touching this array unify spacing and usage of commas and use a named initializer for .name for improved readability. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig(a)baylibre.com> --- Hello, while this is a cleanup that can stand on its own, it is also a preparation for a change to struct platform_device_id that requires that .driver_data isn't assigned by a list initializer. Best regards Uwe drivers/tee/qcomtee/call.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/tee/qcomtee/call.c b/drivers/tee/qcomtee/call.c index 0efc5646242a..4a597eeaf174 100644 --- a/drivers/tee/qcomtee/call.c +++ b/drivers/tee/qcomtee/call.c @@ -798,7 +798,12 @@ static void qcomtee_remove(struct platform_device *pdev) kfree(qcomtee); } -static const struct platform_device_id qcomtee_ids[] = { { "qcomtee", 0 }, {} }; +static const struct platform_device_id qcomtee_ids[] = { + { + .name = "qcomtee", + }, + { } +}; MODULE_DEVICE_TABLE(platform, qcomtee_ids); static struct platform_driver qcomtee_platform_driver = { base-commit: 8d6dbbbe3ba62de0a63e962ee004afb848c8e3ac -- 2.47.3

3 days, 7 hours

3
2
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE