linux/drivers/firmware/arm_ffa, branch master

Merge tag 'soc-drivers-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

2026-04-17T03:34:34Z

Pull SoC driver updates from Arnd Bergmann: "The driver updates again are all over the place with many minor fixes going into platform specific code. The most notable changes are: - Support for Microchip pic64gx system controllers - Work on cleaning up devicetree bindings for SoC drivers, and converting them into the new format - Lots of smaller changes for Qualcomm SoC drivers, including support for a number of newly supported chips - reset controller API cleanups and a new driver for Cix Sky1 - Reworks of the Tegra PMC and CBB drivers, along with a change to how individual Tegra SoCs get selected in Kconfig and BPMP firmware driver updates including a refresh of the ABI header to match the version used by firmware - STM32 updates to the firewall bus driver and support for the debug bus through OP-TEE - SCMI firmware driver improvements for reliability, in particular for dealing with broken firmware interrupts - Memory driver updates for Tegra, and a patch to remove the unused Baikal T1 driver" * tag 'soc-drivers-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (193 commits) firmware: arm_ffa: Use the correct buffer size during RXTX_MAP firmware: qcom: scm: Allow QSEECOM on Lenovo IdeaCentre Mini X clk: spear: fix resource leak in clk_register_vco_pll() reset: rzv2h-usb2phy: Add support for VBUS mux controller registration reset: rzv2h-usb2phy: Convert to regmap API dt-bindings: reset: renesas,rzv2h-usb2phy: Document RZ/G3E USB2PHY reset dt-bindings: reset: renesas,rzv2h-usb2phy: Add '#mux-state-cells' property soc: microchip: add mpfs gpio interrupt mux driver dt-bindings: soc: microchip: document PolarFire SoC's gpio interrupt mux gpio: mpfs: Add interrupt support soc: qcom: ubwc: add helpers to get programmable values soc: qcom: ubwc: add helper to get min_acc length firmware: qcom: scm: Register gunyah watchdog device soc: qcom: socinfo: Add SoC ID for SA8650P dt-bindings: arm: qcom,ids: Add SoC ID for SA8650P firmware: qcom: scm: Allow QSEECOM on Mahua CRD soc: qcom: wcnss: simplify allocation of req soc: qcom: pd-mapper: Add support for Eliza soc: qcom: aoss: compare against normalized cooling state soc: qcom: llcc: fix v1 SB syndrome register offset ...

firmware: arm_ffa: Use the correct buffer size during RXTX_MAP

2026-04-07T09:47:42Z

Don't use the discovered buffer size from an FFA_FEATURES call directly since we can run on a system that has the PAGE_SIZE larger than the returned size which makes the alloc_pages_exact for the buffer to be rounded up. Fixes: 61824feae5c0 ("firmware: arm_ffa: Fetch the Rx/Tx buffer size using ffa_features()") Signed-off-by: Sebastian Ene Link: https://patch.msgid.link/20260402113939.930221-1-sebastianene@google.com Signed-off-by: Sudeep Holla

firmware: arm_ffa: Remove vm_id argument in ffa_rxtx_unmap()

2026-03-06T16:26:08Z

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

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51Z

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28Z

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

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

2025-12-18T14:22:07Z

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

firmware: arm_ffa: Tie FF-A version checks to specific features

2025-12-15T10:31:15Z

The FF-A driver currently performs loose comparisons when checking the supported FF-A feature, which can inadvertently treat future or intermediate revisions as compatible. Replace generic `version {>,<} FFA_VERSION_1_*` pattern checks with feature-specific macros that clearly express which functionality depends on FF-A versioning. This improves readability and future maintainability by tying each feature (e.g. GET_COUNT_ONLY, size/UUID/exec state in responses) to explicit version requirements instead of relying on generic version comparisons. This improves robustness and clarity as the FF-A specification evolves. No functional change, only improves code readability. Message-Id: <20251016094111.946236-1-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla

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

2025-12-15T10:31:15Z

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

firmware: arm_ffa: Add support for IMPDEF value in the memory access descriptor

2025-10-13T09:34:46Z

FF-A v1.2 introduced 16 byte IMPLEMENTATION DEFINED value in the endpoint memory access descriptor to allow any sender could to specify an its any custom value for each receiver. Also this value must be specified by the receiver when retrieving the memory region. The sender must ensure it informs the receiver of this value via an IMPLEMENTATION DEFINED mechanism such as a partition message. So the FF-A driver can use the message interfaces to communicate the value and set the same in the ffa_mem_region_attributes structures when using the memory interfaces. The driver ensure that the size of the endpoint memory access descriptors is set correctly based on the FF-A version. Fixes: 9fac08d9d985 ("firmware: arm_ffa: Upgrade FF-A version to v1.2 in the driver") Reported-by: Lixiang Mao Tested-by: Lixiang Mao Message-Id: <20250923150927.1218364-1-sudeep.holla@arm.com> Signed-off-by: Sudeep Holla

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

2025-07-22T23:23:18Z

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