u-boot.git/drivers/firmware, branch v2026.04

firmware: scmi: Validate device tree node before setup channel

2026-02-26T15:04:46+00:00

SCMI base protocol device does not have a device tree, it should use and
need to use the agent base channel.

For scmi_base.[x], there is no real device tree node for it. ofnode_null() is
assigned as the device tree node for scmi base protocol device:
commit 7eb4eb541c14 ("firmware: scmi: install base protocol to SCMI agent")

However with recent update in commit 0535e46d55d7
("scripts/dtc: Update to upstream version v1.7.2-35-g52f07dcca47c"),
SPL panic in fdt_check_node_offset_()->fdt_next_tag(), because offset is -1
and SPL_OF_LIBFDT_ASSUME_MASK is 0xFF.

So add a check in x_get_channel() to validate the protocol devices'
ofnode.

Reported-by: Ye Li 
Closes: https://lore.kernel.org/u-boot/939a9696-27fa-45a1-b428-feffe21ac6d5@oss.nxp.com/
Signed-off-by: Peng Fan

firmware: scmi: sandbox: Use scmi_clk_state_in_v2

2026-01-28T06:28:01+00:00

The sandbox scmi clock protocol use version 3.0, so need to use
scmi_clk_state_in_v2.

Signed-off-by: Peng Fan 
Reviewed-by: Marek Vasut

dm: core: Default to using DEVRES outside of xPL

2026-01-09T15:08:14+00:00

The devm alloc functions that we have may follow the Linux kernel model
where allocations are (almost always) automatically free()'d. However,
quite often we don't enable, in full U-Boot, the tracking and free()'ing
functionality. This in turn leads to memory leaks because the driver
author expects that since the functions have the same name as in the
Linux Kernel they have the same behavior. In turn we then get
functionally correct commits such as commit 00e1fed93c8c ("firmware:
ti_sci: Fix memory leaks in devm_ti_sci_get_of_resource") that manually
add these calls. Rather than manually tracking allocations and
implementing free()s, rework things so that we follow expectations by
enabling the DEVRES functionality (outside of xPL phases).

This turns DEVRES from a prompted symbol to a symbol that must be
select'd, and we now remove our non-managed alloc/free functions from
outside of xPL builds.

Reviewed-by: Michael Trimarchi 
Signed-off-by: Tom Rini

arm64: versal2: Read and show multiboot value

2025-12-19T07:25:27+00:00

SOC can boot from different boot medias and also different offsets that's
why by default show multiboot value to be aware which image system is
booting out of. It is especially useful for systems with A/B update
enabled.
Also limit zynqmp_pm_get_pmc_multi_boot_reg() usage only for Versal and
Versal Gen 2.

Signed-off-by: Michal Simek 
Link: https://lore.kernel.org/r/fd7564ce2f51d965c273e939e98de01beb92e6f5.1764232124.git.michal.simek@amd.com

firmware: xilinx: Add support for enhancement SMC format

2025-12-19T07:25:26+00:00

Versal Gen 2 is using different SMC format that's why firmware and clock
drivers needs to be align with it.

Signed-off-by: Michal Simek 
Link: https://lore.kernel.org/r/16bdee56fd75113c6d531bae7a8a34900b10280d.1762788250.git.michal.simek@amd.com

firmware: ti_sci: Fix memory leaks in devm_ti_sci_get_of_resource

2025-12-05T22:23:49+00:00

- Fix temp memory leak
- Free memory during error handling

Signed-off-by: Francois Berder

firmware: scmi: Add clock v3.2 CONFIG_SET support

2025-11-10T12:57:42+00:00

SCMI v3.2 introduces a new clock CONFIG_SET message format that can
optionally carry also OEM specific configuration values beside the usual
clock enable/disable requests. Add support to use such new format when
talking to a v3.2 compliant SCMI platform.

Support existing enable/disable operations across different clock protocol
versions: this patch still does not add protocol operations to support the
new OEM specific optional configuration capabilities.

No functional change for the SCMI drivers users of the related enable and
disable clock operations.

[Marek: Remodel after Linux e49e314a2cf7 ("firmware: arm_scmi: Add clock v3.2 CONFIG_SET support")
        Support both old < 2.1 and new >= 2.1 protocol versions.
	Update commit message based on Linux one]

Signed-off-by: Vinh Nguyen 
Signed-off-by: Marek Vasut 
Reviewed-by: Alice Guo 
Signed-off-by: Peng Fan

firmware: scmi: Drop mmu_set_region_dcache_behaviour() misuse

2025-11-10T12:57:42+00:00

MMU region cache behavior configuration for SCMI/SMT mailboxes is
platform specific. Even on ARM systems, the mailbox memory may not
even be located in any cacheable MMU region and may instead reside
in some SRAM. Remove this non-generic cache behavior configuration
code from generic code path.

It is unlikely that any platform is affected by this change if it
did configure its MMU regions correctly on start up. Platforms
which might be affected are i.MX94/95 and STM32MP.

Fixes: 240720e9052f ("firmware: scmi: mailbox/smt agent device")
Fixes: 2a3f161c8b16 ("scmi: correctly configure MMU for SCMI buffer")
Fixes: b2ae10970d40 ("firmware: scmi: use PAGE_SIZE alignment for ARM64")
Signed-off-by: Marek Vasut 
Tested-by: Alice Guo 
Tested-by: Patrice Chotard 
Signed-off-by: Peng Fan

firmware: scmi: Add i.MX95 SCMI CPU Protocol

2025-10-24T19:47:50+00:00

This protocol allows an agent to start, stop a CPU or set reset vector.
It is used to manage auxiliary CPUs in an LM (e.g. additional cores in an
AP cluster).

Signed-off-by: Peng Fan 
Reviewed-by: Alice Guo

firmware: scmi: Add i.MX95 SCMI LMM protocol driver

2025-10-24T19:47:50+00:00

Add Logical Machine Management(LMM) protocol which is intended for boot,
shutdown, and reset of other logical machines (LM). It is usually used to
allow one LM to manager another used as an offload or accelerator engine.

Following Linux Kernel, created a separate folder for holding vendor
protocol drivers.

Signed-off-by: Peng Fan 
Reviewed-by: Alice Guo