[U-Boot] [PATCH 0/7] USB: XHCI: Add xHCI host controller stack driver

[Julius Werner]

Hi Dan,

I've just had a quick glance over the patches you referenced, so
please let me know if I'm making wrong assumptions. Your approach
seems to be to copy the relevant drivers (especially the whole XHCI
stack) from Linux whole and then make as few modifications as possible
to make them run under U-Boot. Is the code you posted actually
functional in its current state, i.e. can you access USB devices
through an XHCI controller?

I think you would need to make major architectural changes to the
driver stack to make it functional under U-Boot. Linux assumes an
asynchronous, interrupt-driven event model where multiple USB
transfers can be enqueued/completed in parallel. Without interrupts
and kernel threads/completions, you will essentially have to rework
the whole event handling to use some kind of polling mechanism and
eventually get back to the single-fire, synchronous USB transfers that
the U-Boot USB core stack expects. Your approach seems to be focused
on changing as little as possible, but I fear that by the time you
have a working solution you will have made so many changes that simply
"syncing back up" to a new release of Linux will be very hard. You
will also need to take the whole nightmare of cache invalidation into
account which Linux easily side-steps through uncacheable memory
mappings (and maintain correctness when you pull in new updates from
it).

Vivek has started out with the same Linux stack, but then cut away
everything that wasn't essential to U-Boot's requirements, reducing
code size and complexity to a more manageable chunk. I think in the
long run it would be easier to have a smaller stack that we have to
maintain ourselves than trying to keep a copy of Linux in sync that
has still been so heavily modified that it takes a lot of effort to
backport stuff. I have worked with Vivek's stack and can confirm that
it's reasonably fast and functional... there are still a few buggy
edge cases here and there, but at least USB storage and network
booting works with all devices we tested.

I don't know very much about the gadget side which you also seem to be
tackling, but I wouldn't be surprised if you are going to have a hard
time with the same issues there as well (interrupt/event model, data
cache consistency). Abstracting out the DWC3 stuff and sharing it
between Exynos/OMAP/... certainly sounds sensible, although I think
that when you cut away all the non-U-Boot-relevant parts there may
only be one or two dozen lines left to share.

Just my two cents.