[PATCH v2 0/3] ACPI: arm64: FFH Operation Region support for FF-A (offset 2)

[Sudeep Holla]

On Tue, Sep 01, 2026 at 12:29:03PM -0700, Jamie Nguyen wrote:
> Arm DEN0048D (Functional Fixed Hardware Specification v1.3), published in
> March 2026, adds a third FFH Operation Region flavour:
> 
>   https://developer.arm.com/documentation/den0048/latest/
> 
> An Operation Region declared with an Offset of 0x2 triggers an
> FFA_MSG_SEND_DIRECT_REQ2 call instead of a bare SMC or HVC:
> 
>   OperationRegion (AFFH, FFixedHW, 2, 40)
>   Field (AFFH, BufferAcc, NoLock, Preserve) { FFAD, 320 }
> 
> Each 64-bit field is one register, ordered from X0. X0 carries the call
> status on return, X1[15:0] the receiver endpoint ID (or zero, which asks
> OSPM to resolve it from the UUID), X2-X3 the service UUID written with
> ToUUID(), and X4-X17 the payload. The region Length is 32 + 8 * N bytes
> with 1 <= N <= 14, so X0-X4 at minimum and X0-X17 at most.
> 
> The spec recommends offset 0x2 for new platforms on the grounds that not
> every OSPM implements offsets 0x0 and 0x1. Linux has had both since v6.2
> but nothing for 0x2, so AML using the recommended encoding currently gets
> AE_ERROR back.
> 
> These patches implement it. I could not find any prior posting of this on
> linux-acpi or linux-arm-kernel, so apologies if I have missed one and
> duplicated someone's work.
> 
> All three patches are co-developed with Dat Mach.
> 
> Design
> ------
> 
> drivers/acpi/arm64/ffh.c holds the DEN0048D side: region length
> validation, the X0-X17 layout, the ToUUID() to FF-A UUID byte order
> conversion, and the table 3 status codes. drivers/firmware/arm_ffa/ holds
> the FF-A side: resolving a service UUID to an endpoint, and the call
> itself, including the FFA_YIELD and FFA_INTERRUPT re-invocation DEN0048D
> asks for.
>

I have concerns regarding the new dependency on the FF-A driver.

Could you clarify how the build and runtime behavior are protected when the
FF-A driver is disabled? The current patchset introduces a strict dependency
without explicit configuration checks or guards, which will likely cause
compilation or execution failures in environments where FF-A is not enabled.

> The two talk through an ops structure the FF-A driver registers rather
> than a direct call, because ffh.c is built in under a bool Kconfig symbol
> while CONFIG_ARM_FFA_TRANSPORT is a tristate. Unregistration takes the
> rwsem for writing, so it cannot race with an access already in flight.
> 

We need to explicitly document the reasons for establishing a hard dependency
between the ACPI FFH and the FF-A driver. In my view, this FFH mechanism (0x2)
simply issues an SMC call with the FFA_MSG_SEND_DIRECT_REQ2 FID. While I
understand the specification assigns extra responsibility to the OSPM to
populate the partition ID, are there any other technical justifications for
this tight coupling?

> None of what the handler needs was reachable through the existing
> ffa_device interface. ffa_sync_send_receive2() always addresses
> dev->vm_id, so a receiver endpoint ID supplied by AML cannot be honoured.
> UUID to endpoint resolution had no in-kernel user at all. And
> ffa_msg_send_direct_req2() throws away the response registers DEN0048D
> wants copied back to AML. Patch 1 splits those out, leaving what existing
> callers see unchanged.
>

I see above as one reason why they need to be separate.

> Testing
> -------
> 
> Built on arm64 with CONFIG_ACPI_FFH=y and CONFIG_ARM_FFA_TRANSPORT both =y
> and =m, and with CONFIG_ACPI_FFH=n, W=1 clean. Every patch builds on its
> own.
> 

How about CONFIG_ARM_FFA_TRANSPORT=n and CONFIG_ACPI_FFH=y ? Is that
blocked in someway I am failing to see ?

-- 
Regards,
Sudeep