Hi, "Dr. Philipp Tomsich" <philipp.toms...@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). -- balbi
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
