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

[Jamie Nguyen <jamien@nvidia.com>]

On Wed, Sep 23, 2026 at 02:38:28PM +0100, Sudeep Holla wrote:
> 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.

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?

[...]
> +	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));