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

On Wed, Sep 23, 2026 at 10:32:40AM -0700, Jamie Nguyen wrote:

On Wed, Sep 23, 2026 at 02:38:28PM +0100, Sudeep Holla wrote:

quoted

I did try to come up something simpler and independent last evening and
this morning, far from completion and I am also thinking of 2 main changes
to it yet:
1. Maintain hash for receiver ID list
2. Drop the whole FFA_VERSION fuss as it must be dealt with in UEFI and
   that should be sufficient.

Of course not tested yet and even not sure this version is compile tested.

Thanks, this looks much simpler. I can confirm that both patches apply to
v7.3-rc4 and build W=1 clean with ARM_FFA_TRANSPORT=y, =m and =n. The =n
vmlinux also links with no transport-driver symbols pulled in.

Thanks for giving it a spin.

On FFA_VERSION: as written, if the transport driver has already mapped
its RX/TX buffers, I think DEN0077A R0216 has this negotiation return the
Null version, so offset 2 would report NOT_SUPPORTED for any AML run after
the driver probes. But if it's dropped, I don't think it's guaranteed that
a compatible version will have been negotiated by then, right?

Agreed, I need to think it through. I definitely want to avoid any usage of
Rx/Tx buffers here.

[...]

quoted

+	memcpy(&args.a4, &buf[4], len - 4 * sizeof(u64));

This would trip CONFIG_FORTIFY_SOURCE's field-spanning write check
whenever the region has more than one payload register. I think this would
cover that case:

	memcpy((void *)&args + offsetof(struct arm_smccc_1_2_regs, a4),
	       &buf[4], len - 4 * sizeof(u64));

Thanks, will update.

Which version of FF-A is being deployed on your platforms ? Just wondering
if we can set v1.3 as minimum required here and use query negotiated version
feature of FFA_VERSION. It is not a must, just checking if that might simplify
things.

-- 
Regards,
Sudeep