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

xilinx: versal2: Clean UFS firmware interface

2026-08-12T04:55:15Z

The M-PHY and SRAM readiness poll loops move out of the UFS controller driver and into the firmware backend, exposed as blocking waits with a caller-owned timeout budget. This keeps the UFS driver backend-agnostic and lets an other backends offload the wait to the platform in a single call instead of round-tripping every poll. set_sram_bypass() now performs the SRAM_CSR read-modify-write in the firmware layer. Hook up functions are also update to reflect their usage. Signed-off-by: Michal Simek Link: https://patch.msgid.link/26bc9aa2c02921690e126ab3401f7974ef04ad6e.1785394153.git.michal.simek@amd.com

xilinx: versal2: Add PM UFS firmware interface

2026-08-12T04:55:14Z

Add firmware interface for UFS access but also keep IO interface when firmware is not enabled. Signed-off-by: Michal Simek Link: https://patch.msgid.link/6419fe4f6f1f451aee624c7762b7aa690d50e498.1784870711.git.michal.simek@amd.com

firmware: zynqmp: Remove duplicated sys_proto.h header

2026-08-12T04:55:14Z

asm/arch/sys_proto.h is included twice that's why remove one. Signed-off-by: Michal Simek Link: https://patch.msgid.link/cd3c11a7e09ed8db3945910cdfed0eb860dcd61e.1784870326.git.michal.simek@amd.com

firmware: scmi: Support probe vendor ID 0x81

2026-08-11T07:44:32Z

Preparing to add the AMD/Xilinx SCMI vendor protocol driver, support probe of SCMI vendor ID 0x81. Add the protocol ID, the per-agent protocol device slot, the probe/lookup switch cases and the scmi command name, gated by a Kconfig option for conditional compilation. The same wiring has been done by commit 7830ccc77a13 ("firmware: scmi: Support probe vendor ID 0x80 and 0x82"). Signed-off-by: Michal Simek Signed-off-by: Peng Fan

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