wireguard-linux/drivers/spi, branch stable

spi: fsl-qspi: Reprogram the clock rate when the operation frequency changes

2026-09-17T18:46:29Z

fsl_qspi_select_mem() returns early when the chip select has not changed, which happens before it reaches clk_set_rate(). Since the rate is now taken from the spi-mem operation rather than from the SPI device, the controller honours op->max_freq exactly once per chip select and ignores it for every operation after that. q->selected is only reset to -1 in fsl_qspi_default_setup(), i.e. at probe and on resume, so on the common single chip select board the very first operation latches a rate that all subsequent operations inherit, whatever frequency they asked for. This results in operations being issued with the wrong frequency. Cache the operation frequency the clock was programmed for next to the selected chip select, and redo the clock setup when either changes. Fixes: 2438db5253eb ("spi: fsl-qspi: Support per spi-mem operation frequency switches") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Frieder Schrempf Acked-by: Han Xu Link: https://patch.msgid.link/20260917-fsl-qspi-freq-op-fix-v1-1-5fbe6b02f738@kontron.de Signed-off-by: Mark Brown

spi: spi-zynqmp-gqspi: stop the controller on shutdown

2026-09-16T17:28:43Z

The driver has no ->shutdown, and platform_drv_shutdown() has no fallback of its own. Unlike pci_device_shutdown(), which clears bus mastering when kexec_in_progress, nothing on the platform bus disarms a device that can still write to memory. The normal kexec path never calls ->suspend either, so the quiesce in zynqmp_qspi_suspend() is not reached. A controller that is still executing a DMA read may therefore keep writing to memory across a kexec. QSPIDMA_DST_ADDR still points at memory owned by the kernel that called kexec, DST_SIZE is non-zero and the flash is still clocked, so data can keep landing in RAM while the new kernel is being relocated, and after it has started executing. That destination is a physical address which means nothing to the new kernel, so the writes can corrupt whatever now occupies it: kernel text or data, page tables, or the initrd. Nothing reports an error and the resulting behaviour is undefined. This can be observed by reading GQSPI_EN (offset 0x114) and QSPIDMA_DST_ADDR/SIZE/STS/CTRL (offsets 0x800 to 0x80c) early in the new kernel, before the driver probes: without this patch GQSPI_EN reads 1 and QSPIDMA_DST_ADDR still points into the previous kernel's memory. Add a ->shutdown that stops the controller the way zynqmp_qspi_suspend() already does. spi_controller_suspend() stops the queue, waits for a message that is already executing and makes any later transfer fail with -ESHUTDOWN, so nothing can be cut short by the register write that follows. It may sleep, which is fine here: device_shutdown() runs in process context. Unlike ->suspend this cannot abort on error, because a controller left mastering the bus is worse than a truncated transfer, so a failure to drain is only logged. GQSPI_EN_OFST is then cleared, as zynqmp_qspi_remove() and zynqmp_qspi_suspend() already do. Skip that write only when pm_runtime_get_if_in_use() returns 0, i.e. runtime suspended: the clocks are gated, so the registers are unreachable and the controller cannot be mastering the bus. A negative return is not the same thing - it is what the CONFIG_PM=n stub always returns, and there probe() has enabled pclk and refclk for good, so the controller is running and must be stopped. Fixes: dfe11a11d523 ("spi: Add support for Zynq Ultrascale+ MPSoC GQSPI controller") Cc: stable@vger.kernel.org Signed-off-by: Itai Handler Link: https://patch.msgid.link/20260910174832.873352-1-itai.handler@gmail.com Signed-off-by: Mark Brown

spi: virtio: Use the per-transfer bits per word

2026-09-15T16:37:50Z

virtio_spi_transfer_one() puts spi->bits_per_word into the request header, so a transfer that sets its own word size reaches the backend with the device default instead. The SPI core has already copied that default into xfer->bits_per_word when the transfer leaves it at zero, the same way it does for xfer->speed_hz, which this function already uses. Per-transfer word sizes are ordinary SPI usage. mipi_dbi, for one, sends a 9-bit command and reads the reply as 8-bit data in the same message. With a 16-bit device default, a one-byte transfer asking for 8 bits goes out as a partial 16-bit word, which the backend may reject. Fixes: f98cabe3f6cf ("SPI: Add virtio SPI driver") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Hao-Qun Huang Link: https://patch.msgid.link/20260913032049.11209.alvinhuang0603@gmail.com Signed-off-by: Mark Brown

