linux-stable.git/drivers/spi, branch v5.4.145

spi: meson-spicc: fix memory leak in meson_spicc_remove

2021-08-12T11:21:04+00:00

commit 8311ee2164c5cd1b63a601ea366f540eae89f10e upstream.

In meson_spicc_probe, the error handling code needs to clean up master
by calling spi_master_put, but the remove function does not have this
function call. This will lead to memory leak of spicc->master.

Reported-by: Dongliang Mu 
Fixes: 454fa271bc4e("spi: Add Meson SPICC driver")
Signed-off-by: Dongliang Mu 
Link: https://lore.kernel.org/r/20210720100116.1438974-1-mudongliangabcd@gmail.com
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

spi: imx: mx51-ecspi: Fix low-speed CONFIGREG delay calculation

2021-08-12T11:20:56+00:00

[ Upstream commit 53ca18acbe645656132fb5a329833db711067e54 ]

The spi_imx->spi_bus_clk may be uninitialized and thus also zero in
mx51_ecspi_prepare_message(), which would lead to division by zero
in kernel. Since bitbang .setup_transfer callback which initializes
the spi_imx->spi_bus_clk is called after bitbang prepare_message
callback, iterate over all the transfers in spi_message, find the
one with lowest bus frequency, and use that bus frequency for the
delay calculation.

Note that it is not possible to move this CONFIGREG delay back into
the .setup_transfer callback, because that is invoked too late, after
the GPIO chipselects were already configured.

Fixes: 135cbd378eab ("spi: imx: mx51-ecspi: Reinstate low-speed CONFIGREG delay")
Signed-off-by: Marek Vasut 
Cc: Uwe Kleine-König 
Cc: Mark Brown 
Link: https://lore.kernel.org/r/20210726100102.5188-1-marex@denx.de
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

spi: imx: mx51-ecspi: Reinstate low-speed CONFIGREG delay

2021-08-12T11:20:55+00:00

[ Upstream commit 135cbd378eab336da15de9c84bbb22bf743b38a5 ]

