Hi,
"Dr. Philipp Tomsich" philipp.tomsich@theobroma-systems.com writes:
Good point on the “long”, especially as I just copied this from other occurences and it’s consistently wrong throughout DWC3 in U-Boot:
Hrm, I thought the driver was ported over from Linux, so is this broken in Linux too ?
haven't seen a problem in almost 6 years dealing with this IP.
The integer-sizes on the flushing really aren’t a big issue, as everyone runs from the lower 32bits as of today. And it could easily be another 6 years, before we hit the first 64bit address for any of the buffers being flushed. Even as the integer types on the dwc3_flush_range are consistently mismatches, that is just a sideshow and doesn’t cause any issues for anyone.
The big one for us is really the patch submitted to reorder the flushes (i.e. clean+invalidate operations), as we sometimes (depends both on what happened before that in U-Boot — e.g. using the network stack will always hide this — and on what configuration we compile into U-Boot) have cachelines matching the allocation via dma_alloc_coherent either as cached (or possibly even as modified) in our cache.
Any opinion on changing the sequencing of cache-maintenance relative to the payload?
no opinion, no. We've had one similar issue in linux WRT RNDIS. It was a very similar situation (cache maintenance was ordered wrongly and ended up corrupting req->buf).