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

[Sudeep Holla]

On Tue, Sep 22, 2026 at 08:52:11AM -0700, Jamie Nguyen wrote:
> 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.
> 

Equally ugly. FF-A spec doesn't talk about ACPI FFH, so it doesn't
belong in FF-A driver.

> 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.
> 

So if on a platform, ASL has FFH with offset 2, we fail if FF-A driver fails
to initialise ? What if this FFH offset 2 is used in some other device
methods that need to be executed before FF-A module is inserted ? We pull
that device down as well ? Is that acceptable ?

> 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.
> 

Fair enough, build dependency was one of the concern and not the only
concern.

> > 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.
> 

Yes but are they strong reasons to break some use-case like above.

> 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.

There is no state management with simple FFA_MSG_SEND_DIRECT_REQ2, it is
synchronous send request if you look at it along wih offset 0/1 and without
FF-A driver knowledge.

I need to think apart from duplication, we shouldn't have much issue.

-- 
Regards,
Sudeep