aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/spi
AgeCommit message (Collapse)AuthorFilesLines
2021-01-13spi: sh-msiof: Fill in controller speed limitsGeert Uytterhoeven1-0/+4
Fill in the controller speed limits, so the SPI core can use them for validating SPI transfers, and adjust or reject transfers when needed. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210113101916.1147695-3-geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-13spi: sh-msiof: Fill in spi_transfer.effective_speed_hzGeert Uytterhoeven1-3/+7
Fill in the effective bit rate used for transfers, so the SPI core can calculate instead of estimate delays. Restore "reverse Christmas tree" order of local variables while adding new variables. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210113101916.1147695-2-geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-13spi: cadence-quadspi: Add multi-chipselect support for Intel LGM SoCRamuthevar Vadivel Murugan1-0/+6
Add multiple chipselect support for Intel LGM SoCs, currently QSPI-NOR and QSPI-NAND supported. Signed-off-by: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com> Link: https://lore.kernel.org/r/20201124041840.31066-4-vadivel.muruganx.ramuthevar@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-13spi: cadence-quadspi: Disable the DAC for Intel LGM SoCRamuthevar Vadivel Murugan1-4/+11
On Intel Lightning Mountain(LGM) SoCs QSPI controller do not use Direct Access Controller(DAC). This patch adds a quirk to disable the Direct Access Controller for data transfer instead it uses indirect data transfe DAC bit resets to 1 so there is no need to explicitly set it. Signed-off-by: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com> Link: https://lore.kernel.org/r/20201124041840.31066-3-vadivel.muruganx.ramuthevar@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-13spi: cadence-quadspi: Add QSPI support for Intel LGM SoCRamuthevar Vadivel Murugan2-1/+4
Add QSPI controller support for Intel LGM SoC. Signed-off-by: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com> Link: https://lore.kernel.org/r/20201124041840.31066-2-vadivel.muruganx.ramuthevar@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-11spi: rpc-if: Gaurd .pm assignment with CONFIG_PM_SLEEP #ifdef checkLad Prabhakar1-0/+2
With CONFIG_PM_SLEEP disabled the rpcif_spi_pm_ops variable is still referenced and thus increasing the size of kernel. Fix this issue by adding CONFIG_PM_SLEEP #ifdef check around the .pm assignment (image size is critical on RZ/A SoC's where the SRAM sizes range 4~5 MiB). Fixes: 9584fc95cadc0 ("spi: rpc-if: Remove CONFIG_PM_SLEEP ifdefery") Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Suggested-by: Pavel Machek <pavel@denx.de> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20210107145329.27966-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-11spi: cadence-quadspi: Fix build warning on 32-bit platformsPratyush Yadav1-1/+1
The kernel test robot reports the following warning. drivers/spi/spi-cadence-quadspi.c:966:24: warning: comparison of distinct pointer types ('typeof (len) *' (aka 'unsigned int *') and 'typeof (500UL) *' (aka 'unsigned long *')) [-Wcompare-distinct-pointer-types] msecs_to_jiffies(max(len, 500UL)))) { ^~~~~~~~~~~~~~~ include/linux/minmax.h:58:19: note: expanded from macro 'max' #define max(x, y) __careful_cmp(x, y, >) ^~~~~~~~~~~~~~~~~~~~~~ include/linux/minmax.h:42:24: note: expanded from macro '__careful_cmp' __builtin_choose_expr(__safe_cmp(x, y), \ ^~~~~~~~~~~~~~~~ include/linux/minmax.h:32:4: note: expanded from macro '__safe_cmp' (__typecheck(x, y) && __no_side_effects(x, y)) ^~~~~~~~~~~~~~~~~ include/linux/minmax.h:18:28: note: expanded from macro '__typecheck' (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) ~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~ 1 warning generated. This happens because size_t is unsigned long on 64-bit platforms like arm64 but it is unsigned int on 32-bit platforms like arm. Omitting the "UL" would result in a warning on 64-bit platforms. Squash it by type casting the arguments to size_t using max_t(). This way builds on both type of platforms can be satisfied. There is no chance of any truncation since 500 is small enough to fit into both int and long. Fixes: f453f293979f ("spi: cadence-quadspi: Wait at least 500 ms for direct reads") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Link: https://lore.kernel.org/r/20210108181457.30291-1-p.yadav@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-11spi: spi-bcm-qspi: style: Simplify bool comparisonYANG LI1-1/+1
Fix the following coccicheck warning: ./drivers/spi/spi-bcm-qspi.c:884:5-34: WARNING: Comparison to bool Signed-off-by: YANG LI <abaci-bugfix@linux.alibaba.com> Reported-by: Abaci Robot<abaci@linux.alibaba.com> Link: https://lore.kernel.org/r/1610357189-60031-1-git-send-email-abaci-bugfix@linux.alibaba.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-08spi: Fix distinct pointer types warning for ARCH=mipsYanteng Si1-1/+1
Fix a new warning report by build for make ARCH=MIPS allmodconfig: drivers/spi/spi-cadence-quadspi.c: In function 'cqspi_direct_read_execute': ./include/linux/minmax.h:18:28: warning: comparison of distinct pointer types lacks a cast 18 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) | ^~ ./include/linux/minmax.h:32:4: note: in expansion of macro '__typecheck' 32 | (__typecheck(x, y) && __no_side_effects(x, y)) | ^~~~~~~~~~~ ./include/linux/minmax.h:42:24: note: in expansion of macro '__safe_cmp' 42 | __builtin_choose_expr(__safe_cmp(x, y), \ | ^~~~~~~~~~ ./include/linux/minmax.h:58:19: note: in expansion of macro '__careful_cmp' 58 | #define max(x, y) __careful_cmp(x, y, >) | ^~~~~~~~~~~~~ drivers/spi/spi-cadence-quadspi.c:1153:24: note: in expansion of macro 'max' 1153 | msecs_to_jiffies(max(len, 500UL)))) { | ^~~ "len" is unsigned,however,"500" is unsigned long. Signed-off-by: Yanteng Si <siyanteng@loongson.cn> Link: https://lore.kernel.org/r/20210107115704.3835282-1-siyanteng@loongson.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-06Merge series "Add Tegra Quad SPI driver" from Sowjanya Komatineni <skomatineni@nvidia.com>:Mark Brown4-0/+1421
This series adds Tegra210, Tegra186, and Tegra194 Quad SPI driver and enables Quad SPI on Jetson Nano and Jetson Xavier NX. QSPI controller is available on Tegra210, Tegra186 and Tegra194. Tegra186 and Tegra194 has additional feature of combined sequence mode where command, address and data can all be transferred in a single transfer. Combined sequence mode is useful only when using DMA mode transfer. This series does not have combined sequence mode feature as Tegra186/Tegra194 GPCDMA driver is not upstreamed yet. This series includes - dt-binding document - QSPI driver for Tegra210/Tegra186/Tegra194 - Enables QSPI on Jetson Nano and Jetson Xavier NX. Delta between patch versions: [v5]: Simplified implementation in Patch-0006 [v4]: Updated dummy cycles implementation based on v3 feedback - Added dummy_data bit field int spi_transfer to indicate corresponding transfer is dummy bytes transfer. - Updated Tegra QSPI transfer_one_message to identify dummy transfer and to use HW supported dummy bytes transfer when dummy cycles are with in Tegra QSPI supported max HW dummy cycles otherwise fallsback to transfer dummy bytes from software. - Updated dt-bindings based on v3 feedback. [v3]: v2 has some mixed patches sent out accidentally. v3 sends proper patches with fixes mentioned in v2. [v2]: below v1 feedback - Added SPI_MASTER_USES_HW_DUMMY_CYCLES flag for controllers supporting hardware dummy cycles and skips dummy bytes transfer from software for these controllers. - Updated dt-binding doc with tx/rx tap delay properties. - Added qspi_out clock to dt-binding doc which will be used later with ddr mode support. - All other v1 feedback on some cleanup. Sowjanya Komatineni (9): dt-bindings: clock: tegra: Add clock ID TEGRA210_CLK_QSPI_PM dt-bindings: spi: Add Tegra Quad SPI device tree binding MAINTAINERS: Add Tegra Quad SPI driver section spi: tegra210-quad: Add support for Tegra210 QSPI controller spi: spi-mem: Mark dummy transfers by setting dummy_data bit spi: tegra210-quad: Add support for hardware dummy cycles transfer arm64: tegra: Enable QSPI on Jetson Nano arm64: tegra: Add QSPI nodes on Tegra194 arm64: tegra: Enable QSPI on Jetson Xavier NX .../bindings/spi/nvidia,tegra210-quad.yaml | 117 ++ MAINTAINERS | 8 + .../dts/nvidia/tegra194-p3509-0000+p3668-0000.dts | 12 + arch/arm64/boot/dts/nvidia/tegra194.dtsi | 28 + arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts | 12 + arch/arm64/boot/dts/nvidia/tegra210.dtsi | 5 +- drivers/spi/Kconfig | 9 + drivers/spi/Makefile | 1 + drivers/spi/spi-mem.c | 1 + drivers/spi/spi-tegra210-quad.c | 1410 ++++++++++++++++++++ include/dt-bindings/clock/tegra210-car.h | 2 +- include/linux/spi/spi.h | 2 + 12 files changed, 1604 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml create mode 100644 drivers/spi/spi-tegra210-quad.c -- 2.7.4
2021-01-06spi: tegra210-quad: Add support for hardware dummy cycles transferSowjanya Komatineni1-3/+31
Tegra Quad SPI controller hardware supports sending dummy bytes based on programmed dummy clock cycles after the actual transfer bytes. This patch adds this support of hardware dummy bytes transfer and skips transfer of dummy bytes from the software. For dummy cycles more than Tegra Quad SPI hardware maximum dummy cycles limit, driver transfers dummy bytes from the software. Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Link: https://lore.kernel.org/r/1608585459-17250-7-git-send-email-skomatineni@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-06spi: spi-mem: Mark dummy transfers by setting dummy_data bitSowjanya Komatineni1-0/+1
This patch marks dummy transfer by setting dummy_data bit to 1. Controllers supporting dummy transfer by hardware use this bit field to skip software transfer of dummy bytes and use hardware dummy bytes transfer. Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Link: https://lore.kernel.org/r/1608585459-17250-6-git-send-email-skomatineni@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-06spi: tegra210-quad: Add support for Tegra210 QSPI controllerSowjanya Komatineni3-0/+1392
Tegra SoC has a Quad SPI controller starting from Tegra210. This patch adds support for Tegra210 QSPI controller. Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Link: https://lore.kernel.org/r/1608585459-17250-5-git-send-email-skomatineni@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-06spi: cadence-quadspi: Add DTR supportPratyush Yadav1-39/+242
Double Transfer Rate (DTR) mode transfers data twice per clock cycle. Add support for parsing DTR ops and set up the registers to allow it. Most SPI NOR flashes expect 2 byte commands. Parse the 2-byte opcode from SPI MEM and set it up in the CQSPI_REG_OP_EXT_LOWER register. Increment the delay needed before issuing indirect writes because larger delay is needed for DTR mode. With the current delay some writes end up missing. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Link: https://lore.kernel.org/r/20201222184425.7028-8-p.yadav@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-06spi: cadence-quadspi: Wait at least 500 ms for direct readsPratyush Yadav1-1/+1
When performing a direct read via DMA the timeout for completion is set equal to the read length. This is fine for larger reads. For a small read like the Read Status Register command, the timeout would be 1 or 2 milliseconds. This is not enough to cover the overhead needed in setting up DMA. Make sure the timeout is at least 500 ms to allow DMA ample time to finish. For reads larger than 500 bytes, the timeout will continue to be equal to the read length. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20201222184425.7028-7-p.yadav@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-06spi: cadence-quadspi: Implement a simple supports_op hookPratyush Yadav1-0/+61
The default SPI MEM supports_op hook rejects DTR ops by default. Add a simple supports_op hook that very closely imitates the SPI MEM one. It will be extended in later commits to allow DTR ops. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Link: https://lore.kernel.org/r/20201222184425.7028-6-p.yadav@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-06spi: cadence-quadspi: Fix dummy cycle calculation when buswidth > 1Pratyush Yadav1-1/+1
SPI MEM deals with dummy bytes but the controller deals with dummy cycles. Multiplying bytes by 8 is correct if the dummy phase uses 1S mode since 1 byte will be sent in 8 cycles. But if the dummy phase uses 4S mode then 1 byte will be sent in 2 cycles. To correctly translate dummy bytes to dummy cycles, the dummy buswidth also needs to be taken into account. Divide 8 by the buswidth to get the correct multiplier for getting the number of cycles. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Link: https://lore.kernel.org/r/20201222184425.7028-5-p.yadav@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-06spi: cadence-quadspi: Set dummy cycles from STIG commandsPratyush Yadav1-1/+22
If a command does not have an address phase it goes via the STIG path. The dummy cycles are not initialized for the STIG commands. As a result, STIG commands with dummy cycles will not work. Initialize the dummy cycle field before issuing the STIG command to make sure it is sent correctly. Move the code to calculate dummy cycle value to a separate function so it is not repeated twice. DTR support will add some more logic here to it is worth it to extract it out in a function. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Link: https://lore.kernel.org/r/20201222184425.7028-4-p.yadav@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-06spi: cadence-quadspi: Abort read if dummy cycles required are too manyPratyush Yadav1-1/+1
The controller can only support up to 31 dummy cycles. If the command requires more it falls back to using 31. This command is likely to fail because the correct number of cycles are not waited upon. Rather than silently issuing an incorrect command, fail loudly so the caller can get a chance to find out the command can't be supported by the controller. Fixes: 140623410536 ("mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller") Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Link: https://lore.kernel.org/r/20201222184425.7028-3-p.yadav@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-06spi: cadence-quadspi: Set master max_speed_hzPratyush Yadav1-0/+1
As of commit 9326e4f1e5dd ("spi: Limit the spi device max speed to controller's max speed"), the SPI device max speed is set to the controller's max speed if it is larger. The Cadence QSPI controller does not set the controller's max speed so it is left at its initial value of 0. This means the SPI device max speed is always set to 0. The SPI device max speed is used to calculate the baud rate divider when performing an operation. If this speed is 0, the default divider of 32 is used. No matter what speed is specified by the device tree property 'spi-max-frequency', the device will always operate at ref_clk / 32. Fix this by setting master->max_speed_hz to the ref clock speed so the correct divider can be calculated. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Link: https://lore.kernel.org/r/20201222184425.7028-2-p.yadav@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-05spi: txx9: Remove driverThomas Bogendoerfer3-484/+0
CPU support for TX49xx is getting removed, so remove support SPI driver for it. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Link: https://lore.kernel.org/r/20210105140305.141401-5-tsbogend@alpha.franken.de Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-05spi: stm32: update dev_dbg() print format for SPI paramsAlexandru Ardelean1-4/+4
With the introduction of the 'include/uapi/linux/spi/spi.h' header, the type of the macros are enforced to 'unsigned long int' via the _BITUL() macro. This causes some -Wformat warnings in the spi-stm32 driver. This patch adds a double-negation operator to the bit-masks. Essentially, the important values for debugging are 0 or 1, while masking them directly would show 0 or BIT(x) values. This way, the type of the arguments are automatically re-cast. Fixes: f7005142dace ("spi: uapi: unify SPI modes into a single spi.h header") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210104143103.56510-1-alexandru.ardelean@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-04spi: renesas rpc-if: Update Add RZ/G2 to Kconfig descriptionAdam Ford1-1/+1
The SPI driver for the Renesas RPC-IF is present on the RZ/G2 Series. Add that to the description. Suggested-by: Biju Das <biju.das.jz@bp.renesas.com> Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210102115412.3402059-3-aford173@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-04spi: fix the divide by 0 error when calculating xfer waiting timeXu Yilun1-1/+5
The xfer waiting time is the result of xfer->len / xfer->speed_hz. This patch makes the assumption of 100khz xfer speed if the xfer->speed_hz is not assigned and stays 0. This avoids the divide by 0 issue and ensures a reasonable tolerant waiting time. Signed-off-by: Xu Yilun <yilun.xu@intel.com> Link: https://lore.kernel.org/r/1609723749-3557-1-git-send-email-yilun.xu@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-31spi: rpc-if: Remove CONFIG_PM_SLEEP ifdeferyLad Prabhakar1-8/+3
Use __maybe_unused for the suspend()/resume() hooks and get rid of the CONFIG_PM_SLEEP ifdefery to improve the code. Suggested-by: Pavel Machek <pavel@denx.de> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Acked-by: Pavel Machek <pavel@denx.de> Link: https://lore.kernel.org/r/20201230145708.28544-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-30spi: Fix the clamping of spi->max_speed_hzTudor Ambarus1-2/+3
If spi->controller->max_speed_hz is zero, a non-zero spi->max_speed_hz will be overwritten by zero. Make sure spi->controller->max_speed_hz is not zero when clamping spi->max_speed_hz. Put the spi->controller->max_speed_hz non-zero check higher in the if, so that we avoid a superfluous init to zero when both spi->max_speed_hz and spi->controller->max_speed_hz are zero. Fixes: 9326e4f1e5dd ("spi: Limit the spi device max speed to controller's max speed") Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20201216092321.413262-1-tudor.ambarus@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-29spi: altera: fix return value for altera_spi_txrx()Xu Yilun1-12/+14
This patch fixes the return value for altera_spi_txrx. It should return 1 for interrupt transfer mode, and return 0 for polling transfer mode. The altera_spi_txrx() implements the spi_controller.transfer_one callback. According to the spi-summary.rst, the transfer_one should return 0 when transfer is finished, return 1 when transfer is still in progress. Signed-off-by: Xu Yilun <yilun.xu@intel.com> Link: https://lore.kernel.org/r/1609219662-27057-2-git-send-email-yilun.xu@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-28spi: Add SPI_NO_TX/RX supportDragos Bogdan1-5/+20
Transmit/receive only is a valid SPI mode. For example, the MOSI/TX line might be missing from an ADC while for a DAC the MISO/RX line may be optional. This patch adds these two new modes: SPI_NO_TX and SPI_NO_RX. This way, the drivers will be able to identify if any of these two lines is missing and to adjust the transfers accordingly. Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20201221152936.53873-2-alexandru.ardelean@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-28spi: orion: enable support for switching CS every transferred byteMarcin Wojtas1-4/+28
Some SPI devices, require toggling the CS every transferred byte. Enable such possibility in the spi-orion driver. Note that in order to use it, in the driver of a secondary device attached to this controller, the SPI bus 'mode' field must be updated with SPI_CS_WORD flag before calling spi_setup() routine. In addition to that include a work-around - some devices, such as certain models of SLIC (Subscriber Line Interface Card), may require extra delay after CS toggling, so add a minimal timing relaxation in relevant places. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: Konstantin Porotchkin <kostap@marvell.com> Link: https://lore.kernel.org/r/20201223103827.29721-3-kostap@marvell.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-28spi: orion: enable clocks before spi_setupMarcin Wojtas1-1/+22
The spi-orion driver disables its clocks whenever it is not used. In usual case during boot (i.e. using SPI flash) it is not a problem, as the child device driver is present and probed along with spi_register_master() execution. However in case the child device driver is not ready (e.g. when its type is module_spi_driver) the spi_setup() callback can be called after the spi-orion probe. It may happen, that as a result there will be an attempt to access controller's registers with the clocks disabled. Prevent such situations and make sure the clocks are on, each time the spi_setup() is called. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: Konstantin Porotchkin <kostap@marvell.com> Link: https://lore.kernel.org/r/20201223103827.29721-2-kostap@marvell.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-21spi: stm32: FIFO threshold level - fix align packet sizeRoman Guskov1-2/+2
if cur_bpw <= 8 and xfer_len < 4 then the value of fthlv will be 1 and SPI registers content may have been lost. * If SPI data register is accessed as a 16-bit register and DSIZE <= 8bit, better to select FTHLV = 2, 4, 6 etc * If SPI data register is accessed as a 32-bit register and DSIZE > 8bit, better to select FTHLV = 2, 4, 6 etc, while if DSIZE <= 8bit, better to select FTHLV = 4, 8, 12 etc Signed-off-by: Roman Guskov <rguskov@dh-electronics.com> Fixes: dcbe0d84dfa5 ("spi: add driver for STM32 SPI controller") Reviewed-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20201221123532.27272-1-rguskov@dh-electronics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-18spi: spi-geni-qcom: Print an error when we timeout setting the CSDouglas Anderson1-1/+3
If we're using geni to manage the chip select line (don't do it--use a GPIO!) and we happen to get a timeout waiting for the chip select command to be completed, no errors are printed even though things might not be in the best shape. Let's add a print. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20201217142842.v3.4.I666b37646de9652cef438ac7c2c6c2053367fc6b@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-18spi: spi-geni-qcom: Don't try to set CS if an xfer is pendingDouglas Anderson1-2/+7
If we get a timeout sending then this happens: spi_transfer_one_message() ->transfer_one() AKA spi_geni_transfer_one() setup_fifo_xfer() mas->cur_xfer = non-NULL spi_transfer_wait() => TIMES OUT if (msg->status != -EINPROGRESS) goto out if (ret != 0 ...) spi_set_cs() ->set_cs AKA spi_geni_set_cs() # mas->cur_xfer is non-NULL The above happens _before_ the SPI core calls ->handle_err() AKA handle_fifo_timeout(). Unfortunately that won't work so well on geni. If we got a timeout transferring then it's likely that our interrupt handler is blocked, but we need that same interrupt handler to run and the command channel to be unblocked in order to adjust the chip select. Trying to set the chip select doesn't crash us but ends up confusing our state machine and leads to messages like: Premature done. rx_rem = 32 bpw8 Let's just drop the chip select request in this case. We can detect the case because cur_xfer is non-NULL--it would have been set to NULL in the interrupt handler if the previous transfer had finished. Sure, we might leave the chip select in the wrong state but it's likely it was going to fail anyway and this avoids getting the driver even more confused about what it's doing. The SPI core in general assumes that setting chip select is a simple operation that doesn't fail. Yet another reason to just reconfigure the chip select line as GPIOs. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20201217142842.v3.3.I07afdedcc49655c5d26880f8df9170aac5792378@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-18spi: spi-geni-qcom: Fail new xfers if xfer/cancel/abort pendingDouglas Anderson1-2/+57
If we got a timeout when trying to send an abort command then it means that we just got 3 timeouts in a row: 1. The original timeout that caused handle_fifo_timeout() to be called. 2. A one second timeout waiting for the cancel command to finish. 3. A one second timeout waiting for the abort command to finish. SPI is clocked by the controller, so nothing (aside from a hardware fault or a totally broken sequencer) should be causing the actual commands to fail in hardware. However, even though the hardware itself is not expected to fail (and it'd be hard to predict how we should handle things if it did), it's easy to hit the timeout case by simply blocking our interrupt handler from running for a long period of time. Obviously the system is in pretty bad shape if a interrupt handler is blocked for > 2 seconds, but there are certainly bugs (even bugs in other unrelated drivers) that can make this happen. Let's make things a bit more robust against this case. If we fail to abort we'll set a flag and then we'll block all future transfers until we have no more interrupts pending. Fixes: 561de45f72bd ("spi: spi-geni-qcom: Add SPI driver support for GENI based QUP") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20201217142842.v3.2.Ibade998ed587e070388b4bf58801f1107a40eb53@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-18spi: spi-geni-qcom: Fix geni_spi_isr() NULL dereference in timeout caseDouglas Anderson1-0/+14
In commit 7ba9bdcb91f6 ("spi: spi-geni-qcom: Don't keep a local state variable") we changed handle_fifo_timeout() so that we set "mas->cur_xfer" to NULL to make absolutely sure that we don't mess with the buffers from the previous transfer in the timeout case. Unfortunately, this caused the IRQ handler to dereference NULL in some cases. One case: CPU0 CPU1 ---- ---- setup_fifo_xfer() geni_se_setup_m_cmd() <hardware starts transfer> <transfer completes in hardware> <hardware sets M_RX_FIFO_WATERMARK_EN in m_irq> ... handle_fifo_timeout() spin_lock_irq(mas->lock) mas->cur_xfer = NULL geni_se_cancel_m_cmd() spin_unlock_irq(mas->lock) geni_spi_isr() spin_lock(mas->lock) if (m_irq & M_RX_FIFO_WATERMARK_EN) geni_spi_handle_rx() mas->cur_xfer NULL dereference! tl;dr: Seriously delayed interrupts for RX/TX can lead to timeout handling setting mas->cur_xfer to NULL. Let's check for the NULL transfer in the TX and RX cases and reset the watermark or clear out the fifo respectively to put the hardware back into a sane state. NOTE: things still could get confused if we get timeouts all the way through handle_fifo_timeout() and then start a new transfer because interrupts from the old transfer / cancel / abort could still be pending. A future patch will help this corner case. Fixes: 561de45f72bd ("spi: spi-geni-qcom: Add SPI driver support for GENI based QUP") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20201217142842.v3.1.I99ee04f0cb823415df59bd4f550d6ff5756e43d6@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-17Merge remote-tracking branch 'spi/for-5.10' into spi-5.11Mark Brown4-8/+16
2020-12-11Merge remote-tracking branch 'spi/for-5.11' into spi-nextMark Brown39-220/+423
2020-12-11spi: Limit the spi device max speed to controller's max speedTudor Ambarus1-1/+2
Make sure the max_speed_hz of spi_device does not override the max_speed_hz of controller. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201209173514.93328-1-tudor.ambarus@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-10Merge series "spi: spi-geni-qcom: Use gpio descriptors for CS" from Stephen Boyd <swboyd@chromium.org>:Mark Brown1-0/+1
Collected patches from the two series below and associated tags so they can be merged in one pile through the spi tree. Merry December! SPI: https://lore.kernel.org/r/20201202214935.1114381-1-swboyd@chromium.org cros-ec: https://lore.kernel.org/r/20201203011649.1405292-1-swboyd@chromium.org Cc: Akash Asthana <akashast@codeaurora.org> Cc: Simon Glass <sjg@chromium.org> Cc: Gwendal Grignou <gwendal@chromium.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Alexandru M Stan <amstan@chromium.org> Stephen Boyd (3): platform/chrome: cros_ec_spi: Don't overwrite spi::mode platform/chrome: cros_ec_spi: Drop bits_per_word assignment spi: spi-geni-qcom: Use the new method of gpio CS control drivers/platform/chrome/cros_ec_spi.c | 2 -- drivers/spi/spi-geni-qcom.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) base-commit: b65054597872ce3aefbc6a666385eabdf9e288da -- https://chromeos.dev
2020-12-09spi: spi-geni-qcom: Use the new method of gpio CS controlStephen Boyd1-0/+1
Let's set the 'use_gpio_descriptors' field so that we use the new way of requesting the CS GPIOs in the core. This allows us to avoid having to configure the CS pins in "output" mode with an 'output-enable' pinctrl setting. Cc: Akash Asthana <akashast@codeaurora.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Cc: Alexandru M Stan <amstan@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20201204193540.3047030-4-swboyd@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-09spi: dw: Add support for the Canaan K210 SoC SPIDamien Le Moal1-0/+16
The Canaan Kendryte K210 RISC-V SoC includes a DW apb_ssi v4 controller which is documented to have a 32 words deep TX and RX FIFO. The FIFO length detection in spi_hw_init() correctly detects this value. However, when the controller RX FIFO is filled up to 32 entries (RXFLR = 32), an RX FIFO overrun error occurs. This likely due to a hardware bug which can be avoided by force setting the fifo_len field of struct dw_spi to 31. Define the dw_spi_canaan_k210_init() function to force set fifo_len to 31 when the device node compatible string is "canaan,k210-spi". Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20201206011817.11700-4-damien.lemoal@wdc.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-09spi: dw: Add support for 32-bits max xfer sizeDamien Le Moal2-7/+42
The Synopsis DesignWare DW_apb_ssi specifications version 3.23 onward define a 32-bits maximum transfer size synthesis parameter (SSI_MAX_XFER_SIZE=32) in addition to the legacy 16-bits configuration (SSI_MAX_XFER_SIZE=16) for SPI controllers. When SSI_MAX_XFER_SIZE=32, the layout of the ctrlr0 register changes, moving the data frame format field from bits [3..0] to bits [16..20], and the RX/TX FIFO word size can be up to 32-bits. To support this new format, introduce the DW SPI capability flag DW_SPI_CAP_DFS32 to indicate that a controller is configured with SSI_MAX_XFER_SIZE=32. Since SSI_MAX_XFER_SIZE is a controller synthesis parameter not accessible through a register, the detection of this parameter value is done in spi_hw_init() by writing and reading the ctrlr0 register and testing the value of bits [3..0]. These bits are ignored (unchanged) for SSI_MAX_XFER_SIZE=16, allowing the detection. If a DFS32 capable SPI controller is detected, the new field dfs_offset in struct dw_spi is set to SPI_DFS32_OFFSET (16). dw_spi_update_config() is modified to set the data frame size field at the correct position is the CTRLR0 register, as indicated by the dfs_offset field of the dw_spi structure. The DW_SPI_CAP_DFS32 flag is also unconditionally set for SPI slave controllers, e.g. controllers that have the DW_SPI_CAP_DWC_SSI capability flag set. However, for these ssi controllers, the dfs_offset field is set to 0 as before (as per specifications). Finally, for any controller with the DW_SPI_CAP_DFS32 capability flag set, dw_spi_add_host() extends the value of bits_per_word_mask from 16-bits to 32-bits. dw_reader() and dw_writer() are also modified to handle 32-bits iTX/RX FIFO words. Suggested-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20201206011817.11700-3-damien.lemoal@wdc.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07Merge series "spi: atmel-quadspi: Fix AHB memory accesses" from Tudor Ambarus <tudor.ambarus@microchip.com>:Mark Brown1-12/+13
Starting with the move of the atmel-quadspi driver under SPI, the following error could be seen when mounting a 16MByte ubifs: UBIFS error (ubi0:0 pid 1893): check_lpt_type.constprop.6: invalid type (15) in LPT node type 1/4 fixes AHB accesses. The rest of the patches are small optimizations. Tested on both sama5d2 and sam9x60. Tudor Ambarus (4): spi: atmel-quadspi: Fix AHB memory accesses spi: atmel-quadspi: Drop superfluous set of QSPI_IFR_APBTFRTYP_READ spi: atmel-quadspi: Write QSPI_IAR only when needed spi: atmel-quadspi: Move common code outside of if else drivers/spi/atmel-quadspi.c | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) -- 2.25.1 base-commit: 3650b228f83adda7e5ee532e2b90429c03f7b9ec _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
2020-12-07spi: atmel-quadspi: Fix use-after-free on unbindLukas Wunner1-10/+5
atmel_qspi_remove() accesses the driver's private data after calling spi_unregister_controller() even though that function releases the last reference on the spi_controller and thereby frees the private data. Fix by switching over to the new devm_spi_alloc_master() helper which keeps the private data accessible until the driver has unbound. Fixes: 2d30ac5ed633 ("mtd: spi-nor: atmel-quadspi: Use spi-mem interface for atmel-quadspi driver") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v5.0+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v5.0+ Cc: Piotr Bugalski <bugalski.piotr@gmail.com> Link: https://lore.kernel.org/r/4b05c65cf6f1ea3251484fe9a00b4c65478a1ae3.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: npcm-fiu: Disable clock in probe error pathLukas Wunner1-2/+6
If the call to devm_spi_register_master() fails on probe of the NPCM FIU SPI driver, the clock "fiu->clk" is erroneously not unprepared and disabled. Fix it. Fixes: ace55c411b11 ("spi: npcm-fiu: add NPCM FIU controller driver") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v5.4+ Cc: Tomer Maimon <tmaimon77@gmail.com> Link: https://lore.kernel.org/r/9ae62f4e1cfe542bec57ac2743e6fca9f9548f55.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: ar934x: Don't leak SPI master in probe error pathLukas Wunner1-3/+11
If the call to devm_spi_register_controller() fails on probe of the Qualcomm Atheros AR934x/QCA95xx SPI driver, the spi_controller struct is erroneously not freed. Fix by switching over to the new devm_spi_alloc_master() helper. Moreover, the controller's clock is enabled on probe but not disabled if any of the subsequent probe steps fail. Finally, there's an ordering issue in ar934x_spi_remove() wherein the clock is disabled even though the controller is not yet unregistered. It is unregistered after ar934x_spi_remove() by the devres framework. As long as it is not unregistered, SPI transfers may still be ongoing and disabling the clock may break them. It is not possible to use devm_spi_register_controller() in this case, so move to the non-devm variant. All of these bugs have existed since the driver was first introduced, so it seems fair to fix them together in a single commit. Fixes: 047980c582af ("spi: add driver for ar934x spi controller") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v5.7+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v5.7+ Cc: Chuanhong Guo <gch981213@gmail.com> Link: https://lore.kernel.org/r/1d58367d74d55741e0c2730a51a2b65012c8ab33.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: mt7621: Don't leak SPI master in probe error pathLukas Wunner1-2/+3
If the calls to device_reset() or devm_spi_register_controller() fail on probe of the MediaTek MT7621 SPI driver, the spi_controller struct is erroneously not freed. Fix by switching over to the new devm_spi_alloc_master() helper. Additionally, there's an ordering issue in mt7621_spi_remove() wherein the spi_controller is unregistered after disabling the SYS clock. The correct order is to call spi_unregister_controller() *before* this teardown step because bus accesses may still be ongoing until that function returns. All of these bugs have existed since the driver was first introduced, so it seems fair to fix them together in a single commit. Fixes: 1ab7f2a43558 ("staging: mt7621-spi: add mt7621 support") Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Stefan Roese <sr@denx.de> Cc: <stable@vger.kernel.org> # v4.17+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v4.17+ Link: https://lore.kernel.org/r/72b680796149f5fcda0b3f530ffb7ee73b04f224.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: mt7621: Disable clock in probe error pathLukas Wunner1-1/+5
Commit 702b15cb9712 ("spi: mt7621: fix missing clk_disable_unprepare() on error in mt7621_spi_probe") sought to disable the SYS clock on probe errors, but only did so for 2 of 3 potentially failing calls: The clock needs to be disabled on failure of devm_spi_register_controller() as well. Moreover, the commit purports to fix a bug in commit cbd66c626e16 ("spi: mt7621: Move SPI driver out of staging") but in reality the bug has existed since the driver was first introduced. Fixes: 1ab7f2a43558 ("staging: mt7621-spi: add mt7621 support") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v4.17+: 702b15cb9712: spi: mt7621: fix missing clk_disable_unprepare() on error in mt7621_spi_probe Cc: <stable@vger.kernel.org> # v4.17+ Cc: Qinglang Miao <miaoqinglang@huawei.com> Link: https://lore.kernel.org/r/36ad42760087952fb7c10aae7d2628547c26a7ec.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: sc18is602: Don't leak SPI master in probe error pathLukas Wunner1-11/+2
If the call to devm_gpiod_get_optional() fails on probe of the NXP SC18IS602/603 SPI driver, the spi_master struct is erroneously not freed. Fix by switching over to the new devm_spi_alloc_master() helper. Fixes: f99008013e19 ("spi: sc18is602: Add reset control via gpio pin.") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v4.9+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v4.9+ Cc: Phil Reid <preid@electromag.com.au> Link: https://lore.kernel.org/r/d5f715527b894b91d530fe11a86f51b3184a4e1a.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: rb4xx: Don't leak SPI master in probe error pathLukas Wunner1-1/+1
If the calls to devm_clk_get(), devm_spi_register_master() or clk_prepare_enable() fail on probe of the Mikrotik RB4xx SPI driver, the spi_master struct is erroneously not freed. Fix by switching over to the new devm_spi_alloc_master() helper. Fixes: 05aec357871f ("spi: Add SPI driver for Mikrotik RB4xx series boards") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v4.2+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v4.2+ Cc: Bert Vermeulen <bert@biot.com> Link: https://lore.kernel.org/r/369bf26d71927f60943b1d9d8f51810f00b0237d.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>