1. 19 Feb, 2017 4 commits
    • Mark Brown's avatar
      34904623
    • Mark Brown's avatar
      42af2f5c
    • Mark Brown's avatar
      Merge remote-tracking branches 'spi/fix/pxa2xx', 'spi/fix/rspi' and... · e0afd0fa
      Mark Brown authored
      Merge remote-tracking branches 'spi/fix/pxa2xx', 'spi/fix/rspi' and 'spi/fix/s3c64xx' into spi-linus
      e0afd0fa
    • Mark Brown's avatar
      Merge tag 'spi-fix-v4.10-rc4' into spi-linus · d2f68a05
      Mark Brown authored
      spi: Fixes for v4.10
      
      The usual small smattering of driver specific fixes.  A few bits that
      stand out here:
      
       - The R-Car patches adding fallbacks are just adding new compatible
         strings to the driver so that device trees are written in a more
         robustly future proof fashion, this isn't strictly a fix but it's
         just new IDs and it's better to get it into mainline sooner to
         improve the ABI.
       - The DesignWare "switch to new API part 2" patch is actually a
         misleadingly titled fix for a bit that got missed in the original
         conversion.
      
      # gpg: Signature made Thu 19 Jan 2017 14:54:15 GMT
      # gpg:                using RSA key ADE668AA675718B59FE29FEA24D68B725D5487D0
      # gpg:                issuer "broonie@kernel.org"
      # gpg: key 0D9EACE2CD7BEEBC: no public key for trusted key - skipped
      # gpg: key 0D9EACE2CD7BEEBC marked as ultimately trusted
      # gpg: key CCB0A420AF88CD16: no public key for trusted key - skipped
      # gpg: key CCB0A420AF88CD16 marked as ultimately trusted
      # gpg: key 162614E316005C11: no public key for trusted key - skipped
      # gpg: key 162614E316005C11 marked as ultimately trusted
      # gpg: key A730C53A5621E907: no public key for trusted key - skipped
      # gpg: key A730C53A5621E907 marked as ultimately trusted
      # gpg: key 276568D75C6153AD: no public key for trusted key - skipped
      # gpg: key 276568D75C6153AD marked as ultimately trusted
      # gpg: Good signature from "Mark Brown <broonie@sirena.org.uk>" [ultimate]
      # gpg:                 aka "Mark Brown <broonie@debian.org>" [ultimate]
      # gpg:                 aka "Mark Brown <broonie@kernel.org>" [ultimate]
      # gpg:                 aka "Mark Brown <broonie@tardis.ed.ac.uk>" [ultimate]
      # gpg:                 aka "Mark Brown <broonie@linaro.org>" [ultimate]
      # gpg:                 aka "Mark Brown <Mark.Brown@linaro.org>" [ultimate]
      d2f68a05
  2. 16 Feb, 2017 2 commits
    • DongCV's avatar
      spi: rspi: Replaces "n" by "len" in qspi_transfer_*() · ad16d4a8
      DongCV authored
      This patch replaced "n" by "len" bytes of data in qspi_transfer_in() and
      qspi_transfer_out() function. This will make improving readability.
      Signed-off-by: default avatarDongCV <cv-dong@jinso.co.jp>
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      ad16d4a8
    • DongCV's avatar
      spi: rspi: Fixes bogus received byte in qspi_transfer_in() · 7264abc7
      DongCV authored
      In qspi_transfer_in(), when receiving the last n (or len) bytes of data,
      one bogus byte was written in the receive buffer.
      This code leads to a buffer overflow.
      
      "jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
      at 0x03b40000: 0x1900 instead
      jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
      at 0x03b40004: 0x000c instead"
      
      The error message above happens when trying to mount, unmount,
      and remount a jffs2-formatted device.
      This patch removed the bogus write to fixes: 3be09bec
      "spi: rspi: supports 32bytes buffer for DUAL and QUAD"
      
      And here is Geert's comment:
      
      "spi: rspi: Fix bogus received byte in qspi_transfer_in()
      When there are less than QSPI_BUFFER_SIZE remaining bytes to be received,
      qspi_transfer_in() writes one bogus byte in the receive buffer, possibly
      leading to a buffer overflow.
      This can be reproduced by mounting, unmounting, and remounting a
      jffs2-formatted device, causing lots of warnings like:
      
      "jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
      at 0x03b40000: 0x1900 instead"
      
      Remove the bogus write to fix this. "
      Signed-off-by: default avatarDongCV <cv-dong@jinso.co.jp>
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      7264abc7
  3. 13 Feb, 2017 1 commit
  4. 31 Jan, 2017 3 commits
    • Johan Hovold's avatar
      spi: fix device-node leaks · 8324147f
      Johan Hovold authored
      Make sure to release the device-node reference taken in
      of_register_spi_device() on errors and when deregistering the device.
      
      Fixes: 284b0189 ("spi: Add OF binding support for SPI busses")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      8324147f
    • Daniel Kurtz's avatar
      spi: mediatek: Only do dma for 4-byte aligned buffers · 1ce24864
      Daniel Kurtz authored
      Mediatek SPI DMA only works when tx and rx buffer addresses are 4-byte
      aligned.
      
      Unaligned DMA transactions appeared to work previously, since we the
      spi core was incorrectly using the spi_master device for dma, which
      had a 0 dma_mask, and therefore the swiotlb dma map operations were
      falling back to using bounce buffers.  Since each DMA transaction would
      use its own buffer, the mapped starting address of each transaction was
      always aligned.  When doing real DMA, the mapped address will share the
      alignment of the raw tx/rx buffer provided by the SPI user, which may or
      may not be aligned.
      
      If a buffer is not aligned, we cannot use DMA, and must use FIFO based
      transaction instead.
      
      So, this patch implements a scheme that allows using the FIFO for
      arbitrary length transactions (larger than the 32-byte FIFO size) by
      reloading the FIFO in the interrupt handler.
      Signed-off-by: default avatarDaniel Kurtz <djkurtz@chromium.org>
      Cc: Leilk Liu <leilk.liu@mediatek.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      1ce24864
    • Daniel Kurtz's avatar
      spi: When no dma_chan map buffers with spi_master's parent · 88b0aa54
      Daniel Kurtz authored
      Back before commit 1dccb598 ("arm64: simplify dma_get_ops"), for
      arm64, devices for which dma_ops were not explicitly set were automatically
      configured to use swiotlb_dma_ops, since this was hard-coded as the
      global "dma_ops" in arm64_dma_init().
      
      Now that global "dma_ops" has been removed, all devices much have their
      dma_ops explicitly set by a call to arch_setup_dma_ops(), otherwise the
      device is assigned dummy_dma_ops, and thus calls to map_sg for such a
      device will fail (return 0).
      
      Mediatek SPI uses DMA but does not use a dma channel.  Support for this
      was added by commit c37f45b5 ("spi: support spi without dma channel
      to use can_dma()"), which uses the master_spi dev to DMA map buffers.
      
      The master_spi device is not a platform device, rather it is created
      in spi_alloc_device(), and therefore its dma_ops are never set.
      
      Therefore, when the mediatek SPI driver when it does DMA (for large SPI
      transactions > 32 bytes), SPI will use spi_map_buf()->dma_map_sg() to
      map the buffer for use in DMA.  But dma_map_sg()->dma_map_sg_attrs() returns
      0, because ops->map_sg is dummy_dma_ops->__dummy_map_sg, and hence
      spi_map_buf() returns -ENOMEM (-12).
      
      Fix this by using the real spi_master's parent device which should be a
      real physical device with DMA properties.
      Signed-off-by: default avatarDaniel Kurtz <djkurtz@chromium.org>
      Fixes: c37f45b5 ("spi: support spi without dma channel to use can_dma()")
      Cc: Leilk Liu <leilk.liu@mediatek.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      88b0aa54
  5. 19 Jan, 2017 1 commit
  6. 17 Jan, 2017 6 commits
  7. 12 Jan, 2017 1 commit
  8. 09 Jan, 2017 1 commit
  9. 04 Jan, 2017 2 commits
  10. 31 Dec, 2016 1 commit
  11. 20 Dec, 2016 1 commit
  12. 16 Dec, 2016 1 commit
  13. 14 Dec, 2016 3 commits
  14. 12 Dec, 2016 9 commits
  15. 11 Dec, 2016 4 commits