summaryrefslogtreecommitdiff
path: root/drivers/firmware/arm_scmi
AgeCommit message (Collapse)Author
9 daysMerge branches 'for-next/scmi/fixes' and 'for-next/juno/fixes', tags ↵Sudeep Holla
'juno-updates-7.4' and 'vexpress-fixes-7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux Arm FVP/Juno device tree updates for v7.4 Three updates to the FVP RevC device tree: - Add the missing CPU topology information by describing the eight CPUs as two clusters of four in cpu-map. - Add the EL2 Generic Watchdog control and refresh frames. - Add a 4 GiB PCIe memory window, matching the range advertised by the ACPI description. ARM: vexpress: Fixes for v7.4 Couple of device tree node references acquired during VExpress SMP preparation were never released. Add `__free(device_node)` to the node pointers in `vexpress_flags_set()` and `vexpress_smp_dt_prepare_cpus()` so their references are dropped when each function returns. Both leaks occur once during boot and have no known functional impact. * tag 'juno-updates-7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: arm64: dts: fvp: Add additional PCIe memory region arm64: dts: fvp: Add EL2 Generic watchdog arm64: dts: fvp: Add cpu-map property * tag 'vexpress-fixes-7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: ARM: vexpress: fix device_node refcount leak in vexpress_smp_dt_prepare_cpus() ARM: vexpress: fix device_node refcount leak in vexpress_flags_set() * 'for-next/scmi/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: (21 commits) firmware: arm_scmi: Skip unused performance-domain devices pinctrl: imx: Match the standard SCMI pinctrl device firmware: arm_scmi: Skip requests for standard protocol devices firmware: arm_scmi: Avoid protocol devices in exclusive raw mode firmware: arm_scmi: Update ARM_SCMI_HAVE_TRANSPORT rationale firmware: arm_scmi: Always create devices for standard protocols firmware: arm_scmi: Add SCMI device table alias support firmware: arm_scmi: Validate PCC shared memory signature firmware: arm_scmi: Initialise known ACPI protocol devices and channels firmware: arm_scmi: Add ACPI PCC transport firmware: arm_scmi: Refactor protocol device creation logic firmware: arm_scmi: Pass protocol ID to transport chan_available() firmware: arm_scmi: Fall back to ACPI HID when "compatible" is absent firmware: arm_scmi: Convert OF-only paths to generic fwnode in SCMI core firmware: arm_scmi: Extend transport driver macro to support ACPI firmware: arm_scmi: Set generated device fwnode with platform helpers firmware: arm_scmi: Merge scmi_reset_proto_ops.name_get() and .latency_get() firmware: arm_scmi: Fix error path leak in scmi_raw_message_send() firmware: arm_scmi: Don't reuse raw xfers with async_done still armed firmware: arm_scmi: Protect xfer->async_done with xfer->lock ... * 'for-next/juno/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: arm64: dts: arm: corstone1000-a320: Fix GIC redistributor region size Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
9 daysfirmware: arm_scmi: Skip unused performance-domain devicesSudeep Holla
The SCMI performance-domain driver uses the named "perf" device only when its firmware node declares #power-domain-cells. Otherwise its probe returns without registering a provider, while the same SCMI protocol may still be needed by the separate "cpufreq" device. Do not create the "perf" device when the provider property is absent. This avoids an unnecessary device claiming the protocol fwnode and leaves cpufreq creation unchanged. Update the device-creation contract to document that an intentionally omitted named device returns NULL. Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Tested-by: Peng Fan <peng.fan@nxp.com> #i.MX95 EVK Link: https://patch.msgid.link/20261005-scmi_bus_fixes-v3-4-d9bada32ed38@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
9 dayspinctrl: imx: Match the standard SCMI pinctrl deviceSudeep Holla
Use the standard "pinctrl" SCMI device name instead of the i.MX-specific "pinctrl-imx" name. Standard devices no longer have exclusive request tracking, so the i.MX and generic pinctrl drivers can register for the same protocol/name pair. Their probe checks select the appropriate driver for the platform. This solves the issue that occurs when both "pinmux" and "pinmux-imx" devices that share the same fwnode as only the first device registered is assigned as the owner of the fwnode. If this owner device fails to probe (e.g., its driver is blocklisted or missing), it never reaches the driver_bound() stage and the system skips cleaning up its supplier links. Even if a alternative device binds successfully, the system still looks to the broken original owner. As a result, all dependent hardware components (I2C, SPI, UART, USB, MMC, PCIe) defer probing forever, halting the boot process. Note that the solution doesn't support same fwnode being shared by multiple devices and associated fw_devlink feature. Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: NXP S32 Linux Team <s32@nxp.com> Reported-by: Peng Fan <peng.fan@nxp.com> Closes: https://lore.kernel.org/all/20260928-driver-core-v1-1-0846bb8e0f32@nxp.com Reviewed-by: Peng Fan <peng.fan@nxp.com> Tested-by: Peng Fan <peng.fan@nxp.com> #i.MX95 EVK Acked-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20261005-scmi_bus_fixes-v3-3-d9bada32ed38@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
11 daysfirmware: arm_scmi: Skip requests for standard protocol devicesSudeep Holla
The SCMI core creates devices for the standard protocol IDs during protocol enumeration, without waiting for an SCMI driver request. Recording a request for one of these devices also rejects a second driver registering the same protocol/name pair. When the first driver unregisters, unrequesting that pair destroys the core-created device. No other driver can be bound to it at that point, but removing it also removes the device that a later driver could bind to or use for module autoloading. Skip request tracking for standard devices. Keep request tracking and rollback for nonstandard devices unchanged. Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Tested-by: Peng Fan <peng.fan@nxp.com> #i.MX95 EVK Link: https://patch.msgid.link/20261005-scmi_bus_fixes-v3-2-d9bada32ed38@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
11 daysfirmware: arm_scmi: Avoid protocol devices in exclusive raw modeSudeep Holla
Since standard protocol devices are created without a driver request, rejecting SCMI driver registration is no longer enough to prevent them from appearing when raw mode is enabled without coexistence. When raw-mode debugfs setup succeeds, scmi_probe() returns success before protocol enumeration, so it does not normally create those devices. That early return is not sufficient: scmi_device_create() is exported and can be called later. Skip protocol-device creation in exclusive raw mode, including named non-transport requests. Keep named transport devices so raw mode can still set up its channels. Share the raw-mode condition and transport name check with the existing bus paths. Cc: Hans de Goede <johannes.goede@oss.qualcomm.com> Fixes: aac4e67d6eb9 ("firmware: arm_scmi: Always create devices for standard protocols") Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Tested-by: Peng Fan <peng.fan@nxp.com> #i.MX95 EVK Link: https://patch.msgid.link/20261005-scmi_bus_fixes-v3-1-d9bada32ed38@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-10-01firmware: arm_scmi: Update ARM_SCMI_HAVE_TRANSPORT rationaleGeert Uytterhoeven
Not enabling any transports no longer breaks the build. Fixes: c0397c85b53d0bc6 ("firmware: arm_scmi: Use WARN_ON() to check configured transports") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/48c4bed8036dcb55f554f513ce2ae61807c5677d.1790684637.git.geert+renesas@glider.be Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-09-24firmware: arm_scmi: Always create devices for standard protocolsHans de Goede
Protocol driver module auto-loading requires the devices to already be created for udev to get the necessary uevents based on which udev loads modules. But SCMI devices are only created after their { protocol, name } device-id has been added to the requested-devices list which is done from scmi_driver_register(). This creates a circular dependency where device creation is waiting for the driver to register and loading the module with the driver is waiting for the device to be created. Add a list of standard protocol device-ids and always create devices for these without relying on these being added to the requested-devices list. This removes the circular dependency, fixing module auto-loading. Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Link: https://patch.msgid.link/20260918092951.5656-3-johannes.goede@oss.qualcomm.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-09-24firmware: arm_scmi: Add SCMI device table alias supportBjorn Andersson
SCMI client drivers already describe their bus match data with MODULE_DEVICE_TABLE(scmi, ...), but modpost does not know how to consume SCMI device tables. As a result, SCMI modules do not get generated module aliases from their id tables. Move struct scmi_device_id to mod_devicetable.h so it has a fixed layout visible to modpost, add the corresponding generated offsets and teach file2alias to emit scmi:<protocol>:<name> aliases. Use the same stable alias format for SCMI device uevents and sysfs modaliases. The previous string included the instance-specific device name, which is not useful for matching modules. Assisted-by: Codex:GPT-5.5 Tested-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Tested-by: Rob Clark <rob.clark@oss.qualcomm.com> Tested-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> # Lenovo Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Link: https://patch.msgid.link/20260918092951.5656-2-johannes.goede@oss.qualcomm.com Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> (sudeep.holla: updated the title to use standard format for SCMI) Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-09-15firmware: arm_scmi: Validate PCC shared memory signatureSudeep Holla
Validate the PCC shared memory signature when setting up an SCMI PCC channel. Reject channels whose shared memory signature does not encode PCC_SIGNATURE combined with the PCC subspace ID, so misconfigured firmware is caught before the transport starts using the shared memory region. Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-acpi_scmi_pcc-v5-9-298579e9f359@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-09-15firmware: arm_scmi: Initialise known ACPI protocol devices and channelsSudeep Holla
Unlike Device Tree, the ACPI SCMI namespace device does not provide child fwnodes to represent each protocol. Iterate over the non-BASE entries in scmi_dsd_info_list to initialize their protocol devices and transport channels. The BASE channel and device are handled by the common setup path. Let the transport channel-availability and SCMI protocol implementation checks decide which of the known protocols are usable on the platform. Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-acpi_scmi_pcc-v5-8-298579e9f359@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-09-15firmware: arm_scmi: Add ACPI PCC transportSudeep Holla
Add an SCMI transport for ACPI-described systems using PCCT PCC subspaces through the Linux PCC mailbox layer. Parse the SCMI Device Properties _DSD packages defined by Arm document 111115A v1.0, sections 2.2.1.1, 2.2.2.1 and 2.2.3. Map transport UIDs to PCC subspaces for common and protocol-exclusive A2P and P2A channels, validate the mappings, and cache them for channel setup. Support the Powercap and System Telemetry protocol properties and add the System Telemetry protocol ID. Implement PCC channel management, message framing, shared-memory bounds validation, and response and notification delivery. Add the corresponding Kconfig, module and ARML0001 ACPI matching plumbing. Link: https://patch.msgid.link/20260915-acpi_scmi_pcc-v5-7-298579e9f359@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-09-15firmware: arm_scmi: Refactor protocol device creation logicSudeep Holla
Move the protocol validation and device creation logic in scmi_probe() into a reusable scmi_device_check_create() helper. The helper centralizes checks for the protocol ID range, implementation availability and duplicate activation before invoking scmi_create_protocol_devices(). This preserves the existing behavior while allowing the logic to be reused by the ACPI path, where protocol child fwnodes are absent. No functional change intended. Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-acpi_scmi_pcc-v5-6-298579e9f359@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-09-15firmware: arm_scmi: Pass protocol ID to transport chan_available()Sudeep Holla
Pass the protocol ID to the transport chan_available() callback so a transport can distinguish channels associated with different protocols when they share the same firmware node. This is required by the ACPI PCC transport to resolve protocol-exclusive PCC subspaces. Update all transport implementations for the new callback signature. Existing transports ignore the protocol ID, so there is no functional change. Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-acpi_scmi_pcc-v5-5-298579e9f359@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-09-15firmware: arm_scmi: Fall back to ACPI HID when "compatible" is absentSudeep Holla
scmi_debugfs_common_setup() uses the "compatible" property to populate the debugfs transport type string. ACPI-described SCMI devices do not provide that DT property, so the string remains NULL and debugfs setup falls through the allocation failure path. Check the property lookup result and use the ACPI HID as the fallback transport type when an ACPI companion is present. All supported DT SCMI platforms are expected to provide "compatible", so the non-ACPI fallback is not needed for normal DT operation. Keep the explicit "unknown" fallback anyway to avoid passing NULL to kstrdup() if that assumption is ever violated. Link: https://patch.msgid.link/20260915-acpi_scmi_pcc-v5-4-298579e9f359@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-09-15firmware: arm_scmi: Convert OF-only paths to generic fwnode in SCMI coreSudeep Holla
Switch SCMI core plumbing from struct device_node * to struct fwnode_handle * so the core can describe SCMI instances and protocols using firmware nodes rather than OF nodes directly. This change: - Replaces core OF property lookups with fwnode_property_*() helpers. - Plumbs fwnode through the SCMI device creation and channel setup paths. - Updates transport ->chan_available() callbacks to take a fwnode. - Stores per-protocol child fwnodes in info->active_protocols so the core can later locate the descriptor for a given protocol ID. - Updates mailbox/optee/smc/virtio transports to accept fwnodes and map back to OF nodes where their existing parsing remains DT-specific. DT-only transports such as mailbox, OP-TEE and SMC still parse DT properties by mapping the fwnode back to an OF node. On non-DT systems these transports report no channel available. This is a mechanical step towards firmware-node neutrality and prepares the SCMI core for non-DT transports, such as an ACPI/PCC transport. DT users continue to work unchanged; no non-DT transport is enabled by this patch. Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-acpi_scmi_pcc-v5-3-298579e9f359@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-09-15firmware: arm_scmi: Extend transport driver macro to support ACPISudeep Holla
Extend the SCMI transport driver helper to support ACPI-based systems. Introduce an internal helper macro that accepts both OF and ACPI match tables, and expose two wrappers: - DEFINE_SCMI_TRANSPORT_DRIVER(...) for DT/OF transports - DEFINE_SCMI_ACPI_TRANSPORT_DRIVER(...) for ACPI transports For ACPI, set the generated platform_driver .acpi_match_table via ACPI_PTR(). The ACPI wrapper relies on the firmware-node propagation provided by the preceding change so fwnode lookups on the spawned platform device see the correct firmware description. Keep existing DT users unchanged while allowing transports to be probed using struct acpi_device_id tables on ACPI platforms. Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com> Link: https://patch.msgid.link/20260915-acpi_scmi_pcc-v5-2-298579e9f359@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-09-15firmware: arm_scmi: Set generated device fwnode with platform helpersSudeep Holla
The SCMI transport probe helper creates a platform device for the SCMI core. device_set_of_node_from_dev() propagates the supplier's OF node, but leaves generated devices for non-DT transports without a firmware node. Use platform_device_set_of_node_from_dev() for devicetree suppliers so the shared OF node is referenced and marked as reused. For all other suppliers, use platform_device_set_fwnode() so ACPI and other firmware nodes are propagated with a reference that platform_device_release() can balance. Link: https://patch.msgid.link/20260915-acpi_scmi_pcc-v5-1-298579e9f359@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-09-14Merge tag 'scmi-ffa-fixes-7.3' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes Arm firmware fixes for v7.3 SCPI fixes address resource leaks and invalid firmware responses, while FF-A gains shutdown cleanup needed for normal kexec. - Release the device node reference acquired during SCPI domain lookup. - Validate SCPI DVFS OPP counts and indices returned by firmware to prevent out-of-bounds accesses and invalid clock rates. - Register the SCPI cpufreq device only once across DVFS providers, preserving the registered device pointer for cleanup and allowing retries after registration failure. - Run FF-A teardown during orderly shutdown so notifications, partition devices and RX/TX mappings are released before a replacement kernel boots through normal kexec. Also includes replacing a literal platform device ID with PLATFORM_DEVID_NONE and correcting an SCMI comment typo. * tag 'scmi-ffa-fixes-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: Fix typo "upto" in comment firmware: arm_ffa: Tear down driver during shutdown clk: scpi: use PLATFORM_DEVID_NONE for scpi-cpufreq clk: scpi: register scpi-cpufreq once and clear on failure clk: scpi: bound-check DVFS index in scpi_dvfs_recalc_rate firmware: arm_scpi: reject DVFS OPP count above MAX_DVFS_OPPS firmware: arm_scpi: fix device_node leak in scpi_dev_domain_id Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-09-11firmware: arm_scmi: Merge scmi_reset_proto_ops.name_get() and .latency_get()Geert Uytterhoeven
The SCMI reset domain protocol operations structure does not provide a .info_get() method, unlike most other protocols. Instead, it provides two separate methods to get a domain's name and reset latency. Merge the .name_get() and .latency_get() methods into a single .info_get() method, to increase uniformity. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/77c9651a11715013c0eaa8a56dbbc7dc3d9ddeec.1788429130.git.geert+renesas@glider.be Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-09-10firmware: arm_scmi: Fix error path leak in scmi_raw_message_send()Roland Dreier
When the is_transport_polling_capable() check fails in scmi_raw_message_send(), it returns -EINVAL without doing scmi_xfer_raw_put(), which will leak a struct scmi_xfer. Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://sashiko.dev/#/patchset/20260909-scmi-async-done-race-v2-0-cc5dec25c6be%40rivian.com Fixes: 07cb8c324b63 ("firmware: arm_scmi: Add polling support to raw mode") Signed-off-by: Roland Dreier <rolanddreier@rivian.com> Link: https://patch.msgid.link/20260909-scmi-raw-v1-1-de3fa75d2c6f@rivian.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-09-10firmware: arm_scmi: Don't reuse raw xfers with async_done still armedRoland Dreier
In SCMI raw mode, scmi_xfer_raw_worker() releases the xfer before releasing the waiter that disarms xfer->async_done, and scmi_xfer_get() does not clear async_done when it hands out a recycled xfer. A concurrent transaction can therefore pick up the xfer while it still points at the old waiter's completion, so: - a delayed response arriving for the new transaction can be signalled on the old waiter's completion, which may already be re-armed for yet another unrelated transaction, making that transaction's wait return early; and - the old waiter's disarm, which still runs after the xfer has been released, clobbers the arming just installed by the new transaction, so the new waiter times out even if its delayed response arrives. Release the waiter first, while the worker still holds a reference on the xfer, so that an xfer can never reach the free list still armed. Track whether a delayed response is expected in the waiter itself instead of peeking at xfer->async_done outside xfer->lock, and wait on the waiter's own embedded completion. (The new async flag is not strictly needed but it makes the logic easier to reason about) Finally, harden scmi_xfer_get() to clear async_done when handing out an xfer, so that no future release-ordering change can leak a stale arming into a new transaction. Fixes: 3c3d818a9317 ("firmware: arm_scmi: Add core raw transmission support") Signed-off-by: Roland Dreier <rolanddreier@rivian.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://patch.msgid.link/20260909-scmi-async-done-race-v2-2-cc5dec25c6be@rivian.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-09-10firmware: arm_scmi: Protect xfer->async_done with xfer->lockRoland Dreier
Asynchronous SCMI commands are completed by a delayed response. The RX path signals the response with complete(xfer->async_done). Unlike xfer->done, xfer->async_done is a pointer to a completion owned by whoever is waiting for the delayed response, and it stays valid only for as long as that waiter is still waiting. In do_xfer_with_response() it is a DECLARE_COMPLETION_ONSTACK() in the caller's stack frame. Nothing serialises the RX path against a waiter that gives up on a timeout. scmi_msg_response_validate() does read xfer->async_done under xfer->lock, and documents that as a requirement, but the lock is dropped again before scmi_handle_response() dereferences the pointer, and neither the arming nor the disarming side takes it at all. So a delayed response arriving just as the wait times out can be signalled on a completion that is already gone: waiter RX path (IRQ context) ------ --------------------- do_xfer_with_response(): xfer->async_done = &async_response do_xfer(xfer) wait_for_completion_timeout(xfer->async_done, tmo) /* returns 0, gives up */ /* response receive interrupt */ scmi_handle_response(): scmi_xfer_command_acquire() lock xfer->lock validate: async_done != NULL unlock xfer->lock xfer->async_done = NULL return -ETIMEDOUT /* async_response goes out of scope */ complete(xfer->async_done) That last complete() has two possible bad outcomes: it either dereferences the NULL just stored by the waiter or - if that store is not yet visible on the RX CPU - it takes a lock and writes to a stack frame that the waiter may already have returned from. Fix this by making xfer->lock cover xfer->async_done end-to-end. Add helpers to arm and disarm it under the lock, use them on both the regular and the raw paths, and have the RX path read and signal the completion under that same lock. A waiter that is timing out then either completes its disarm before the RX path looks, in which case the delayed response is dropped, or blocks in the disarm until the RX path is done with the completion, in which case the completion is still alive. Log the dropped case, so every path where a delayed response that was matched to a pending xfer and then discarded produces an error. (This is the same treatment scmi_msg_response_validate() already gives a delayed response that arrives after the waiter has disarmed the xfer) Fixes: 58ecdf03dbb9 ("firmware: arm_scmi: Add support for asynchronous commands and delayed response") Signed-off-by: Roland Dreier <rolanddreier@rivian.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://patch.msgid.link/20260909-scmi-async-done-race-v2-1-cc5dec25c6be@rivian.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-09-04treewide: refresh kmalloc_obj() conversionsKees Cook
This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook <kees+treewide@kernel.org>
2026-09-04firmware: arm_scmi: Fix typo "upto" in commentHemanth Selam
Correct "upto" to "up to", reported by scripts/checkpatch.pl using the misspelling list in scripts/spelling.txt. Only touches comments, no code changes. Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Link: https://patch.msgid.link/20260904103732.7320-1-hemanth.selam@gmail.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-22firmware: arm_scmi: Unrequest devices if driver registration failsSudeep Holla
scmi_driver_register() requests protocol devices before registering the driver. If driver_register() fails, those requests remain in the global IDR and retain pointers to the module's ID table. Once the failed module load releases that storage, later request matching or SCMI device creation can dereference the stale pointers. Unrequest the complete protocol table before returning the registration failure. At this point table registration succeeded, so every entry is owned by the current registration attempt. Fixes: d3cd7c525fd2 ("firmware: arm_scmi: Refactor protocol device creation") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260722173521.2184378-2-sudeep.holla@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-22firmware: arm_scmi: Roll back partial protocol table registrationSudeep Holla
scmi_protocol_table_register() can leave earlier requests registered when a later entry in the same ID table fails. Each request retains a pointer to the driver's ID table, so a failed module load can leave a dangling pointer after the module storage is released. Unrequest only the successfully registered prefix, in reverse order, before returning the failure. Leave the failed entry and the remaining entries untouched because matching requests can be owned by another driver. Fixes: 2858f6e5f064 ("firmware: arm_scmi: Add multiple protocols registration support") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260722173521.2184378-1-sudeep.holla@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-22firmware: arm_scmi: Fix requested device removal raceSudeep Holla
scmi_protocol_device_unrequest() drops scmi_requested_devices_mtx while notifying listeners but continues to retain the per-protocol list head. When two SCMI drivers for the same protocol unregister concurrently, one thread can remove the final request and free the list head while the other is running its notifier. The latter then dereferences the freed list head after reacquiring the mutex and can free it a second time. Complete the list and IDR updates, including freeing an empty list head, before dropping the mutex. Keep the blocking notifier outside the critical section and retain only the detached request across the callback. Fixes: d3cd7c525fd2 ("firmware: arm_scmi: Refactor protocol device creation") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260722095250.2011630-1-sudeep.holla@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Fix transport device teardown lookupSudeep Holla
SCMI transport devices are deliberately excluded from normal SCMI bus matching so protocol drivers cannot bind to the internal transport children. However, scmi_device_destroy() uses the same protocol/name lookup to find devices that must be unregistered during channel teardown. Split the match helper so driver matching still skips transport devices, while explicit child lookup can find them for teardown. Use a shared transport-device name prefix macro for both matching and name generation. Since transport-device names are derived from direction and protocol ID, reject duplicate protocol channel setup before creating or finding a transport device. This prevents malformed firmware with duplicate protocol child nodes from reusing an existing transport device and then destroying it when the duplicate IDR insertion fails. Fixes: 9593804c44c2 ("firmware: arm_scmi: Exclude transport devices from bus matching") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-16-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Fix SCMI device destroy lifetimesSudeep Holla
scmi_child_dev_find() drops the reference returned by device_find_child() before returning the scmi_device pointer. A concurrent unregister can then release the device while the destroy path is still using the returned pointer. Make the lookup helper return the device_find_child() reference and keep it until scmi_device_destroy() has finished unregistering the child. Also split device_unregister() in __scmi_device_destroy() so the SCMI bus ID is not made reusable until after device_del() has removed the old scmi_dev.N name from sysfs. This avoids a new SCMI device reusing the same ID while the old device is still registered. The final device release callback is also a possible cleanup path when SCMI children are deleted by driver core recursion rather than __scmi_device_destroy(). Release the SCMI bus ID from a common helper used by destroy, register-failure and final-release paths, and clear scmi_dev->id after freeing it so the final release cannot free the same ID again. Fixes: 9ca67840c0dd ("firmware: arm_scmi: Balance device refcount when destroying devices") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-15-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Unwind P2A receiver mailbox setup failureSudeep Holla
mailbox_chan_setup() can request an additional P2A receiver channel after successfully acquiring the primary P2A channel. If that later request fails, the function returns immediately and leaves the primary channel allocated. Unwind the primary mailbox channel before returning the error so probe deferral or other setup failures do not leave the channel busy for later probe attempts. Fixes: fa8b28ba22d9 ("firmware: arm_scmi: Add support for platform to agent channel completion") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-14-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Unwind TX receiver mailbox setup failureSudeep Holla
mailbox_chan_setup() can request an additional unidirectional TX receiver channel after successfully acquiring the primary channel. If that second request fails, the function returns immediately and leaves the primary channel allocated. Unwind the primary mailbox channel before returning the error so probe deferral or other setup failures do not leave the channel busy for later probe attempts. Fixes: 9f68ff79ec2c ("firmware: arm_scmi: Add support for unidirectional mailbox channels") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-13-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Fix OF node reference handlingSudeep Holla
SCMI devices store the DT node in dev.of_node through device_set_node(), but that helper only assigns the fwnode and of_node pointers without taking an OF node reference. Take a reference when assigning the node and release it from the SCMI device release path. With the device owning that reference, remove the separate channel-side get/put pair from the core driver. Fixes: 96da4a99ce50 ("firmware: arm_scmi: Set fwnode for the scmi_device") Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-12-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Clear SystemPower flag on create failureSudeep Holla
__scmi_device_create() reserves the singleton SystemPower protocol device before registering the SCMI device. If any later step fails, a stale reservation can make a later retry reject SystemPower device creation permanently, for example after probe deferral. A plain global boolean is not enough to track the reservation. A delayed final release of an older SystemPower device could clear the boolean after a newer device has already claimed it, breaking the singleton guarantee for the active device. Track the reservation with the scmi_device pointer itself. Claim it with cmpxchg(NULL, scmi_dev) after allocating the device object, and release it with cmpxchg(scmi_dev, NULL) from the common cleanup helper. This lets the create-failure, explicit destroy and final release paths clear only the reservation owned by the device being cleaned up. Fixes: 2c3e674465e7 ("firmware: arm_scmi: Refactor device create/destroy helpers") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-11-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Drop handle on protocol bind failuresSudeep Holla
The SCMI bus notifier acquires an SCMI handle when the driver core emits BUS_NOTIFY_BIND_DRIVER, before invoking the protocol driver probe callback. The protocol probe path only checks whether sdev->handle is set. If device_link_add() fails after the handle has been acquired, the protocol device can still bind with a valid handle but without the dependency link to the SCMI parent. A concurrent parent unbind can then miss the child and tear down the SCMI instance while the child still holds a handle into it. If the protocol driver probe later fails, for example with -EPROBE_DEFER, the driver core emits BUS_NOTIFY_DRIVER_NOT_BOUND rather than BUS_NOTIFY_UNBOUND_DRIVER. The SCMI notifier only released the handle on BUS_NOTIFY_UNBOUND_DRIVER, so each failed protocol-device bind leaked the SCMI instance users refcount and left sdev->handle set after the failed probe. Make the link helper report failure and drop the acquired handle if the link cannot be created. Also handle BUS_NOTIFY_DRIVER_NOT_BOUND in the same cleanup path used for unbind so failed probes balance the earlier BUS_NOTIFY_BIND_DRIVER acquisition. Fixes: 971fc0665f13 ("firmware: arm_scmi: Move handle get/set helpers") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-10-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Protect device request lookup with RCUSudeep Holla
The SCMI device request notifier looks up protocol OF nodes from the active_protocols IDR. The IDR lookup can run concurrently with protocol activation while probe is still registering protocols and creating their SCMI devices. Wrap the lookup in an RCU read-side critical section as required by the IDR API for lockless readers. Fixes: 53b8c25df708 ("firmware: arm_scmi: Add common notifier helpers") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-9-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Use channel ID for transport teardownSudeep Holla
SCMI protocols can share the BASE transport channel when firmware does not describe a dedicated channel for the protocol. In that case multiple IDR entries can point at the same scmi_chan_info, whose owning transport device was created with cinfo->id. scmi_chan_destroy() used the IDR iterator key when destroying the transport device. If an alias entry is visited before the owning channel entry, the lookup can miss the device because the iterator key does not match the protocol ID used when the transport device was created. The code then clears cinfo->dev, so the later owning entry skips teardown and leaks the transport device. Destroy the transport device using cinfo->id, which is the protocol ID that owns the channel and was used when creating the transport device. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-8-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Reject out of range DT protocol IDsSudeep Holla
SCMI protocol IDs carried in message headers are limited by MSG_PROTOCOL_ID_MASK. The DT parsing paths noticed protocol IDs outside that range, but only logged an error and then kept processing the invalid value. That lets a malformed 32-bit DT reg value reach helpers which take a u8 protocol ID, where it can be truncated and/or treated as a different protocol. For channel setup, two different out-of-range values can also be used as distinct IDR keys while aliasing the generated SCMI protocol identity. Skip DT protocol nodes whose reg value does not fit the SCMI protocol ID field before setting up channels or creating protocol devices. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-7-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Avoid IDR updates while cleaning channelsSudeep Holla
scmi_cleanup_channels() walks the TX/RX channel IDRs with idr_for_each() to free transport resources and destroy the dedicated transport devices before calling idr_destroy(). The destroy callback removed each entry from the same IDR being walked. That is not needed for this cleanup path, and it is unsafe because idr_for_each() has not advanced its radix-tree iterator while the callback is running. Removing the current entry from the callback can invalidate the iterator state. The callback also cannot be protected by rcu_read_lock(), because scmi_device_destroy() may sleep. Leave IDR teardown to the following idr_destroy() call and keep the callback limited to device destruction. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-6-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Free transport channel on IDR failureSudeep Holla
If transport channel setup succeeds but the following IDR insertion fails, the error path destroys the transport device and frees the channel info without invoking the transport cleanup callback. Call chan_free() before destroying the device so transport specific resources such as IRQs, mailbox channels and mapped shared memory are released consistently with the normal teardown path. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-5-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Clean up channels on setup failureSudeep Holla
scmi_channels_setup() can fail after the common BASE channel or earlier protocol channels have already been registered in the TX/RX IDRs. Route this failure through the existing channel cleanup label so the transport channels, transport devices and IDR state created before the failure are released before the probe error path frees the SCMI instance ID. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-4-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Quiesce notifications before teardownSudeep Holla
scmi_notification_exit() clears and releases the notification instance, but transport callbacks can still deliver incoming notifications until the TX/RX channels are freed. During remove, an RX interrupt in that window can enter scmi_notify() while notification state is being torn down and then dereference freed memory. The same ordering exists on the probe error path after notification initialization. The notification late-init worker has a separate lifetime issue: protocol event registration queues ni->init_work on the system workqueue, so destroying ni->notify_wq does not drain that work. If the devres group is released while init_work is still pending or running, the late-init worker can dereference the freed notification instance. Quiesce the notification core before TX/RX channels are torn down, then clean up the channels before releasing the notification core resources. Use disable_work_sync() so future late-init queueing is rejected and any already queued or running late-init work has completed before channel teardown starts. Fixes: 1e7cbfaa66d3 ("firmware: arm_scmi: Free mailbox channels if probe fails") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-3-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Unregister device notifier before IDR teardownSudeep Holla
The requested-devices notifier looks up protocol fwnodes from the active_protocols IDR. During remove, unregister the notifier before releasing and destroying active_protocols so no notifier callback can race with the IDR teardown. Keep the bus notifier registered until after the protocol state is torn down, matching the existing remove ordering for SCMI bus users. Fixes: 53b8c25df708 ("firmware: arm_scmi: Add common notifier helpers") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-2-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-14firmware: arm_scmi: Publish channel state before callbacksSudeep Holla
Transport setup can enable callbacks before the setup routine returns. mailbox_chan_setup() registers the mailbox client with mbox_request_channel(), and the mailbox controller startup path can enable interrupt delivery before SCMI mailbox channel state has been published. Similarly, smc_chan_setup() requests the optional A2P completion IRQ before the SMC transport has made its cinfo pointer visible. If a pending or spurious callback fires in those windows, the transport RX callback can dereference a NULL transport cinfo pointer. Publishing only the transport-private pointer is not sufficient either: an early callback can enter the SCMI core before scmi_chan_setup() has assigned cinfo->handle. The core derives scmi_info from cinfo->handle in the RX path, so a NULL handle can still fault even when the transport-private cinfo is valid. Assign cinfo->handle before invoking the transport setup callback. Publish the mailbox and SMC transport-private channel state before requesting the mailbox channels or IRQ, and clear the early-published pointers again on setup failure. Also unwind mailbox setup devres resources on failure so an optional RX setup error that is ignored by the core does not leave stale transport state behind. Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-1-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-13firmware: arm_scmi: Simplify notification allocationsRosen Penev
Several SCMI notification data structures allocate a descriptor and then allocate a fixed-size array referenced by that descriptor. Use flexible array members for per-protocol registered events and per-event source refcounts so each descriptor and its array can be allocated together. Annotate the flexible arrays with __counted_by() and assign the count fields immediately after allocation, before any array access. The registered_protocols table has a fixed SCMI_MAX_PROTO size, so embed it directly in the notification instance instead of allocating it separately. Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260630204719.334211-1-rosenp@gmail.com (sudeep.holla: Updated title and improved change description) Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-09firmware: arm_scmi: Rate-limit queue-full warnings in IRQ contextPushpendra Singh
The scmi_notify() function is called from interrupt context to queue received notification events onto a per-protocol kfifo. When the kfifo is full, it logs a warning via dev_warn() for every dropped event. Under conditions where the platform sends a burst of SCMI notifications faster than the deferred worker can drain the queue, this results in a flood of dev_warn() calls from IRQ context. Each call acquires the console lock and may execute blocking console writes, causing the CPU to be held in interrupt context for an extended period and leading to observable system stalls. Fix this by switching to dev_warn_ratelimited() to limit the frequency of log messages when the notification queue is full. This reduces console overhead in interrupt context and prevents CPU stalls caused by excessive logging, while still preserving diagnostic visibility. Fixes: bd31b249692e ("firmware: arm_scmi: Add notification dispatch and delivery") Signed-off-by: Pushpendra Singh <pushpendra.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20260708072339.3021140-1-pushpendra.singh@oss.qualcomm.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-07-09firmware: arm_scmi: Use 64-bit division for clock rate roundingSteve Dunnagan
SCMI clock range descriptors report rates as 64-bit values. When handling a range clock, scmi_clock_determine_rate() rounds the requested rate up to the next supported step using the SCMI RATE_STEP value. The current code uses div64_ul() for this calculation. Since div64_ul() takes an unsigned long divisor, the 64-bit RATE_STEP value can be truncated on 32-bit builds. In the worst case, a non-zero 64-bit step can be narrowed to zero before the division. Store RATE_STEP in a u64, reject a malformed zero step, and use DIV64_U64_ROUND_UP() so the divisor is handled as a 64-bit value. This does not change behavior for valid firmware reporting a non-zero step that fits in unsigned long. Tested on Xunlong Orange Pi 5 Plus / RK3588 with SCMI over SMC. SCMI clocks probed successfully before and after the change. SCMI-backed CPU clocks were exercised through cpufreq-dt by switching each CPU policy between its lowest and highest available OPP. Fixes: ecde921eb460 ("firmware: arm_scmi: Add clock determine_rate operation") Signed-off-by: Steve Dunnagan <sdunnaga@redhat.com> Link: https://patch.msgid.link/20260701195923.444270-1-sdunnaga@redhat.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-06-30firmware: arm_scmi: Grammar s/may needed/may be needed/Geert Uytterhoeven
Fix grammar in the help text for the ARM_SCMI_POWER_CONTROL symbol. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/5180d04abfb8e3074a321e2eb73bacfdd61c30c5.1780499850.git.geert+renesas@glider.be Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-05-21firmware: arm_scmi: optee: Rework transport probe sequenceCristian Marussi
Use the new per-instance transport handles helpers to synchronize and optionally defer the core SCMI driver probe up until the transport driver has completely been initialized and it is fully operational as a supplier. Introduce proper module init/exit routines while removing the ugly trick of registering a driver from within the probe sequence of another one, just to avoid to have to deal with probe deferrals. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://patch.msgid.link/20260510160527.3537474-5-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-05-21firmware: arm_scmi: virtio: Rework transport probe sequenceCristian Marussi
Use the new per-instance transport handles helpers to synchronize and optionally defer the core SCMI driver probe up until the transport driver has completely been initialized and it is fully operational as a supplier. Introduce proper module init/exit routines while removing the ugly trick of registering a driver from within the probe sequence of another one, just to avoid to have to deal with probe deferrals. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://patch.msgid.link/20260510160527.3537474-4-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-05-21firmware: arm_scmi: Add a generic transport supplierCristian Marussi
Add the capability to define a common generic transport supplier which embeds the logic needed to support one single unique instance of transport supplier. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://patch.msgid.link/20260510160527.3537474-3-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>