u-boot.git/drivers/firmware, branch master

treewide: Kconfig: use bool instead of tristate

2026-07-10T21:45:57Z

U-Boot does not support modules, so having tristate options is useless. Therefore this patch does a blind replace of all tristate options to bool tree-wide. Signed-off-by: Anshul Dalal Reviewed-by: Heiko Schocher Reviewed-by: Quentin Schulz Reviewed-by: Siddharth Vadapalli Reviewed-by: Neha Malcom Francis Reviewed-by: Romain Gantois Reviewed-by: Simon Glass

arm64: zynqmp: Decouple MMIO accessors from firmware

2026-07-08T06:55:51Z

zynqmp_mmio_read() and zynqmp_mmio_write() selected between direct MMIO and the firmware (PM_MMIO_READ/WRITE) interface with an in-function IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) / current_el() check. Generic arch code should not carry firmware-specific ifdefs, and with SCMI the access method changes again. Split the accessors like the multiboot and bootmode hooks: the weak default in arch/arm/mach-zynqmp does the direct MMIO access (used in SPL, at EL3 and when no firmware is present), while firmware-zynqmp.c provides a strong definition that issues the firmware call and falls back to the direct access in SPL/EL3 where the SMC path is unavailable. The raw MMIO primitives zynqmp_mmio_rawread() and zynqmp_mmio_rawwrite() are exported for the shared fallback, and the read-modify-write helper now uses the raw read instead of routing through the firmware-aware accessor. The firmware-vs-MMIO decision is selected at link time, so adding SCMI later only requires a third strong definition with no changes to generic code. Signed-off-by: Michal Simek Link: https://patch.msgid.link/d532df144d2c8e34be835bad6d0de3b26befdf01.1782219202.git.michal.simek@amd.com

arm64: versal-net: Move bootmode decoding out of board code

2026-07-08T06:55:51Z

versal_net_get_bootmode() open-coded the IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) selection between the firmware call zynqmp_pm_get_bootmode_reg() and a direct readl() in board code. Like the Versal change, move the whole function behind an overridable hook so generic board code stays free of firmware specifics and is ready for SCMI. The weak versal_net_get_bootmode() in arch/arm/mach-versal-net does the plain MMIO read via versal_net_bootmode_reg() and decodes it (used at EL3 and without firmware). When CONFIG_ZYNQMP_FIRMWARE is enabled, firmware-zynqmp.c provides a strong definition that reads the register through the firmware call, falling back to the direct read at EL3 where the SMC path to firmware is unavailable. This preserves the existing firmware-based bootmode behaviour while removing the firmware interface from board code; the now unused zynqmp_firmware.h include is dropped. Signed-off-by: Michal Simek Link: https://patch.msgid.link/be67e9c6d0bc36840a46594413886d2003967c64.1782219202.git.michal.simek@amd.com

arm64: versal: Move bootmode decoding out of board code

2026-07-08T06:55:51Z

versal_get_bootmode() lived in board code and open-coded the IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) selection between the firmware call zynqmp_pm_get_bootmode_reg() and a direct readl(). To keep generic board code free of firmware specifics and SoC register details and ready for SCMI, move the whole function, including the alt-shift and mask decoding, behind an overridable hook. The weak versal_get_bootmode() in arch/arm/mach-versal does the plain MMIO read via versal_bootmode_reg() and decodes it (used at EL3 and without firmware). When CONFIG_ZYNQMP_FIRMWARE is enabled, firmware-zynqmp.c provides a strong definition that reads the register through the firmware call, falling back to the direct read at EL3 where the SMC path to firmware is unavailable. This preserves the existing firmware-based bootmode behaviour while removing the firmware interface from board code; the now unused zynqmp_firmware.h include is dropped. Signed-off-by: Michal Simek Link: https://patch.msgid.link/d60073feed8da8d3aff9eabee6ab132e0bbd0f8e.1782219202.git.michal.simek@amd.com

arm64: versal: Decouple multiboot register access from firmware

2026-07-08T06:55:51Z

versal_multi_boot() in board code selected between the firmware call zynqmp_pm_get_pmc_multi_boot_reg() and a direct readl() based on an IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) check. Generic board code should not carry firmware-specific ifdefs, and this becomes harder to maintain once SCMI introduces yet another access method. Introduce an overridable accessor versal_pmc_multi_boot(). The weak default lives in arch/arm/mach-versal and performs the plain MMIO read (used at EL3 and when no firmware is present). When CONFIG_ZYNQMP_FIRMWARE is enabled, firmware-zynqmp.c provides a strong definition that issues the firmware call, falling back to the direct read at EL3 where the SMC path to firmware is unavailable. The shared MMIO read is factored into versal_multi_boot_reg() so the firmware override does not duplicate it. versal_multi_boot() keeps the generic JTAG/QEMU workaround and simply calls the accessor, so board code no longer references the firmware interface for the multiboot register. The firmware-vs-MMIO decision is selected at link time, and adding SCMI later only requires a third strong definition with no board-code changes. Signed-off-by: Michal Simek Link: https://patch.msgid.link/199ef6a1411c54f154fe4a43b5fef166b9927f7a.1782219202.git.michal.simek@amd.com

arm64: versal2: Decouple multiboot register access from firmware

2026-07-08T06:55:51Z

versal2_multi_boot() in board code selected between the firmware call zynqmp_pm_get_pmc_multi_boot_reg() and a direct readl() based on an IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) check. Generic board code should not carry firmware-specific ifdefs, and this becomes harder to maintain once SCMI introduces yet another access method. Introduce an overridable accessor versal2_pmc_multi_boot(). The weak default lives in arch/arm/mach-versal2 and performs the plain MMIO read (used at EL3 and when no firmware is present). When CONFIG_ZYNQMP_FIRMWARE is enabled, firmware-zynqmp.c provides a strong definition that issues the firmware call, falling back to the direct read at EL3 where the SMC path to firmware is unavailable. The shared MMIO read is factored into versal2_multi_boot_reg() so the firmware override does not duplicate it. versal2_multi_boot() keeps the generic JTAG/QEMU workaround and simply calls the accessor, so board code no longer references the firmware interface and the now unused zynqmp_firmware.h include is dropped. The firmware-vs-MMIO decision is selected at link time, and adding SCMI later only requires a third strong definition with no board-code changes. Signed-off-by: Michal Simek Link: https://patch.msgid.link/0033a1fa8efb4ae0c3ac6a6f5c5c1b4e0f22f02c.1782219202.git.michal.simek@amd.com

Merge branch 'next'

2026-07-07T00:26:12Z

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: zynqmp: Add PMC PGGS register read API

2026-06-08T08:50:05Z

Add zynqmp_pm_get_pmc_global_pggs_reg() to read PMC Global PGGS3 and PGGS4 registers via firmware IOCTL. Supports IOCTL_READ_PGGS as the preferred path and falls back to IOCTL_READ_REG for older PLM firmware versions that do not support IOCTL_READ_PGGS. Signed-off-by: Padmarao Begari Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/20260514102601.1759779-3-padmarao.begari@amd.com

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