linux.git/drivers/spi, branch v5.9-rc7

Merge tag 'spi-fix-v5.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi

2020-09-25T22:21:54+00:00

Pull spi fixes from Mark Brown:
 "A small collection of driver specific fixes, the fsl-espi and bcm-qspi
  changes in particular have been causing breakage for users"

* tag 'spi-fix-v5.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
  spi: bcm-qspi: Fix probe regression on iProc platforms
  spi: fsl-dspi: fix use-after-free in remove path
  spi: fsl-espi: Only process interrupts for expected events
  spi: bcm2835: Make polling_limit_us static
  spi: spi-fsl-dspi: use XSPI mode instead of DMA for DPAA2 SoCs

spi: bcm-qspi: Fix probe regression on iProc platforms

2020-09-24T11:09:46+00:00

iProc chips have QSPI controller that does not have the MSPI_REV
offset. Reading from that offset will cause a bus error. Fix it by
having MSPI_REV query disabled in the generic compatible string.

Fixes: 3a01f04d74ef ("spi: bcm-qspi: Handle lack of MSPI_REV offset")
Link: https://lore.kernel.org/linux-arm-kernel/20200909211857.4144718-1-f.fainelli@gmail.com/T/#u
Signed-off-by: Ray Jui 
Acked-by: Florian Fainelli 
Link: https://lore.kernel.org/r/20200910152539.45584-3-ray.jui@broadcom.com
Signed-off-by: Mark Brown

spi: fsl-dspi: fix use-after-free in remove path

2020-09-23T16:31:14+00:00

spi_unregister_controller() not only unregisters the controller, but
also frees the controller. This will free the driver data with it, so
we must not access it later dspi_remove().

Solve this by allocating the driver data separately from the SPI
controller.

Signed-off-by: Sascha Hauer 
Link: https://lore.kernel.org/r/20200923131026.20707-1-s.hauer@pengutronix.de
Signed-off-by: Mark Brown

spi: fsl-espi: Only process interrupts for expected events

2020-09-21T20:22:51+00:00

The SPIE register contains counts for the TX FIFO so any time the irq
handler was invoked we would attempt to process the RX/TX fifos. Use the
SPIM value to mask the events so that we only process interrupts that
were expected.

This was a latent issue exposed by commit 3282a3da25bd ("powerpc/64:
Implement soft interrupt replay in C").

Signed-off-by: Chris Packham 
Link: https://lore.kernel.org/r/20200904002812.7300-1-chris.packham@alliedtelesis.co.nz
Signed-off-by: Mark Brown

spi: bcm2835: Make polling_limit_us static

2020-09-15T15:48:38+00:00

This eliminates the following sparse warning:

drivers/spi/spi-bcm2835.c:78:14: warning: symbol 'polling_limit_us' was
not declared. Should it be static?

Reported-by: Hulk Robot 
Signed-off-by: Jason Yan 
Link: https://lore.kernel.org/r/20200912072211.602735-1-yanaijie@huawei.com
Signed-off-by: Mark Brown

Merge tag 'spi-fix-v5.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi

2020-09-11T18:35:55+00:00

Pull spi fixes from Mark Brown:
 "There's some driver specific fixes here plus one core fix for memory
  leaks that could be triggered by a potential race condition when
  cleaning up after we have split transfers to fit into what the
  controller can support"

* tag 'spi-fix-v5.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
  spi: stm32: fix pm_runtime_get_sync() error checking
  spi: Fix memory leak on splited transfers
  spi: spi-cadence-quadspi: Fix mapping of buffers for DMA reads
  spi: stm32: Rate-limit the 'Communication suspended' message
  spi: spi-loopback-test: Fix out-of-bounds read
  spi: spi-cadence-quadspi: Populate get_name() interface
  MAINTAINERS: add myself as maintainer for spi-fsl-dspi driver

spi: spi-fsl-dspi: use XSPI mode instead of DMA for DPAA2 SoCs

2020-09-11T13:31:29+00:00

The arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi device tree lacks DMA
channels for DSPI, so naturally, the driver fails to probe:

[ 2.945302] fsl-dspi 2100000.spi: rx dma channel not available
[ 2.951134] fsl-dspi 2100000.spi: can't get dma channels

In retrospect, this should have been obvious, because LS2080A, LS2085A
LS2088A and LX2160A don't appear to have an eDMA module at all. Looking
again at their datasheets, the CTARE register (which is specific to XSPI
functionality) seems to be documented, so switch them to XSPI mode
instead.

Fixes: 0feaf8f5afe0 ("spi: spi-fsl-dspi: Convert the instantiations that support it to DMA")
Reported-by: Qiang Zhao 
Tested-by: Qiang Zhao 
Signed-off-by: Vladimir Oltean 
Link: https://lore.kernel.org/r/20200910121532.1138596-1-olteanv@gmail.com
Signed-off-by: Mark Brown

spi: stm32: fix pm_runtime_get_sync() error checking

2020-09-09T14:11:44+00:00

The pm_runtime_get_sync() can return either 0 or 1 on success but this
code treats 1 as a failure.

Fixes: db96bf976a4f ("spi: stm32: fixes suspend/resume management")
Signed-off-by: Dan Carpenter 
Reviewed-by: Alain Volmat 
Link: https://lore.kernel.org/r/20200909094304.GA420136@mwanda
Signed-off-by: Mark Brown

spi: Fix memory leak on splited transfers

2020-09-09T14:11:43+00:00

In the prepare_message callback the bus driver has the
opportunity to split a transfer into smaller chunks.
spi_map_msg is done after prepare_message.

Function spi_res_release releases the splited transfers
in the message. Therefore spi_res_release should be called
after spi_map_msg.

The previous try at this was commit c9ba7a16d0f1
which released the splited transfers after
spi_finalize_current_message had been called.
This introduced a race since the message struct could be
out of scope because the spi_sync call got completed.

Fixes this leak on spi bus driver spi-bcm2835.c when transfer
size is greater than 65532:

Kmemleak:
sg_alloc_table+0x28/0xc8
spi_map_buf+0xa4/0x300
__spi_pump_messages+0x370/0x748
__spi_sync+0x1d4/0x270
spi_sync+0x34/0x58
spi_test_execute_msg+0x60/0x340 [spi_loopback_test]
spi_test_run_iter+0x548/0x578 [spi_loopback_test]
spi_test_run_test+0x94/0x140 [spi_loopback_test]
spi_test_run_tests+0x150/0x180 [spi_loopback_test]
spi_loopback_test_probe+0x50/0xd0 [spi_loopback_test]
spi_drv_probe+0x84/0xe0

Signed-off-by: Gustav Wiklander 
Link: https://lore.kernel.org/r/20200908151129.15915-1-gustav.wiklander@axis.com
Signed-off-by: Mark Brown

spi: spi-cadence-quadspi: Fix mapping of buffers for DMA reads

2020-09-08T14:20:10+00:00

Buffers need to mapped to DMA channel's device pointer instead of SPI
controller's device pointer as its system DMA that actually does data
transfer.
Data inconsistencies have been reported when reading from flash
without this fix.

Fixes: ffa639e069fb ("mtd: spi-nor: cadence-quadspi: Add DMA support for direct mode reads")
Signed-off-by: Vignesh Raghavendra 
Tested-by: Jan Kiszka 
Link: https://lore.kernel.org/r/20200831130720.4524-1-vigneshr@ti.com
Signed-off-by: Mark Brown