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

[Jamie Nguyen <jamien@nvidia.com>]

On Tue, Sep 22, 2026 at 09:46:59AM +0100, Sudeep Holla wrote:
> Could you clarify how the build and runtime behavior are protected when
> the FF-A driver is disabled?

There is no build-time dependency from ACPI FFH to the FF-A driver. The
registration direction is from FF-A into FFH: the FF-A driver registers an
optional backend after probe and unregisters it on removal.

With CONFIG_ARM_FFA_TRANSPORT=n, no backend is registered and an offset 2
access returns FFH_FFA_NOT_SUPPORTED. With CONFIG_ACPI_FFH=n, the
registration functions are static inline stubs.

I have also built CONFIG_ACPI_FFH=y with CONFIG_ARM_FFA_TRANSPORT=n.
The W=1 build and full vmlinux link are clean, with no unresolved
references to the FF-A transport driver. I'll mention this case in the v3
cover letter.

> Are there any other technical justifications for this tight coupling?

FFA_MSG_SEND_DIRECT_REQ2 requires FF-A state already owned by the driver:
the selected SMC or HVC conduit, the sender endpoint ID from FFA_ID_GET,
UUID-to-endpoint resolution through the partition discovery ABIs, REQ2
feature detection, and FFA_RUN handling after FFA_YIELD or FFA_INTERRUPT.

Open-coding those operations in ffh.c would duplicate FF-A initialization
and state management. The ops registration lets FFH use that state when the
driver is available while degrading cleanly when it is not.