spi: spi-qpic-snand: avoid writing QPIC_EBI2_ECC_BUF_CFG register

2026-09-13T23:41:31Z

The description of commit bfb34eced559 ("mtd: rawnand: qcom: avoid writing to obsolete register") says this: "QPIC_EBI2_ECC_BUF_CFG register got obsolete from QPIC V2.0 onwards. Avoid writing this register if QPIC version is V2.0 or newer." Although the referenced commit is related to the 'qcom-nandc' driver, however the hardware supported by the current driver is also based on QPIC v2.0 so we should avoid writing that register here as well. Remove the register writing code to avoid undefined behaviour. Fixes: 7304d1909080 ("spi: spi-qpic: add driver for QCOM SPI NAND flash Interface") Signed-off-by: Gabor Juhos Reviewed-by: Md Sadre Alam Link: https://patch.msgid.link/20260909-qpic-snand-avoid-ebi2-reg-write-v1-1-9b1b1466cc75@gmail.com Signed-off-by: Mark Brown

treewide: refresh kmalloc_obj() conversions

2026-09-05T04:37:00Z

This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook

Merge tag 'spi-fix-v7.3-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi

2026-08-27T19:38:05Z

Pull spi fixes from Mark Brown: "A couple of fixes that came in during the merge window: Geert fixed an uninitialised data bug in the amlogic-spisg driver which could crash and in the Loongson driver Li Jun hooked up the existing suspend operations more fully to fix hibernation" * tag 'spi-fix-v7.3-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: loongson: pm: add .freeze .poweroff .thaw .restore spi: amlogic-spisg: Make sure clk_init_data is fully initialized

spi: loongson: pm: add .freeze .poweroff .thaw .restore

2026-08-20T12:14:02Z

after execute s4, the spi error, [ 1104.754246][ 4] [ T1] tpm_tis_spi spi-SMO0768:00: SPI transfer failed: -110 [ 1104.761503][ 4] [ T1] spi_master spi1: failed to transfer one message from queue [ 1104.769201][ 4] [ T1] spi_master spi1: noqueue transfer failed [ 1104.776344][ 4] [ T1] tpm_tis_spi spi-SMO0768:00: SPI transfer failed: -110 [ 1104.783609][ 4] [ T1] spi_master spi1: failed to transfer one message from queue [ 1104.791308][ 4] [ T1] spi_master spi1: noqueue transfer failed [ 1104.797446][ 4] [ T1] gttadd tpm_chip_start1 ret = -110 and in s4 the loongson_spi_resume&suspend are not called at all. use DEFINE_SIMPLE_DEV_PM_OPS() add .freeze .poweroff .thaw .restore, after s4 the spi communication is normal. Signed-off-by: Li Jun Link: https://patch.msgid.link/20260820092351.101605-1-lijun01@kylinos.cn Signed-off-by: Mark Brown

spi: amlogic-spisg: Make sure clk_init_data is fully initialized

2026-08-20T12:11:44Z

The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. aml_spisg_clk_init() fills in init.parent_data, and assumes that init.parent_names is NULL. However, the latter in uninitialized, and thus may cause a crash. Make sure all members are fully initialized, to fix such bugs, and to avoid future breakage when converting drivers to a different method for specifying the parents. Fixes: cef9991e04aed330 ("spi: Add Amlogic SPISG driver") Signed-off-by: Geert Uytterhoeven Reviewed-by: Brian Masney Reviewed-by: Xianwei Zhao Link: https://patch.msgid.link/9fb35ae0aedb7a6db0db6c78a8193c7602dd9d44.1787165329.git.geert+renesas@glider.be Signed-off-by: Mark Brown

Merge tag 'spi-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi

2026-08-19T16:47:41Z