Since 00b80ac935539 ("spi: imx: mx51-ecspi: Move some initialisation to
prepare_message hook."), the MX51_ECSPI_CONFIG write no longer happens
in prepare_transfer hook, but rather in prepare_message hook, however
the MX51_ECSPI_CONFIG delay is still left in prepare_transfer hook and
thus has no effect. This leads to low bus frequency operation problems
described in 6fd8b8503a0dc ("spi: spi-imx: Fix out-of-order CS/SCLK
operation at low speeds") again.

Move the MX51_ECSPI_CONFIG write delay into the prepare_message hook
as well, thus reinstating the low bus frequency fix.

Fixes: 00b80ac935539 ("spi: imx: mx51-ecspi: Move some initialisation to prepare_message hook.")
Signed-off-by: Marek Vasut 
Cc: Uwe Kleine-König 
Cc: Mark Brown 
Link: https://lore.kernel.org/r/20210703022300.296114-1-marex@denx.de
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

spi: mediatek: Fix fifo transfer

2021-08-08T07:04:09+00:00

commit 0d5c3954b35eddff0da0436c31e8d721eceb7dc2 upstream.

Commit 3a70dd2d0503 ("spi: mediatek: fix fifo rx mode") claims that
fifo RX mode was never handled, and adds the presumably missing code
to the FIFO transfer function. However, the claim that receive data
was not handled is incorrect. It was handled as part of interrupt
handling after the transfer was complete. The code added with the above
mentioned commit reads data from the receive FIFO before the transfer
is started, which is wrong. This results in an actual transfer error
on a Hayato Chromebook.

Remove the code trying to handle receive data before the transfer is
started to fix the problem.

Fixes: 3a70dd2d0503 ("spi: mediatek: fix fifo rx mode")
Cc: Peter Hess 
Cc: Frank Wunderlich 
Cc: Tzung-Bi Shih 
Cc: Hsin-Yi Wang 
Signed-off-by: Guenter Roeck 
Tested-by: Hsin-Yi Wang 
Tested-by: Tzung-Bi Shih 
Link: https://lore.kernel.org/r/20210802030023.1748777-1-linux@roeck-us.net
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

spi: stm32h7: fix full duplex irq handler handling

2021-08-08T07:04:07+00:00

[ Upstream commit e4a5c19888a5f8a9390860ca493e643be58c8791 ]

In case of Full-Duplex mode, DXP flag is set when RXP and TXP flags are
set. But to avoid 2 different handlings, just add TXP and RXP flag in
the mask instead of DXP, and then keep the initial handling of TXP and
RXP events.
Also rephrase comment about EOTIE which is one of the interrupt enable
bits. It is not triggered by any event.

Signed-off-by: Amelie Delaunay 
Signed-off-by: Alain Volmat 
Reviewed-by: Amelie Delaunay 
Link: https://lore.kernel.org/r/1625042723-661-3-git-send-email-alain.volmat@foss.st.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

spi: cadence: Correct initialisation of runtime PM again

2021-07-28T11:30:56+00:00

[ Upstream commit 56912da7a68c8356df6a6740476237441b0b792a ]

The original implementation of RPM handling in probe() was mostly
correct, except it failed to call pm_runtime_get_*() to activate the
hardware. The subsequent fix, 734882a8bf98 ("spi: cadence: Correct
initialisation of runtime PM"), breaks the implementation further,
to the point where the system using this hard IP on ZynqMP hangs on
boot, because it accesses hardware which is gated off.

Undo 734882a8bf98 ("spi: cadence: Correct initialisation of runtime
PM") and instead add missing pm_runtime_get_noresume() and move the
RPM disabling all the way to the end of probe(). That makes ZynqMP
not hang on boot yet again.

Fixes: 734882a8bf98 ("spi: cadence: Correct initialisation of runtime PM")
Signed-off-by: Marek Vasut 
Cc: Charles Keepax 
Cc: Mark Brown 
Link: https://lore.kernel.org/r/20210716182133.218640-1-marex@denx.de
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

spi: mediatek: fix fifo rx mode

2021-07-28T11:30:55+00:00

[ Upstream commit 3a70dd2d050331ee4cf5ad9d5c0a32d83ead9a43 ]

In FIFO mode were two problems:
- RX mode was never handled and
- in this case the tx_buf pointer was NULL and caused an exception

fix this by handling RX mode in mtk_spi_fifo_transfer

Fixes: a568231f4632 ("spi: mediatek: Add spi bus for Mediatek MT8173")
Signed-off-by: Peter Hess 
Signed-off-by: Frank Wunderlich 
Link: https://lore.kernel.org/r/20210706121609.680534-1-linux@fw-web.de
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

spi: stm32: fixes pm_runtime calls in probe/remove

2021-07-28T11:30:55+00:00

[ Upstream commit 7999d2555c9f879d006ea8469d74db9cdb038af0 ]

Add pm_runtime calls in probe/probe error path and remove
in order to be consistent in all places in ordering and
ensure that pm_runtime is disabled prior to resources used
by the SPI controller.

This patch also fixes the 2 following warnings on driver remove:
WARNING: CPU: 0 PID: 743 at drivers/clk/clk.c:594 clk_core_disable_lock+0x18/0x24
WARNING: CPU: 0 PID: 743 at drivers/clk/clk.c:476 clk_unprepare+0x24/0x2c

Fixes: 038ac869c9d2 ("spi: stm32: add runtime PM support")

Signed-off-by: Amelie Delaunay 
Signed-off-by: Alain Volmat 
Link: https://lore.kernel.org/r/1625646426-5826-2-git-send-email-alain.volmat@foss.st.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

spi: stm32: Use dma_request_chan() instead dma_request_slave_channel()

2021-07-28T11:30:54+00:00

[ Upstream commit 0a454258febb73e4c60d7f5d9a02d1a8c64fdfb8 ]

dma_request_slave_channel() is a wrapper on top of dma_request_chan()
eating up the error code.

By using dma_request_chan() directly the driver can support deferred
probing against DMA.

Signed-off-by: Peter Ujfalusi 
Link: https://lore.kernel.org/r/20191212135550.4634-10-peter.ujfalusi@ti.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

spi: imx: add a check for speed_hz before calculating the clock

2021-07-28T11:30:54+00:00

[ Upstream commit 4df2f5e1372e9eec8f9e1b4a3025b9be23487d36 ]

When some drivers use spi to send data, spi_transfer->speed_hz is
not assigned. If spidev->max_speed_hz is not assigned as well, it
will cause an error in configuring the clock.
Add a check for these two values before configuring the clock. An
error will be returned when they are not assigned.

Signed-off-by: Clark Wang 
Link: https://lore.kernel.org/r/20210408103347.244313-2-xiaoning.wang@nxp.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin