1. 16 Jun, 2011 16 commits
  2. 15 Jun, 2011 3 commits
  3. 13 Jun, 2011 11 commits
  4. 12 Jun, 2011 9 commits
  5. 11 Jun, 2011 1 commit
    • Mika Westerberg's avatar
      net: ep93xx_eth: fix DMA API violations · f1c089e3
      Mika Westerberg authored
      Russell King said:
      >
      > So, to summarize what its doing:
      >
      > 1. It allocates buffers for rx and tx.
      > 2. It maps them with dma_map_single().
      >       This transfers ownership of the buffer to the DMA device.
      > 3. In ep93xx_xmit,
      > 3a. It copies the data into the buffer with skb_copy_and_csum_dev()
      >       This violates the DMA buffer ownership rules - the CPU should
      >       not be writing to this buffer while it is (in principle) owned
      >       by the DMA device.
      > 3b. It then calls dma_sync_single_for_cpu() for the buffer.
      >       This transfers ownership of the buffer to the CPU, which surely
      >       is the wrong direction.
      > 4. In ep93xx_rx,
      > 4a. It calls dma_sync_single_for_cpu() for the buffer.
      >       This at least transfers the DMA buffer ownership to the CPU
      >       before the CPU reads the buffer
      > 4b. It then uses skb_copy_to_linear_data() to copy the data out.
      >       At no point does it transfer ownership back to the DMA device.
      > 5. When the driver is removed, it dma_unmap_single()'s the buffer.
      >       This transfers ownership of the buffer to the CPU.
      > 6. It frees the buffer.
      >
      > While it may work on ep93xx, it's not respecting the DMA API rules,
      > and with DMA debugging enabled it will probably encounter quite a few
      > warnings.
      
      This patch fixes these violations.
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@iki.fi>
      Acked-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: default avatarH Hartley Sweeten <hsweeten@visionengravers.com>
      Tested-by: default avatarPetr Stetiar <ynezz@true.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f1c089e3