user/sven/linux.git/drivers/spi, branch v6.17.9

spi: Try to get ACPI GPIO IRQ earlier

2025-11-24T09:37:46Z

commit 3cd2018e15b3d66d2187d92867e265f45ad79e6f upstream. Since commit d24cfee7f63d ("spi: Fix acpi deferred irq probe"), the acpi_dev_gpio_irq_get() call gets delayed till spi_probe() is called on the SPI device. If there is no driver for the SPI device then the move to spi_probe() results in acpi_dev_gpio_irq_get() never getting called. This may cause problems by leaving the GPIO pin floating because this call is responsible for setting up the GPIO pin direction and/or bias according to the values from the ACPI tables. Re-add the removed acpi_dev_gpio_irq_get() in acpi_register_spi_device() to ensure the GPIO pin is always correctly setup, while keeping the acpi_dev_gpio_irq_get() call added to spi_probe() to deal with -EPROBE_DEFER returns caused by the GPIO controller not having a driver yet. Link: https://bbs.archlinux.org/viewtopic.php?id=302348 Fixes: d24cfee7f63d ("spi: Fix acpi deferred irq probe") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20251102190921.30068-1-hansg@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

spi: rpc-if: Add resume support for RZ/G3E

2025-11-13T20:36:52Z

[ Upstream commit ad4728740bd68d74365a43acc25a65339a9b2173 ] On RZ/G3E using PSCI, s2ram powers down the SoC. After resume, reinitialize the hardware for SPI operations. Signed-off-by: Biju Das Link: https://patch.msgid.link/20250921112649.104516-3-biju.das.jz@bp.renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: spi-qpic-snand: handle 'use_ecc' parameter of qcom_spi_config_cw_read()

2025-11-13T20:36:46Z

[ Upstream commit 9c45f95222beecd6a284fd1284d54dd7a772cf59 ] During raw read, neither the status of the ECC correction nor the erased state of the codeword gets checked by the qcom_spi_read_cw_raw() function, so in case of raw access reading the corresponding registers via DMA is superfluous. Extend the qcom_spi_config_cw_read() function to evaluate the existing (but actually unused) 'use_ecc' parameter, and configure reading only the flash status register when ECC is not used. With the change, the code gets in line with the corresponding part of the config_nand_cw_read() function in the qcom_nandc driver. Signed-off-by: Gabor Juhos Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20250808-qpic-snand-handle-use_ecc-v1-1-67289fbb5e2f@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: loopback-test: Don't use %pK through printk

2025-11-13T20:36:46Z

[ Upstream commit b832b19318534bb4f1673b24d78037fee339c679 ] In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. There are still a few users of %pK left, but these use it through seq_file, for which its usage is safe. Signed-off-by: Thomas Weißschuh Link: https://patch.msgid.link/20250811-restricted-pointers-spi-v1-1-32c47f954e4d@linutronix.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: airoha: fix reading/writing of flashes with more than one plane per lun

2025-10-29T13:10:27Z

[ Upstream commit 0b7d9b25e4bc2e478c9d06281a65f930769fca09 ] Attaching UBI on the flash with more than one plane per lun will lead to the following error: [ 2.980989] spi-nand spi0.0: Micron SPI NAND was found. [ 2.986309] spi-nand spi0.0: 256 MiB, block size: 128 KiB, page size: 2048, OOB size: 128 [ 2.994978] 2 fixed-partitions partitions found on MTD device spi0.0 [ 3.001350] Creating 2 MTD partitions on "spi0.0": [ 3.006159] 0x000000000000-0x000000020000 : "bl2" [ 3.011663] 0x000000020000-0x000010000000 : "ubi" ... [ 6.391748] ubi0: attaching mtd1 [ 6.412545] ubi0 error: ubi_attach: PEB 0 contains corrupted VID header, and the data does not contain all 0xFF [ 6.422677] ubi0 error: ubi_attach: this may be a non-UBI PEB or a severe VID header corruption which requires manual inspection [ 6.434249] Volume identifier header dump: [ 6.438349] magic 55424923 [ 6.441482] version 1 [ 6.444007] vol_type 0 [ 6.446539] copy_flag 0 [ 6.449068] compat 0 [ 6.451594] vol_id 0 [ 6.454120] lnum 1 [ 6.456651] data_size 4096 [ 6.459442] used_ebs 1061644134 [ 6.462748] data_pad 0 [ 6.465274] sqnum 0 [ 6.467805] hdr_crc 61169820 [ 6.470943] Volume identifier header hexdump: [ 6.475308] hexdump of PEB 0 offset 4096, length 126976 [ 6.507391] ubi0 warning: ubi_attach: valid VID header but corrupted EC header at PEB 4 [ 6.515415] ubi0 error: ubi_compare_lebs: unsupported on-flash UBI format [ 6.522222] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd1, error -22 [ 6.529294] UBI error: cannot attach mtd1 Non dirmap reading works good. Looking to spi_mem_no_dirmap_read() code we'll see: static ssize_t spi_mem_no_dirmap_read(struct spi_mem_dirmap_desc *desc, u64 offs, size_t len, void *buf) { struct spi_mem_op op = desc->info.op_tmpl; int ret; // --- see here --- op.addr.val = desc->info.offset + offs; //----------------- op.data.buf.in = buf; op.data.nbytes = len; ret = spi_mem_adjust_op_size(desc->mem, &op); if (ret) return ret; ret = spi_mem_exec_op(desc->mem, &op); if (ret) return ret; return op.data.nbytes; } The similar happens for spi_mem_no_dirmap_write(). Thus the address passed to the flash should take in the account the value of desc->info.offset. This patch fix dirmap reading/writing of flashes with more than one plane per lun. Fixes: a403997c12019 ("spi: airoha: add SPI-NAND Flash controller driver") Signed-off-by: Mikhail Kshevetskiy Reviewed-by: AngeloGioacchino Del Regno Link: https://patch.msgid.link/20251012121707.2296160-7-mikhail.kshevetskiy@iopsys.eu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: airoha: switch back to non-dma mode in the case of error

