[26.04_linux-nvidia] NVIDIA: SAUCE: ARM FF-A EC services on GB10 — DEN0077A v1.3 support - #575
Conversation
PR Validation ReportPatchscan ✅ No Missing FixesAll cherry-picked commits checked — no missing upstream fixes found. PR Lint ❌ Errors foundDetailsChecking 10 commits... Cherry-pick digest: ┌──────────────┬──────────────────────────────────────────────────────────────────┬────────────┬─────────┬───────────────────────────┐ │ Local │ Referenced upstream / Patch subject │ Patch-ID │ Subject │ SoB chain │ ├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤ │ a76283eece6f │ [SAUCE] platform/arm64: nvidia-ffa-ec: suppress driver bind/unbi │ N/A │ N/A │ abhsahu │ ├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤ │ 62c56d6df7c7 │ [SAUCE] platform/arm64: nvidia-ffa-ec: retry ffa send on transie │ N/A │ N/A │ abhsahu │ ├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤ │ 0167a0eef634 │ [SAUCE] platform/arm64: nvidia-ffa-ec: add oem ffa service uuids │ N/A │ N/A │ abhsahu │ ├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤ │ efef9d929b5d │ [SAUCE] platform/arm64: nvidia-ffa-ec: inline uuids in ffa_devic │ N/A │ N/A │ abhsahu │ ├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤ │ 11799ebeb01e │ [SAUCE] platform/arm64: nvidia-ffa-ec: remove acpi rescan workar │ N/A │ N/A │ abhsahu │ ├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤ │ 9c8eb0e45aea │ [SAUCE] platform/arm64: nvidia-ffa-ec: map aml cookies to physic │ N/A │ N/A │ abhsahu │ ├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤ │ 712b18073281 │ [SAUCE] acpi: battery: clear consumer dependencies after success │ N/A │ N/A │ abhsahu │ ├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤ │ 1ac565bc2ac2 │ [SAUCE] acpi: scan: add ff-a bridge hids to acpi_ignore_dep_ids[ │ N/A │ N/A │ abhsahu │ ├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤ │ d57cba359a9f │ [SAUCE] acpi / firmware / platform: probe arm ff-a early before │ N/A │ N/A │ abhsahu │ ├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤ │ f8e0f46081e1 │ [SAUCE] platform/arm64: nvidia-ffa-ec: add arml0002 / den0077a r │ N/A │ N/A │ abhsahu │ └──────────────┴──────────────────────────────────────────────────────────────────┴────────────┴─────────┴───────────────────────────┘ Lint: all checks passed. PR metadata: E: PR targets 26.04_linux-nvidia but body has no https://bugs.launchpad.net/... link |
BaseOS Kernel ReviewWarning
|
|
Hi @abhsahu,
|
|
Some findings with Codex
|
|
In addition to what Carol reported, here is a pass over all nine commits One piece of history behind Carol's second finding: the code it replaces is One correction to the automated review: the use-after-free it flags in Items 1 to 3 are one design question rather than three.
acpi_get_devices() runs before acpi_root is assigned (scan.c:2891), so
Would creating acpi_root first, or scanning _SB before the bridge, avoid
The message says "Only ACPI scan-handlers are hooked into the enumeration Existing acpi_ignore_dep_ids[] entries were all added because Linux has no Would honor_dep_ids plus that call in nvidia_ffa_probe() work here? If so
0e0546e moved ffa_init() to rootfs_initcall; cc7e8f2 reverted it as "That initcall ordering workaround is not a proper solution and potentially That series landed e659fc8 and 3acc80a, and this tree already has It also has no effect where ffa_probe() returns -EPROBE_DEFER under pKVM,
nvidia_ffa_next_notif_id only increments, is not rolled back on the error
36b0c01 added guard(mutex)(&nvidia_ffa_lock) to nvidia_ffh_do_ffa_send()
36b0c01 "released-spec support" / "ARM has released the framework": 36b0c01: both FFH offsets attributed to DEN0048D section 2.3, which 36b0c01: the packet comment says recvid is "(OS populates)" and status 3d376f4: "from rootfs_initcall (level 6)" - the parent has 5195c03: beyond the acpi_battery_add() and acpi_driver points already c18cae7: ffa_setup_partitions() does register a device for every
36b0c01: struct nvidia_ec_ffa_packet keeps its name for the new 144-byte 3d376f4: acpi_scan_one_handle_cb() discards acpi_bus_scan()'s return and 5cf2f49: only -EBUSY is retried, while FFA_RET_RETRY and b636ed3 leaves a double blank line in nvidia_ffa_ec_service_probe(). Checked and found clean 9d43c55 is a true no-op - the compiled .rodata is identical before and |
… released-spec support Background ========== When DGX Spark launched, the ARM FF-A EC services specification was still a draft maintained in the OpenDevicePartnership documentation repository. The initial deployed firmware tracks that draft and identifies its FF-A bridge with the ACPI HID MSFT000C. The pinned draft is preserved at https://github.com/OpenDevicePartnership/documentation/blob/0f7b6bad77a3eb07b66b66d0e3af718db2ec1c24/bookshelf/Shelf%204%20Specifications/EC%20Interface/src/secure-ec-services-overview.md Since then ARM has released the framework. FF-A itself is now the "Arm Firmware Framework for Arm A-profile" v1.3 ALP5 (DEN0077A), the FFH operation-region interface it rides on is the "Arm Functional Fixed Hardware Specification" (DEN0048D), and the EC secure-services layer has moved into a companion repository at https://github.com/OpenDevicePartnership/odp-embedded-controller/blob/a018ff0ca21ac95c84b3d3559bda0d11962a0344/docs/src/specs/ec_interface/secure-ec-services-overview.md Platforms that ship this released stack identify their FF-A bridge with the ACPI HID ARML0002. Extend the driver to support the released stack (ACPI HID ARML0002) in addition to the existing draft-spec support (ACPI HID MSFT000C). The two specs share most of the driver machinery but differ in packet layout, FFH operation-region offset, notification encoding, and inter-partition setup. Key changes in this patch: * Add a boolean ffa_ec_legacy_spec that is populated from the ACPI device-ID match at probe time: MSFT000C -> true (legacy draft spec) ARML0002 -> false (released spec) All spec-dependent branches key off this flag. * New packet structure for ARML0002 (144 bytes = 18 x 8-byte registers X0..X17) alongside the existing 18-byte MSFT000C packet. Fields: u64 status bytes 0..7 driver-side status: AML writes 0; FFH handler sets 1 on error u64 recvid bytes 8..15 receiver endpoint ID, populated by the FFA framework path u8 uuid[16] bytes 16..31 service UUID u8 rawdata bytes 32+ payload mapped to X4..X17 * Two FFH operation-region handlers, dispatched on info->offset: 0x02 -> nvidia_ffh_handler_arml0002() (released), operation- region defined by ARM DEN0048D "Arm Functional Fixed Hardware Specification (FFH)" v1.3 section 2.3 0x04 -> nvidia_ffh_handler_msft000c() (draft), operation-region defined by the OpenDevicePartnership secure-ec-services draft, not by DEN0048D Both delegate to a shared nvidia_ffh_do_ffa_send() helper that performs UUID lookup, FFA send, and response copy. For MSFT000C, the response copy uses ffh_copy_len = min(rawdata_buflen, sizeof_field(struct ffa_send_direct_data2, data)) so the full response register file is copied back and legacy consumers do not see stale bytes past pkt->length. * Notification map property parsing handles both revisions: MSFT000C: pkg4_rev = 1 ARML0002: pkg4_rev = 0x00010000 (packed v1.0 per DEN0077A v1.3 section 18.8.2) * Released-spec notification registration uses the inter-partition setup protocol (UUID e474d87e-...) per DEN0077A v1.3 section 18.7 with FFA_MSG_SEND_DIRECT_REQ2 and the encoded 64-bit notification tuple (cookie << 32 | (notif_id & 0x1FF) << 23 | per_vCPU_flag). * Consolidate MSFT000C notify and ARML0002 setup handling into a single nvidia_ffa_control_service_driver whose id_table lists both UUIDs; the FFA framework matches whichever the platform exposes. The shared probe stores it in control_ffa_dev and guards against duplicate registration by returning -EBUSY instead of silently overwriting the global pointer. * Accept either FF-A Device Properties GUID as the outer _DSD identifier. DEN0077A v1.3 renamed the identifier between drafts: ALP3 and earlier: daffd814-6eba-4d8c-8a91-bc9bbf4aa301 (classic ACPI 6.x Device Properties GUID) ALP4 and later: c08c3233-b316-4723-a9d7-e21b7ac0fb6a (FF-A specific Device Properties GUID) Firmware in the field ships either one depending on which draft of the spec the BIOS was locked against; accepting both keeps a single Linux driver working across revisions. Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com>
…e consumer enumeration Several ACPI consumer devices on ARM platforms declare _DEP on the FF-A bridge device (HID ARML0002 for the DEN0077A released spec or MSFT000C for the OpenDevicePartnership draft spec) and call into \_SB.FFA0.FFAC and \_SB.FFA0.AVAL() from their _STA / _DSM methods during ACPI device enumeration. If the FF-A core driver or the NVIDIA EC vendor driver are not bound at that point, the FFH operation-region handler is not yet installed, every FFAC store hits AE_NOT_EXIST, and the consumer method aborts, leaving those devices in a permanently broken state. Four coordinated changes make the FF-A stack available before consumer ACPI devices are enumerated: 1. drivers/acpi/scan.c In acpi_scan_init(), before the full namespace scan (acpi_bus_scan(ACPI_ROOT_OBJECT)), walk the namespace for both ARML0002 and MSFT000C and enumerate those devices first using acpi_get_devices(). A new helper acpi_scan_one_handle_cb() bridges the acpi_get_devices callback into acpi_bus_scan(); it logs any acpi_bus_scan() failure with acpi_handle_warn() so a silent enumeration miss is visible, and returns AE_CTRL_TERMINATE unconditionally because a given platform exposes at most one node per bridge HID. 2. drivers/firmware/arm_ffa/bus.c Move the FF-A bus registration from subsys_initcall (level 4) to arch_initcall (level 3) so the bus exists before any driver registers FFA devices on it. 3. drivers/firmware/arm_ffa/driver.c Move the FF-A core driver initialization from module_init (device_initcall, level 6) to arch_initcall (level 3) so the FFA partition list and FFA devices are populated before acpi_init runs at subsys_initcall (level 4). 4. drivers/platform/arm64/nvidia-ffa-ec.c Move the NVIDIA EC vendor driver registration from module_init (device_initcall, level 6) to arch_initcall (level 3) for the same reason. NVIDIA_FFA_EC is switched from tristate to bool (with depends on ARM_FFA_TRANSPORT=y) so that arch_initcall really runs at level 3 -- for a module it would only be a load-time initializer, not a level-3 built-in initializer, so with CONFIG_NVIDIA_FFA_EC=m or CONFIG_ARM_FFA_TRANSPORT=m the early ACPI scan would enumerate the bridge while the FFH handler is absent. With these changes, when acpi_scan_init() enumerates ARML0002 / MSFT000C early, the FF-A bus + core + NVIDIA EC vendor driver are already in place, the FFH custom-offset handler is installed, and subsequent enumeration of consumer ACPI devices succeeds on the first invocation of their _STA / _DSM methods. Note on upstream direction. An earlier upstream change, commit 0e0546e ("firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall"), moved ffa_init() to rootfs_initcall to work around an IMA / TPM boot-ordering issue. That workaround was withdrawn by commit cc7e8f2 ("Revert "firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall"") once IMA started retrying its TPM lookup at late_initcall_sync, and ffa_init() went back to module_init upstream by design. Our concern here is different: the FFH region handler must be installed before consumer ACPI devices under \_SB.FFA0 have their _STA / _DSM evaluated during the initial acpi_bus_scan(). Neither module_init (level 6) nor rootfs_initcall (level 5) runs before acpi_init (subsys_initcall, level 4), so we move ffa_init() (and the FF-A bus + our vendor driver) to arch_initcall (level 3), the earliest level at which the transport, bus, and vendor driver can all be present before namespace enumeration. This is a SAUCE change contained to the downstream tree; a future upstream submission of this driver in a vendor-neutral form is expected to have a different approach. Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com>
ARM FF-A EC service consumers declare _DEP on the FF-A bridge device, with HID ARML0002 for the DEN0077A released spec, or MSFT000C for the OpenDevicePartnership draft spec. Without ignoring these HIDs the consumers accumulate dep_unmet >= 1 forever and never probe, for two reasons: 1. The FF-A bridge driver is a plain platform driver, not an ACPI scan-handler. Only ACPI scan-handlers are hooked into the enumeration loop's acpi_dev_clear_dependencies() path, so when the bridge driver successfully probes nothing decrements the dep_unmet counter on its consumers. 2. The companion patch in this series moves the FF-A bus, core, and NVIDIA EC vendor drivers to arch_initcall and enumerates the ARML0002 / MSFT000C platform devices before the namespace scan. At that point no consumer ACPI device has been scanned yet, so even an explicit acpi_dev_clear_dependencies() call from the bridge would walk an empty consumer list. The dep entries on the consumers are created later, during acpi_scan_add_dep(), with no remaining opportunity to clear them. The clean fix is to skip the _DEP entry creation entirely. Add both HIDs to acpi_ignore_dep_ids[] so the FF-A bridge dep is not tracked, and consumers can probe as soon as their other dependencies (if any) are satisfied. Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com>
…ssful probe Some platforms declare _DEP on a battery device for unrelated consumers. On those systems the consumer driver's probe keeps returning -EPROBE_DEFER because adev->dep_unmet for the consumer never drops to zero. acpi_dev_clear_dependencies() is what walks the consumer list and decrements their dep_unmet counters. ACPI scan handlers (e.g. the FFA provider) call it explicitly in their .attach. This battery driver is registered as a platform_driver whose .probe path does not do that, so a successful battery probe currently leaves consumer dependencies pending forever. Call acpi_dev_clear_dependencies() at the end of acpi_battery_probe() when initialization has succeeded, so any device that legitimately depends on the battery can finish enumerating. Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com>
…ical FFA notification IDs
The previous implementation conflated the AML cookie value (read from
the ACPI _DSD "arm-arml0002-ffa-ntf-bind" property) with the physical
FFA notification ID (the 0..63 bitmap position registered with the FFA
framework via notify_request).
This worked accidentally on GB10 platforms where every AML cookie
value happened to be < 64, but it is wrong in general:
* AML cookies are u32 values defined by firmware and can exceed the
FFA framework's 6-bit notification ID space.
* Two services that happen to use the same low cookie value would
collide in the FFA framework, causing one of the notify_request
calls to fail.
* When a notification fires, the FFA framework only knows the
physical notification ID; the AML _DSM Function 1 (notify) expects
the cookie that was declared in _DSD.
Decouple the two:
* Introduce struct nvidia_ec_notification { u32 cookie; u8 notif_id; }
and replace the bare u8 notification_id[] array with an array of
these pairs.
* Add a global DECLARE_BITMAP(nvidia_ffa_notif_id_map,
NVIDIA_FFA_MAX_NOTIFICATIONS) used to hand out physical
notification IDs for ARML0002 across all EC services. A free bit
is picked with find_first_zero_bit() and set with set_bit() under
nvidia_ffa_lock; the bit is released with clear_bit() at every
notify_relinquish() site (create-time rollback and remove) so
repeated probe/remove cycles do not exhaust the 0..63 range.
For MSFT000C the older draft-spec firmware rejects NOTIFY_SETUP
when the upper and lower halves of X8 differ, so the cookie itself
is used as the physical notif_id and the bitmap is bypassed; the
AML-declared cookie must fit in the FFA framework's 6-bit
notification ID space.
* In nvidia_ffa_create_notifications(): for ARML0002 allocate the
next free physical notif_id from the bitmap under the lock; for
MSFT000C set notif_id = cookie. Store both the cookie (from _DSD)
and the assigned notif_id in the device's notifications[] array,
and pass both to the setup helpers.
* Update nvidia_ffa_notification_setup_msft000c() and
nvidia_ffa_notification_setup_arml0002() to encode cookie in the
upper 32 bits and physical notif_id in the lower bits of the
notification-setup register field (X8 for MSFT000C, X11 for
ARML0002 with the spec's bits[31:23] placement).
Refcount the per-service state so lookup + use in the FFH send helper
and the notification callback can straddle nvidia_ffa_lock safely.
The mutex cannot be held across sync_send_receive2() or across
acpi_evaluate_dsm() because those paths enter the SPMC / AML on the
same CPU and can re-enter our own FFH region handler; that would
deadlock on the same non-recursive mutex. Instead:
* Add struct kref refcnt to nvidia_ec_ffa_device with a kfree-based
release, and allocate with kzalloc/kfree instead of devm_kzalloc
so the lifetime is decoupled from the ffa_device devm resource
ordering.
* kref_init at probe before publishing on the global list; drop this
reference in nvidia_ffa_ec_service_remove() after list_del.
* nvidia_ffh_do_ffa_send(): kref_get inside the list walk under
nvidia_ffa_lock, drop the mutex, do the FFA send, and kref_put at
return via a common out_put label. This closes the UAF window
where nvidia_ffa_ec_service_remove() could free ec_dev between
the mutex drop and the sync_send_receive2() dereference.
* Pass ec_ffa_dev as the notify_request cb_data (instead of
ffa_dev), take a reference per successful notify_request in
nvidia_ffa_create_notifications(), and drop it per
notify_relinquish() in nvidia_ffa_remove_notifications(). In
nvidia_ffa_ec_service_notif_callback() read the cookie directly
from ec_ffa_dev->notifications[] with no list walk, so an
in-flight callback the framework snapshotted before we
relinquished still resolves the cookie correctly.
Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com>
…around The driver previously walked the ACPI bus after each EC service FFA device probe to rescan consumer ACPI devices. This was needed because the FFH operation-region handler became available only after the FFA core driver was bound, by which time consumer ACPI devices' _STA / _DSM methods (called during the initial acpi_init() namespace scan) had already failed against \_SB.FFA0.FFAC. With the FF-A bus, FF-A core driver, and NVIDIA FFA EC vendor driver all moved to arch_initcall, and with acpi_scan_init() now explicitly enumerating the ARML0002 platform device first via acpi_get_devices() before the rest of the namespace scan, the FFH handler is installed before any consumer ACPI method runs. The rescan walk is no longer needed. Remove: - nvidia_ffa_rescan_acpi_device() - nvidia_get_acpi_id_from_uuid() - the acpi_bus_for_each_dev() call site and the local acpi_id Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com>
…ice_id tables Each per-service uuid_t constant was used exactly once -- as the initializer for its slot in an ffa_device_id[] table -- so the named-constant indirection adds no value and makes adding a new service a two-step edit. Drop the ten `static const uuid_t nvidia_ec_*_uuid = UUID_INIT(...)` declarations and put UUID_INIT() inline in the two id_table arrays (nvidia_ffa_ec_service_ids and nvidia_ffa_control_service_ids), matching the convention already used by drivers/tee/optee/ffa_abi.c. Each table entry now carries a brief comment naming the service it maps to, so the table itself is self-describing. Adding a new EC service becomes a single-line addition. Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com>
ACPI tables collected from GB10 platforms issue FFA requests through the FFAC channel for service UUIDs not yet listed in nvidia_ffa_ec_service_ids[]. Without a matching entry the FFA bus framework does not create a per-service device for those partitions, so the FFH handler cannot route the AML packet to the correct FFA endpoint and the AML method aborts. Add eight OEM-specific service UUIDs observed across GB10 platforms. These cover platform-defined services such as vendor management, EC RAM access, WMI BIOS attributes, SMBIOS extensions, and other custom services. These are grouped under a single "custom UUIDs used by OEM platforms" comment because their FF-A service definitions are platform-defined and not published in a public spec. Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com>
…ient failures Some Secure Partition implementations return a transient failure when a previous FFA request is still in flight or the SP is not yet ready. The FFA framework maps these to two Linux errnos: FFA_RET_BUSY becomes -EBUSY, and both FFA_RET_RETRY and FFA_RET_NOT_READY become -EAGAIN. This has been observed on GB10 platforms during early ACPI enumeration when an SP-originated notification arrives while the kernel is servicing a back-to-back AML FFH write, causing the second write to fail. AML cannot retry within a single FFAC field write (the handler must return success or the whole method aborts), so do the retry here in the unified FFH send helper. Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com>
…bind
The FF-A bridge and its EC subunits are a single firmware fixture on
the systems this driver targets:
* They expose the ACPI FFH region handler that consumer ACPI devices
depend on for the life of the system.
* There is no way to re-create the FFH region or the EC secure
services once torn down.
* The driver is built-in only (NVIDIA_FFA_EC is bool, depends on
ARM_FFA_TRANSPORT=y), so module removal is not possible.
The only live-runtime way for the .remove callbacks of the three
in-tree drivers (nvidia_ffa_driver, nvidia_ffa_ec_service_driver,
nvidia_ffa_control_service_driver) to fire is via sysfs bind/unbind
attributes -- an admin-triggered debug/test path that has no legitimate
use here.
Set driver.suppress_bind_attrs = true on all three drivers to remove
the sysfs unbind path.
Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com>
5cf2f49 to
a76283e
Compare
Commit 1 — ARML0002 / DEN0077A support1.1 clsotog — P1-A — X5/X6 zero during notification registration
Reply: Thanks for the catch. Could you point me to the specific spec / ODP-EC text that pins X5/X6 for the OS-originated notification-registration message? TF-A EL3 SPMC treats X5/X6 as opaque payload — 1.2 clsotog — P1-B —
|
|
Thanks @nirmoy, @jamieNguyenNVIDIA, and @clsotog. I have addressed all the review comments and updated the PR. I also replied directly to each inline comment with its status.
Because the Open Device Partnership specification undergoes frequent updates and the external links often break or shift, there isn't a reliable way to reference specific historical versions of the spec. Since this downstream driver must support both older draft revisions and the current spec, I included the exact commit hash instead. This ensures we can reliably correlate the code with the exact state of the spec at that point in time, especially given that the current Open Device Partnership repositories lack release tags.
Since the spec is now incorporated into the standard Arm specification, it is much closer to being finalized. DGX Spark was the first platform to adopt this specification. However, because the DGX Spark launch schedule did not align directly with the specification development timeline, we had to write the firmware against the draft spec version available at the time.
One potential resolution is to update the firmware to align with the latest specification and ship it as part of an upcoming OTA release. Since upstream kernels will not support the older draft specification, we will need to continue carrying nvidia-ffa-ec as SAUCE if we are unable to update the firmware to the final specification.
Understood. I will send out the backport PR targeting 26.04_linux-nvidia-bos as soon as we conclude the review on this PR. |
|
Thanks for the fixes. |
Thanks @clsotog. This is a framework-level race in drivers/firmware/arm_ffa/, not something the nvidia-ffa-ec driver can close on its own. handle_notif_callbacks() snapshots (cb, cb_data) under notify_lock and then invokes cb() after dropping the lock. __ffa_notify_relinquish() clears the hash-table entry under In-tree caller is also affected with this:
The correct fix is in the FF-A notifier core, along the lines of the SRCU notifier chain (kernel/notifier.c: srcu_notifier_chain_unregister() uses synchronize_srcu() for exactly Given this issue is not specific to this patch series and needs changes in core layer. So, I will follow-up regarding this separately in upstream. |
|
On the callback use-after-free Carol reported. The framework analysis is right and the optee example holds up, and an SRCU The framework does protect its own objects against its own dispatch - That is why cb_data == ffa_dev was safe before this series. This commit And one path reaches the free with dispatch fully live and no sysfs involved: Would a local fix work meanwhile? Passing ffa_dev as cb_data again and Commit message, 9c8eb0e: Correct for acpi_evaluate_dsm(). Does it hold for sync_send_receive2()? Two earlier items look partly applied: "v1.3 ALP5" was added, but the subject still says "released-spec support" and battery.c: the comment and the acpi_battery_probe() reference are fixed, but Smaller: 62c56d6 - on timeout ret is still -EBUSY/-EAGAIN, so the new dev_warn() 62c56d6 - -EAGAIN also covers FFA_RET_NOT_READY, which can persist, so 9c8eb0e - the comment above list_add in nvidia_ffa_ec_service_probe() d57cba3 - acpi_scan_one_handle_cb() could be __init. a76283e - the FF-A core's platform driver does not set Checked clean: kref accounting is balanced on every path including both error |
4 participants
Overview
This series brings the nvidia-ffa-ec driver in line with the released
ARM DEN0077A v1.3 firmware framework spec, fixes the boot ordering that
kept early ACPI consumers from finding the FF-A bridge, decouples
firmware-declared AML cookies from the FF-A framework's physical
notification-ID space, and papers over transient SPMC busy responses
during early boot.
Motivation
GB10 platforms ship EC services behind the ARM FF-A bridge. Two
firmware generations coexist in the field:
18.8, with inter-partition setup, the FFH offset-2 packet layout,
and the cookie / notification-id split. DEN0077A v1.3 also updated
the outer FF-A Device Properties GUID between ALP3 (daffd814-...)
and ALP4 (c08c3233-...) drafts. The OpenDevicePartnership released-
spec companion covering the EC-services layer is at [3]. The FFH
operation-region layout, which the two packet formats key off, is
defined by ARM DEN0048D "Arm Functional Fixed Hardware Specification
(FFH)" v1.3 section 2.3 ([4]).
Before this series the driver only handled MSFT000C, and it probed too
late in boot for consumers that declare _DEP on the FF-A bridge and
evaluate FFH regions from _STA / _INI / _DSM during the initial ACPI
namespace scan. Those consumers ended up permanently missing (battery
absent, lid not detected, UCSI dead) until a manual rebind.
References
[1] OpenDevicePartnership draft EC-services overview (MSFT000C):
https://github.com/OpenDevicePartnership/documentation/blob/0f7b6bad77a3eb07b66b66d0e3af718db2ec1c24/bookshelf/Shelf%204%20Specifications/EC%20Interface/src/secure-ec-services-overview.md
[2] Arm Firmware Framework for Arm A-profile (DEN0077A v1.3):
https://support.arm.com/documentation/den0077
[3] OpenDevicePartnership released-spec EC-services overview
(odp-embedded-controller):
https://github.com/OpenDevicePartnership/odp-embedded-controller/blob/main/docs/src/specs/ec_interface/secure-ec-services-overview.md
[4] Arm Functional Fixed Hardware Specification (DEN0048D v1.3):
https://developer.arm.com/documentation/den0048