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: Wed, 4 Nov 2026 09:01:29 -0800 [thread overview]
Message-ID: <20261104170129.27701-1-jamien@nvidia.com> (raw)
In-Reply-To: <20261104-poetic-durable-jaguar-cdf3ee@sudeepholla>
On Wed, Nov 04, 2026 at 09:40:08AM +0000, Sudeep Holla wrote:
> 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.
From the kernel side: the transport driver and ffh.c are the same FF-A
caller from firmware's point of view. Could a small built-in helper call
FFA_VERSION once, under a mutex, and keep the effective negotiated
version? Both would use it, with the transport's existing compatibility
handling, so it wouldn't matter which runs first.
I haven't been able to think of a clean solution for the bootloader
case, though. It looks like the same hole the transport already has
today, since the helper would negotiate the way ffa_version_check() does
now.
next prev parent reply other threads:[~2026-11-04 17:01 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
2026-11-04 9:40 ` Sudeep Holla
2026-11-04 17:01 ` Jamie Nguyen [this message]
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=20261104170129.27701-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.