Hi Kevin, On Tue, 1 Jan 2013 01:47:52 -0800 Kevin Cernekee <cernekee@xxxxxxxxx> wrote: > On Tue, Jan 1, 2013 at 1:23 AM, Shmulik Ladkani > <shmulik.ladkani@xxxxxxxxx> wrote: > > Following a8ca8b64, another commit was submitted, adding similar > > 'cache_op' instructions to 'mips_sc_inv' - namely 96983ffe > > (MIPS: MIPSxx SC: Avoid destructive invalidation on partial L2 cachelines). > > > > Its purpose was to extend a8ca8b64, aligning behavior of 'mips_sc_inv' > > to be similar to 'r4k_dma_cache_inv'. > > > > Since the explicit 'cache_op' instrcutions are now removed from > > 'r4k_dma_cache_inv' (as of a16dad77), it probably makes sense to remove > > them from 'mips_sc_inv' as well. > > > > Any reason to keep these 'cache_op's? If not, I'll submit a patch. > > There were a couple of USB drivers that stored DMA buffers inside a > struct with other data, and invalidating the whole cacheline tended to > clobber the other data. For instance, intr_buff in > drivers/net/usb/pegasus.h . I see. > Does CONFIG_DMA_API_DEBUG complain if it sees unaligned start > addresses or sizes? That would be a much nicer way of catching the > problem, than troubleshooting random corruption. Have no idea ;) Hoping for Ralf to examine this. I accidentally happened to notice an anomaly in the code: a revert was executed (by Ralf Baechle in a16dad77), but it was incomplete: (1) the comment was left, (2) revert wasn't executed on 'mips_sc_inv'. Just pointing out the anomalies, for Ralf to acknowledge whether they were deliberate or not. Regards, Shmulik
