kernel/git/stable/linux.git/drivers/spi, branch linux-6.0.y

spi: spi-gpio: Don't set MOSI as an input if not 3WIRE mode

2022-12-31T12:26:11+00:00

[ Upstream commit 3a6f994f848a69deb2bf3cd9d130dd0c09730e55 ] The addition of 3WIRE support would affect MOSI direction even when still in standard (4 wire) mode. This can lead to MOSI being at an invalid logic level when a device driver sets an SPI message with a NULL tx_buf. spi.h states that if tx_buf is NULL then "zeros will be shifted out ... " If MOSI is tristated then the data shifted out is subject to pull resistors, keepers, or in the absence of those, noise. This issue came to light when using spi-gpio connected to an ADS7843 touchscreen controller. MOSI pulled high when clocking MISO data in caused the SPI device to interpret this as a command which would put the device in an unexpected and non-functional state. Fixes: 4b859db2c606 ("spi: spi-gpio: add SPI_3WIRE support") Fixes: 5132b3d28371 ("spi: gpio: Support 3WIRE high-impedance turn-around") Signed-off-by: Kris Bahnsen Link: https://lore.kernel.org/r/20221207230853.6174-1-kris@embeddedTS.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: spidev: mask SPI_CS_HIGH in SPI_IOC_RD_MODE

2022-12-31T12:26:06+00:00

[ Upstream commit 7dbfa445ff7393d1c4c066c1727c9e0af1251958 ] Commit f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs") has changed the user-space interface so that bogus SPI_CS_HIGH started to appear in the mask returned by SPI_IOC_RD_MODE even for active-low CS pins. Commit 138c9c32f090 ("spi: spidev: Fix CS polarity if GPIO descriptors are used") fixed only SPI_IOC_WR_MODE part of the problem. Let's fix SPI_IOC_RD_MODE symmetrically. Test case: #include #include #include int main(int argc, char **argv) { char modew = SPI_CPHA; char moder; int f = open("/dev/spidev0.0", O_RDWR); if (f < 0) return 1; ioctl(f, SPI_IOC_WR_MODE, &modew); ioctl(f, SPI_IOC_RD_MODE, &moder); return moder == modew ? 0 : 2; } Fixes: f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs") Signed-off-by: Alexander Sverdlin Link: https://lore.kernel.org/r/20221130162927.539512-1-alexander.sverdlin@siemens.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: mt65xx: Add dma max segment size declaration

2022-12-31T12:26:05+00:00

[ Upstream commit 309e98548c2b144512d0a212f2d786ae9694f5e4 ] Add spi dma max segment size declaration according to spi hardware capability, instead of 64KB by system default setting, to improve bus bandwidth for mass data transmission. Signed-off-by: zhichao.liu Link: https://lore.kernel.org/r/20220927083248.25404-1-zhichao.liu@mediatek.com Signed-off-by: Mark Brown Stable-dep-of: c6f7874687f7 ("spi: mediatek: Enable irq when pdata is ready") Signed-off-by: Sasha Levin

spi: mediatek: Fix DEVAPC Violation at KO Remove

2022-12-14T10:40:46+00:00

[ Upstream commit 0d10e90cee9eb57882b0f7e19fd699033722e226 ] A DEVAPC violation occurs when removing the module due to accessing HW registers without base clock. To fix this bug, the correct method is: 1. Call the runtime resume function to enable the clock; 2. Operate the registers to reset the HW; 3. Turn off the clocks and disable the device RPM mechanism. Signed-off-by: Zhichao Liu Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20221110072839.30961-1-zhichao.liu@mediatek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: spi-imx: spi_imx_transfer_one(): check for DMA transfer first

2022-12-02T16:43:11+00:00

commit e85e9e0d8cb759013d6474011c227f92e442d746 upstream. The SPI framework checks for each transfer (with the struct spi_controller::can_dma callback) whether the driver wants to use DMA for the transfer. If the driver returns true, the SPI framework will map the transfer's data to the device, start the actual transfer and map the data back. In commit 07e759387788 ("spi: spi-imx: add PIO polling support") the spi-imx driver's spi_imx_transfer_one() function was extended. If the estimated duration of a transfer does not exceed a configurable duration, a polling transfer function is used. This check happens before checking if the driver decided earlier for a DMA transfer. If spi_imx_can_dma() decided to use a DMA transfer, and the user configured a big maximum polling duration, a polling transfer will be used. The DMA unmap after the transfer destroys the transferred data. To fix this problem check in spi_imx_transfer_one() if the driver decided for DMA transfer first, then check the limits for a polling transfer. Fixes: 07e759387788 ("spi: spi-imx: add PIO polling support") Link: https://lore.kernel.org/all/20221111003032.82371-1-festevam@gmail.com Reported-by: Frieder Schrempf Reported-by: Fabio Estevam Tested-by: Fabio Estevam Cc: David Jander Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde Tested-by: Frieder Schrempf Reviewed-by: Frieder Schrempf Link: https://lore.kernel.org/r/20221116164930.855362-1-mkl@pengutronix.de Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

