1. 05 Sep, 2019 2 commits
  2. 04 Sep, 2019 36 commits
  3. 03 Sep, 2019 2 commits
    • Colin Ian King's avatar
      spi: npcm-fiu: fix spelling mistake "frequancy" -> "frequency" · 0d6fccc1
      Colin Ian King authored
      There is a spelling mistake in a dev_warning message. Fix it. Also
      break line to clear up checkpatch warning.
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Link: https://lore.kernel.org/r/20190903122812.3986-1-colin.king@canonical.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      0d6fccc1
    • Vladimir Oltean's avatar
      spi: spi-fsl-dspi: Fix race condition in TCFQ/EOQ interrupt · e3273649
      Vladimir Oltean authored
      When the driver is working in TCFQ/EOQ mode (i.e. interacts with the SPI
      controller's FIFOs directly) the following sequence of operations
      happens:
      
      - The first byte of the tx buffer gets pushed to the TX FIFO (dspi->len
        gets decremented). This triggers the train of interrupts that handle
        the rest of the bytes.
      
      - The dspi_interrupt handles a TX confirmation event. It reads the newly
        available byte from the RX FIFO, checks the dspi->len exit condition,
        and if there's more to be done, it kicks off the next interrupt in the
        train by writing the next byte to the TX FIFO.
      
      Now the problem is that the wait queue is woken up one byte too early,
      because dspi->len becomes 0 as soon as the byte has been pushed into the
      TX FIFO. Its interrupt has not yet been processed and the RX byte has
      not been put from the FIFO into the buffer.
      
      Depending on the timing of the wait queue wakeup vs the handling of the
      last dspi_interrupt, it can happen that the main SPI message pump thread
      has already returned back into the spi_device driver. When the rx buffer
      is on stack (which it can be, because in this mode, the DSPI doesn't do
      DMA), the last interrupt will perform a memory write into an rx buffer
      that has been freed. This manifests as stack corruption.
      
      The solution is to only wake up the wait queue when dspi_rxtx says so,
      i.e. after it has processed the last TX confirmation interrupt and
      collected the last RX byte.
      
      Fixes: c55be305 ("spi: spi-fsl-dspi: Use poll mode in case the platform IRQ is missing")
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Link: https://lore.kernel.org/r/20190903105708.32273-1-olteanv@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      e3273649