pm24.git/drivers/spi, branch v5.10

spi: dw: Fix spi registration for controllers overriding CS

2020-11-25T12:54:05Z

When SPI DW memory ops support was introduced, there was a check for excluding controllers which supplied their own CS function. Even so, the mem_ops pointer is *always* presented to the SPI core. This causes the SPI core sanity check in spi_controller_check_ops() to refuse registration, since a mem_ops pointer is being supplied without an exec_op member function. The end result is failure of the SPI DW driver on sparx5 and similar platforms. The fix in the core SPI DW driver is to avoid presenting the mem_ops pointer if the exec_op function is not set. Fixes: 6423207e57ea (spi: dw: Add memory operations support) Signed-off-by: Lars Povlsen Acked-by: Serge Semin Link: https://lore.kernel.org/r/20201120213414.339701-1-lars.povlsen@microchip.com Signed-off-by: Mark Brown

spi: imx: fix the unbalanced spi runtime pm management

2020-11-24T14:14:02Z

If set active without increase the usage count of pm, the dont use autosuspend function will call the suspend callback to close the two clocks of spi because the usage count is reduced to -1. This will cause the warning dump below when the defer-probe occurs. [ 129.379701] ecspi2_root_clk already disabled [ 129.384005] WARNING: CPU: 1 PID: 33 at drivers/clk/clk.c:952 clk_core_disable+0xa4/0xb0 So add the get noresume function before set active. Fixes: 43b6bf406cd0 spi: imx: fix runtime pm support for !CONFIG_PM Signed-off-by: Clark Wang Link: https://lore.kernel.org/r/20201124085247.18025-1-xiaoning.wang@nxp.com Signed-off-by: Mark Brown

spi: spi-nxp-fspi: fix fspi panic by unexpected interrupts

2020-11-23T14:10:02Z

Given the case that bootloader(such as UEFI)'s FSPI driver might not handle all interrupts before loading kernel, those legacy interrupts would assert immidiately once kernel's FSPI driver enable them. Further, if it was FSPI_INTR_IPCMDDONE, the irq handler nxp_fspi_irq_handler() would call complete(&f->c) to notify others. However, f->c might not be initialized yet at that time, then cause kernel panic. Of cause, we should fix this issue within bootloader. But it would be better to have this pacth to make dirver more robust (by clearing all interrupt status bits before enabling interrupts). Suggested-by: Han Xu Signed-off-by: Ran Wang Link: https://lore.kernel.org/r/20201123025715.14635-1-ran.wang_1@nxp.com Signed-off-by: Mark Brown

spi: Take the SPI IO-mutex in the spi_setup() method

2020-11-20T17:18:22Z

I've discovered that due to the recent commit 49d7d695ca4b ("spi: dw: Explicitly de-assert CS on SPI transfer completion") a concurrent usage of the spidev devices with different chip-selects causes the "SPI transfer timed out" error. The root cause of the problem has turned to be in a race condition of the SPI-transfer execution procedure and the spi_setup() method being called at the same time. In particular in calling the spi_set_cs(false) while there is an SPI-transfer being executed. In my case due to the commit cited above all CSs get to be switched off by calling the spi_setup() for /dev/spidev0.1 while there is an concurrent SPI-transfer execution performed on /dev/spidev0.0. Of course a situation of the spi_setup() being called while there is an SPI-transfer being executed for two different SPI peripheral devices of the same controller may happen not only for the spidev driver, but for instance for MMC SPI + some another device, or spi_setup() being called from an SPI-peripheral probe method while some other device has already been probed and is being used by a corresponding driver... Of course I could have provided a fix affecting the DW APB SSI driver only, for instance, by creating a mutual exclusive access to the set_cs callback and setting/clearing only the bit responsible for the corresponding chip-select. But after a short research I've discovered that the problem most likely affects a lot of the other drivers: - drivers/spi/spi-sun4i.c - RMW the chip-select register; - drivers/spi/spi-rockchip.c - RMW the chip-select register; - drivers/spi/spi-qup.c - RMW a generic force-CS flag in a CSR. - drivers/spi/spi-sifive.c - set a generic CS-mode flag in a CSR. - drivers/spi/spi-bcm63xx-hsspi.c - uses an internal mutex to serialize the bus config changes, but still isn't protected from the race condition described above; - drivers/spi/spi-geni-qcom.c - RMW a chip-select internal flag and set the CS state in HW; - drivers/spi/spi-orion.c - RMW a chip-select register; - drivers/spi/spi-cadence.c - RMW a chip-select register; - drivers/spi/spi-armada-3700.c - RMW a chip-select register; - drivers/spi/spi-lantiq-ssc.c - overwrites the chip-select register; - drivers/spi/spi-sun6i.c - RMW a chip-select register; - drivers/spi/spi-synquacer.c - RMW a chip-select register; - drivers/spi/spi-altera.c - directly sets the chip-select state; - drivers/spi/spi-omap2-mcspi.c - RMW an internally cached CS state and writes it to HW; - drivers/spi/spi-mt65xx.c - RMW some CSR; - drivers/spi/spi-jcore.c - directly sets the chip-selects state; - drivers/spi/spi-mt7621.c - RMW a chip-select register; I could have missed some drivers, but a scale of the problem is obvious. As you can see most of the drivers perform an unprotected Read-modify-write chip-select register modification in the set_cs callback. Seeing the spi_setup() function is calling the spi_set_cs() and it can be executed concurrently with SPI-transfers exec procedure, which also calls spi_set_cs() in the SPI core spi_transfer_one_message() method, the race condition of the register modification turns to be obvious. To sum up the problem denoted above affects each driver for a controller having more than one chip-select lane and which: 1) performs the RMW to some CS-related register with no serialization; 2) directly disables any CS on spi_set_cs(dev, false). * the later is the case of the DW APB SSI driver. The controllers which equipped with a single CS theoretically can also experience the problem, but in practice will not since normally the spi_setup() isn't called concurrently with the SPI-transfers executed on the same SPI peripheral device. In order to generically fix the denoted bug I'd suggest to serialize an access to the controller IO by taking the IO mutex in the spi_setup() callback. The mutex is held while there is an SPI communication going on on the SPI-bus of the corresponding SPI-controller. So calling the spi_setup() method and disabling/updating the CS state within it would be safe while there is no any SPI-transfers being executed. Also note I suppose it would be safer to protect the spi_controller->setup() callback invocation too, seeing some of the SPI-controller drivers update a HW state in there. Fixes: 49d7d695ca4b ("spi: dw: Explicitly de-assert CS on SPI transfer completion") Signed-off-by: Serge Semin Link: https://lore.kernel.org/r/20201117094517.5654-1-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown

spi: npcm-fiu: Don't leak SPI master in probe error path

2020-11-17T17:08:39Z

If the calls to of_match_device(), of_alias_get_id(), devm_ioremap_resource(), devm_regmap_init_mmio() or devm_clk_get() fail on probe of the NPCM FIU SPI driver, the spi_controller struct is erroneously not freed. Fix by switching over to the new devm_spi_alloc_master() helper. Fixes: ace55c411b11 ("spi: npcm-fiu: add NPCM FIU controller driver") Signed-off-by: Lukas Wunner Cc: # v5.4+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation Cc: # v5.4+ Cc: Tomer Maimon Link: https://lore.kernel.org/r/a420c23a363a3bc9aa684c6e790c32a8af106d17.1605512876.git.lukas@wunner.de Signed-off-by: Mark Brown

spi: dw: Set transfer handler before unmasking the IRQs

2020-11-17T17:08:39Z

It turns out the IRQs most like can be unmasked before the controller is enabled with no problematic consequences. The manual doesn't explicitly state that, but the examples perform the controller initialization procedure in that order. So the commit da8f58909e7e ("spi: dw: Unmask IRQs after enabling the chip") hasn't been that required as I thought. But anyway setting the IRQs up after the chip enabling still worth adding since it has simplified the code a bit. The problem is that it has introduced a potential bug. The transfer handler pointer is now initialized after the IRQs are enabled. That may and eventually will cause an invalid or uninitialized callback invocation. Fix that just by performing the callback initialization before the IRQ unmask procedure. Fixes: da8f58909e7e ("spi: dw: Unmask IRQs after enabling the chip") Signed-off-by: Serge Semin Link: https://lore.kernel.org/r/20201117094054.4696-1-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown

spi: cadence-quadspi: Fix error return code in cqspi_probe

2020-11-16T20:02:42Z

Fix to return the error code from devm_reset_control_get_optional_exclusive() instaed of 0 in cqspi_probe(). Fixes: 31fb632b5d43ca ("spi: Move cadence-quadspi driver to drivers/spi/") Reported-by: Hulk Robot Signed-off-by: Zhihao Cheng Reviewed-by: Philipp Zabel Link: https://lore.kernel.org/r/20201116141836.2970579-1-chengzhihao1@huawei.com Signed-off-by: Mark Brown

