u-boot.git/drivers/usb/dwc3, branch v2026.01

usb: dwc3: Remove redundant test

2025-09-30T09:55:23Z

In dwc3_ep0_complete_data there is a test for 'r' being null and the code will return at that point if so. After that point 'r' is guaranteed to not be null and testing for that is redundant. Remove the test for 'r' being non-null. This issue was found by Smatch. Signed-off-by: Andrew Goodbody Reviewed-by: Mattijs Korpershoek Reviewed-by: Marek Vasut Link: https://lore.kernel.org/r/20250929-dwc3_ep0-v1-1-1d5c58933bde@linaro.org Signed-off-by: Mattijs Korpershoek

usb: dwc3: Tighten driver glue dependencies

2025-09-25T22:06:00Z

A few of the platform specific DWC3 host glue drivers cannot build without access to some platform specific header files. Express those requirements in Kconfig as well. Reviewed-by: Marek Vasut Signed-off-by: Tom Rini

Merge patch series "Fix dma_addr_t for R5 SPL"

2025-09-11T16:03:12Z

Anshul Dalal says: On various TI's K3 platforms boot failure was observed on SPI NOR since the commit 5609f200d062 ("arm: Kconfig: enable LTO for ARCH_K3"). This issue was root caused to stack corruption by the 'udma_transfer' function. Where the local variable 'paddr' of type 'dma_addr_t' was being written to as a 64-bit value which overwrote the stack frame of the caller (dma_memcpy) as only 32-bits had been reserved for paddr on the stack, specifically the r4 register in the frame of dma_memcpy was being overwritten with a 0. drivers/dma/ti/k3-udma.c:2192: int udma_transfer(...) { ... dma_addr_t paddr = 0; ... /* paddr was written to as 64-bit value here */ udma_poll_completion(uc, &paddr); } drivers/dma/dma-uclass.c:234: int dma_memcpy(...) { dma_addr_t destination; dma_addr_t source; int ret; ... /* This call resolves to udma_transfer */ ret = ops->transfer(...); ... dma_unmap_single(destination, ...); dma_unmap_single(...); return ret; } Enabling LTO changed how gcc mapped local variables of dma_memcpy to CPU registers, where earlier the bug was hidden since the overwritten register 'r4' was allotted to 'ret' but was allotted to 'destination' once LTO was enabled. And since the overwritten value was 0, the bug remained undetected as it just meant ret was 0, but having 'destination' set to 0 caused dma_unmap_single to fail silently leading to boot failures. The fix entails enabling DMA_ADDR_T_64BIT which changes dma_addr_t from u32 to u64 for the R5 SPL thus reserving enough space for 'paddr' to prevent the overflow. Link: https://lore.kernel.org/r/20250903115207.572304-1-anshuld@ti.com

dma: ti: k3-udma: fix dma_addr_t typecasts

2025-09-11T16:03:02Z

dma_addr_t is used to store any valid DMA address which might not necessarily be the same size as host architecture's word size. Though various typecasts in k3's dma and usb driver expect dma_addr_t to be the same size as the word size. This leads the compiler to throw a "cast from pointer to integer of different size" warning when the condition is not met, for example when enabling CONFIG_DMA_ADDR_T_64BIT for the R5 core. Therefore this patch fixes the typecasts by using 'uintptr_t' as an intermediary type which is guaranteed to be the same size as void* on the host architecture. Thus, eliminating the compiler warning. Signed-off-by: Anshul Dalal

usb: dwc3-generic: Use combined glue and ctrl node for RK3528

2025-08-30T15:26:08Z

Like Rockchip RK3328, RK3568 and RK3588, the RK3528 also have a single node to represent the glue and ctrl for USB 3.0. Use rk_ops as driver data to select correct ctrl node for RK3528 DWC3. Signed-off-by: Jonas Karlman Reviewed-by: Kever Yang

usb: dwc3-generic: Use combined glue and ctrl node for RK3576

2025-08-30T15:01:29Z

Like Rockchip RK3328, RK3568 and RK3588, the RK3576 also have a single node to represent the glue and ctrl for USB 3.0. Use rk_ops as driver data to select correct ctrl node for RK3576 DWC3. Signed-off-by: Jonas Karlman Reviewed-by: Kever Yang

usb: dwc3-generic: Add Exynos850 support

2025-07-25T01:17:21Z

The only thing needed from DWC3 glue layer for Exynos850 is to enable USB clocks. The generic glue layer driver already does that. Add Exynos850 dwc3 compatible string to enable support for this chip. Signed-off-by: Sam Protsenko Reviewed-by: Mattijs Korpershoek Signed-off-by: Minkyu Kang

usb: dwc3: core: Fix timeout check

2025-05-25T13:44:13Z

dwc3_core_init loops 'timeout' times to check if the IP block is out of reset using 'while (timeout--)'. If there is some issue and the block doesn't come out of reset, the loop will run till 'timeout' becomes zero and the post decrement operator would set timeout to 0xffffffff. Though the IP block is not out reset, the subsequent if check 'if !timeout' would fail as timeout is not equal to zero and the function proceeds with the initialization. Use poll API instead to resolve this. Signed-off-by: Varadarajan Narayanan Reviewed-by: Mattijs Korpershoek Reviewed-by: Caleb Connolly

Merge patch series "Switch to using $(PHASE_) in Makefiles"

2025-04-11T18:16:49Z

Tom Rini says: This series switches to always using $(PHASE_) in Makefiles when building rather than $(PHASE_) or $(XPL_). It also starts on documenting this part of the build, but as a follow-up we need to rename doc/develop/spl.rst and expand on explaining things a bit. Link: https://lore.kernel.org/r/20250401225851.1125678-1-trini@konsulko.com

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