On Mon, May 11, 2026 at 01:57:25PM +0530, Anshul Dalal wrote:
> 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?For something this big and still RFC, perhaps a pointer to a public tree is OK, until there's some substantive feedback from Marek? -- Tom
signature.asc
Description: PGP signature
