kernel/linux.git/drivers/spi, branch v3.18.62

spi: dw-mid: refactor to use helpers

2017-02-08T08:43:05+00:00

commit a5c2db964d3eb26b41bd7abc1b13486f732b3aa2 upstream. This patch splits few helpers, namely dw_spi_dma_prepare_rx(), dw_spi_dma_prepare_tx(), and dw_spi_dma_setup() which will be useful for the consequent improvements. There is no functional change. Signed-off-by: Andy Shevchenko Signed-off-by: Mark Brown [removes a build warning with newer versions of gcc - gregkh] Signed-off-by: Greg Kroah-Hartman

spi/rockchip: Make sure spi clk is on in rockchip_spi_set_cs

2016-07-12T12:47:51+00:00

[ Upstream commit b920cc3191d7612f26f36ee494e05b5ffd9044c0 ] Rockchip_spi_set_cs could be called by spi_setup, but spi_setup may be called by device driver after runtime suspend. Then the spi clock is closed, rockchip_spi_set_cs may access the spi registers, which causes cpu block in some socs. Fixes: 64e36824b32 ("spi/rockchip: add driver for Rockchip RK3xxx") Signed-off-by: Huibin Hong Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: sunxi: fix transfer timeout

2016-07-12T12:46:50+00:00

[ Upstream commit 719bd6542044efd9b338a53dba1bef45f40ca169 ] The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over 1MHz SPI bus takes way longer than that. Calculate the timeout from the actual time the transfer is supposed to take and multiply by 2 for good measure. Signed-off-by: Michal Suchanek Acked-by: Maxime Ripard Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin

spi: sun4i: allow transfers to set transmission speed

2016-07-12T12:46:44+00:00

[ Upstream commit 47284e3e0f3c427c93f8583549b6c938e8a18015 ] Allow transfers to set the transmission speed rather than using the device max_speed_hz value. The SPI core makes sure that the speed_hz value is always set on the transfer. Signed-off-by: Marcus Weseloh Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: sun4i: fix FIFO limit

2016-07-11T15:16:34+00:00

[ Upstream commit 6d9fe44bd73d567d04d3a68a2d2fa521ab9532f2 ] When testing SPI without DMA I noticed that filling the FIFO on the spi controller causes timeout. Always leave room for one byte in the FIFO. Signed-off-by: Michal Suchanek Acked-by: Maxime Ripard Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin

spi: spi-pxa2xx: Check status register to determine if SSSR_TINT is disabled

2015-10-28T02:13:18+00:00

[ Upstream commit 02bc933ebb59208f42c2e6305b2c17fd306f695d ] On Intel Baytrail, there is case when interrupt handler get called, no SPI message is captured. The RX FIFO is indeed empty when RX timeout pending interrupt (SSSR_TINT) happens. Use the BIOS version where both HSUART and SPI are on the same IRQ. Both drivers are using IRQF_SHARED when calling the request_irq function. When running two separate and independent SPI and HSUART application that generate data traffic on both components, user will see messages like below on the console: pxa2xx-spi pxa2xx-spi.0: bad message state in interrupt handler This commit will fix this by first checking Receiver Time-out Interrupt, if it is disabled, ignore the request and return without servicing. Signed-off-by: Tan, Jui Nee Acked-by: Jarkko Nikula Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin

spi: xtensa-xtfpga: fix register endianness

2015-10-28T02:13:17+00:00

[ Upstream commit b0b4855099e301c8603ea37da9a0103a96c2e0b1 ] XTFPGA SPI controller has native endian registers. Fix register acessors so that they work in big-endian configurations. Signed-off-by: Max Filippov Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin

spi: Fix documentation of spi_alloc_master()

2015-10-28T02:13:17+00:00

[ Upstream commit a394d635193b641f2c86ead5ada5b115d57c51f8 ] Actually, spi_master_put() after spi_alloc_master() must _not_ be followed by kfree(). The memory is already freed with the call to spi_master_put() through spi_master_class, which registers a release function. Calling both spi_master_put() and kfree() results in often nasty (and delayed) crashes elsewhere in the kernel, often in the networking stack. This reverts commit eb4af0f5349235df2e4a5057a72fc8962d00308a. Link to patch and concerns: https://lkml.org/lkml/2012/9/3/269 or http://lkml.iu.edu/hypermail/linux/kernel/1209.0/00790.html Alexey Klimov: This revert becomes valid after 94c69f765f1b4a658d96905ec59928e3e3e07e6a when spi-imx.c has been fixed and there is no need to call kfree() so comment for spi_alloc_master() should be fixed. Signed-off-by: Guenter Roeck Signed-off-by: Alexey Klimov Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin

spi: orion: Fix maximum baud rates for Armada 370/XP

2015-07-04T03:02:19+00:00

[ Upstream commit ce2f6ea1cbd41d78224f703af980a6ceeb0eb56a ] The commit df59fa7f4bca "spi: orion: support armada extended baud rates" was too optimistic for the maximum baud rate that the Armada SoCs can support. According to the hardware datasheet the maximum frequency supported by the Armada 370 SoC is tclk/4. But for the Armada XP, Armada 38x and Armada 39x SoCs the limitation is 50MHz and for the Armada 375 it is tclk/15. Currently the armada-370-spi compatible is only used by the Armada 370 and the Armada XP device tree. On Armada 370, tclk cannot be higher than 200MHz. In order to be able to handle both SoCs, we can take the minimum of 50MHz and tclk/4. A proper solution is adding a compatible string for each SoC, but it can't be done as a fix for compatibility reason (we can't modify device tree that have been already released) and it will be part of a separate patch. Fixes: df59fa7f4bca (spi: orion: support armada extended baud rates) Reported-by: Kostya Porotchkin Signed-off-by: Gregory CLEMENT Signed-off-by: Mark Brown Cc: Signed-off-by: Sasha Levin

spi: fix race freeing dummy_tx/rx before it is unmapped

2015-07-04T03:02:14+00:00

[ Upstream commit 8e76ef88f607174082023f50b87fe12dcdbe5db5 ] Fix a race (with some kernel configurations) where a queued master->pump_messages runs and frees dummy_tx/rx before spi_unmap_msg is running (or is finished). This results in the following messages: BUG: Bad page state in process page:db7ba030 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x200(arch_1) page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set ... Reported-by: Noralf Trønnes Suggested-by: Noralf Trønnes Tested-by: Noralf Trønnes Signed-off-by: Martin Sperl Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin