OP-TEE September 2026

op-tee@lists.trustedfirmware.org

22 participants
15 discussions

[PATCH] tee: optee: ffa: support shared memory offsets on large-page kernels

by Mahantesh Salimath

OP-TEE FF-A memory objects use 4 KiB pages, while the kernel page size may be larger. Consequently, tee_shm->offset can be greater than or equal to FFA_PAGE_SIZE, but OP-TEE rejects such a value in internal_offs. Do not encode the excess page offset in offs_low/offs_high. Those fields describe the logical memref offset and are copied back into tee_param->shm_offs on return. Folding the page offset into them breaks parameter round trips when a memref is reused. They are also ignored by the OPTEE_RPC_CMD_SHM_ALLOC response path, which uses only global_id and internal_offs to construct the shared-memory mobj. Instead, start the FF-A descriptor at the 4 KiB page containing the shared buffer, the same approach as optee_fill_pages_list() in the SMC ABI. Store the remaining in-page offset in internal_offs and preserve shm_offs in offs_low/offs_high. This keeps internal_offs within the FF-A page size, maps RPC allocations at the correct address, and preserves normal memref offsets across repeated invocations. Tested on ARMv8-A with 64 KiB PAGE_SIZE. OP-TEE OS ran as a secure partition under Hafnium (SPMC) over FF-A. Verified registered shared memory with tee_shm->offset >= 4 KiB, memref reuse on the same TEEC_Operation, and RPC OPTEE_RPC_CMD_SHM_ALLOC (xtest regression 6007-6009). optee_hello_world, optee_aes, and xtest regression 1005, 1007, 1008, 4001-4003 and 6001-6003 also passed. Fixes: 4615e5a34b95 ("optee: add FF-A support") Acked-by: Liming Sun <limings(a)nvidia.com> Acked-by: James Hurley <jahurley(a)nvidia.com> Acked-by: Dave Thompson <davthompson(a)nvidia.com> Signed-off-by: Mahantesh Salimath <mahantesh(a)nvidia.com> --- drivers/tee/optee/ffa_abi.c | 66 +++++++++++++++++++++++++++++------ drivers/tee/optee/optee_msg.h | 4 +-- 2 files changed, 57 insertions(+), 13 deletions(-) diff --git a/drivers/tee/optee/ffa_abi.c b/drivers/tee/optee/ffa_abi.c index 633715b98625..2a37e4899dc6 100644 --- a/drivers/tee/optee/ffa_abi.c +++ b/drivers/tee/optee/ffa_abi.c @@ -187,6 +187,40 @@ static int optee_ffa_from_msg_param(struct optee *optee, return 0; } +/* + * OP-TEE FF-A memory objects use 4 KiB pages while the kernel page size may + * be larger, for example 64 KiB on arm64. The FF-A descriptor is registered + * from the 4 KiB page containing the start of the shared buffer, so + * internal_offs is the offset into that page. + */ +static void optee_ffa_set_internal_offs(struct optee_msg_param_fmem *fmem, + struct tee_shm *shm) +{ + size_t page_offs = tee_shm_get_page_offset(shm); + + BUILD_BUG_ON(PAGE_SIZE < FFA_PAGE_SIZE); + + fmem->internal_offs = page_offs & (FFA_PAGE_SIZE - 1); +} + +/* + * Keep shm_offs unchanged in offs_low/offs_high: it is returned to callers + * and may be reused for a subsequent invocation. + */ +static int optee_ffa_set_fmem_offsets(struct optee_msg_param_fmem *fmem, + struct tee_shm *shm, u64 shm_offs) +{ + optee_ffa_set_internal_offs(fmem, shm); + + fmem->offs_low = shm_offs; + fmem->offs_high = shm_offs >> 32; + /* Check that the entire offset could be stored. */ + if (fmem->offs_high != shm_offs >> 32) + return -EINVAL; + + return 0; +} + static int to_msg_param_ffa_mem(struct optee_msg_param *mp, const struct tee_param *p) { @@ -196,14 +230,8 @@ static int to_msg_param_ffa_mem(struct optee_msg_param *mp, TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT; if (shm) { - u64 shm_offs = p->u.memref.shm_offs; - - mp->u.fmem.internal_offs = shm->offset; - - mp->u.fmem.offs_low = shm_offs; - mp->u.fmem.offs_high = shm_offs >> 32; - /* Check that the entire offset could be stored. */ - if (mp->u.fmem.offs_high != shm_offs >> 32) + if (optee_ffa_set_fmem_offsets(&mp->u.fmem, shm, + p->u.memref.shm_offs)) return -EINVAL; mp->u.fmem.global_id = shm->sec_world_id; @@ -284,14 +312,30 @@ static int optee_ffa_shm_register(struct tee_context *ctx, struct tee_shm *shm, .nattrs = 1, }; struct sg_table sgt; + size_t page_offs; + size_t ffa_offs; + size_t ffa_size; int rc; + if (!num_pages) + return -EINVAL; + rc = optee_check_mem_type(start, num_pages); if (rc) return rc; - rc = sg_alloc_table_from_pages(&sgt, pages, num_pages, 0, - num_pages * PAGE_SIZE, GFP_KERNEL); + page_offs = tee_shm_get_page_offset(shm); + ffa_offs = round_down(page_offs, FFA_PAGE_SIZE); + ffa_size = num_pages * PAGE_SIZE - ffa_offs; + + /* + * Start the FF-A descriptor at the 4 KiB page containing the shared + * buffer, skipping unused leading 4 KiB pages when PAGE_SIZE is + * larger. Same approach as optee_fill_pages_list() in the SMC ABI. + * This leaves only page_offs & (FFA_PAGE_SIZE - 1) for internal_offs. + */ + rc = sg_alloc_table_from_pages(&sgt, pages, num_pages, ffa_offs, + ffa_size, GFP_KERNEL); if (rc) return rc; args.sg = sgt.sgl; @@ -458,8 +502,8 @@ static void handle_ffa_rpc_func_cmd_shm_alloc(struct tee_context *ctx, .attr = OPTEE_MSG_ATTR_TYPE_FMEM_OUTPUT, .u.fmem.size = tee_shm_get_size(shm), .u.fmem.global_id = shm->sec_world_id, - .u.fmem.internal_offs = shm->offset, }; + optee_ffa_set_internal_offs(&arg->params[0].u.fmem, shm); arg->ret = TEEC_SUCCESS; } diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h index 7d9b12e71c03..6c3043f8da33 100644 --- a/drivers/tee/optee/optee_msg.h +++ b/drivers/tee/optee/optee_msg.h @@ -136,8 +136,8 @@ struct optee_msg_param_rmem { * struct optee_msg_param_fmem - FF-A memory reference parameter * @offs_low: lower bits of offset into shared memory reference * @offs_high: higher bits of offset into shared memory reference - * @internal_offs: internal offset into the first page of shared memory - * reference + * @internal_offs: offset into the first 4 KiB page of the FF-A shared + * memory region * @size: size of the buffer * @global_id: global identifier of the shared memory */ -- 2.43.0

1 week, 3 days

[PATCH RESEND] tee: move tee_ioctl_shm_register_data to above IOCTL definition

by Andrew Davis

Most of the struct definitions for a given IOCTL definition immediately preceded that definition. The struct tee_ioctl_shm_register_data is an exception as it is placed above the TEE_IOC_SHM_REGISTER_FD definition, not the TEE_IOC_SHM_REGISTER one it is to be used with. Move it down to match the others. This is a non-functional change for consistency and to help prevent someone from accidentally using the wrong struct with the wrong IOCTL based on the struct's location. Fix a couple small spelling issues while here. Signed-off-by: Andrew Davis <afd(a)ti.com> --- Resending using folks updated emails :) include/uapi/linux/tee.h | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/include/uapi/linux/tee.h b/include/uapi/linux/tee.h index 5203977ed35d1..76815b0f4b665 100644 --- a/include/uapi/linux/tee.h +++ b/include/uapi/linux/tee.h @@ -384,24 +384,6 @@ struct tee_iocl_supp_send_arg { #define TEE_IOC_SUPPL_SEND _IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + 7, \ struct tee_ioctl_buf_data) -/** - * struct tee_ioctl_shm_register_data - Shared memory register argument - * @addr: [in] Start address of shared memory to register - * @length: [in/out] Length of shared memory to register - * @flags: [in/out] Flags to/from registration. - * @id: [out] Identifier of the shared memory - * - * The flags field should currently be zero as input. Updated by the call - * with actual flags as defined by TEE_IOCTL_SHM_* above. - * This structure is used as argument for TEE_IOC_SHM_REGISTER below. - */ -struct tee_ioctl_shm_register_data { - __u64 addr; - __u64 length; - __u32 flags; - __s32 id; -}; - /** * struct tee_ioctl_shm_register_fd_data - Shared memory registering argument * @fd: [in] File descriptor identifying dmabuf reference @@ -426,13 +408,31 @@ struct tee_ioctl_shm_register_fd_data { * Returns a file descriptor on success or < 0 on failure * * The returned file descriptor refers to the shared memory object in the - * kernel. The supplied file deccriptor can be closed if it's not needed + * kernel. The supplied file descriptor can be closed if it's not needed * for other purposes. The shared memory is freed when the descriptor is * closed. */ #define TEE_IOC_SHM_REGISTER_FD _IOWR(TEE_IOC_MAGIC, TEE_IOC_BASE + 8, \ struct tee_ioctl_shm_register_fd_data) +/** + * struct tee_ioctl_shm_register_data - Shared memory register argument + * @addr: [in] Start address of shared memory to register + * @length: [in/out] Length of shared memory to register + * @flags: [in/out] Flags to/from registration. + * @id: [out] Identifier of the shared memory + * + * The flags field should currently be zero as input. Updated by the call + * with actual flags as defined by TEE_IOCTL_SHM_* above. + * This structure is used as argument for TEE_IOC_SHM_REGISTER below. + */ +struct tee_ioctl_shm_register_data { + __u64 addr; + __u64 length; + __u32 flags; + __s32 id; +}; + /** * TEE_IOC_SHM_REGISTER - Register shared memory argument * @@ -440,7 +440,7 @@ struct tee_ioctl_shm_register_fd_data { * * Returns a file descriptor on success or < 0 on failure * - * The shared memory is unregisterred when the descriptor is closed. + * The shared memory is unregistered when the descriptor is closed. */ #define TEE_IOC_SHM_REGISTER _IOWR(TEE_IOC_MAGIC, TEE_IOC_BASE + 9, \ struct tee_ioctl_shm_register_data) -- 2.39.2

1 week, 3 days

[PATCH 0/2] Add TPM support via Qualcomm TEE TPM TA

by Kuldeep Singh

Qualcomm platforms with a discrete TPM (dTPM) talked to it directly over a non-secure SPI channel from the kernel. Arm's Base Boot Security Requirements (BBSR) v1.4 require that access to go through TrustZone instead, so on affected Qualcomm platforms the TPM 2.0 instance is now fronted by a Trusted Application (TA) running inside Qualcomm's Trusted Execution Environment (QTEE), which talks to the dTPM (or implements an fTPM) on the kernel's behalf. This series adds a kernel driver for that TA, built on the QCOMTEE object-IPC transport (drivers/tee/qcomtee/) already used to reach other QTEE services. This patch series functionally depends on below(patch 5/6 specifically) for qtee service discovery. - https://lore.kernel.org/lkml/20260722-qcom_uefisecapp_migrate_qcomtee-v2-0-… Tested on Glymur-crd target with tpm2-tools utility. Validations: - Get capabilities - Random number generator - RSA key creation, encryption and decryption. Signed-off-by: Kuldeep Singh <kuldeep.singh(a)oss.qualcomm.com> --- Kuldeep Singh (2): tee: qcomtee: Register qcom.tz.tpm service for discovery firmware: tpm: Introduce tpm-qcom driver MAINTAINERS | 7 + drivers/char/tpm/Kconfig | 9 + drivers/char/tpm/Makefile | 1 + drivers/char/tpm/tpm_qcom.c | 371 ++++++++++++++++++++++++++++++++++++++ drivers/char/tpm/tpm_qcom.h | 82 +++++++++ drivers/tee/qcomtee/call.c | 4 +- drivers/tee/qcomtee/qcomtee_msg.h | 2 + 7 files changed, 475 insertions(+), 1 deletion(-) --- base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e change-id: 20260831-tpm_qcom_driver-d21c720e73b2 prerequisite-change-id: 20260408-qcom_uefisecapp_migrate_qcomtee-13869d45e014:v2 prerequisite-patch-id: 4dc81445c9baf36f420da8c2e2bed96e71b31a5b prerequisite-patch-id: b487dfe2fbc076f4815dc6c73b9e68b0b78c961f prerequisite-patch-id: c5df2b3696520a96f95b2d3535ed84cdc21cc315 prerequisite-patch-id: bbdd5327c15aeaa99ce9b74bab324a98f084ed48 prerequisite-patch-id: 07d9c4e9fe9fd61f60e3f35b30b9d81716f0734c prerequisite-patch-id: 10ff88d87586f21f3cff3f72dbd21c27adbfbbcc Best regards, -- Kuldeep Singh <kuldeep.singh(a)oss.qualcomm.com>

1 week, 3 days

[RFC PATCH v1 0/6] tee: optee: RISC-V support over the RPMI TEE service group

by marouene.boubakri＠oss.nxp.com

From: Marouene Boubakri <marouene.boubakri(a)oss.nxp.com> On RISC-V, OP-TEE runs as a supervisor domain isolated from Linux by the M-mode firmware. There is no SMC or HVC instruction: the firmware has to switch the calling hart between the two domains, and the way Linux asks for that switch has to come from the RISC-V specifications rather than from an ad-hoc SBI extension. This series adds RISC-V support to the OP-TEE driver by carrying the existing SMC ABI over the TEE service group of the RISC-V Platform Management Interface (RPMI) [1], sent with the SBI Message Proxy (MPXY) extension of SBI v3.0 [2] through the in-tree MPXY mailbox driver. Each invocation of the SMC ABI becomes a TEE_CALL request whose service data holds the register arguments a0-a7, and whose service response holds the return values a0-a3. The M-mode firmware implementing the service group (the "RPMI TEE framework") switches the calling hart to the OP-TEE domain until OP-TEE responds, so a TEE_CALL behaves like an SMC: it runs on the calling hart and returns when OP-TEE completes the call, requests an RPC or yields on a foreign interrupt. The SMC ABI, the message protocol, RPCs, dynamic and static shared memory and notifications are unchanged, which is why the conduit lives next to the SMCCC one in smc_abi.c instead of being a new ABI like ffa_abi.c. Specification status, and how the series is split: The TEE service group (SERVICEGROUP_ID 0x0010) is part of RPMI v2.0, which is in development: it was added to the main branch of the specification repository in June 2026 [3] and is not in the released RPMI v1.0. Everything in this series that depends on it is kept in the last three patches, which are RFC until RPMI v2.0 is frozen as required by Documentation/arch/riscv/patch-acceptance.rst: - patches 1-3 only rely on SBI v3.0 MPXY and RPMI v1.0 as already supported by the kernel, and on existing OP-TEE driver internals. They are meant to be mergeable on their own; - patches 4-6 add the RPMI v2.0 TEE service group definitions, the binding and the conduit. They implement TEE_CALL as specified; the only OP-TEE specific parts are the content of the service data and service response, which the specification leaves to the service, and the OP-TEE API UID used as service UUID. Why this conduit rather than the alternatives: - A raw ecall to a "TEE" SBI extension, as used by the current OP-TEE OS RISC-V port and by the RISE reference firmware, relies on an EID that does not exist in the SBI specification and on returning four values from an ecall, which the SBI calling convention does not allow. - The RPMI MANAGEMENT_MODE service group (RPMI v1.0) is defined for UEFI PI Management Mode communication and its data is the MM communication buffer; carrying the OP-TEE message protocol in it would go against the specification's intent and collide with its intended users. - An implementation specific service group (0x8000-0xFFFF) is allowed by RPMI v1.0 but would not be a generic OP-TEE conduit. The one non-obvious part is patch 1. An MPXY message send is an ecall on the calling hart, using per-hart shared memory, which returns once the message has been processed. With TEE_CALL that is when OP-TEE has finished running on that hart, which can take an arbitrarily long time. Sending such messages with mbox_send_message() would execute OP-TEE from within msg_submit() with the mailbox channel spinlock held and interrupts disabled, serializing every hart on that lock. Patch 1 adds riscv_sbi_mpxy_mbox_call() to the MPXY mailbox driver, which performs the transfer directly in the calling context with only local interrupts disabled (the per-hart shared memory is also used from hard interrupt context by mbox_send_message() users). Harts proceed in parallel since each one has its own shared memory. The channel is still requested through the mailbox core so that its ownership is tracked. Opinions on whether this belongs in the MPXY driver, or whether the MPXY shared memory handling should move to a core helper usable by several drivers, are welcome. Endpoint identifiers: the framework assigns an identifier to every REE and TEE. The only way for an endpoint to learn them without firmware help is the optional TEE_PROBE_SYSTEM service, whose response is CBOR encoded and cannot be parsed in the kernel, so the binding carries the REE and OP-TEE identifiers as properties that the firmware is expected to fix up in the device tree. Feedback on this is welcome too. Known gaps: - The framework side (OpenSBI: TEE_CALL forwarding through domain context switching) and the messaging return path of the OP-TEE OS RISC-V port are being upstreamed separately. - The service group defines no notification events; OP-TEE asynchronous notifications on RISC-V are left for later and OP-TEE OS does not advertise them on this conduit. - The byte order of the SERVICE UUID field is not specified by RPMI; this series uses the RFC 4122 order. The memory parcel services of the service group are not used, secure world accesses registered pages directly as with the SMC conduit. Testing: built for riscv64 (defconfig plus TEE/OP-TEE, both built-in and as modules) and for arm64 (defconfig plus OP-TEE and FF-A) with W=1 at every step of the series, plus dt_binding_check. [TODO before posting: describe the runtime testing done on QEMU virt with the OpenSBI and OP-TEE OS changes mentioned above, e.g. xtest results.] [1] https://github.com/riscv-non-isa/riscv-rpmi/releases [2] https://github.com/riscv-non-isa/riscv-sbi-doc/releases [3] https://github.com/riscv-non-isa/riscv-rpmi/commits/main/src/srvgrp-tee.adoc Marouene Boubakri (6): mailbox: riscv-sbi-mpxy: add riscv_sbi_mpxy_mbox_call() for hart-local requests tee: optee: select the SMC ABI conduit from the firmware node match data tee: optee: teach the memory type check about RISC-V page attributes mailbox: riscv-rpmi-message: add TEE service group definitions dt-bindings: firmware: add OP-TEE over the RISC-V RPMI TEE service group tee: optee: add a RISC-V conduit over the RPMI TEE service group .../bindings/firmware/linaro,optee-rpmi.yaml | 79 +++++++ Documentation/tee/op-tee.rst | 18 +- MAINTAINERS | 2 + drivers/mailbox/riscv-sbi-mpxy-mbox.c | 60 ++++++ drivers/tee/Kconfig | 2 +- drivers/tee/optee/Kconfig | 11 +- drivers/tee/optee/Makefile | 1 + drivers/tee/optee/call.c | 8 + drivers/tee/optee/optee_private.h | 3 + drivers/tee/optee/optee_rpmi.h | 69 ++++++ drivers/tee/optee/rpmi_conduit.c | 203 ++++++++++++++++++ drivers/tee/optee/smc_abi.c | 41 +++- include/linux/mailbox/riscv-rpmi-message.h | 25 +++ include/linux/mailbox/riscv-sbi-mpxy-mbox.h | 23 ++ 14 files changed, 538 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/firmware/linaro,optee-rpmi.yaml create mode 100644 drivers/tee/optee/optee_rpmi.h create mode 100644 drivers/tee/optee/rpmi_conduit.c create mode 100644 include/linux/mailbox/riscv-sbi-mpxy-mbox.h base-commit: 50d05c7c76c96b90462f24debacca971d2e86713 -- 2.43.0

1 week, 4 days

[PATCH v9 00/10] arm64: Unmap FF-A lent memory from direct map

by Vincent Donnefort

This series is a follow-up to the discussion that has started here [1]. While standalone, it also provides primitives reusable for the VPR DMA heap. When memory is lent to the Secure world via FF-A, CPU speculative accesses from NS to the lent pages can still occur as long as it retains a cacheable mapping to it. Ideally, lent memory would be "no-map" but that would mean giving up MiBs of useful memory, so let's try to do better with the help of a CMA pool. On arm64, modifying the direct map at runtime is generally restricted because the linear map defaults to block mapping and splitting blocks at runtime may trigger fatal page fault, unless the CPU implements BBML3 or the entire direct map was mapped at page granularity from boot. Forcing last-level mappings system-wide incurs a severe penalty we want to avoid. Instead, this series introduces targeted last-level mappings for designated memory regions, along with the "arm,ffa-lend-pool" CMA driver to manage unmapping and remapping on lend/reclaim transitions: 1. memblock & OF reserved memory ("ll-map"): - Introduce MEMBLOCK_LLMAP and the DT "ll-map" property for reserved-memory nodes to force last-level (PTE) mappings only for a specific region. 2. set_memory infrastructure: - Introduce can_set_direct_map_range() to check if a specific address range is mapped with last-level entries and can be modified safely. - Introduce __set_direct_map_*() variants that bypass redundant checks when the caller has already validated the range. 3. "arm,ffa-lend-pool" driver - Introduce the "arm,ffa-lend-pool" CMA reserved-memory driver, which unmaps pages prior to lending (ffa_prepare_lend()) and restores them when reclaimed (ffa_lend_reclaimed()). 4. Optee support - Hook OP-TEE dynamic protected memory pools to "arm,ffa-lend-pool" for both SMC (via DT memory-region phandle) and FF-A (via ffa_lend_pool_attach()) transports. Testing: ======== Tested with QEMU v8 using OP-TEE OS (built with CFG_CORE_DYN_PROTMEM=y) under both SMC and FF-A transports [2] static void dump_direct_map(const char *label) { printf("\n=== %s ===\n", label); fflush(stdout); system("sed -n '/Linear Mapping start/,/Linear Mapping end/p' /sys/kernel/debug/kernel_page_tables"); fflush(stdout); } int main(int argc, char *argv[]) { int heap_fd; int dmabuf_fd; struct dma_heap_allocation_data data = { 0 }; size_t size = 1024 * 1024; /* 1MB */ if (argc > 1) size = strtoul(argv[1], NULL, 0); dump_direct_map("BEFORE ALLOCATION"); heap_fd = open("/dev/dma_heap/protected,secure-video", O_RDWR); if (heap_fd < 0) { perror("open /dev/dma_heap/protected,secure-video"); return 1; } printf("\nOpened /dev/dma_heap/protected,secure-video\n"); printf("Allocating %zu bytes of protected memory via DMA heap...\n", size); data.len = size; data.fd_flags = O_RDWR | O_CLOEXEC; if (ioctl(heap_fd, DMA_HEAP_IOCTL_ALLOC, &data) < 0) { perror("ioctl DMA_HEAP_IOCTL_ALLOC"); close(heap_fd); return 1; } dmabuf_fd = data.fd; printf("Successfully allocated %zu bytes! dmabuf_fd = %d\n", size, dmabuf_fd); dump_direct_map("DURING LEND (EXPECT HOLE IN DIRECT MAP)"); printf("\nReleasing dmabuf_fd...\n"); close(dmabuf_fd); close(heap_fd); dump_direct_map("AFTER RECLAIM (RESTORED DIRECT MAP)"); return 0; } [1] https://lore.kernel.org/all/20260807-tegra-vpr-v4-7-5510d16af89e@nvidia.com/ [2] https://optee.readthedocs.io/en/latest/building/gits/build.html#qemu-v8 Vincent Donnefort (10): memblock: Introduce MEMBLOCK_LLMAP of: reserved_mem: Introduce "ll-map" property set_memory.h: Introduce can_set_direct_map_range() set_memory.h: Introduce __set_direct_map*() arm64: can_set_direct_map() if BBML3 arm64: Implement can_set_direct_map_range() arm64: Implement __set_direct_map*() arm64: Add support for MEMBLOCK_LLMAP firmware: arm_ffa: Introduce ffa-lend-pool optee: Add support for arm,ffa-lend-pool arch/arm64/include/asm/set_memory.h | 7 + arch/arm64/mm/mmu.c | 23 ++- arch/arm64/mm/pageattr.c | 67 +++++++- drivers/firmware/arm_ffa/Kconfig | 5 + drivers/firmware/arm_ffa/Makefile | 1 + drivers/firmware/arm_ffa/lend_pool.c | 223 +++++++++++++++++++++++++++ drivers/of/of_reserved_mem.c | 104 ++++++++++--- drivers/tee/optee/ffa_abi.c | 13 +- drivers/tee/optee/protmem.c | 8 - drivers/tee/optee/smc_abi.c | 17 +- drivers/tee/tee_shm.c | 11 +- include/linux/arm_ffa.h | 21 +++ include/linux/memblock.h | 9 ++ include/linux/set_memory.h | 39 +++++ mm/memblock.c | 50 ++++++ 15 files changed, 545 insertions(+), 53 deletions(-) create mode 100644 drivers/firmware/arm_ffa/lend_pool.c base-commit: cee9395acd8043be0644b25c34bfa86623f2b935 -- 2.55.0.970.g62bdec98f9-goog

1 week, 5 days

2026

2025

2024

2023

2022

2021

2020

OP-TEE September 2026