From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felipe Balbi Date: Wed, 05 Apr 2017 12:49:39 +0300 Subject: [U-Boot] [PATCH] usb: dwc3: gadget: make cache-maintenance on event buffers more robust In-Reply-To: References: <1491241798-37084-1-git-send-email-philipp.tomsich@theobroma-systems.com> <8bb1f19c-a7f5-bbc8-3a0d-6c2de73a7410@denx.de> <52CB490A-0557-4C75-99B9-B9137D85C789@theobroma-systems.com> <87wpazgtde.fsf@linux.intel.com> Message-ID: <87k26zgp58.fsf@linux.intel.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de Hi, "Dr. Philipp Tomsich" 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: