Re: [RFC PATCH v2 00/64] drivers: usb: dwc3: sync code with Linux v6.16-rc7

[Anshul Dalal <anshuld@ti.com>]

On Thu May 7, 2026 at 2:57 PM IST, Jens Wiklander wrote:
> Hi,
>
> This is a follow-up to Jerome's patchset [1], addressing previous feedback
> regarding the monolithic nature of the driver update.
>
> The DWC3 USB driver was forked from the Linux kernel v3.19-rc1 eleven years
> ago by commit 85d5e7075f33 ("usb: dwc3: add dwc3 folder from linux kernel
> to u-boot"). Since then, not many kernel changes have been ported back into
> U-Boot.
>
> This series synchronizes the DWC3 core with Linux v6.16-rc7. To provide 
> a clear audit trail and maintain bisectability, I have structured the 
> series as follows:
>
> 1. Restore to Baseline: The first commit reverts U-Boot-specific changes 
>    to drivers/usb/dwc3 to return the directory to a clean v3.19-rc1 state.
> 2. Milestone Imports: A sequence of 50+ commits follows, each performing 
>    a "snapshot" import of the drivers/usb/dwc3 directory for every major 
>    kernel version (v3.19 through v6.16-rc7). 
> 3. U-Boot Adaptation: The final commits (based on Jerome's original work) 
>    re-introduce the necessary glue code, XHCI/UDC updates, and build fixes 
>    required for U-Boot integration.
>
> The final diff is identical to [1]. I decided to stick with that for now to
> focus on the method of how we import or update the code.
>
> Note that this is compile-tested only. The CI pipeline on source.denx.de
> was used as an OK/NOK indicator [2]. 
>
> The previous patchset was tested on xilinx_zynqmp_kria_defconfig and since
> this diff is identical to the previous, it should still work on that
> platform. With the help of a custom build script [3] and with an additional
> patch [4], I could boot the Kria KV260 board and make it detect a USB SSD
> plugged into one of its USB 3.0 ports. It certainly doesn't mean all
> platforms using the DWC3 driver are still OK, but at least there is some
> hope. If this breaks your platform I'd like to know, and if you can send a
> fix it's even better.
>
> I tried cherry-picking all the 1000+ patches in v3.19-rc1..v6.16-rc7. There
> were a few conflicts, even when backing out the original U-Boot patches on
> top of the original v3.19-rc1 import. However, the resulting state still
> diverged significantly from [1].
>
> Instead, I've imported each new kernel in a separate commit. That way it's
> very clear which kernel patches are included. Since there aren't too many
> patches for each kernel I'm listing the relevant commits in the U-Boot
> commit message for easier reference. I did this with a script so it's easy
> to make changes, if the approach is OK but we need to tune it. With this
> approach it should be easy to tell if a Fixes patch for the kernel might
> also be needed here.

Hi Jens,

Thanks for the work though I wasn't able to test out the series since it
doesn't apply cleanly on master.

Could you respin with a rebase?

CC+: Chintan, Siddharth

Regards,
Anshul