[PATCH 2/2] ACPI: FFH: Support FF-A direct request 2 calls

[Sudeep Holla]

On Tue, Nov 03, 2026 at 01:11:36PM -0800, Jamie Nguyen wrote:
> On Tue, Nov 03, 2026 at 05:39:07PM +0000, Sudeep Holla wrote:
> [...]
> > +	if (!acpi_ffh_ffa_version_negotiated) {
> > +		args.a0 = FFA_VERSION;
> > +		args.a1 = FFA_VERSION_1_2;
> 
> Same question as on the earlier thread: how does this work if the
> transport driver has already negotiated a version?
> 

Handling this coordination is difficult, which prompted my earlier query about
requiring v1.3 as a baseline. On ACPI platforms, this initialization conflict
is already an inherent issue, as the UEFI or early bootloader might negotiate
a version before the kernel FF-A driver probes. I welcome any feedback or
proposals on how we might cleanly resolve or track this pre-negotiated state.

> [...]
> > +	ret = acpi_ffh_ffa_features(ffh_ctxt, FFA_PARTITION_INFO_GET_REGS);
> > +	if (ret)
> > +		goto out;
> 
> I think REGS is only needed when X1 is zero, and if I understand
> correctly it's optional at the Non-secure physical instance. Would it
> make sense to check it in the lookup path instead, so an explicit
> receiver ID still works without it?
> 

That is good point. I completely forgot why I didn't add this check in
the RFC patch. Thank you for catching it; I will make sure to include
the proper fallback implementation in the next revision.

> [...]
> > +	memcpy(&args.a4, &buf[4], len - 4 * sizeof(u64));
> 
> I believe this would trip FORTIFY_SOURCE's field-spanning write check.
> So I suggest:
> 
> 	memcpy((void *)&args + offsetof(struct arm_smccc_1_2_regs, a4),
> 	       &buf[4], len - 4 * sizeof(u64));


Apologies for the oversight, as I remember you pointing this out before. I was
rushing to get these patches sent out, but I will make sure it is corrected in
the next revision.

-- 
Regards,
Sudeep