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

[Sudeep Holla]

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

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