kernel/linux.git/drivers/firmware/arm_ffa, branch v6.12.80

firmware: arm_ffa: Remove vm_id argument in ffa_rxtx_unmap()

2026-03-25T10:08:51+00:00

[ Upstream commit a4e8473b775160f3ce978f621cf8dea2c7250433 ] According to the FF-A specification (DEN0077, v1.1, §13.7), when FFA_RXTX_UNMAP is invoked from any instance other than non-secure physical, the w1 register must be zero (MBZ). If a non-zero value is supplied in this context, the SPMC must return FFA_INVALID_PARAMETER. The Arm FF-A driver operates exclusively as a guest or non-secure physical instance where the partition ID is always zero and is not invoked from a hypervisor context where w1 carries a VM ID. In this execution model, the partition ID observed by the driver is always zero, and passing a VM ID is unnecessary and potentially invalid. Remove the vm_id parameter from ffa_rxtx_unmap() and ensure that the SMC call is issued with w1 implicitly zeroed, as required by the specification. This prevents invalid parameter errors and aligns the implementation with the defined FF-A ABI behavior. Fixes: 3bbfe9871005 ("firmware: arm_ffa: Add initial Arm FFA driver support") Signed-off-by: Yeoreum Yun Message-Id: <20260304120953.847671-1-yeoreum.yun@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: arm_ffa: Unmap Rx/Tx buffers on init failure

2026-03-04T12:20:58+00:00

[ Upstream commit 9fda364cb78c8b9e1abe4029f877300c94655742 ] ffa_init() maps the Rx/Tx buffers via ffa_rxtx_map() but on the partition setup failure path it never unmaps them. Add the missing ffa_rxtx_unmap() call in the error path so that the Rx/Tx buffers are properly released before freeing the backing pages. Signed-off-by: Haoxiang Li Message-Id: <20251210031656.56194-1-lihaoxiang@isrc.iscas.ac.cn> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: arm_ffa: Correct 32-bit response handling in NOTIFICATION_INFO_GET

2026-03-04T12:19:41+00:00

[ Upstream commit be4d4543f78074fbebd530ba5109d39a2a34e668 ] The FF-A specification allows NOTIFICATION_INFO_GET to return either a 64-bit (FFA_FN64_SUCCESS) or a 32-bit (FFA_SUCCESS) response, depending on whether the firmware chooses the SMC64 or SMC32 calling convention. The driver previously detected the response format by checking ret.a0, but still interpreted the returned ID lists (x3..x17 or w3..w7) as if they always followed the 64-bit SMC64 layout. In the SMC32 case, the upper 32 bits of each argument register are undefined by the calling convention, meaning the driver could read stale or garbage values when parsing notification IDs. This resulted in incorrectly decoded partition/VCPU IDs whenever the FF-A firmware used an SMC32 return path. Fix the issue by: - Introducing logic to map list indices to the correct u16 offsets, depending on whether the response width matches the kernel word size or is a 32-bit response on a 64-bit kernel. - Ensuring that the packed ID list is parsed using the proper layout, avoiding reads from undefined upper halves in the SMC32 case. With this change, NOTIFICATION_INFO_GET now correctly interprets ID list entries regardless of the response width, aligning the driver with the FF-A specification. Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface") Reported-by: Sourav Mohapatra Message-Id: <20251218142001.2457111-1-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall

2025-08-20T16:30:19+00:00

[ Upstream commit 0e0546eabcd6c19765a8dbf5b5db3723e7b0ea75 ] The Linux IMA (Integrity Measurement Architecture) subsystem used for secure boot, file integrity, or remote attestation cannot be a loadable module for few reasons listed below: o Boot-Time Integrity: IMA’s main role is to measure and appraise files before they are used. This includes measuring critical system files during early boot (e.g., init, init scripts, login binaries). If IMA were a module, it would be loaded too late to cover those. o TPM Dependency: IMA integrates tightly with the TPM to record measurements into PCRs. The TPM must be initialized early (ideally before init_ima()), which aligns with IMA being built-in. o Security Model: IMA is part of a Trusted Computing Base (TCB). Making it a module would weaken the security model, as a potentially compromised system could delay or tamper with its initialization. IMA must be built-in to ensure it starts measuring from the earliest possible point in boot which inturn implies TPM must be initialised and ready to use before IMA. To enable integration of tpm_event_log with the IMA subsystem, the TPM drivers (tpm_crb and tpm_crb_ffa) also needs to be built-in. However with FF-A driver also being initialised at device initcall level, it can lead to an initialization order issue where: - crb_acpi_driver_init() may run before tpm_crb_ffa_driver()_init and ffa_init() - As a result, probing the TPM device via CRB over FFA is deferred - ima_init() (called as a late initcall) runs before deferred probe completes, IMA fails to find the TPM and logs the below error: | ima: No TPM chip found, activating TPM-bypass! Eventually it fails to generate boot_aggregate with PCR values. Because of the above stated dependency, the ffa driver needs to initialised before tpm_crb_ffa module to ensure IMA finds the TPM successfully when present. [ jarkko: reformatted some of the paragraphs because they were going past the 75 character boundary. ] Signed-off-by: Yeoreum Yun Reviewed-by: Mimi Zohar Reviewed-by: Sudeep Holla Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin

firmware: arm_ffa: Replace mutex with rwlock to avoid sleep in atomic context

