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

Merge branch 'qcom-next' of https://git.u-boot-project.org/u-boot/custodians/u-boot-snapdragon into next

2026-08-11T16:34:48Z

* Support for building mbn files during the build with the new mkmbn tool. * Remove UCLASS_SMEM and the old smem driver (Qualcomm was the only user of both), replace it with a port of the Linux SMEM driver. * Refactor memory map parsing and support reading the memory layout from the SMEM database. * Set the serial# from SMEM. * Introduce initial support for SPL in mach-snapdragon. * Add a defconfig for sm8650 with U-Boot as the primary bootloader. * Workaround an MMC issue by limiting the transfer size. * Add support for SM7125/SC7180 (clock/pinctrl drivers and UFS phy). * Add support for the QCS6490 powered Rubik Pi 3 board and document it.

usb: mtu3: add SPL support

2026-08-09T11:26:42Z

MediaTek platforms may need the MTU3 controller before U-Boot proper is available, but the driver is currently selected and built only with the main U-Boot configuration symbols. Add an explicit SPL controller option with host and gadget modes. Make the driver build and its role checks phase-aware so each phase can select the MTU3 role it needs without coupling it to the U-Boot proper controller configuration. The upstream binding locates the xHCI child registers through the parent ranges property. Select SPL_OF_TRANSLATE for host mode so SPL can resolve that address before mapping it. Signed-off-by: Julien Masson Signed-off-by: Carlo Caione Reviewed-by: Marek Vasut

drivers: allow clk_stub and spmi in SPL

2026-08-07T12:47:07Z

Only Makefile and Kconfig changes necessary. Signed-off-by: Michael Srba Reviewed-by: Simon Glass Reviewed-by: Casey Connolly Link: https://patch.msgid.link/20260521-qcom_spl-v9-3-c108ebe8ff4e@seznam.cz Signed-off-by: Casey Connolly

Revert "dm: SMEM (Shared memory) uclass"

2026-08-07T12:32:14Z

SMEM is a highly Qualcomm specific interface, while having a dedicated UCLASS for it offers a nice abstraction, for things like memory layout parsing we need to use it before the driver model is available. Therefore, it doesn't make sense to fit SMEM into the driver model. Instead let's adopt a model closer to Linux, and parse SMEM really early during boot (as soon as we have the FDT). This reverts commit 7b384eccc785b596f68448b155cbda26df57fb23. Reviewed-by: Sumit Garg Reviewed-by: Neil Armstrong Tested-by: Sumit Garg Link: https://patch.msgid.link/20260504-b4-modernise-smem-v2-1-c01ec2ff3886@linaro.org Signed-off-by: Casey Connolly

spl: Make UFS available for SPL builds

2026-03-12T08:30:44Z

Add minimal infrastructure to build SPL images with support for UFS storage devices. This also pulls in SCSI support and charset functions, which are dependencies of the UFS code. With this, only a fixed offset is supported for loading the next image, which should be specified in CONFIG_SPL_UFS_RAW_U_BOOT_SECTOR as the number of 4096-byte sectors into the UFS block device. Reviewed-by: Neil Armstrong Signed-off-by: Alexey Charkov Link: https://patch.msgid.link/20260120-rk3576-ufs-v5-1-0edb61b301b7@gmail.com Signed-off-by: Neil Armstrong

Introduce the Generic System Interconnect Subsystem

2025-11-20T08:17:58Z

Let's introduce the Generic System Interconnect subsystem based on the counterpart Linux framework which is used to vote for bandwidth across multiple SoC busses. Documentation for the Linux Generic System Interconnect Subsystem can be found at [1]. Each bus endpoints are materialised as "nodes" which are linked together, and the DT will specify a pair of nodes to enable and set a bandwidth on the route between those endpoints. The hardware resources that provide those nodes and provides the way to vote for the bandwidth are called "providers". The Interconnect uclass code is heavily based on the Linux one, with some small differences: - nodes are allocated as udevices instead of Linux idr_alloc() - tag management is minimal, only normal xlate is supported - getting nodes states at probe is not implemented - providers are probed on demand while the nodes links are traversed - nodes are populated on bind - id management is simplified, static IDs and dynamics IDs can be used - identical consume API as Linux, only implementation differs Fully tested with associated DM test suite. [1] https://docs.kernel.org/driver-api/interconnect.html Link: https://patch.msgid.link/20251120-topic-interconnect-next-v5-1-e8a82720da5d@linaro.org Signed-off-by: Neil Armstrong

spl: Add support for Device Firmware Upgrade (DFU) over PCIe

2025-11-06T09:17:05Z

Introduces support for Device Firmware Upgrade (DFU) over PCIe in U-Boot. Traditionally, the DFU protocol is used over USB, where a device enters DFU mode and allows a host to upload firmware or binary images directly via the USB interface. This is a widely adopted and convenient method for updating firmware. In the context of Texas Instruments (TI) SoCs, PCIe can be used as a boot interface in a manner that differs from the conventional "PCIe Boot" process, which typically refers to booting an OS or firmware image from an NVMe SSD or other PCIe-attached storage devices. Instead, TI SoCs can be configured as a PCIe Endpoint, allowing a connected PCIe Root Complex (host) to transfer images directly into the device’s memory over the PCIe bus for boot purposes. This mechanism is analogous to DFU over USB, but leverages the high-speed PCIe link and does not depend on traditional storage devices. By extending the DFU framework in U-Boot to support PCIe, it will be possible to flash images over PCIe. While this implementation is motivated by TI SoC use cases, the framework is generic and can be adopted by everyone for platforms that support PCIe Endpoint mode. Platforms with hardware support for PCIe-based memory loading can use this to implement PCIe as a boot mode, as well as to enable flashing and recovery scenarios similar to DFU over USB. In summary, enable support for: - DFU-style flashing of firmware/images over PCIe, analogous to existing USB DFU workflows - PCIe as a boot mode where a host can load images directly into device memory using DFU over PCIe Signed-off-by: Hrushikesh Salunke Reviewed-by: Mattijs Korpershoek Link: https://lore.kernel.org/r/20251023080922.3527052-1-h-salunke@ti.com Signed-off-by: Mattijs Korpershoek

drivers: Enabled Kconfig and Makefile for i3c support

2025-08-06T06:38:26Z

Add new i3c driver to U-Boot drivers. Signed-off-by: Dinesh Maniyam

Kbuild: Always use $(PHASE_)

2025-04-11T18:16:44Z

It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our Makefiles as part of the macros to determine when to do something in our Makefiles based on what phase of the build we are in. For consistency, bring this down to a single macro and use "$(PHASE_)" only. Signed-off-by: Tom Rini

mux: Makefile: Add config for mux drivers

2024-12-14T15:34:16Z

Add config required to build mmio-mux driver and dependencies. Signed-off-by: Anurag Dutta