spi: spi-imx: Fix spi_bus_clk if requested clock is higher than input clock

2022-12-02T16:43:11+00:00

commit db2d2dc9a0b58c6faefb6b002fdbed4f0362d1a4 upstream. In case the requested bus clock is higher than the input clock, the correct dividers (pre = 0, post = 0) are returned from mx51_ecspi_clkdiv(), but *fres is left uninitialized and therefore contains an arbitrary value. This causes trouble for the recently introduced PIO polling feature as the value in spi_imx->spi_bus_clk is used there to calculate for which transfers to enable PIO polling. Fix this by setting *fres even if no clock dividers are in use. This issue was observed on Kontron BL i.MX8MM with an SPI peripheral clock set to 50 MHz by default and a requested SPI bus clock of 80 MHz for the SPI NOR flash. With the fix applied the debug message from mx51_ecspi_clkdiv() now prints the following: spi_imx 30820000.spi: mx51_ecspi_clkdiv: fin: 50000000, fspi: 50000000, post: 0, pre: 0 Fixes: 6fd8b8503a0d ("spi: spi-imx: Fix out-of-order CS/SCLK operation at low speeds") Fixes: 07e759387788 ("spi: spi-imx: add PIO polling support") Cc: Marc Kleine-Budde Cc: David Jander Cc: Fabio Estevam Cc: Mark Brown Cc: Marek Vasut Cc: stable@vger.kernel.org Signed-off-by: Frieder Schrempf Tested-by: Fabio Estevam Acked-by: Marek Vasut Link: https://lore.kernel.org/r/20221115181002.2068270-1-frieder@fris.de Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

spi: tegra210-quad: Fix duplicate resource error

2022-12-02T16:43:03+00:00

[ Upstream commit 2197aa6b0aa236b9896a09b9d08d6924d18b84f6 ] controller data alloc is done with client device data causing duplicate resource error. Allocate memory using controller device when using devm Fixes: f89d2cc3967a ("spi: tegra210-quad: use devm call for cdata memory") Signed-off-by: Krishna Yarlagadda Reviewed-by: Jon Hunter Tested-by: Jon Hunter Link: https://lore.kernel.org/r/20221117070320.18720-1-kyarlagadda@nvidia.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: dw-dma: decrease reference count in dw_spi_dma_init_mfld()

2022-12-02T16:43:03+00:00

[ Upstream commit 804313b64e412a81b0b3389a10e7622452004aa6 ] pci_get_device() will increase the reference count for the returned pci_dev. Since 'dma_dev' is only used to filter the channel in dw_spi_dma_chan_filer() after using it we need to call pci_dev_put() to decrease the reference count. Also add pci_dev_put() for the error case. Fixes: 7063c0d942a1 ("spi/dw_spi: add DMA support") Signed-off-by: Xiongfeng Wang Acked-by: Serge Semin Link: https://lore.kernel.org/r/20221116093204.46700-1-wangxiongfeng2@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: stm32: fix stm32_spi_prepare_mbr() that halves spi clk for every run

2022-12-02T16:43:00+00:00

[ Upstream commit 62aa1a344b0904549f6de7af958e8a1136fd5228 ] When this driver is used with a driver that uses preallocated spi_transfer structs. The speed_hz is halved by every run. This results in: spi_stm32 44004000.spi: SPI transfer setup failed ads7846 spi0.0: SPI transfer failed: -22 Example when running with DIV_ROUND_UP(): - First run; speed_hz = 1000000, spi->clk_rate 125000000 div 125 -> mbrdiv = 7, cur_speed = 976562 - Second run; speed_hz = 976562 div 128,00007 (roundup to 129) -> mbrdiv = 8, cur_speed = 488281 - Third run; speed_hz = 488281 div 256,000131072067109 (roundup to 257) and then -EINVAL is returned. Use DIV_ROUND_CLOSEST to allow to round down and allow us to keep the set speed. Signed-off-by: Sean Nyekjaer Link: https://lore.kernel.org/r/20221103080043.3033414-1-sean@geanix.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: tegra210-quad: Don't initialise DMA if not supported

2022-12-02T16:42:59+00:00

[ Upstream commit ae4b3c1252f0fd0951d2f072a02ba46cac8d6c92 ] The following error messages are observed on boot for Tegra234 ... ERR KERN tegra-qspi 3270000.spi: cannot use DMA: -19 ERR KERN tegra-qspi 3270000.spi: falling back to PIO Tegra234 does not support DMA for the QSPI and so initialising the DMA is expected to fail. The above error messages are misleading for devices that don't support DMA and so fix this by skipping the DMA initialisation for devices that don't support DMA. Signed-off-by: Jon Hunter Acked-by: Thierry Reding Link: https://lore.kernel.org/r/20221026155633.141792-1-jonathanh@nvidia.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin