BMC/Intel-BMC/linux.git/drivers/spi, branch dev-4.19

Merge tag 'v4.19.14' into dev-4.19

2019-01-10T03:32:21+00:00

This is the 4.19.14 stable release

spi: bcm2835: Unbreak the build of esoteric configs

2019-01-09T16:38:49+00:00

commit 29bdedfd9cf40e59456110ca417a8cb672ac9b92 upstream. Commit e82b0b382845 ("spi: bcm2835: Fix race on DMA termination") broke the build with COMPILE_TEST=y on arches whose cmpxchg() requires 32-bit operands (xtensa, older arm ISAs). Fix by changing the dma_pending flag's type from bool to unsigned int. Fixes: e82b0b382845 ("spi: bcm2835: Fix race on DMA termination") Signed-off-by: Lukas Wunner Signed-off-by: Mark Brown Cc: Frank Pavlic Cc: Martin Sperl Cc: Noralf Trønnes Cc: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

spi: bcm2835: Avoid finishing transfer prematurely in IRQ mode

2019-01-09T16:38:44+00:00

commit 56c1723426d3cfd4723bfbfce531d7b38bae6266 upstream. The IRQ handler bcm2835_spi_interrupt() first reads as much as possible from the RX FIFO, then writes as much as possible to the TX FIFO. Afterwards it decides whether the transfer is finished by checking if the TX FIFO is empty. If very few bytes were written to the TX FIFO, they may already have been transmitted by the time the FIFO's emptiness is checked. As a result, the transfer will be declared finished and the chip will be reset without reading the corresponding received bytes from the RX FIFO. The odds of this happening increase with a high clock frequency (such that the TX FIFO drains quickly) and either passing "threadirqs" on the command line or enabling CONFIG_PREEMPT_RT_BASE (such that the IRQ handler may be preempted between filling the TX FIFO and checking its emptiness). Fix by instead checking whether rx_len has reached zero, which means that the transfer has been received in full. This is also more efficient as it avoids one bus read access per interrupt. Note that bcm2835_spi_transfer_one_poll() likewise uses rx_len to determine whether the transfer has finished. Signed-off-by: Lukas Wunner Fixes: e34ff011c70e ("spi: bcm2835: move to the transfer_one driver model") Cc: stable@vger.kernel.org # v4.1+ Cc: Mathias Duckeck Cc: Frank Pavlic Cc: Martin Sperl Cc: Noralf Trønnes Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

spi: bcm2835: Fix book-keeping of DMA termination

2019-01-09T16:38:44+00:00

commit dbc944115eed48af110646992893dc43321368d8 upstream. If submission of a DMA TX transfer succeeds but submission of the corresponding RX transfer does not, the BCM2835 SPI driver terminates the TX transfer but neglects to reset the dma_pending flag to false. Thus, if the next transfer uses interrupt mode (because it is shorter than BCM2835_SPI_DMA_MIN_LENGTH) and runs into a timeout, dmaengine_terminate_all() will be called both for TX (once more) and for RX (which was never started in the first place). Fix it. Signed-off-by: Lukas Wunner Fixes: 3ecd37edaa2a ("spi: bcm2835: enable dma modes for transfers meeting certain conditions") Cc: stable@vger.kernel.org # v4.2+ Cc: Mathias Duckeck Cc: Frank Pavlic Cc: Martin Sperl Cc: Noralf Trønnes Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

spi: bcm2835: Fix race on DMA termination

2019-01-09T16:38:44+00:00

commit e82b0b3828451c1cd331d9f304c6078fcd43b62e upstream. If a DMA transfer finishes orderly right when spi_transfer_one_message() determines that it has timed out, the callbacks bcm2835_spi_dma_done() and bcm2835_spi_handle_err() race to call dmaengine_terminate_all(), potentially leading to double termination. Prevent by atomically changing the dma_pending flag before calling dmaengine_terminate_all(). Signed-off-by: Lukas Wunner Fixes: 3ecd37edaa2a ("spi: bcm2835: enable dma modes for transfers meeting certain conditions") Cc: stable@vger.kernel.org # v4.2+ Cc: Mathias Duckeck Cc: Frank Pavlic Cc: Martin Sperl Cc: Noralf Trønnes Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

Merge tag 'v4.19.13' into dev-4.19

2019-01-03T08:51:37+00:00

This is the 4.19.13 stable release Signed-off-by: Joel Stanley

spi: omap2-mcspi: Add missing suspend and resume calls

2018-12-17T08:24:32+00:00

[ Upstream commit 91b9deefedf4c35a01027ce38bed7299605026a3 ] I've been wondering still about omap2-mcspi related suspend and resume flakeyness and looks like we're missing calls to spi_master_suspend() and spi_master_resume(). Adding those and using pm_runtime_force_suspend() and pm_runtime_force_resume() makes things work for suspend and resume and allows us to stop using noirq suspend and resume. And while at it, let's use SET_SYSTEM_SLEEP_PM_OPS to simplify things further. Signed-off-by: Tony Lindgren Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: npcm: Modify pspi send function

2018-12-12T23:37:04+00:00

Align pspi send function code with the recieve function code, Also simplify the code a bit with early return. OpenBMC-Staging-Count: 1 Signed-off-by: Tomer Maimon Signed-off-by: Mark Brown Signed-off-by: Joel Stanley

spi: npcm: Fix uninitialized variable warning

2018-12-12T23:37:00+00:00

The compiler has no way to know that rsize 1 or 2 are the only valid values. Also simplify the code a bit with early return. The warning was: drivers/spi/spi-npcm-pspi.c:215:6: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized] OpenBMC-Staging-Count: 1 Signed-off-by: Olof Johansson Signed-off-by: Mark Brown Signed-off-by: Joel Stanley

spi: npcm: Fix an error code in the probe function

2018-12-12T23:36:58+00:00

There is an IS_ERR() vs PTR_ERR() typo here. The current code returns 1 but we want to return the negative error code. OpenBMC-Staging-Count: 1 Fixes: 2a22f1b30cee ("spi: npcm: add NPCM PSPI controller driver") Signed-off-by: Dan Carpenter Signed-off-by: Mark Brown Signed-off-by: Joel Stanley