2025-10-29T13:10:27Z

[ Upstream commit 20d7b236b78c7ec685a22db5689b9c829975e0c3 ] Current dirmap code does not switch back to non-dma mode in the case of error. This is wrong. This patch fixes dirmap read/write error path. Fixes: a403997c12019 ("spi: airoha: add SPI-NAND Flash controller driver") Signed-off-by: Mikhail Kshevetskiy Acked-by: Lorenzo Bianconi Reviewed-by: AngeloGioacchino Del Regno Link: https://patch.msgid.link/20251012121707.2296160-6-mikhail.kshevetskiy@iopsys.eu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: airoha: add support of dual/quad wires spi modes to exec_op() handler

2025-10-29T13:10:27Z

[ Upstream commit edd2e261b1babb92213089b5feadca12e3459322 ] Booting without this patch and disabled dirmap support results in [ 2.980719] spi-nand spi0.0: Micron SPI NAND was found. [ 2.986040] spi-nand spi0.0: 256 MiB, block size: 128 KiB, page size: 2048, OOB size: 128 [ 2.994709] 2 fixed-partitions partitions found on MTD device spi0.0 [ 3.001075] Creating 2 MTD partitions on "spi0.0": [ 3.005862] 0x000000000000-0x000000020000 : "bl2" [ 3.011272] 0x000000020000-0x000010000000 : "ubi" ... [ 6.195594] ubi0: attaching mtd1 [ 13.338398] ubi0: scanning is finished [ 13.342188] ubi0 error: ubi_read_volume_table: the layout volume was not found [ 13.349784] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd1, error -22 [ 13.356897] UBI error: cannot attach mtd1 If dirmap is disabled or not supported in the spi driver, the dirmap requests will be executed via exec_op() handler. Thus, if the hardware supports dual/quad spi modes, then corresponding requests will be sent to exec_op() handler. Current driver does not support such requests, so error is arrised. As result the flash can't be read/write. This patch adds support of dual and quad wires spi modes to exec_op() handler. Fixes: a403997c12019 ("spi: airoha: add SPI-NAND Flash controller driver") Signed-off-by: Mikhail Kshevetskiy Reviewed-by: AngeloGioacchino Del Regno Link: https://patch.msgid.link/20251012121707.2296160-4-mikhail.kshevetskiy@iopsys.eu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: airoha: return an error for continuous mode dirmap creation cases

2025-10-29T13:10:26Z

[ Upstream commit 4314ffce4eb81a6c18700af1b6e29b6e0c6b9e37 ] This driver can accelerate single page operations only, thus continuous reading mode should not be used. Continuous reading will use sizes up to the size of one erase block. This size is much larger than the size of single flash page. Use this difference to identify continuous reading and return an error. Signed-off-by: Mikhail Kshevetskiy Reviewed-by: Frieder Schrempf Reviewed-by: AngeloGioacchino Del Regno Fixes: a403997c12019 ("spi: airoha: add SPI-NAND Flash controller driver") Link: https://patch.msgid.link/20251012121707.2296160-2-mikhail.kshevetskiy@iopsys.eu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: cadence-quadspi: Fix pm_runtime unbalance on dma EPROBE_DEFER

2025-10-29T13:10:26Z

[ Upstream commit 8735696acea24ac1f9d4490992418c71941ca68c ] In csqspi_probe(), when cqspi_request_mmap_dma() returns -EPROBE_DEFER, we handle the error by jumping to probe_setup_failed. In that label, we call pm_runtime_disable(), even if we never called pm_runtime_enable() before. Because of this, the driver cannot probe: [ 2.690018] cadence-qspi 47040000.spi: No Rx DMA available [ 2.699735] spi-nor spi0.0: resume failed with -13 [ 2.699741] spi-nor: probe of spi0.0 failed with error -13 Only call pm_runtime_disable() if it was enabled by adding a new label to handle cqspi_request_mmap_dma() failures. Fixes: b07f349d1864 ("spi: spi-cadence-quadspi: Fix pm runtime unbalance") Signed-off-by: Mattijs Korpershoek Reviewed-by: Dan Carpenter Link: https://patch.msgid.link/20251009-cadence-quadspi-fix-pm-runtime-v2-1-8bdfefc43902@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: spi-nxp-fspi: limit the clock rate for different sample clock source selection

2025-10-29T13:10:26Z

[ Upstream commit f43579ef3500527649b1c233be7cf633806353aa ] For different sample clock source selection, the max frequency flexspi supported are different. For mode 0, max frequency is 66MHz. For mode 3, the max frequency is 166MHz. Refer to 3.9.9 FlexSPI timing parameters on page 65. https://www.nxp.com/docs/en/data-sheet/IMX8MNCEC.pdf Though flexspi maybe still work under higher frequency, but can't guarantee the stability. IC suggest to add this limitation on all SoCs which contain flexspi. Fixes: c07f27032317 ("spi: spi-nxp-fspi: add the support for sample data from DQS pad") Signed-off-by: Haibo Chen Link: https://patch.msgid.link/20250922-fspi-fix-v1-3-ff4315359d31@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin