[U-Boot] [PATCH] usb: dwc3: gadget: make cache-maintenance on event buffers more robust

[Felipe Balbi <felipe.balbi@linux.intel.com>]

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).

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170405/c3ccbc9d/attachment.sig>