linux-stable.git/drivers/spi, branch linux-4.15.y

spi: sh-msiof: Fix timeout failures for TX-only DMA transfers

2018-04-12T10:31:05+00:00

[ Upstream commit 89434c3c35081439627baa2225622d5bd12242fe ]

When using RX (with or without TX), the DMA interrupt triggers
completion when the RX FIFO has been emptied, i.e. after the full
transfer has finished.

However, when using TX without RX, the DMA interrupt triggers completion
as soon as the DMA engine has filled the TX FIFO, i.e. before the full
transfer has finished.  Then sh_msiof_modify_ctr_wait() will spin until
the transfer has really finished and the TFSE bit is cleared, for at
most 1 ms.  For slow speeds and/or large transfers, this may cause
timeouts and transfer failures:

    spi_sh_msiof e6e10000.spi: failed to shut down hardware
    74x164 spi2.0: SPI transfer failed: -110
    spi_master spi2: failed to transfer one message from queue
    74x164 spi2.0: Failed writing: -110

Fix this by waiting explicitly until the TX FIFO has been emptied.

Based on a patch in the BSP by Hiromitsu Yamasaki.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

spi: sh-msiof: Avoid writing to registers from spi_master.setup()

2018-03-24T10:02:45+00:00

[ Upstream commit 7ff0b53c4051145d1cf992d2f60987e6447eed4f ]

The spi_master.setup() callback must not change configuration registers,
as that could corrupt I/O that is in progress for other SPI slaves.

The only exception is the configuration of the native chip select
polarity in SPI master mode, as a wrong chip select polarity will cause
havoc during all future transfers to any other SPI slave.

Hence stop writing to registers in sh_msiof_spi_setup(), unless it is
the first call for a controller using a native chip select, or unless
native chip select polarity has changed (note that you'll loose anyway
if I/O is in progress).  Even then, only do what is strictly necessary,
instead of calling sh_msiof_spi_set_pin_regs().

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

spi: sun6i: disable/unprepare clocks on remove

2018-03-19T08:09:57+00:00

[ Upstream commit 2d9bbd02c54094ceffa555143b0d68cd06504d63 ]

sun6i_spi_probe() uses sun6i_spi_runtime_resume() to prepare/enable
clocks, so sun6i_spi_remove() should use sun6i_spi_runtime_suspend() to
disable/unprepare them if we're not suspended.
Replacing pm_runtime_disable() by pm_runtime_force_suspend() will ensure
that sun6i_spi_runtime_suspend() is called if needed.

Found by Linux Driver Verification project (linuxtesting.org).

Fixes: 3558fe900e8af (spi: sunxi: Add Allwinner A31 SPI controller driver)
Signed-off-by: Tobias Jordan 
Acked-by: Maxime Ripard 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

spi: imx: Fix failure path leak on GPIO request error correctly

2018-03-19T08:09:49+00:00

[ Upstream commit 8197f489f4c4398391746a377c10501076b05168 ]

In commit 974488e4ce1e ("spi: imx: Fix failure path leak on GPIO request
error"), spi_bitbang_start() was moved later in the probe sequence.  But
this doesn't work, as spi_bitbang_start() has to be called before
requesting GPIOs because the GPIO data in the spi master is populated when
the master is registed, and that doesn't happen until spi_bitbang_start()
is called.  The default only works if one uses one CS.

So add a failure path call to spi_bitbang_stop() to fix the leak.

CC: Shawn Guo 
CC: Sascha Hauer 
CC: Fabio Estevam 
CC: Mark Brown 
CC: Oleksij Rempel 
Signed-off-by: Trent Piepho 
Reviewed-by: Oleksij Rempel 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

spi: imx: do not access registers while clocks disabled

2018-02-03T16:58:42+00:00

commit d593574aff0ab846136190b1729c151c736727ec upstream.

Since clocks are disabled except during message transfer clocks
are also disabled when spi_imx_remove gets called. Accessing
registers leads to a freeeze at least on a i.MX 6ULL. Enable
clocks before disabling accessing the MXC_CSPICTRL register.

Fixes: 9e556dcc55774 ("spi: spi-imx: only enable the clocks when we start to transfer a message")
Signed-off-by: Stefan Agner 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

Merge remote-tracking branches 'spi/fix/armada', 'spi/fix/atmel', 'spi/fix/doc', 'spi/fix/imx', 'spi/fix/rspi', 'spi/fix/sun4i' and 'spi/fix/xilinx' into spi-linus

2017-12-19T11:07:00+00:00

spi: atmel: fixed spin_lock usage inside atmel_spi_remove

2017-12-19T09:35:35+00:00

The only part of atmel_spi_remove which needs to be atomic is hardware
reset.

atmel_spi_stop_dma calls dma_terminate_all and this needs interrupts
enabled.
atmel_spi_release_dma calls dma_release_channel and dma_release_channel
locks a mutex inside of spin_lock.

So the call of these functions can't be inside a spin_lock.

Reported-by: Jia-Ju Bai 
Signed-off-by: Radu Pirea 
Signed-off-by: Mark Brown

spi: sun4i: disable clocks in the remove function

2017-12-07T11:59:15+00:00

mclk and hclk need to be disabled. Since pm_runtime_disable does
not disable the clocks, use pm_runtime_force_suspend instead.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Takuo Koguchi 
Acked-by: Maxime Ripard 
Signed-off-by: Mark Brown

spi: rspi: Do not set SPCR_SPE in qspi_set_config_register()

2017-12-07T11:55:38+00:00

The R-Car Gen2 Hardware User Manual Rev. 2.00 states:

    If the master/slave mode select bit (MSTR) is modified while the SPI
    function enable bit (SPE) is set to 1 (that is, this module is
    enabled), the subsequent operation cannot be guaranteed.

Hence do not set SPCR_SPE when setting SPCR_MSTR, just like the
.set_config_register() implementations for other RSPI variants do.

Note that when booted from QSPI, the boot loader will have set SPCR_MSTR
already, hence usually the bit is never modified by the Linux driver.

Reported-by: Yoshihiro Shimoda 
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Mark Brown

spi: a3700: Fix clk prescaling for coefficient over 15

2017-11-27T15:23:30+00:00

The Armada 3700 SPI controller has 2 ranges of prescaler coefficients.
One ranging from 0 to 15 by steps of 1, and one ranging from 0 to 30 by
steps of 2.

This commit fixes the prescaler coefficients that are over 15 so that it
uses the correct range of values. The prescaling coefficient is rounded
to the upper value if it is odd.

This was tested on Espressobin with spidev and a locigal analyser.

Signed-off-by: Maxime Chevallier 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org