Pull spi updates from Mark Brown: "Along with a lot of driver specific work we've got a couple of core features here. The bigger one is that we've now got support for instantiating devices from sysfs similarly to how it's already done for I2C, this is used with development boards with non-enumerable expansion headers since SPI devices need to be manually specified. We also have support for the DQS signal on higher end flash devices. - Support for instantiating devices from sysfs, useful for development boards with non-enumerable plugin modules, from Vishwaroop A. - Support for DQS in spi-mem, an additional signal used by flash devices to avoid clock skew from Miquel Raynal. - Support for more advanced SPI modes on DesignWare controllers from Sudip Mukherjee. - Changes from Jisheng Zhang to update to modern methods of specifying the PM callbacks. - Fixes for DMA mapping error handling, plus KUnit tests for this, from Honghui Jiang. - Substantial cleanup and performance work in the nxp-spi driver. - Support for Microchip LAN969x, Nuvoton MA35D1 QSPI, Qualcomm SA8255p and SA8797P, and StarFive JHB100 SFC" * tag 'spi-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (132 commits) spi: Add KUnit coverage for DMA mapping error paths spi: Clear current DMA devices when unmapping a message spi: Move __spi_unmap_msg() before __spi_map_msg() spi: Fix DMA mapping ownership on partial map failure spi: dt-bindings: sun6i: Add compatibles for A733's SPI controllers spi: ma35d1-qspi: Use the existing update helper spi: ma35d1-qspi: Add DTR support spi: ma35d1-qspi: Allow several command bytes spi: ma35d1-qspi: Move speed setting to bus configuration spi: ma35d1-qspi: Remove redundant reset operation spi: dw: Remove shadowed dws in dw_spi_setup() spi: img-spfi: don't disable runtime PM on DMA deferred probe spi: mtk-nor: Propagate errors from IRQ request spi: mtk-nor: Propagate errors from optional IRQ lookup spi: spi-qpic-snand: Handle Macronix quad read opcode 0x6b spi: spi-qpic-snand: add quad mode support spi: spi-qpic-snand: move command mapping helper spi: hisi-sfc-v3xx: Propagate errors from optional IRQ lookup spi: meson-spifc: use devm_pm_runtime_set_active_enabled spi: sprd-adi: Fix probe succeeding without registering the controller ...

spi: Fix DMA mapping ownership on partial map failure

2026-08-14T15:48:53Z

Honghui Jiang says: A partial DMA mapping failure can leave per-transfer mapping flags set while cur_{tx,rx}_dma_dev are NULL or still refer to the devices used for an earlier message. The subsequent cleanup may then unmap a transfer with a NULL or stale device. Before commit e289df82344f ("spi: Rework per message DMA mapped flag to be per transfer"), partial-failure handling was already incomplete, but __spi_unmap_msg() was gated by cur_msg_mapped, which was set only after the whole message mapped successfully. Earlier mappings could leak, but cleanup could not unmap them with an unpublished device. The per-transfer conversion removed that gate: mapping flags can now remain set while cur_{tx,rx}_dma_dev are still unpublished, turning the leak into a NULL- or stale-device unmap regression. Patch 1 publishes the mapping devices before the loop and unwinds every failure through __spi_unmap_msg(). It keeps the forward declaration so it is independently buildable and straightforward to backport. Patch 2 then removes the declaration by moving __spi_unmap_msg() above __spi_map_msg(). Patch 3 clears the current DMA device pointers once the message has been unmapped, while leaving them intact during partial-map unwind and DMA-to-PIO fallback. Patch 4 adds the DMA mapping KUnit suite as a separate translation unit. Only patch 1 is a stable candidate; patches 2 through 4 are follow-up cleanup and test changes for mainline. Testing: - Patch 1 builds independently with the x86_64 reproducer configuration. - The spi_dma KUnit suite passes all four cases on x86_64 and UML. Moving the DMA device assignments back after the mapping loop makes both failure-path cases fail. - The default and all-tests KUnit configurations both select the suite. - All four reproducer cases complete without an oops when run as the first message, and map/unmap counts are balanced after a successful first message. - After message cleanup, cur_{tx,rx}_dma_dev are NULL. v1: https://lore.kernel.org/r/20260805151456.756579-1-jiang_hh2019@163.com Link: https://patch.msgid.link/20260814031419.43378-1-jiang_hh2019@163.com