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

drivers: sysreset: revert support for args in request

2026-07-03T19:45:58Z

This reverts: - commit e49c84f7bb7b ("doc: usage: cmd: reset: specify when the -edl option is available") - commit 1076feb8a3f9 ("cmd: boot: fix edl being shown when not supported") - commit 63c806ba0e12 ("qcom_defconfig: enable psci based sysreset") - commit ef06c5d76ff4 ("cmd: boot: Add '-edl' option to reset command documentation") - commit 32825eaddc37 ("sysreset: Implement PSCI based reset to EDL mode for QCOM SoCs") - commit fcb48b89813b ("drivers: sysreset: Add sysreset op that can take arguments") There was a conflict reverting commit 63c806ba0e12 ("qcom_defconfig: enable psci based sysreset") due to commit 02ef1859b44f ("configs: Resync with savedefconfig"), but the conflict resolution was trivial. The args support for the sysreset uclass contains a logic bug. The first sysreset device implementing the request_arg callback will consume the args, not support the specified arg and thus return -EPROTONOSUPPORT which will stop the iteration over all sysreset devices. This is an issue if one has multiple sysreset devices and each with support for different (valid) args. If a sysreset device implements a -dummy argument and another -foo and a user calls reset -dummy from the U-Boot CLI, it'll depend on which sysreset device will be attempted first. If it is the one implementing -foo, it'll return it doesn't support the argument with -EPROTONOSUPPORT in which case the device implementing -dummy will never be attempted and instead we'll do a cold reset which is very likely not what's expected from the user. Casey suggested[1] we revert this and start from scratch again with a different implementation instead. [1] https://lore.kernel.org/u-boot/77ff0f56-5c3b-42e7-bdd1-bf90296da900@linaro.org/ Acked-by: Casey Connolly Signed-off-by: Quentin Schulz

firmware: scmi: sandbox: Staticize and constify driver ops

2026-05-15T11:28:31Z

Set the ops structure as static const. The structure is not accessible from outside of this driver and is not going to be modified at runtime. Signed-off-by: Marek Vasut Reviewed-by: Peng Fan Signed-off-by: Peng Fan

sysreset: Implement PSCI based reset to EDL mode for QCOM SoCs

2026-04-27T10:38:44Z

Implement request_arg() sysreset_op for QCOM SoCs that use PSCI to reset to EDL (Emergency Download) mode. Reviewed-by: Casey Connolly Reviewed-by: Sumit Garg Signed-off-by: Varadarajan Narayanan Link: https://patch.msgid.link/20260121063920.1500293-4-varadarajan.narayanan@oss.qualcomm.com [casey: add missing ARM_SMCCC depends to kconfig to fix CI allyesconfig] Signed-off-by: Casey Connolly

firmware: scmi: Fix setting the function

2026-04-09T18:16:58Z

Set BIT(10) when the function needs to be set, otherwise the setting is ignored. Fixes: 0cb160f1b629 ("scmi: pinctrl: add pinctrl driver for SCMI") Signed-off-by: Dan Carpenter Signed-off-by: Peng Fan

scmi: pinctrl: add pinctrl driver for SCMI

2026-03-23T02:58:20Z

This driver adds the base support of pinctrl over SCMI. The driver does two main things. First, it allows you to configure the initial pin states. Secondly, it's used a base to build a GPIO driver on top of it. To configure the states then add a pinmux config to the scmi_pinctrl section: scmi_pinctrl: protocol@19 { reg = <0x19>; pinmux1: pinmux_test { pinmux = <0 1 0xFFFFFFFF 18 1 0 2 0xFFFFFFFF 18 1 0 3 0xFFFFFFFF 18 1>; function = "f_gpio1"; groups = "grp_1", "grp_3"; }; }; Under linux the pinctrl subsystem will parse the function and group properties and use that to handle muxing. However, under u-boot the pin muxing is done using the "pinmux" property, which feeds raw SCMI pinctrl PINCTRL_SETTINGS_CONFIGURE commands to the server. The numbers are: selector, identifier, function_id, config_type, and config_value. In the example above, it sets pins 1, 2, and 3 to 1. The linux-kernel ignores this pinmux property. Signed-off-by: Dan Carpenter Reviewed-by: Peng Fan Signed-off-by: Peng Fan

scmi: Rework SCMI_FIRMWARE implementation

2026-03-23T02:55:01Z

As exposed by "make randconfig", how we have SCMI_FIRMWARE today is incomplete, and in one case, used incorrectly. First, SCMI_FIRMWARE has a build-time dependency on OF_CONTROL being enabled, so add that. Second, RESET_SCMI depends on SCMI_FIRMWARE being enabled, it should not select that symbol. In turn, a number of platforms need to now enable SCMI_FIRMWARE explicitly and not rely on RESET_SCMI to enable it for them. Signed-off-by: Tom Rini Acked-by: Peng Fan Acked-by: Anshul Dalal Acked-by: Michal Simek # Versal Gen 2 Reviewed-by: Patrice Chotard Signed-off-by: Peng Fan

Merge tag 'v2026.04-rc4' into next

2026-03-09T21:26:34Z

Prepare v2026.04-rc4

firmware: scmi: Validate device tree node before setup channel

2026-02-26T15:04:46Z

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

Merge patch series "treewide: Clean up usage of DECLARE_GLOBAL_DATA_PTR"

2026-02-17T19:51:26Z

Peng Fan (OSS) says: This patch set primarily removes unused DECLARE_GLOBAL_DATA_PTR instances. Many files declare DECLARE_GLOBAL_DATA_PTR and include asm/global_data.h even though gd is never used. In these cases, asm/global_data.h is effectively treated as a proxy header, which is not a good practice. Following the Include What You Use principle, files should include only the headers they actually depend on, rather than relying on global_data.h indirectly. This approach is also adopted in Linux kernel [1]. The first few patches are prepartion to avoid building break after remove the including of global_data.h. A script is for filtering the files: list=`find . -name "*.[ch]"` for source in ${list} do result=`sed -n '/DECLARE_GLOBAL_DATA_PTR/p' ${source}` if [ "${result}" == "DECLARE_GLOBAL_DATA_PTR;" ]; then echo "Found in ${source}" result=`sed -n '/\/p' ${source}` result2=`sed -n '/\/p' ${source}` if [ "${result}" == "" ] && [ "${result2}" == "" ] && [ "${result3}" == "" ];then echo "Cleanup ${source}" sed -i '/DECLARE_GLOBAL_DATA_PTR/{N;/\n[[:space:]]*$/d;s/.*\n//;}' ${source} sed -i '/DECLARE_GLOBAL_DATA_PTR/d' ${source} sed -i '/global_data.h/d' ${source} git add ${source} fi fi done [1] https://lpc.events/event/17/contributions/1620/attachments/1228/2520/Linux%20Kernel%20Header%20Optimization.pdf CI: https://github.com/u-boot/u-boot/pull/865 Link: https://lore.kernel.org/r/20260209-cleanup-v2-0-73a3a84ddbdb@nxp.com

treewide: Clean up DECLARE_GLOBAL_DATA_PTR usage

2026-02-17T19:50:22Z

Remove DECLARE_GLOBAL_DATA_PTR from files where gd is not used, and drop the unnecessary inclusion of asm/global_data.h. Headers should be included directly by the files that need them, rather than indirectly via global_data.h. Reviewed-by: Patrice Chotard #STMicroelectronics boards and STM32MP1 ram test driver Tested-by: Anshul Dalal #TI boards Acked-by: Yao Zi #TH1520 Signed-off-by: Peng Fan