All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Nguyen <jamien@nvidia.com>
To: Sudeep Holla <sudeep.holla@kernel.org>
Cc: Jamie Nguyen <jamien@nvidia.com>, <linux-acpi@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Hanjun Guo <guohanjun@huawei.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Dat Mach <dmach@nvidia.com>
Subject: Re: [PATCH 2/2] ACPI: FFH: Support FF-A direct request 2 calls
Date: Tue, 3 Nov 2026 13:11:36 -0800	[thread overview]
Message-ID: <20261103211136.4122648-1-jamien@nvidia.com> (raw)
In-Reply-To: <20261103173907.1996118-3-sudeep.holla@kernel.org>

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?

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

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

  reply	other threads:[~2026-11-03 21:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03 17:39 [PATCH 0/2] ACPI: Arm FFH: Add support for OpRegion Offset 2 (FF-A DIRECT_REQ2) Sudeep Holla
2026-11-03 17:39 ` [PATCH 1/2] firmware: arm_ffa: Share FF-A register field definitions Sudeep Holla
2026-11-03 17:39 ` [PATCH 2/2] ACPI: FFH: Support FF-A direct request 2 calls Sudeep Holla
2026-11-03 21:11   ` Jamie Nguyen [this message]
2026-11-04  9:40     ` Sudeep Holla
2026-11-04 17:01       ` Jamie Nguyen
2026-11-03 22:53   ` Jonathan Cameron
2026-11-04 10:19     ` Sudeep Holla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261103211136.4122648-1-jamien@nvidia.com \
    --to=jamien@nvidia.com \
    --cc=catalin.marinas@arm.com \
    --cc=dmach@nvidia.com \
    --cc=guohanjun@huawei.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=lpieralisi@kernel.org \
    --cc=sudeep.holla@kernel.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.