2025-07-10T14:04:44+00:00

commit 9ca7a421229bbdfbe2e1e628cff5cfa782720a10 upstream. The current use of a mutex to protect the notifier hashtable accesses can lead to issues in the atomic context. It results in the below kernel warnings: | BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0 #4 | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn | Call trace: | show_stack+0x18/0x24 (C) | dump_stack_lvl+0x78/0x90 | dump_stack+0x18/0x24 | __might_resched+0x114/0x170 | __might_sleep+0x48/0x98 | mutex_lock+0x24/0x80 | handle_notif_callbacks+0x54/0xe0 | notif_get_and_handle+0x40/0x88 | generic_exec_single+0x80/0xc0 | smp_call_function_single+0xfc/0x1a0 | notif_pcpu_irq_work_fn+0x2c/0x38 | process_one_work+0x14c/0x2b4 | worker_thread+0x2e4/0x3e0 | kthread+0x13c/0x210 | ret_from_fork+0x10/0x20 To address this, replace the mutex with an rwlock to protect the notifier hashtable accesses. This ensures that read-side locking does not sleep and multiple readers can acquire the lock concurrently, avoiding unnecessary contention and potential deadlocks. Writer access remains exclusive, preserving correctness. This change resolves warnings from lockdep about potential sleep in atomic context. Cc: Jens Wiklander Reported-by: Jérôme Forissier Closes: https://github.com/OP-TEE/optee_os/issues/7394 Fixes: e0573444edbf ("firmware: arm_ffa: Add interfaces to request notification callbacks") Message-Id: <20250528-ffa_notif_fix-v1-3-5ed7bc7f8437@arm.com> Reviewed-by: Jens Wiklander Tested-by: Jens Wiklander Signed-off-by: Sudeep Holla Signed-off-by: Greg Kroah-Hartman

firmware: arm_ffa: Move memory allocation outside the mutex locking

2025-07-10T14:04:44+00:00

commit 27e850c88df0e25474a8caeb2903e2e90b62c1dc upstream. The notifier callback node allocation is currently done while holding the notify_lock mutex. While this is safe even if memory allocation may sleep, we need to move the allocation outside the locked region in preparation to move from using muxtes to rwlocks. Move the memory allocation to avoid potential sleeping in atomic context once the locks are moved from mutex to rwlocks. Fixes: e0573444edbf ("firmware: arm_ffa: Add interfaces to request notification callbacks") Message-Id: <20250528-ffa_notif_fix-v1-2-5ed7bc7f8437@arm.com> Reviewed-by: Jens Wiklander Signed-off-by: Sudeep Holla Signed-off-by: Greg Kroah-Hartman

firmware: arm_ffa: Fix memory leak by freeing notifier callback node

2025-07-10T14:04:44+00:00

[ Upstream commit a833d31ad867103ba72a0b73f3606f4ab8601719 ] Commit e0573444edbf ("firmware: arm_ffa: Add interfaces to request notification callbacks") adds support for notifier callbacks by allocating and inserting a callback node into a hashtable during registration of notifiers. However, during unregistration, the code only removes the node from the hashtable without freeing the associated memory, resulting in a memory leak. Resolve the memory leak issue by ensuring the allocated notifier callback node is properly freed after it is removed from the hashtable entry. Fixes: e0573444edbf ("firmware: arm_ffa: Add interfaces to request notification callbacks") Message-Id: <20250528-ffa_notif_fix-v1-1-5ed7bc7f8437@arm.com> Reviewed-by: Jens Wiklander Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: arm_ffa: Handle the presence of host partition in the partition info

2025-05-29T09:02:47+00:00

[ Upstream commit 2f622a8b0722d332a2a149794a3add47bc9bdcf3 ] Currently it is assumed that the firmware doesn't present the host partition in the list of partitions presented as part of the response to PARTITION_INFO_GET from the firmware. However, there are few platforms that prefer to present the same in the list of partitions. It is not manadatory but not restricted as well. So handle the same by making sure to check the presence of the host VM ID in the XArray partition information maintained/managed in the driver before attempting to add it. Tested-by: Viresh Kumar Message-Id: <20250217-ffa_updates-v3-7-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: arm_ffa: Reject higher major version as incompatible

2025-05-29T09:02:47+00:00

[ Upstream commit efff6a7f16b34fd902f342b58bd8bafc2d6f2fd1 ] When the firmware compatibility was handled previously in the commit 8e3f9da608f1 ("firmware: arm_ffa: Handle compatibility with different firmware versions"), we only addressed firmware versions that have higher minor versions compared to the driver version which is should be considered compatible unless the firmware returns NOT_SUPPORTED. However, if the firmware reports higher major version than the driver supported, we need to reject it. If the firmware can work in a compatible mode with the driver requested version, it must return the same major version as requested. Tested-by: Viresh Kumar Message-Id: <20250217-ffa_updates-v3-12-bd1d9de615e7@arm.com> Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: arm_ffa: Set dma_mask for ffa devices

2025-05-29T09:02:35+00:00

[ Upstream commit cc0aac7ca17e0ea3ca84b552fc79f3e86fd07f53 ] Set dma_mask for FFA devices, otherwise DMA allocation using the device pointer lead to following warning: WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124 Signed-off-by: Viresh Kumar Message-Id: Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin