Re: Regarding commit a16dad7 [MIPS: Fix potencial corruption]

[Kevin Cernekee <cernekee@gmail.com>]

On Tue, Jan 1, 2013 at 1:23 AM, Shmulik Ladkani
<shmulik.ladkani@gmail.com> 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 .

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.