linux/drivers/spi, branch v3.15

Merge remote-tracking branches 'spi/fix/pxa2xx' and 'spi/fix/qup' into spi-linus

2014-05-13T18:08:34Z

Merge remote-tracking branch 'spi/fix/core' into spi-linus

2014-05-13T18:08:33Z

spi/pxa2xx: Prevent DMA from transferring too many bytes

2014-05-12T21:05:37Z

In case we are doing DMA transfer and the size of the buffer is not multiple of 4 bytes the driver truncates that to 4-byte boundary and tries to handle remaining bytes using PIO. Or that is what it tried to do. What actually happens is that it calls ALIGN() to the buffer size which aligns it to the next 4-byte boundary (doesn't truncate). Doing this results 1-3 bytes extra to be transferred. Furthermore we handle remaining bytes using PIO which results one extra byte to be transferred. In worst case the driver transfers 4 extra bytes. While investigating this it turned out that the DMA hardware doesn't even have such limitation so we can solve this by dropping the code that tries to handle unaligned bytes. Reported-by: Chiau Ee Chew Reported-by: Hock Leong Kweh Signed-off-by: Mika Westerberg Signed-off-by: Mark Brown

spi: core: Don't destroy master queue if we fail to create it

2014-05-03T16:58:19Z

If we fail to create the master queue for some reason we should not attempt to clean it up since attempting to stop a kthread that was not created will hang and it's just generally bad practice. Unfortunately at present we call spi_destroy_queue() even in cases where the creation fails. Fix this by fixing the error handling in spi_master_initialize_queue() so that we only flag the master as queued or destroy the queue if creation succeeded. The change to the flag is done since the general master cleanup uses this to destroy the queue. Reported-by: Ricardo Ribalda Delgado Signed-off-by: Mark Brown Acked-by: Geert Uytterhoeven

spi: qup: Fix return value checking for pm_runtime_get_sync()

2014-05-03T16:52:27Z

pm_runtime_get_sync() returns 1 if !CONFIG_PM_RUNTIME. Signed-off-by: Axel Lin Signed-off-by: Mark Brown

spi: core: Protect DMA code by #ifdef CONFIG_HAS_DMA

2014-05-02T17:08:40Z

If NO_DMA=y: drivers/built-in.o: In function `spi_map_buf': spi.c:(.text+0x21bc60): undefined reference to `dma_map_sg' drivers/built-in.o: In function `spi_unmap_buf.isra.33': spi.c:(.text+0x21c32e): undefined reference to `dma_unmap_sg' make[3]: *** [vmlinux] Error 1 Protect the DMA code by #ifdef CONFIG_HAS_DMA to fix this: - Extract __spi_map_msg() from spi_map_msg(), - Provide dummy definitions of __spi_map_msg() and spi_unmap_msg() if !CONFIG_HAS_DMA. Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown

Merge remote-tracking branches 'spi/fix/atmel', 'spi/fix/bfin5xx', 'spi/fix/hspi' and 'spi/fix/sirf' into spi-linus

2014-04-23T12:50:18Z

spi: core: Ignore unsupported Dual/Quad Transfer Mode bits

2014-04-18T17:24:38Z

The availability of SPI Dual or Quad Transfer Mode as indicated by the "spi-tx-bus-width" and "spi-rx-bus-width" properties in the device tree is a hardware property of the SPI master, SPI slave, and board wiring. Hence the SPI core should not reject an SPI slave because an SPI master driver doesn't (yet) support Dual or Quad Transfer Mode. Change the lack of Dual or Quad Transfer Mode support in the SPI master driver from an error condition to a warning condition, and ignore the unsupported mode bits, falling back to Single Transfer Mode, to avoid breakages when running old kernels with new device trees. Fixes: f477b7fb13df (spi: DUAL and QUAD support) Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown Cc: stable@vger.kernel.org

spi: atmel: Fix scheduling while atomic bug

2014-04-18T14:41:23Z

atmel_spi_lock does a spin_lock_irqsave, so we need to renable the interrupts when we want to schedule. Signed-off-by: Alexander Stein Signed-off-by: Mark Brown

spi: sh-hspi: Do not specifically request shyway_clk clock

2014-04-14T20:14:54Z

Rather than requesting the shyway_clk call clk_get with the device and a NULL con_id. This is in keeping with the way that clk_get() is called on other drivers used by Renesas Gen 1 SoCs. And I believe it is compatible with supplying clocks via DT, unlike the current code. It appears to me that the two uses of this driver are the r8a7778 and r8a7779 SoCs. The r8a7779 already has clocks setup to allow this driver to continue to work with this change applied. The r8a7778 has clocks incorrectly setup to allow this driver to continue to work with this change applied. This problem is addressed in "ARM: shmobile: r8a7778: Use clks as MSTP007 parent" which is thus a pre-requisite of this patch. Signed-off-by: Simon Horman Signed-off-by: Mark Brown