summaryrefslogtreecommitdiff
path: root/drivers/spi
AgeCommit message (Collapse)AuthorFilesLines
2023-10-10spi: zynqmp-gqspi: fix clock imbalance on probe failureJohan Hovold1-4/+8
[ Upstream commit 1527b076ae2cb6a9c590a02725ed39399fcad1cf ] Make sure that the device is not runtime suspended before explicitly disabling the clocks on probe failure and on driver unbind to avoid a clock enable-count imbalance. Fixes: 9e3a000362ae ("spi: zynqmp: Add pm runtime support") Cc: stable@vger.kernel.org # 4.19 Cc: Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com> Cc: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/Message-Id: <20230622082435.7873-1-johan+linaro@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06spi: intel-pci: Add support for Granite Rapids SPI serial flashMika Westerberg1-0/+1
[ Upstream commit 9855d60cfc720ff32355484c119acafd3c4dc806 ] Intel Granite Rapids has a flash controller that is compatible with the other Cannon Lake derivatives. Add Granite Rapids PCI ID to the driver list of supported devices. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20230911074616.3473347-1-mika.westerberg@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06spi: stm32: add a delay before SPI disableValentin Caron1-0/+8
[ Upstream commit 6de8a70c84ee0586fdde4e671626b9caca6aed74 ] As explained in errata sheet, in section "2.14.5 Truncation of SPI output signals after EOT event": On STM32MP1x, EOT interrupt can be thrown before the true end of communication. So we add a delay of a half period to wait the real end of the transmission. Link: https://www.st.com/resource/en/errata_sheet/es0539-stm32mp131x3x5x-device-errata-stmicroelectronics.pdf Signed-off-by: Valentin Caron <valentin.caron@foss.st.com> Link: https://lore.kernel.org/r/20230906132735.748174-1-valentin.caron@foss.st.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06spi: nxp-fspi: reset the FLSHxCR1 registersHan Xu1-0/+7
[ Upstream commit 18495676f7886e105133f1dc06c1d5e8d5436f32 ] Reset the FLSHxCR1 registers to default value. ROM may set the register value and it affects the SPI NAND normal functions. Signed-off-by: Han Xu <han.xu@nxp.com> Link: https://lore.kernel.org/r/20230906183254.235847-1-han.xu@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06spi: sun6i: fix race between DMA RX transfer completion and RX FIFO drainTobias Schramm1-1/+28
[ Upstream commit 1f11f4202caf5710204d334fe63392052783876d ] Previously the transfer complete IRQ immediately drained to RX FIFO to read any data remaining in FIFO to the RX buffer. This behaviour is correct when dealing with SPI in interrupt mode. However in DMA mode the transfer complete interrupt still fires as soon as all bytes to be transferred have been stored in the FIFO. At that point data in the FIFO still needs to be picked up by the DMA engine. Thus the drain procedure and DMA engine end up racing to read from RX FIFO, corrupting any data read. Additionally the RX buffer pointer is never adjusted according to DMA progress in DMA mode, thus calling the RX FIFO drain procedure in DMA mode is a bug. Fix corruptions in DMA RX mode by draining RX FIFO only in interrupt mode. Also wait for completion of RX DMA when in DMA mode before returning to ensure all data has been copied to the supplied memory buffer. Signed-off-by: Tobias Schramm <t.schramm@manjaro.org> Link: https://lore.kernel.org/r/20230827152558.5368-3-t.schramm@manjaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06spi: sun6i: reduce DMA RX transfer width to single byteTobias Schramm1-1/+1
[ Upstream commit 171f8a49f212e87a8b04087568e1b3d132e36a18 ] Through empirical testing it has been determined that sometimes RX SPI transfers with DMA enabled return corrupted data. This is down to single or even multiple bytes lost during DMA transfer from SPI peripheral to memory. It seems the RX FIFO within the SPI peripheral can become confused when performing bus read accesses wider than a single byte to it during an active SPI transfer. This patch reduces the width of individual DMA read accesses to the RX FIFO to a single byte to mitigate that issue. Signed-off-by: Tobias Schramm <t.schramm@manjaro.org> Link: https://lore.kernel.org/r/20230827152558.5368-2-t.schramm@manjaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06spi: spi-gxp: BUG: Correct spi write return valueCharles Kearney1-1/+1
[ Upstream commit 1a8196a93e493c0a50b800cb09cef60b124eee15 ] Bug fix to correct return value of gxp_spi_write function to zero. Completion of succesful operation should return zero. Fixes: 730bc8ba5e9e spi: spi-gxp: Add support for HPE GXP SoCs Signed-off-by: Charles Kearney <charles.kearney@hpe.com> Link: https://lore.kernel.org/r/20230920215339.4125856-2-charles.kearney@hpe.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13treewide: Fix probing of devices in DT overlaysGeert Uytterhoeven1-0/+5
commit 1a50d9403fb90cbe4dea0ec9fd0351d2ecbd8924 upstream. When loading a DT overlay that creates a device, the device is not probed, unless the DT overlay is unloaded and reloaded again. After the recent refactoring to improve fw_devlink, it no longer depends on the "compatible" property to identify which device tree nodes will become struct devices. fw_devlink now picks up dangling consumers (consumers pointing to descendent device tree nodes of a device that aren't converted to child devices) when a device is successfully bound to a driver. See __fw_devlink_pickup_dangling_consumers(). However, during DT overlay, a device's device tree node can have sub-nodes added/removed without unbinding/rebinding the driver. This difference in behavior between the normal device instantiation and probing flow vs. the DT overlay flow has a bunch of implications that are pointed out elsewhere[1]. One of them is that the fw_devlink logic to pick up dangling consumers is never exercised. This patch solves the fw_devlink issue by marking all DT nodes added by DT overlays with FWNODE_FLAG_NOT_DEVICE (fwnode that won't become device), and by clearing the flag when a struct device is actually created for the DT node. This way, fw_devlink knows not to have consumers waiting on these newly added DT nodes, and to propagate the dependency to an ancestor DT node that has the corresponding struct device. Based on a patch by Saravana Kannan, which covered only platform and spi devices. [1] https://lore.kernel.org/r/CAGETcx_bkuFaLCiPrAWCPQz+w79ccDp6=9e881qmK=vx3hBMyg@mail.gmail.com Fixes: 4a032827daa89350 ("of: property: Simplify of_link_to_phandle()") Link: https://lore.kernel.org/r/CAGETcx_+rhHvaC_HJXGrr5_WAd2+k5f=rWYnkCZ6z5bGX-wj4w@mail.gmail.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Wolfram Sang <wsa@kernel.org> # for I2C Acked-by: Shawn Guo <shawnguo@kernel.org> Acked-by: Saravana Kannan <saravanak@google.com> Tested-by: Ivan Bornyakov <i.bornyakov@metrotek.ru> Link: https://lore.kernel.org/r/e1fa546682ea4c8474ff997ab6244c5e11b6f8bc.1680182615.git.geert+renesas@glider.be Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-13spi: tegra20-sflash: fix to check return value of platform_get_irq() in ↵Zhang Shurong1-1/+5
tegra_sflash_probe() [ Upstream commit 29a449e765ff70a5bd533be94babb6d36985d096 ] The platform_get_irq might be failed and return a negative result. So there should have an error handling code. Fixed this by adding an error handling code. Fixes: 8528547bcc33 ("spi: tegra: add spi driver for sflash controller") Signed-off-by: Zhang Shurong <zhang_shurong@foxmail.com> Link: https://lore.kernel.org/r/tencent_71FC162D589E4788C2152AAC84CD8D5C6D06@qq.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-27spi: dw: Remove misleading comment for Mount Evans SoCAbe Kohandel1-8/+1
commit 5b6d0b91f84cff3f28724076f93f6f9e2ef8d775 upstream. Remove a misleading comment about the DMA operations of the Intel Mount Evans SoC's SPI Controller as requested by Serge. Signed-off-by: Abe Kohandel <abe.kohandel@intel.com> Link: https://lore.kernel.org/linux-spi/20230606191333.247ucbf7h3tlooxf@mobilestation/ Fixes: 0760d5d0e9f0 ("spi: dw: Add compatible for Intel Mount Evans SoC") Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20230606231844.726272-1-abe.kohandel@intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-27spi: s3c64xx: clear loopback bit after loopback testJaewon Kim1-0/+2
[ Upstream commit 9ec3c5517e22a12d2ff1b71e844f7913641460c6 ] When SPI loopback transfer is performed, S3C64XX_SPI_MODE_SELF_LOOPBACK bit still remained. It works as loopback even if the next transfer is not spi loopback mode. If not SPI_LOOP, needs to clear S3C64XX_SPI_MODE_SELF_LOOPBACK bit. Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com> Fixes: ffb7bcd3b27e ("spi: s3c64xx: support loopback mode") Reviewed-by: Chanho Park <chanho61.park@samsung.com> Link: https://lore.kernel.org/r/20230711082020.138165-1-jaewon02.kim@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-27spi: bcm63xx: fix max prepend lengthJonas Gorski1-1/+1
[ Upstream commit 5158814cbb37bbb38344b3ecddc24ba2ed0365f2 ] The command word is defined as following: /* Command */ #define SPI_CMD_COMMAND_SHIFT 0 #define SPI_CMD_DEVICE_ID_SHIFT 4 #define SPI_CMD_PREPEND_BYTE_CNT_SHIFT 8 #define SPI_CMD_ONE_BYTE_SHIFT 11 #define SPI_CMD_ONE_WIRE_SHIFT 12 If the prepend byte count field starts at bit 8, and the next defined bit is SPI_CMD_ONE_BYTE at bit 11, it can be at most 3 bits wide, and thus the max value is 7, not 15. Fixes: b17de076062a ("spi/bcm63xx: work around inability to keep CS up") Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Link: https://lore.kernel.org/r/20230629071453.62024-1-jonas.gorski@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-27spi: dw: Add compatible for Intel Mount Evans SoCAbe Kohandel1-0/+29
[ Upstream commit 0760d5d0e9f0c0e2200a0323a61d1995bb745dee ] The Intel Mount Evans SoC's Integrated Management Complex uses the SPI controller for access to a NOR SPI FLASH. However, the SoC doesn't provide a mechanism to override the native chip select signal. This driver doesn't use DMA for memory operations when a chip select override is not provided due to the native chip select timing behavior. As a result no DMA configuration is done for the controller and this configuration is not tested. The controller also has an errata where a full TX FIFO can result in data corruption. The suggested workaround is to never completely fill the FIFO. The TX FIFO has a size of 32 so the fifo_len is set to 31. Signed-off-by: Abe Kohandel <abe.kohandel@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230606145402.474866-2-abe.kohandel@intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19spi: bcm-qspi: return error if neither hif_mspi nor mspi is availableJonas Gorski1-7/+3
[ Upstream commit 7c1f23ad34fcdace50275a6aa1e1969b41c6233f ] If neither a "hif_mspi" nor "mspi" resource is present, the driver will just early exit in probe but still return success. Apart from not doing anything meaningful, this would then also lead to a null pointer access on removal, as platform_get_drvdata() would return NULL, which it would then try to dereference when trying to unregister the spi master. Fix this by unconditionally calling devm_ioremap_resource(), as it can handle a NULL res and will then return a viable ERR_PTR() if we get one. The "return 0;" was previously a "goto qspi_resource_err;" where then ret was returned, but since ret was still initialized to 0 at this place this was a valid conversion in 63c5395bb7a9 ("spi: bcm-qspi: Fix use-after-free on unbind"). The issue was not introduced by this commit, only made more obvious. Fixes: fa236a7ef240 ("spi: bcm-qspi: Add Broadcom MSPI driver") Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Kamal Dasu <kamal.dasu@broadcom.com> Link: https://lore.kernel.org/r/20230629134306.95823-1-jonas.gorski@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19spi: spi-geni-qcom: enable SPI_CONTROLLER_MUST_TX for GPI DMA modeDmitry Baryshkov1-0/+6
[ Upstream commit d10005837be83906bbd2078c3b4f9dfcbd6c95b6 ] The GPI DMA mode requires for TX DMA to be prepared. Force SPI core to provide TX buffer even if the caller didn't provide one by setting the SPI_CONTROLLER_MUST_TX flag. Fixes: b59c122484ec ("spi: spi-geni-qcom: Add support for GPI dma") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230629095847.3648597-1-dmitry.baryshkov@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19spi: dw: Round of n_bytes to power of 2Joy Chakraborty1-1/+4
[ Upstream commit 9f34baf67e4d08908fd94ff29c825bb673295336 ] n_bytes variable in the driver represents the number of bytes per word that needs to be sent/copied to fifo. Bits/word can be between 8 and 32 bits from the client but in memory they are a power of 2, same is mentioned in spi.h header: " * @bits_per_word: Data transfers involve one or more words; word sizes * like eight or 12 bits are common. In-memory wordsizes are * powers of two bytes (e.g. 20 bit samples use 32 bits). * This may be changed by the device's driver, or left at the * default (0) indicating protocol words are eight bit bytes. * The spi_transfer.bits_per_word can override this for each transfer. " Hence, round of n_bytes to a power of 2 to avoid values like 3 which would generate unalligned/odd accesses to memory/fifo. * tested on Baikal-T1 based system with DW SPI-looped back interface transferring a chunk of data with DFS:8,12,16. Fixes: a51acc2400d4 ("spi: dw: Add support for 32-bits max xfer size") Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com Signed-off-by: Joy Chakraborty <joychakr@google.com Reviewed-by: Serge Semin <fancer.lancer@gmail.com Tested-by: Serge Semin <fancer.lancer@gmail.com Link: https://lore.kernel.org/r/20230512104746.1797865-4-joychakr@google.com Signed-off-by: Mark Brown <broonie@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19spi: spi-geni-qcom: Correct CS_TOGGLE bit in SPI_TRANS_CFGVijaya Krishna Nivarthi1-1/+1
[ Upstream commit 5fd7c99ecf45c8ee8a9b1268f0ffc91cc6271da2 ] The CS_TOGGLE bit when set is supposed to instruct FW to toggle CS line between words. The driver with intent of disabling this behaviour has been unsetting BIT(0). This has not caused any trouble so far because the original BIT(1) is untouched and BIT(0) likely wasn't being used. Correct this to prevent a potential future bug. Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org Fixes: 561de45f72bd ("spi: spi-geni-qcom: Add SPI driver support for GENI based QUP") Reviewed-by: Douglas Anderson <dianders@chromium.org Link: https://lore.kernel.org/r/1682412128-1913-1-git-send-email-quic_vnivarth@quicinc.com Signed-off-by: Mark Brown <broonie@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-28spi: lpspi: disable lpspi module irq in DMA modeClark Wang1-1/+6
[ Upstream commit 9728fb3ce11729aa8c276825ddf504edeb00611d ] When all bits of IER are set to 0, we still can observe the lpspi irq events when using DMA mode to transfer data. So disable irq to avoid the too much irq events. Signed-off-by: Clark Wang <xiaoning.wang@nxp.com> Link: https://lore.kernel.org/r/20230505063557.3962220-1-xiaoning.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-28spi: spi-geni-qcom: correctly handle -EPROBE_DEFER from dma_request_chan()Neil Armstrong1-0/+2
[ Upstream commit 9d7054fb3ac2e8d252aae1268f20623f244e644f ] Now spi_geni_grab_gpi_chan() errors are correctly reported, the -EPROBE_DEFER error should be returned from probe in case the GPI dma driver is built as module and/or not probed yet. Fixes: b59c122484ec ("spi: spi-geni-qcom: Add support for GPI dma") Fixes: 6532582c353f ("spi: spi-geni-qcom: fix error handling in spi_geni_grab_gpi_chan()") Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20230615-topic-sm8550-upstream-fix-spi-geni-qcom-probe-v2-1-670c3d9e8c9c@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-21spi: fsl-dspi: avoid SCK glitches with continuous transfersVladimir Oltean1-0/+15
[ Upstream commit c5c31fb71f16ba75bad4ade208abbae225305b65 ] The DSPI controller has configurable timing for (a) tCSC: the interval between the assertion of the chip select and the first clock edge (b) tASC: the interval between the last clock edge and the deassertion of the chip select What is a bit surprising, but is documented in the figure "Example of continuous transfer (CPHA=1, CONT=1)" in the datasheet, is that when the chip select stays asserted between multiple TX FIFO writes, the tCSC and tASC times still apply. With CONT=1, chip select remains asserted, but SCK takes a break and goes to the idle state for tASC + tCSC ns. In other words, the default values (of 0 and 0 ns) result in SCK glitches where the SCK transition to the idle state, as well as the SCK transition from the idle state, will have no delay in between, and it may appear that a SCK cycle has simply gone missing. The resulting timing violation might cause data corruption in many peripherals, as their chip select is asserted. The driver has device tree bindings for tCSC ("fsl,spi-cs-sck-delay") and tASC ("fsl,spi-sck-cs-delay"), but these are only specified to apply when the chip select toggles in the first place, and this timing characteristic depends on each peripheral. Many peripherals do not have explicit timing requirements, so many device trees do not have these properties present at all. Nonetheless, the lack of SCK glitches is a common sense requirement, and since the SCK stays in the idle state during transfers for tCSC+tASC ns, and that in itself should look like half a cycle, then let's ensure that tCSC and tASC are at least a quarter of a SCK period, such that their sum is at least half of one. Fixes: 95bf15f38641 ("spi: fsl-dspi: Add ~50ns delay between cs and sck") Reported-by: Lisa Chen (陈敏捷) <minjie.chen@geekplus.com> Debugged-by: Lisa Chen (陈敏捷) <minjie.chen@geekplus.com> Tested-by: Lisa Chen (陈敏捷) <minjie.chen@geekplus.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20230529223402.1199503-1-vladimir.oltean@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-21spi: cadence-quadspi: Add missing check for dma_set_maskJiasheng Jiang1-2/+5
[ Upstream commit 947c70a213769f60e9d5aca2bc88b50a1cfaf5a6 ] Add check for dma_set_mask() and return the error if it fails. Fixes: 1a6f854f7daa ("spi: cadence-quadspi: Add Xilinx Versal external DMA support") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Link: https://lore.kernel.org/r/20230606093859.27818-1-jiasheng@iscas.ac.cn Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-14spi: qup: Request DMA before enabling clocksStephan Gerhold1-19/+18
[ Upstream commit 0c331fd1dccfba657129380ee084b95c1cedfbef ] It is usually better to request all necessary resources (clocks, regulators, ...) before starting to make use of them. That way they do not change state in case one of the resources is not available yet and probe deferral (-EPROBE_DEFER) is necessary. This is particularly important for DMA channels and IOMMUs which are not enforced by fw_devlink yet (unless you use fw_devlink.strict=1). spi-qup does this in the wrong order, the clocks are enabled and disabled again when the DMA channels are not available yet. This causes issues in some cases: On most SoCs one of the SPI QUP clocks is shared with the UART controller. When using earlycon UART is actively used during boot but might not have probed yet, usually for the same reason (waiting for the DMA controller). In this case, the brief enable/disable cycle ends up gating the clock and further UART console output will halt the system completely. Avoid this by requesting the DMA channels before changing the clock state. Fixes: 612762e82ae6 ("spi: qup: Add DMA capabilities") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20230518-spi-qup-clk-defer-v1-1-f49fc9ca4e02@gerhold.net Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-14spi: mt65xx: make sure operations completed before unloadingDaniel Golle1-0/+3
[ Upstream commit 4be47a5d59cbc9396a6ffd327913eb4c8d67a32f ] When unloading the spi-mt65xx kernel module during an ongoing spi-mem operation the kernel will Oops shortly after unloading the module. This is because wait_for_completion_timeout was still running and returning into the no longer loaded module: Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: [many, but spi-mt65xx is no longer there] CPU: 0 PID: 2578 Comm: block Tainted: G W O 6.3.0-next-20230428+ #0 Hardware name: Bananapi BPI-R3 (DT) pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __lock_acquire+0x18c/0x20e8 lr : __lock_acquire+0x9b8/0x20e8 sp : ffffffc009ec3400 x29: ffffffc009ec3400 x28: 0000000000000001 x27: 0000000000000004 x26: ffffff80082888c8 x25: 0000000000000000 x24: 0000000000000000 x23: ffffffc009609da8 x22: ffffff8008288000 x21: ffffff8008288968 x20: 00000000000003c2 x19: ffffff8008be7990 x18: 00000000000002af x17: 0000000000000000 x16: 0000000000000000 x15: ffffffc008d78970 x14: 000000000000080d x13: 00000000000002af x12: 00000000ffffffea x11: 00000000ffffefff x10: ffffffc008dd0970 x9 : ffffffc008d78918 x8 : 0000000000017fe8 x7 : 0000000000000001 x6 : 0000000000000000 x5 : ffffff807fb53910 x4 : 0000000000000000 x3 : 0000000000000027 x2 : 0000000000000027 x1 : 0000000000000000 x0 : 00000000000c03c2 Call trace: __lock_acquire+0x18c/0x20e8 lock_acquire+0x100/0x2a4 _raw_spin_lock_irq+0x58/0x74 __wait_for_common+0xe0/0x1b4 wait_for_completion_timeout+0x1c/0x24 0xffffffc000acc8a4 <--- used to be mtk_spi_transfer_wait spi_mem_exec_op+0x390/0x3ec spi_mem_no_dirmap_read+0x6c/0x88 spi_mem_dirmap_read+0xcc/0x12c spinand_read_page+0xf8/0x1dc spinand_mtd_read+0x1b4/0x2fc mtd_read_oob_std+0x58/0x7c mtd_read_oob+0x8c/0x148 mtd_read+0x50/0x6c ... Prevent this by completing in mtk_spi_remove if needed. Fixes: 9f763fd20da7 ("spi: mediatek: add spi memory support for ipm design") Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/r/ZFAF6pJxMu1z6k4w@makrotopia.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-24spi: spi-imx: fix MX51_ECSPI_* macros when cs > 3Kevin Groeneveld1-6/+18
[ Upstream commit 87c614175bbf28d3fd076dc2d166bac759e41427 ] When using gpio based chip select the cs value can go outside the range 0 – 3. The various MX51_ECSPI_* macros did not take this into consideration resulting in possible corruption of the configuration. For example for any cs value over 3 the SCLKPHA bits would not be set and other values in the register possibly corrupted. One way to fix this is to just mask the cs bits to 2 bits. This still allows all 4 native chip selects to work as well as gpio chip selects (which can use any of the 4 chip select configurations). Signed-off-by: Kevin Groeneveld <kgroeneveld@lenbrook.com> Link: https://lore.kernel.org/r/20230318222132.3373-1-kgroeneveld@lenbrook.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-17spi: fsl-cpm: Use 16 bit mode for large transfers with even sizeChristophe Leroy2-0/+26
commit fc96ec826bced75cc6b9c07a4ac44bbf651337ab upstream. On CPM, the RISC core is a lot more efficiant when doing transfers in 16-bits chunks than in 8-bits chunks, but unfortunately the words need to be byte swapped as seen in a previous commit. So, for large tranfers with an even size, allocate a temporary tx buffer and byte-swap data before and after transfer. This change allows setting higher speed for transfer. For instance on an MPC 8xx (CPM1 comms RISC processor), the documentation tells that transfer in byte mode at 1 kbit/s uses 0.200% of CPM load at 25 MHz while a word transfer at the same speed uses 0.032% of CPM load. This means the speed can be 6 times higher in word mode for the same CPM load. For the time being, only do it on CPM1 as there must be a trade-off between the CPM load reduction and the CPU load required to byte swap the data. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Link: https://lore.kernel.org/r/f2e981f20f92dd28983c3949702a09248c23845c.1680371809.git.christophe.leroy@csgroup.eu Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-17spi: fsl-spi: Re-organise transfer bits_per_word adaptationChristophe Leroy1-25/+21
commit 8a5299a1278eadf1e08a598a5345c376206f171e upstream. For different reasons, fsl-spi driver performs bits_per_word modifications for different reasons: - On CPU mode, to minimise amount of interrupts - On CPM/QE mode to work around controller byte order For CPU mode that's done in fsl_spi_prepare_message() while for CPM mode that's done in fsl_spi_setup_transfer(). Reunify all of it in fsl_spi_prepare_message(), and catch impossible cases early through master's bits_per_word_mask instead of returning EINVAL later. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Link: https://lore.kernel.org/r/0ce96fe96e8b07cba0613e4097cfd94d09b8919a.1680371809.git.christophe.leroy@csgroup.eu Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-11spi: cadence-quadspi: use macro DEFINE_SIMPLE_DEV_PM_OPSDhruva Gole1-11/+2
[ Upstream commit be3206e8906e7a93df673ab2e96d69304a008edc ] Using this macro makes the code more readable. It also inits the members of dev_pm_ops in the following manner without us explicitly needing to: .suspend = cqspi_suspend, \ .resume = cqspi_resume, \ .freeze = cqspi_suspend, \ .thaw = cqspi_resume, \ .poweroff = cqspi_suspend, \ .restore = cqspi_resume Also get rid of conditional compilation based on CONFIG_PM_SLEEP because it introduces build issues with certain configs when CQSPI_DEV_PM_OPS is just NULL. Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/oe-kbuild-all/202304191900.2fARFQW9-lkp@intel.com/ Fixes: 140623410536 ("mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller") Signed-off-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20230420054257.925092-1-d-gole@ti.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11spi: cadence-quadspi: fix suspend-resume implementationsDhruva Gole1-3/+16
[ Upstream commit 2087e85bb66ee3652dafe732bb9b9b896229eafc ] The cadence QSPI driver misbehaves after performing a full system suspend resume: ... spi-nor spi0.0: resume() failed ... This results in a flash connected via OSPI interface after system suspend- resume to be unusable. fix these suspend and resume functions. Fixes: 140623410536 ("mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller") Signed-off-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20230417091027.966146-3-d-gole@ti.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11spi: fsl-spi: Fix CPM/QE mode Litte EndianChristophe Leroy1-5/+7
[ Upstream commit c20c57d9868d7f9fd1b2904c7801b07e128f6322 ] CPM has the same problem as QE so for CPM also use the fix added by commit 0398fb70940e ("spi/spi_mpc8xxx: Fix QE mode Litte Endian"): CPM mode uses Little Endian so words > 8 bits are byte swapped. Workaround this by always enforcing wordsize 8 for 16 and 32 bits words. Unfortunately this will not work for LSB transfers where wordsize is > 8 bits so disable these for now. Also limit the workaround to 16 and 32 bits words because it can only work for multiples of 8-bits. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Joakim Tjernlund <Joakim.Tjernlund@infinera.com> Fixes: 0398fb70940e ("spi/spi_mpc8xxx: Fix QE mode Litte Endian") Link: https://lore.kernel.org/r/1b7d3e84b1128f42c1887dd2fb9cdf390f541bc1.1680371809.git.christophe.leroy@csgroup.eu Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11spi: qup: Don't skip cleanup in remove's error pathUwe Kleine-König1-9/+13
[ Upstream commit 61f49171a43ab1f80c73c5c88c508770c461e0f2 ] Returning early in a platform driver's remove callback is wrong. In this case the dma resources are not released in the error path. this is never retried later and so this is a permanent leak. To fix this, only skip hardware disabling if waking the device fails. Fixes: 64ff247a978f ("spi: Add Qualcomm QUP SPI controller support") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230330210341.2459548-2-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11spi: imx: Don't skip cleanup in remove's error pathUwe Kleine-König1-7/+5
[ Upstream commit 11951c9e3f364d7ae3b568a0e52c8335d43066b5 ] Returning early in a platform driver's remove callback is wrong. In this case the dma resources are not released in the error path. this is never retried later and so this is a permanent leak. To fix this, only skip hardware disabling if waking the device fails. Fixes: d593574aff0a ("spi: imx: do not access registers while clocks disabled") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230306065733.2170662-2-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11spi: atmel-quadspi: Free resources even if runtime resume failed in .remove()Uwe Kleine-König1-7/+17
[ Upstream commit 9448bc1dee65f86c0fe64d9dea8b410af0586886 ] An early error exit in atmel_qspi_remove() doesn't prevent the device unbind. So this results in an spi controller with an unbound parent and unmapped register space (because devm_ioremap_resource() is undone). So using the remaining spi controller probably results in an oops. Instead unregister the controller unconditionally and only skip hardware access and clk disable. Also add a warning about resume failing and return zero unconditionally. The latter has the only effect to suppress a less helpful error message by the spi core. Fixes: 4a2f83b7f780 ("spi: atmel-quadspi: add runtime pm support") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://lore.kernel.org/r/20230317084232.142257-3-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11spi: atmel-quadspi: Don't leak clk enable count in pm resumeUwe Kleine-König1-1/+5
[ Upstream commit c18bbac353ffed50be134b0a2a059a2bd540c503 ] The pm resume call is supposed to enable two clocks. If the second enable fails the callback reports failure but doesn't undo the first enable. So call clk_disable() for the first clock when clk_enable() for the second one fails. Fixes: 4a2f83b7f780 ("spi: atmel-quadspi: add runtime pm support") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://lore.kernel.org/r/20230317084232.142257-2-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-26spi: spi-rockchip: Fix missing unwind goto in rockchip_sfc_probe()Li Lanzhe1-1/+1
[ Upstream commit 359f5b0d4e26b7a7bcc574d6148b31a17cefe47d ] If devm_request_irq() fails, then we are directly return 'ret' without clk_disable_unprepare(sfc->clk) and clk_disable_unprepare(sfc->hclk). Fix this by changing direct return to a goto 'err_irq'. Fixes: 0b89fc0a367e ("spi: rockchip-sfc: add rockchip serial flash controller") Signed-off-by: Li Lanzhe <u202212060@hust.edu.cn> Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn> Link: https://lore.kernel.org/r/20230419115030.6029-1-u202212060@hust.edu.cn Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-17spi: intel: Check number of chip selects after reading the descriptorMika Westerberg1-4/+4
[ Upstream commit 574fbb95cd9d88bdc9c9c4c64223a38a61d7de9a ] The flash decriptor contains the number of flash components that we use to figure out how many flash chips there are connected. Therefore we need to read it first before deciding how many chip selects the controller has. Reported-by: Marcin Witkowski <marcin.witkowski@intel.com> Fixes: 3f03c618bebb ("spi: intel: Add support for second flash chip") Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20230215110040.42186-1-mika.westerberg@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-11spi: tegra210-quad: Fix iterator outside loopKrishna Yarlagadda1-4/+8
[ Upstream commit 2449d436681d40bc63ec2c766fd51b632270d8a7 ] Fix warn: iterator used outside loop: 'xfer'. 'xfer' variable contain invalid value in few conditions. Complete transfer within DATA phase in successful case and at the end for failed transfer. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Link:https://lore.kernel.org/all/202210191211.46FkzKmv-lkp@intel.com/ Fixes: 8777dd9dff40 ("spi: tegra210-quad: Fix combined sequence") Signed-off-by: Krishna Yarlagadda <kyarlagadda@nvidia.com> Link: https://lore.kernel.org/r/20230227200428.45832-1-kyarlagadda@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-11spi: tegra210-quad: Fix validate combined sequenceKrishna Yarlagadda1-1/+1
[ Upstream commit 047ee71ae4f412d8819e39e4b08c588fa299cfc2 ] Check for non dma transfers that do not fit in FIFO has issue and skips combined sequence for Tegra234 & Tegra241 which does not have GPCDMA. Fixes: 1b8342cc4a38 ("spi: tegra210-quad: combined sequence mode") Signed-off-by: Krishna Yarlagadda <kyarlagadda@nvidia.com> Link: https://lore.kernel.org/r/20230224164034.56933-1-kyarlagadda@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10spi: synquacer: Fix timeout handling in synquacer_spi_transfer_one()Christophe JAILLET1-4/+3
[ Upstream commit e6a0b671880207566e1ece983bf989dde60bc1d7 ] wait_for_completion_timeout() never returns a <0 value. It returns either on timeout or a positive value (at least 1, or number of jiffies left till timeout) So, fix the error handling path and return -ETIMEDOUT should a timeout occur. Fixes: b0823ee35cf9 ("spi: Add spi driver for Socionext SynQuacer platform") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Jassi Brar <jaswinder.singh@linaro.org> Link: https://lore.kernel.org/r/c2040bf3cfa201fd8890cfab14fa5a701ffeca14.1676466072.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10spi: bcm63xx-hsspi: Fix multi-bit mode settingWilliam Zhang1-3/+9
[ Upstream commit 811ff802aaf878ebbbaeac0307a0164fa21e7d40 ] Currently the driver always sets the controller to dual data bit mode for both tx and rx data in the profile mode control register even for single data bit transfer. Luckily the opcode is set correctly according to SPI transfer data bit width so it does not actually cause issues. This change fixes the problem by setting tx and rx data bit mode field correctly according to the actual SPI transfer tx and rx data bit width. Fixes: 142168eba9dc ("spi: bcm63xx-hsspi: add bcm63xx HSSPI driver") Signed-off-by: William Zhang <william.zhang@broadcom.com> Link: https://lore.kernel.org/r/20230209200246.141520-11-william.zhang@broadcom.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10spi: dw_bt1: fix MUX_MMIO dependenciesArnd Bergmann1-1/+0
[ Upstream commit d4bde04318c0d33705e9a77d4c7df72f262011e0 ] Selecting a symbol with additional dependencies requires adding the same dependency here: WARNING: unmet direct dependencies detected for MUX_MMIO Depends on [n]: MULTIPLEXER [=y] && OF [=n] Selected by [y]: - SPI_DW_BT1 [=y] && SPI [=y] && SPI_MASTER [=y] && SPI_DESIGNWARE [=y] && (MIPS_BAIKAL_T1 || COMPILE_TEST [=y]) Drop the 'select' here to avoid the problem. Anyone using the dw-bt1 SPI driver should make sure they include the mux driver as well now. Fixes: 7218838109fe ("spi: dw-bt1: Fix undefined devm_mux_control_get symbol") Fixes: abf00907538e ("spi: dw: Add Baikal-T1 SPI Controller glue driver") Link: https://lore.kernel.org/all/20221218192523.c6vnfo26ua6xqf26@mobilestation/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20230130140156.3620863-1-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-25spi: mediatek: Enable irq before the spi registrationRicardo Ribalda1-7/+5
[ Upstream commit b24cded8c065d7cef8690b2c7b82b828cce57708 ] If the irq is enabled after the spi si registered, there can be a race with the initialization of the devices on the spi bus. Eg: mtk-spi 1100a000.spi: spi-mem transfer timeout spi-nor: probe of spi0.0 failed with error -110 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: mtk_spi_can_dma+0x0/0x2c Fixes: c6f7874687f7 ("spi: mediatek: Enable irq when pdata is ready") Reported-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Tested-by: Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/r/20221225-mtk-spi-fixes-v1-0-bb6c14c232f8@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-25spi: mediatek: Enable irq when pdata is readyRicardo Ribalda1-5/+7
[ Upstream commit c6f7874687f7027d7c4b2f53ff6e4d22850f915d ] If the device does not come straight from reset, we might receive an IRQ before we are ready to handle it. Fixes: [ 0.832328] Unable to handle kernel read from unreadable memory at virtual address 0000000000000010 [ 1.040343] Call trace: [ 1.040347] mtk_spi_can_dma+0xc/0x40 ... [ 1.262265] start_kernel+0x338/0x42c Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20221128-spi-mt65xx-v1-0-509266830665@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-14spi: dw: Fix wrong FIFO level setting for long xfersSerge Semin1-1/+1
[ Upstream commit c63b8fd14a7db719f8252038a790638728c4eb66 ] Due to using the u16 type in the min_t() macros the SPI transfer length will be cast to word before participating in the conditional statement implied by the macro. Thus if the transfer length is greater than 64KB the Tx/Rx FIFO threshold level value will be determined by the leftover of the truncated after the type-case length. In the worst case it will cause the dramatical performance drop due to the "Tx FIFO Empty" or "Rx FIFO Full" interrupts triggered on each xfer word sent/received to/from the bus. The problem can be easily fixed by specifying the unsigned int type in the min_t() macros thus preventing the possible data loss. Fixes: ea11370fffdf ("spi: dw: get TX level without an additional variable") Reported-by: Sergey Nazarov <Sergey.Nazarov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230113185942.2516-1-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-01spi: spidev: remove debug messages that access spidev->spi without lockingBartosz Golaszewski1-2/+0
[ Upstream commit 6b35b173dbc1711f8d272e3f322d2ad697015919 ] The two debug messages in spidev_open() dereference spidev->spi without taking the lock and without checking if it's not null. This can lead to a crash. Drop the messages as they're not needed - the user-space will get informed about ENOMEM with the syscall return value. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20230106100719.196243-2-brgl@bgdev.pl Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-01spi: cadence: Fix busy cycles calculationWitold Sadowski1-1/+4
[ Upstream commit e8bb8f19e73a1e855e54788f8673b9b49e46b5cd ] If xSPI is in x2/x4/x8 mode to calculate busy cycles, busy bits count must be divided by the number of lanes. If opcommand is using 8 busy bits, but SPI is in x4 mode, there will be only 2 busy cycles. Signed-off-by: Witold Sadowski <wsadowski@marvell.com> Reviewed-by: Chandrakala Chavva <cchavva@marvell.com> Reviewed-by: Sunil Kovvuri Goutham <sgoutham@marvell.com> Link: https://lore.kernel.org/r/20221219144254.20883-2-wsadowski@marvell.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31spi: fsl_spi: Don't change speed while chipselect is activeChristophe Leroy1-3/+16
commit 3b553e0041a65e499fa4e25ee146f01f4ec4e617 upstream. Commit c9bfcb315104 ("spi_mpc83xx: much improved driver") made modifications to the driver to not perform speed changes while chipselect is active. But those changes where lost with the convertion to tranfer_one. Previous implementation was allowing speed changes during message transfer when cs_change flag was set. At the time being, core SPI does not provide any feature to change speed while chipselect is off, so do not allow any speed change during message transfer, and perform the transfer setup in prepare_message in order to set correct speed while chipselect is still off. Reported-by: Herve Codina <herve.codina@bootlin.com> Fixes: 64ca1a034f00 ("spi: fsl_spi: Convert to transfer_one") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Tested-by: Herve Codina <herve.codina@bootlin.com> Reviewed-by: Herve Codina <herve.codina@bootlin.com> Link: https://lore.kernel.org/r/8aab84c51aa330cf91f4b43782a1c483e150a4e3.1671025244.git.christophe.leroy@csgroup.eu Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-31spi: spi-gpio: Don't set MOSI as an input if not 3WIRE modeKris Bahnsen1-3/+13
[ 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 <kris@embeddedTS.com> Link: https://lore.kernel.org/r/20221207230853.6174-1-kris@embeddedTS.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31spi: spidev: mask SPI_CS_HIGH in SPI_IOC_RD_MODEAlexander Sverdlin1-5/+16
[ 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 <sys/ioctl.h> #include <fcntl.h> #include <linux/spi/spidev.h> 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 <alexander.sverdlin@siemens.com> Link: https://lore.kernel.org/r/20221130162927.539512-1-alexander.sverdlin@siemens.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-11-23Merge tag 'spi-fix-v6.1-rc6' of ↵Linus Torvalds4-7/+20
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "A few fixes, all device specific. The most important ones are for the i.MX driver which had a couple of nasty data corruption inducing errors appear after the change to support PIO mode in the last merge window (one introduced by the change and one latent one which the PIO changes exposed). Thanks to Frieder, Fabio, Marc and Marek for jumping on that and resolving the issues quickly once they were found" * tag 'spi-fix-v6.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: spi-imx: spi_imx_transfer_one(): check for DMA transfer first spi: tegra210-quad: Fix duplicate resource error spi: dw-dma: decrease reference count in dw_spi_dma_init_mfld() spi: spi-imx: Fix spi_bus_clk if requested clock is higher than input clock spi: mediatek: Fix DEVAPC Violation at KO Remove
2022-11-18spi: spi-imx: spi_imx_transfer_one(): check for DMA transfer firstMarc Kleine-Budde1-3/+7
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 <frieder.schrempf@kontron.de> Reported-by: Fabio Estevam <festevam@gmail.com> Tested-by: Fabio Estevam <festevam@gmail.com> Cc: David Jander <david@protonic.nl> Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Link: https://lore.kernel.org/r/20221116164930.855362-1-mkl@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>