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 07:06:02PM +0100, Sudeep Holla wrote:
> Equally ugly. FF-A spec doesn't talk about ACPI FFH, so it doesn't
> belong in FF-A driver.

Okay -- I'll move the ACPI-specific handling into ffh.c.

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

You're right. With the current registration, offset 2 may be unavailable
during initial enumeration or before module load. That's not suitable for
AML.

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

The request itself is synchronous and register-only. But the whole operation
still shares FF-A state: version negotiation must be coordinated with other
FF-A use, and X1 == 0 needs UUID lookup. It looks like
FFA_PARTITION_INFO_GET_REGS is optional at the Non-secure physical instance
according to DEN0077A Table 13.1. As such, I believe a portable
implementation would need the shared RX/TX buffers. For example, if X1 is
zero and that ABI is unavailable, UUID lookup would need to fall back to
FFA_PARTITION_INFO_GET, whose results are returned through the caller's RX
buffer.