spi: bcm2835aux: Restore err assignment in bcm2835aux_spi_probe

2020-11-13T18:22:24Z

Clang warns: drivers/spi/spi-bcm2835aux.c:532:50: warning: variable 'err' is uninitialized when used here [-Wuninitialized] dev_err(&pdev->dev, "could not get clk: %d\n", err); ^~~ ./include/linux/dev_printk.h:112:32: note: expanded from macro 'dev_err' _dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__) ^~~~~~~~~~~ drivers/spi/spi-bcm2835aux.c:495:9: note: initialize the variable 'err' to silence this warning int err; ^ = 0 1 warning generated. Restore the assignment so that the error value can be used in the dev_err statement and there is no uninitialized memory being leaked. Fixes: e13ee6cc4781 ("spi: bcm2835aux: Fix use-after-free on unbind") Link: https://github.com/ClangBuiltLinux/linux/issues/1199 Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20201113180701.455541-1-natechancellor@gmail.com Signed-off-by: Mark Brown

Merge series "Use-after-free be gone" from Lukas Wunner :

2020-11-12T19:34:52Z

Here's my proposal to fix the use-after-free bugs reported by Sascha Hauer and Florian Fainelli: I scrutinized all SPI drivers in the v5.10 tree: * There are 9 drivers with a use-after-free in the ->remove() hook caused by accessing driver private data after spi_unregister_controller(). * There are 8 drivers which leak the spi_controller in the ->probe() error path because of a missing spi_controller_put(). I'm introducing devm_spi_alloc_master/slave() which automatically calls spi_controller_put() on ->remove(). This fixes both classes of bugs while at the same time reducing code amount and complexity in the ->probe() hook. I propose that spi_controller_unregister() should no longer release a reference on the spi_controller. Instead, drivers need to either do it themselves or use one of the devm functions introduced herein. The vast majority of drivers can be converted to the devm functions. See the commit message of patch [1/4] for the rationale and details. Enclosed are patches for 3 Broadcom drivers. Patches for the other drivers are on this branch: https://github.com/l1k/linux/commits/spi_fixes @Florian Fainelli: Could you verify that there are no KASAN splats or leaks with these patches? Unfortunately I do not have any SPI-capable hardware at my disposal right now, so can only compile-test. You may want to augment spi_controller_release() with a printk() to log when the spi_controller is freed. @Mark Brown: Patches [2/4] to [4/4] reference the SHA-1 of patch [1/4] in their stable tags. Because the hash is unknown to me until you apply the patch, I've used "123456789abc" as a placeholder. You'll have to replace the hash if/when applying. Alternatively, only apply patch [1/4] and I'll repost the other patches with the hash fixed up. Thanks! Lukas Wunner (4): spi: Introduce device-managed SPI controller allocation spi: bcm2835: Fix use-after-free on unbind spi: bcm2835aux: Fix use-after-free on unbind spi: bcm-qspi: Fix use-after-free on unbind drivers/spi/spi-bcm-qspi.c | 34 ++++++++------------- drivers/spi/spi-bcm2835.c | 24 +++++---------- drivers/spi/spi-bcm2835aux.c | 21 +++++-------- drivers/spi/spi.c | 58 +++++++++++++++++++++++++++++++++++- include/linux/spi/spi.h | 19 ++++++++++++ 5 files changed, 103 insertions(+), 53 deletions(-) -- 2.28.0

spi: lpspi: Fix use-after-free on unbind

2020-11-12T18:45:56Z

Normally the last reference on an spi_controller is released by spi_unregister_controller(). In the case of the i.MX lpspi driver, the spi_controller is registered with devm_spi_register_controller(), so spi_unregister_controller() is invoked automatically after the driver has unbound. However the driver already releases the last reference in fsl_lpspi_remove() through a gratuitous call to spi_master_put(), causing a use-after-free when spi_unregister_controller() is subsequently invoked by the devres framework. Fix by dropping the superfluous spi_master_put(). Fixes: 944c01a889d9 ("spi: lpspi: enable runtime pm for lpspi") Signed-off-by: Lukas Wunner Cc: # v5.2+ Cc: Han Xu Link: https://lore.kernel.org/r/ab3c0b18bd820501a12c85e440006e09ec0e275f.1604874488.git.lukas@wunner.de Signed-off-by: Mark Brown