summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-05-25spi: mux: repair mux usagePeter Rosin1-4/+4
It is not valid to cache/short out selection of the mux. mux_control_select() only locks the mux until mux_control_deselect() is called. mux_control_deselect() may put the mux in some low power state or some other user of the mux might select it for other purposes. These things are probably not happening in the original setting where this driver was developed, but it is said to be a generic SPI mux. Also, the mux framework will short out the actual low level muxing operation when/if that is possible. Fixes: e9e40543ad5b ("spi: Add generic SPI multiplexer") Signed-off-by: Peter Rosin <peda@axentia.se> Link: https://lore.kernel.org/r/20200525104352.26807-1-peda@axentia.se Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-20spi: bcm2835aux: Fix controller unregister orderLukas Wunner1-1/+3
The BCM2835aux SPI driver uses devm_spi_register_master() on bind. As a consequence, on unbind, __device_release_driver() first invokes bcm2835aux_spi_remove() before unregistering the SPI controller via devres_release_all(). This order is incorrect: bcm2835aux_spi_remove() turns off the SPI controller, including its interrupts and clock. The SPI controller is thus no longer usable. When the SPI controller is subsequently unregistered, it unbinds all its slave devices. If their drivers need to access the SPI bus, e.g. to quiesce their interrupts, unbinding will fail. As a rule, devm_spi_register_master() must not be used if the ->remove() hook performs teardown steps which shall be performed after unbinding of slaves. Fix by using the non-devm variant spi_register_master(). Note that the struct spi_master as well as the driver-private data are not freed until after bcm2835aux_spi_remove() has finished, so accessing them is safe. Fixes: 1ea29b39f4c8 ("spi: bcm2835aux: add bcm2835 auxiliary spi device driver") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org # v4.4+ Cc: Martin Sperl <kernel@martin.sperl.org> Link: https://lore.kernel.org/r/32f27f4d8242e4d75f9a53f7e8f1f77483b08669.1589557526.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-20spi: bcm2835: Fix controller unregister orderLukas Wunner1-1/+3
The BCM2835 SPI driver uses devm_spi_register_controller() on bind. As a consequence, on unbind, __device_release_driver() first invokes bcm2835_spi_remove() before unregistering the SPI controller via devres_release_all(). This order is incorrect: bcm2835_spi_remove() tears down the DMA channels and turns off the SPI controller, including its interrupts and clock. The SPI controller is thus no longer usable. When the SPI controller is subsequently unregistered, it unbinds all its slave devices. If their drivers need to access the SPI bus, e.g. to quiesce their interrupts, unbinding will fail. As a rule, devm_spi_register_controller() must not be used if the ->remove() hook performs teardown steps which shall be performed after unbinding of slaves. Fix by using the non-devm variant spi_register_controller(). Note that the struct spi_controller as well as the driver-private data are not freed until after bcm2835_spi_remove() has finished, so accessing them is safe. Fixes: 247263dba208 ("spi: bcm2835: use devm_spi_register_master()") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org # v3.13+ Link: https://lore.kernel.org/r/2397dd70cdbe95e0bc4da2b9fca0f31cb94e5aed.1589557526.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-20spi: Fix controller unregister orderLukas Wunner1-1/+2
When an SPI controller unregisters, it unbinds all its slave devices. For this, their drivers may need to access the SPI bus, e.g. to quiesce interrupts. However since commit ffbbdd21329f ("spi: create a message queueing infrastructure"), spi_destroy_queue() is executed before unbinding the slaves. It sets ctlr->running = false, thereby preventing SPI bus access and causing unbinding of slave devices to fail. Fix by unbinding slaves before calling spi_destroy_queue(). Fixes: ffbbdd21329f ("spi: create a message queueing infrastructure") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org # v3.4+ Cc: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/8aaf9d44c153fe233b17bc2dec4eb679898d7e7b.1589557526.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-21spi: bcm-qspi: Handle clock probe deferralFlorian Fainelli1-7/+5
The clock provider may not be ready by the time spi-bcm-qspi gets probed, handle probe deferral using devm_clk_get_optional(). Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Kamal Dasu <kdasu.kdev@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200420190853.45614-2-kdasu.kdev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-21spi: bcm-qspi: when tx/rx buffer is NULL set to 0Justin Chen1-4/+4
Currently we set the tx/rx buffer to 0xff when NULL. This causes problems with some spi slaves where 0xff is a valid command. Looking at other drivers, the tx/rx buffer is usually set to 0x00 when NULL. Following this convention solves the issue. Fixes: fa236a7ef240 ("spi: bcm-qspi: Add Broadcom MSPI driver") Signed-off-by: Justin Chen <justinpopo6@gmail.com> Signed-off-by: Kamal Dasu <kdasu.kdev@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200420190853.45614-6-kdasu.kdev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-21spi: bcm-qspi: Make PM suspend/resume work with SCMI clock managementKamal Dasu1-2/+2
SCMI only passes clk_prepare_enable() and clk_disable_unprepare(), made changes to suspend/resume ops to use the appropriate calls so that PM works for ARM and ARM64 platforms. Signed-off-by: Kamal Dasu <kdasu.kdev@gmail.com> Link: https://lore.kernel.org/r/20200420190853.45614-7-kdasu.kdev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-21spi: bcm-qspi: Drive MSPI peripheral SSb pin on cs_changeKamal Dasu1-7/+12
As per the spi core implementation for MSPI devices when the transfer is the last one in the message, the chip may stay selected until the next transfer. On multi-device SPI busses with nothing blocking messages going to other devices, this is just a performance hint; starting a message to another device deselects this one. But in other cases, this can be used to ensure correctness. Some devices need protocol transactions to be built from a series of spi_message submissions, where the content of one message is determined by the results of previous messages and where the whole transaction ends when the chipselect goes intactive. On CS change after completing the last serial transfer, the MSPI driver drives SSb pin CDRAM register correctly according comments in core spi.h as shown below: case 1) EOM =1, cs_change =0: SSb inactive case 2) EOM =1, cs_change =1: SSb active case 3) EOM =0, cs_change =0: SSb active case 4) EOM =0, cs_change =1: SSb inactive Signed-off-by: Kamal Dasu <kdasu.kdev@gmail.com> Link: https://lore.kernel.org/r/20200420190853.45614-5-kdasu.kdev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14spi: Respect DataBitLength field of SpiSerialBusV2() ACPI resourceAndy Shevchenko1-0/+1
By unknown reason the commit 64bee4d28c9e ("spi / ACPI: add ACPI enumeration support") missed the DataBitLength property to encounter when parse SPI slave device data from ACPI. Fill the gap here. Fixes: 64bee4d28c9e ("spi / ACPI: add ACPI enumeration support") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200413180406.1826-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14spi: sc18is602: Fix a typo in MODULE_DESCRIPTIONChristophe JAILLET1-1/+1
This should be 'SC18IS602', not 'SC18IC602' Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/20200413154043.23064-1-christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-09spi: spi-axi-spi-engine: Access register after clock initializationRafał Hibner1-16/+16
Move register access after clock initialization. Clock "s_axi_aclk" is needed for register access. Without the clock running AXI bus hangs and causes kernel freeze. Signed-off-by: Rafał Hibner <rafal.hibner@secom.com.pl> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20200409155621.12174-1-rafal.hibner@secom.com.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-03spi: spi-ep93xx: fix wrong SPI mode selectionJungseung Lee1-2/+6
The mode bits on control register 0 are in a different order compared to the spi mode define values. Thus, in the current code, it fails to set the correct SPI mode selection. Fix it. Signed-off-by: Jungseung Lee <js07.lee@samsung.com> Link: https://lore.kernel.org/r/20200402121022.9976-1-js07.lee@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-27spi: efm32: Convert to use GPIO descriptorsLinus Walleij1-41/+3
This switches the EFM32 driver over to use the GPIO descriptor handling in the core. The GPIO handling in this driver is pretty simplistic so this should just work. Drop the GPIO headers and insert the implicitly included <linux/of.h> header. Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> Cc: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> Link: https://lore.kernel.org/r/20200317094914.331932-1-linus.walleij@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-23spi: spi-fsl-lpspi: Replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Link: https://lore.kernel.org/r/20200320232515.GA24800@embeddedor.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-23spi: spi-s3c24xx: Replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: Andi Shyti <andi@etezian.org> Link: https://lore.kernel.org/r/20200320232556.GA24989@embeddedor.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-21spi: stm32: Fix comments compilation warningsAlain Volmat1-17/+45
Fix all functions and structure descriptions to have the driver warning free when built with W=1. Signed-off-by: Alain Volmat <alain.volmat@st.com> Reviewed-by: Amelie Delaunay <amelie.delaunay@st.com> Link: https://lore.kernel.org/r/1584711857-9162-1-git-send-email-alain.volmat@st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-20spi: atmel-quadspi: Add verbose debug facilities to monitor register accessesTudor Ambarus1-22/+97
This feature should not be enabled in release but can be useful for developers who need to monitor register accesses at some specific places. Helped me identify a bug in u-boot, by comparing the register accesses from the linux driver with the ones from its u-boot variant. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20200320065058.891221-1-tudor.ambarus@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-19spi: spi-fsl-dspi: Add support for LS1028AVladimir Oltean1-0/+9
This is similar to the DSPI instantiation on LS1028A, except that: - The A-011218 erratum has been fixed, so DMA works - The endianness is different, which has implications on XSPI mode Some benchmarking with the following command: spidev_test --device /dev/spidev2.0 --bpw 8 --size 256 --cpha --iter 10000000 --speed 20000000 shows that in DMA mode, it can achieve around 2400 kbps, and in XSPI mode, the same command goes up to 4700 kbps. This is somewhat to be expected, since the DMA buffer size is extremely small at 8 bytes, the winner becomes whomever can prepare the buffers for transmission quicker, and DMA mode has higher overhead there. So XSPI FIFO mode has been chosen as the operating mode for this chip. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-11-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-19spi: spi-fsl-dspi: Move invariant configs out of dspi_transfer_one_messageVladimir Oltean1-26/+29
The operating mode (DMA, XSPI, EOQ) is not going to change across the lifetime of the device. So it makes no sense to keep writing to SPI_RSER on each message. Move this configuration to dspi_init instead. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-10-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-19spi: spi-fsl-dspi: Fix interrupt-less DMA mode taking an XSPI code pathVladimir Oltean1-7/+9
Interrupts are not necessary for DMA functionality, since the completion event is provided by the DMA driver. But if the driver fails to request the IRQ defined in the device tree, it will call dspi_poll which would make the driver hang waiting for data to become available in the RX FIFO. Fixes: c55be3059159 ("spi: spi-fsl-dspi: Use poll mode in case the platform IRQ is missing") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-9-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-19spi: spi-fsl-dspi: Avoid NULL pointer in dspi_slave_abort for non-DMA modeVladimir Oltean1-2/+4
The driver does not create the dspi->dma structure unless operating in DSPI_DMA_MODE, so it makes sense to check for that. Fixes: f4b323905d8b ("spi: Introduce dspi_slave_abort() function for NXP's dspi SPI driver") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-8-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-19spi: spi-fsl-dspi: Replace interruptible wait queue with a simple completionVladimir Oltean1-13/+6
Currently the driver puts the process in interruptible sleep waiting for the interrupt train to finish transfer to/from the tx_buf and rx_buf. But exiting the process with ctrl-c may make the kernel panic: the wait_event_interruptible call will return -ERESTARTSYS, which a proper driver implementation is perhaps supposed to handle, but nonetheless this one doesn't, and aborts the transfer altogether. Actually when the task is interrupted, there is still a high chance that the dspi_interrupt is still triggering. And if dspi_transfer_one_message returns execution all the way to the spi_device driver, that can free the spi_message and spi_transfer structures, leaving the interrupts to access a freed tx_buf and rx_buf. hexdump -C /dev/mtd0 00000000 00 75 68 75 0a ff ff ff ff ff ff ff ff ff ff ff |.uhu............| 00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * ^C[ 38.495955] fsl-dspi 2120000.spi: Waiting for transfer to complete failed! [ 38.503097] spi_master spi2: failed to transfer one message from queue [ 38.509729] Unable to handle kernel paging request at virtual address ffff800095ab3377 [ 38.517676] Mem abort info: [ 38.520474] ESR = 0x96000045 [ 38.523533] EC = 0x25: DABT (current EL), IL = 32 bits [ 38.528861] SET = 0, FnV = 0 [ 38.531921] EA = 0, S1PTW = 0 [ 38.535067] Data abort info: [ 38.537952] ISV = 0, ISS = 0x00000045 [ 38.541797] CM = 0, WnR = 1 [ 38.544771] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000082621000 [ 38.551494] [ffff800095ab3377] pgd=00000020fffff003, p4d=00000020fffff003, pud=0000000000000000 [ 38.560229] Internal error: Oops: 96000045 [#1] PREEMPT SMP [ 38.565819] Modules linked in: [ 38.568882] CPU: 0 PID: 2729 Comm: hexdump Not tainted 5.6.0-rc4-next-20200306-00052-gd8730cdc8a0b-dirty #193 [ 38.578834] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT) [ 38.587129] pstate: 20000085 (nzCv daIf -PAN -UAO) [ 38.591941] pc : ktime_get_real_ts64+0x3c/0x110 [ 38.596487] lr : spi_take_timestamp_pre+0x40/0x90 [ 38.601203] sp : ffff800010003d90 [ 38.604525] x29: ffff800010003d90 x28: ffff80001200e000 [ 38.609854] x27: ffff800011da9000 x26: ffff002079c40400 [ 38.615184] x25: ffff8000117fe018 x24: ffff800011daa1a0 [ 38.620513] x23: ffff800015ab3860 x22: ffff800095ab3377 [ 38.625841] x21: 000000000000146e x20: ffff8000120c3000 [ 38.631170] x19: ffff0020795f6e80 x18: ffff800011da9948 [ 38.636498] x17: 0000000000000000 x16: 0000000000000000 [ 38.641826] x15: ffff800095ab3377 x14: 0720072007200720 [ 38.647155] x13: 0720072007200765 x12: 0775076507750771 [ 38.652483] x11: 0720076d076f0772 x10: 0000000000000040 [ 38.657812] x9 : ffff8000108e2100 x8 : ffff800011dcabe8 [ 38.663139] x7 : 0000000000000000 x6 : ffff800015ab3a60 [ 38.668468] x5 : 0000000007200720 x4 : ffff800095ab3377 [ 38.673796] x3 : 0000000000000000 x2 : 0000000000000ab0 [ 38.679125] x1 : ffff800011daa000 x0 : 0000000000000026 [ 38.684454] Call trace: [ 38.686905] ktime_get_real_ts64+0x3c/0x110 [ 38.691100] spi_take_timestamp_pre+0x40/0x90 [ 38.695470] dspi_fifo_write+0x58/0x2c0 [ 38.699315] dspi_interrupt+0xbc/0xd0 [ 38.702987] __handle_irq_event_percpu+0x78/0x2c0 [ 38.707706] handle_irq_event_percpu+0x3c/0x90 [ 38.712161] handle_irq_event+0x4c/0xd0 [ 38.716008] handle_fasteoi_irq+0xbc/0x170 [ 38.720115] generic_handle_irq+0x2c/0x40 [ 38.724135] __handle_domain_irq+0x68/0xc0 [ 38.728243] gic_handle_irq+0xc8/0x160 [ 38.732000] el1_irq+0xb8/0x180 [ 38.735149] spi_nor_spimem_read_data+0xe0/0x140 [ 38.739779] spi_nor_read+0xc4/0x120 [ 38.743364] mtd_read_oob+0xa8/0xc0 [ 38.746860] mtd_read+0x4c/0x80 [ 38.750007] mtdchar_read+0x108/0x2a0 [ 38.753679] __vfs_read+0x20/0x50 [ 38.757002] vfs_read+0xa4/0x190 [ 38.760237] ksys_read+0x6c/0xf0 [ 38.763471] __arm64_sys_read+0x20/0x30 [ 38.767319] el0_svc_common.constprop.3+0x90/0x160 [ 38.772125] do_el0_svc+0x28/0x90 [ 38.775449] el0_sync_handler+0x118/0x190 [ 38.779468] el0_sync+0x140/0x180 [ 38.782793] Code: 91000294 1400000f d50339bf f9405e80 (f90002c0) [ 38.788910] ---[ end trace 55da560db4d6bef7 ]--- [ 38.793540] Kernel panic - not syncing: Fatal exception in interrupt [ 38.799914] SMP: stopping secondary CPUs [ 38.803849] Kernel Offset: disabled [ 38.807344] CPU features: 0x10002,20006008 [ 38.811451] Memory Limit: none [ 38.814513] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- So it is clear that the "interruptible" part isn't handled correctly. When the process receives a signal, one could either attempt a clean abort (which appears to be difficult with this hardware) or just keep restarting the sleep until the wait queue really completes. But checking in a loop for -ERESTARTSYS is a bit too complicated for this driver, so just make the sleep uninterruptible, to avoid all that nonsense. The wait queue was actually restructured as a completion, after polling other drivers for the most "popular" approach. Fixes: 349ad66c0ab0 ("spi:Add Freescale DSPI driver for Vybrid VF610 platform") Reported-by: Michael Walle <michael@walle.cc> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-7-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-19spi: spi-fsl-dspi: Protect against races on dspi->words_in_flightVladimir Oltean1-59/+52
dspi->words_in_flight is a variable populated in the *_write functions and used in the dspi_fifo_read function. It is also used in dspi_fifo_write, immediately after transmission, to update the message->actual_length variable used by higher layers such as spi-mem for integrity checking. But it may happen that the IRQ which calls dspi_fifo_read to be triggered before the updating of message->actual_length takes place. In that case, dspi_fifo_read will decrement dspi->words_in_flight to -1, and that will cause an invalid modification of message->actual_length. For that, we make the simplest fix possible: to not decrement the actual shared variable in dspi->words_in_flight from dspi_fifo_read, but actually a copy of it which is on stack. But even if dspi_fifo_read from the next IRQ does not interfere with the dspi_fifo_write of the current chunk, the *next* dspi_fifo_write still can. So we must assume that everything after the last write to the TX FIFO can be preempted by the "TX complete" IRQ, and the dspi_fifo_write function must be safe against that. This means refactoring the 2 flavours of FIFO writes (for EOQ and XSPI) such that the calculation of the number of words to be written is common and happens a priori. This way, the code for updating the message->actual_length variable works with a copy and not with the volatile dspi->words_in_flight. After some interior debate, the dspi->progress variable used for software timestamping was *not* backed up against preemption in a copy on stack. Because if preemption does occur between spi_take_timestamp_pre and spi_take_timestamp_post, there's really no point in trying to save anything. The first-in-time spi_take_timestamp_post call with a dspi->progress higher than the requested xfer->ptp_sts_word_post will trigger xfer->timestamped = true anyway and will close the deal. To understand the above a bit better, consider a transfer with xfer->ptp_sts_word_pre = xfer->ptp_sts_word_post = 3, and xfer->bits_per_words = 8 (so byte 3 needs to be timestamped). The DSPI controller timestamps in chunks of 4 bytes at a time, and preemption occurs in the middle of timestamping the first chunk: spi_take_timestamp_pre(0) . . (preemption) . . spi_take_timestamp_pre(4) . . spi_take_timestamp_post(7) . spi_take_timestamp_post(3) So the reason I'm not bothering to back up dspi->progress for that spi_take_timestamp_post(3) is that spi_take_timestamp_post(7) is going to (a) be more honest, (b) provide better accuracy and (c) already render the spi_take_timestamp_post(3) into a noop by setting xfer->timestamped = true anyway. Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode") Reported-by: Michael Walle <michael@walle.cc> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-6-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-19spi: spi-fsl-dspi: Avoid reading more data than written in EOQ modeVladimir Oltean1-2/+5
If dspi->words_in_flight is populated with the hardware FIFO size, then in dspi_fifo_read it will attempt to read more data at the end of a buffer that is not a multiple of 16 bytes in length. It will probably time out attempting to do so. So limit the num_fifo_entries variable to the actual number of FIFO entries that is going to be used. Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-5-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-19spi: spi-fsl-dspi: Fix bits-per-word acceleration in DMA modeVladimir Oltean1-54/+32
In DMA mode, dspi_setup_accel does not get called, which results in the dspi->oper_word_size variable (which is used by dspi_dma_xfer) to not be initialized properly. Because oper_word_size is zero, a few calculations end up being incorrect, and the DMA transfer eventually times out instead of sending anything on the wire. Set up native transfers (or 8-on-16 acceleration) using dspi_setup_accel for DMA mode too. Also take the opportunity and simplify the DMA buffer handling a little bit. Fixes: 6c1c26ecd9a3 ("spi: spi-fsl-dspi: Accelerate transfers using larger word size if possible") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-4-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-19spi: spi-fsl-dspi: Fix little endian access to PUSHR CMD and TXDATAVladimir Oltean1-6/+20
In XSPI mode, the 32-bit PUSHR register can be written to separately: the higher 16 bits are for commands and the lower 16 bits are for data. This has nicely been hacked around, by defining a second regmap with a width of 16 bits, and effectively splitting a 32-bit register into 2 16-bit ones, from the perspective of this regmap_pushr. The problem is the assumption about the controller's endianness. If the controller is little endian (such as anything post-LS1046A), then the first 2 bytes, in the order imposed by memory layout, will actually hold the TXDATA, and the last 2 bytes will hold the CMD. So take the controller's endianness into account when performing split writes to PUSHR. The obvious and simple solution would have been to call regmap_get_val_endian(), but that is an internal regmap function and we don't want to change regmap just for this. Therefore, we just re-read the "big-endian" device tree property. Fixes: 58ba07ec79e6 ("spi: spi-fsl-dspi: Add support for XSPI mode registers") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-3-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-19spi: spi-fsl-dspi: Don't access reserved fields in SPI_MCRVladimir Oltean1-2/+5
The SPI_MCR_PCSIS macro assumes that the controller has a number of chip select signals equal to 6. That is not always the case, but actually is described through the driver-specific "spi-num-chipselects" device tree binding. LS1028A for example only has 4 chip selects. Don't write to the upper bits of the PCSIS field, which are reserved in the reference manual. Fixes: 349ad66c0ab0 ("spi:Add Freescale DSPI driver for Vybrid VF610 platform") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-2-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-17spi: mxs: Drop GPIO includesLinus Walleij1-2/+1
This driver is not using any symbols from the GPIO .h files so drop them. It was however implicitly using <linux/pinctrl/consumer.h> so include that instead. Cc: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20200317092457.264055-1-linus.walleij@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-13spi: dt-bindings: spi-controller: Fix spi-[rt]x-bus-width for slave modeGeert Uytterhoeven1-2/+2
The descriptions for the spi-rx-bus-width and spi-tx-bus-width properties refer to "MISO" and "MOSI", which are not explained in the document. While these abbreviations are fairly common when talking about SPI, and thus may not need an explanation, they are not entirely correct in this context, as the SPI controller may be used in slave mode instead of master mode. Fix this by replacing them by "read transfers" resp. "write transfers", like is done for the spi-rx-delay-us and spi-tx-delay-us properties. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200306085038.8111-3-geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-13spi: dt-bindings: spi-controller: Fix #address-cells for slave modeGeert Uytterhoeven1-0/+6
Currently, the DT bindings for an SPI controller specify that "#address-cells" must be fixed to one. However, that applies to an SPI controller in master mode only. When running in SPI slave mode, "#address-cells" should not be specified. Fix this making "#address-cells" mutually-exclusive with "spi-slave". Fixes: 0a1b929356830257 ("spi: Add YAML schemas for the generic SPI options") Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200306085038.8111-2-geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-12Merge series "spi: meson-spicc: add support for AXG and G12A variants" from ↵Mark Brown3-127/+392
Neil Armstrong <narmstrong@baylibre.com>: The SPICC controller in Amlogic AXG & G12A is capable of driving the CLK/MOSI/SS signal lines through the idle state which avoid the signals floating in unexpected state, is capable of using linear clock divider to reach a much fine tuned range of clocks, while the old controller only uses a power of two clock divider, result at a more coarse clock range and finally is capable of running at 80M clock. The SPICC controller in Amlogic G12A takes the source clock from a specific clock instead of the bus clock and has a different FIFO size and doesn't handle the RX Half interrupt the same way as GXL & AXG variants. Thus the burst management is simplified and takes in account a variable FIFO size. Now the controller can support frequencies higher than 30MHz, we need the setup the I/O line delays in regard of the SPI clock frequency. Neil Armstrong (7): spi: meson-spicc: remove unused variables spi: meson-spicc: support max 80MHz clock spi: meson-spicc: add min sclk for each compatible spi: meson-spicc: setup IO line delay spi: meson-spicc: adapt burst handling for G12A support dt-bindings: spi: amlogic,meson-gx-spicc: add Amlogic G12A compatible spi: meson-spicc: add support for Amlogic G12A Sunny Luo (2): spi: meson-spicc: enhance output enable feature spi: meson-spicc: add a linear clock divider support .../bindings/spi/amlogic,meson-gx-spicc.yaml | 22 + drivers/spi/Kconfig | 1 + drivers/spi/spi-meson-spicc.c | 496 +++++++++++++----- 3 files changed, 392 insertions(+), 127 deletions(-) -- 2.22.0 _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic
2020-03-12spi: acpi: remove superfluous parameter checkWolfram Sang1-1/+1
to_spi_device() already checks 'dev'. No need to do it before calling it. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20200312134507.10000-1-wsa@the-dreams.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-12spi: dt-bindings: amlogic, meson-gx-spicc: add Amlogic G12A compatibleNeil Armstrong1-0/+22
The Amlogic G12A SPICC controllers uses a secondary clock used to feed the baud rate generator and the delay control logic. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20200312133131.26430-9-narmstrong@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-12spi: meson-spicc: add support for Amlogic G12ANeil Armstrong1-8/+46
Add support for the SPICC controllers on the Amlogic G12A SoCs family. The G12A SPICC controllers inherit from the AXG enhanced registers but takes an external pclk for the baud rate generator and can achieve up to 166MHz SCLK. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20200312133131.26430-10-narmstrong@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-12spi: meson-spicc: adapt burst handling for G12A supportNeil Armstrong1-79/+50
The G12A SPICC controller variant has a different FIFO size and doesn't handle the RX Half interrupt the same way as GXL & AXG variants. Thus simplify the burst management and take in account a variable FIFO size. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20200312133131.26430-8-narmstrong@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-12spi: meson-spicc: setup IO line delayNeil Armstrong1-1/+60
Now the controller can support frequencies higher than 30MHz, we need the setup the I/O line delays in regard of the SPI clock frequency. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20200312133131.26430-7-narmstrong@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-12spi: meson-spicc: add min sclk for each compatibleNeil Armstrong1-1/+4
The G12A SPICC controller variant takes the source clock from a specific clock instead of the bus clock. The minimal clock calculus won't work with the G12A support, thus add the minimal supported clock for each variant and pass this to the SPI core. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20200312133131.26430-6-narmstrong@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-12spi: meson-spicc: support max 80MHz clockNeil Armstrong1-6/+6
The SPICC controller in Meson-AXG is capable of running at 80M clock. The ASIC IP is improved and the clock is actually running higher than previous old SoCs. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com> Signed-off-by: Sunny Luo <sunny.luo@amlogic.com> Link: https://lore.kernel.org/r/20200312133131.26430-5-narmstrong@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-12spi: meson-spicc: add a linear clock divider supportSunny Luo2-40/+165
The SPICC controller in Meson-AXG SoC is capable of using a linear clock divider to reach a much fine tuned range of clocks, while the old controller only use a power of two clock divider, result at a more coarse clock range. Also convert the clock registration into Common Clock Framework. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com> Signed-off-by: Sunny Luo <sunny.luo@amlogic.com> Link: https://lore.kernel.org/r/20200312133131.26430-4-narmstrong@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-12spi: meson-spicc: enhance output enable featureSunny Luo1-2/+51
The SPICC controller in Meson-AXG is capable of driving the CLK/MOSI/SS signal lines through the idle state (between two transmission operation), which avoid the signals floating in unexpected state. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com> Signed-off-by: Sunny Luo <sunny.luo@amlogic.com> Link: https://lore.kernel.org/r/20200312133131.26430-3-narmstrong@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-12spi: meson-spicc: remove unused variablesNeil Armstrong1-2/+0
Remove unused variables from spicc data struct. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20200312133131.26430-2-narmstrong@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-12spi: spi-nxp-fspi: Fix a NULL vs IS_ERR() check in probeDan Carpenter1-2/+2
The platform_get_resource_byname() function returns NULL on error, it doesn't return error pointers. Fixes: d166a73503ef ("spi: fspi: dynamically alloc AHB memory") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20200312113154.GC20562@mwanda Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-11Merge tag 'mtk-mtd-spi-move' of ↵Mark Brown8-590/+708
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi into spi-5.7 spi: Rewrite mtk-quadspi spi-nor driver with spi-mem This patchset from Chuanhong Guo <gch981213@gmail.com> adds a spi-mem driver for Mediatek SPI-NOR controller, which already has limited support by mtk-quadspi. This new driver can make use of full quadspi capability of this controller.
2020-03-11mtd: spi-nor: remove mtk-quadspi driverChuanhong Guo3-574/+0
This driver is superseded by the new spi-mtk-nor driver. Signed-off-by: Chuanhong Guo <gch981213@gmail.com> Acked-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20200306085052.28258-5-gch981213@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-11dt-bindings: convert mtk-quadspi binding doc for spi-mtk-norChuanhong Guo1-9/+6
spi-mtk-nor is a driver to replace mtk-quadspi and they have almost the same device-tree bindings. Reuse this binding documentation and convert it for new driver: 1. "Mediatek SoCs" -> "Mediatek ARM SoCs" because MTK MIPS SoCs use different controllers. 2. document "interrupts" as a required property because it's available on all SoCs with this controller and new driver takes advantages of it. It's implemented as optional only to maintain backward compatibility. 3. add a dummy interrupt binding in example. Signed-off-by: Chuanhong Guo <gch981213@gmail.com> Link: https://lore.kernel.org/r/20200306085052.28258-4-gch981213@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-11spi: add support for mediatek spi-nor controllerChuanhong Guo3-0/+700
This is a driver for mtk spi-nor controller using spi-mem interface. The same controller already has limited support provided by mtk-quadspi driver under spi-nor framework and this new driver is a replacement for the old one. Comparing to the old driver, this driver has following advantages: 1. It can handle any full-duplex spi transfer up to 6 bytes, and this is implemented using generic spi interface. 2. It take account into command opcode properly. The reading routine in this controller can only use 0x03 or 0x0b as opcode on 1-1-1 transfers, but old driver doesn't implement this properly. This driver checks supported opcode explicitly and use (1) to perform unmatched operations. 3. It properly handles SFDP reading. Old driver can't read SFDP due to the bug mentioned in (2). 4. It can do 1-2-2 and 1-4-4 fast reading on spi-nor. These two ops requires parsing SFDP, which isn't possible in old driver. And the old driver is only flagged to support 1-1-2 mode. 5. It takes advantage of the DMA feature in this controller for long reads and supports IRQ on DMA requests to free cpu cycles from polling status registers on long DMA reading. It achieves up to 17.5MB/s reading speed (1-4-4 mode) which is way faster than the old one. IRQ is implemented as optional to maintain backward compatibility. Signed-off-by: Chuanhong Guo <gch981213@gmail.com> Link: https://lore.kernel.org/r/20200306085052.28258-3-gch981213@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-11spi: make spi-max-frequency optionalChuanhong Guo1-7/+2
We only need a spi-max-frequency when we specifically request a spi frequency lower than the max speed of spi host. This property is already documented as optional property and current host drivers are implemented to operate at highest speed possible when spi->max_speed_hz is 0. This patch makes spi-max-frequency an optional property so that we could just omit it to use max controller speed. Signed-off-by: Chuanhong Guo <gch981213@gmail.com> Link: https://lore.kernel.org/r/20200306085052.28258-2-gch981213@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-11spi: Stop selecting MTD_SPI_NOR for SPI_HISI_SFC_V3XXJohn Garry1-1/+0
By selecting MTD_SPI_NOR for SPI_HISI_SFC_V3XX, we may introduce unmet dependencies: WARNING: unmet direct dependencies detected for MTD_SPI_NOR Depends on [m]: MTD [=m] && SPI_MASTER [=y] Selected by [y]: - SPI_HISI_SFC_V3XX [=y] && SPI [=y] && SPI_MASTER [=y] && (ARM64 && ACPI [=y] || COMPILE_TEST [=y]) && HAS_IOMEM [=y] Since MTD_SPI_NOR is only selected by SPI_HISI_SFC_V3XX for practical reasons - slave devices use the spi-nor driver, enabled by MTD_SPI_NOR - just drop it. Signed-off-by: John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/1583948115-239907-1-git-send-email-john.garry@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-10spi: spi-fsl-dspi: fix DMA mappingMichael Walle1-7/+10
Use the correct device to request the DMA mapping. Otherwise the IOMMU doesn't get the mapping and it will generate a page fault. The error messages look like: [ 3.008452] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xf9800000, fsynr=0x3f0022, cbfrsynra=0x828, cb=8 [ 3.020123] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xf9800000, fsynr=0x3f0022, cbfrsynra=0x828, cb=8 This was tested on a custom board with a LS1028A SoC. Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200310073313.21277-1-michael@walle.cc Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-10Merge series "spi: Add FSI-attached SPI controller driver" from Eddie James ↵Mark Brown5-0/+609
<eajames@linux.ibm.com>: This series adds a dts binding and a driver for a new SPI controller that is accessed over FSI bus. Eddie James (2): dt-bindings: fsi: Add FSI2SPI bindings spi: Add FSI-attached SPI controller driver .../devicetree/bindings/fsi/ibm,fsi2spi.yaml | 36 ++ MAINTAINERS | 7 + drivers/spi/Kconfig | 7 + drivers/spi/Makefile | 1 + drivers/spi/spi-fsi.c | 558 ++++++++++++++++++ 5 files changed, 609 insertions(+) create mode 100644 Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml create mode 100644 drivers/spi/spi-fsi.c -- 2.24.0
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-03 14:33:19 +0300