wireguard-linux/drivers/mtd/nand, branch stable

mtd: spinand: Do not update the QE bit on devices without one

2026-09-25T14:53:51Z

Commit be0b86c648bf ("mtd: spinand: Gather all the bus interface steps in one single function") moved quad-enable setup into spinand_configure_chip(). The new code only determines whether quad mode is needed when SPINAND_HAS_QE_BIT is set, but calls spinand_init_quad_enable() unconditionally. This clears configuration register bit 0 on devices without a QE bit. That bit is not universally a QE bit. On the Winbond W25N02KV it is H-DIS, which disables the active-low HOLD function. Clearing H-DIS enables HOLD during single and dual I/O operations. If IO3 is not kept high, the flash can pause a command and ignore clock and data. H-DIS is not restored by the FFh reset command, allowing the incorrect state to survive an SoC warm reboot while the flash remains powered. Before the refactoring, spinand_init_quad_enable() returned without touching the configuration register on devices without SPINAND_HAS_QE_BIT. Restore that behavior by only calling the helper when the flag is set. Return zero explicitly once SSDR configuration completes, as all errors are returned immediately. This avoids returning an uninitialized value when neither optional configuration step runs. The regression was reproduced on a JioRouter JIDU6401 with an MT7986 SoC and a W25N02KV. With Linux 6.18.44, sysupgrade failed and the following warm reboot hung in BL2. With this change applied, both sysupgrade and warm reboot completed successfully. Fixes: be0b86c648bf ("mtd: spinand: Gather all the bus interface steps in one single function") Cc: stable@vger.kernel.org Suggested-by: Miquel Raynal Assisted-by: LLM Signed-off-by: Sagnik Sasmal Signed-off-by: Miquel Raynal

mtd: rawnand: cadence: Initialize IRQ state before requesting IRQ

2026-09-04T18:32:21Z

The Cadence NAND interrupt handler uses both the IRQ lock and completion object. Registering the IRQ before initializing them leaves a window in which a pending interrupt can access uninitialized synchronization state. Initialize them before registering the handler. Fixes: ec4ba01e894d ("mtd: rawnand: Add new Cadence NAND driver to MTD subsystem") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao Signed-off-by: Miquel Raynal

mtd: rawnand: vf610_nfc: fix false bitflips on reads of erased pages

2026-09-04T18:32:21Z

When the ECC engine fails to decode a page, the driver re-reads the OOB area with the engine bypassed, but runs the erased-page check for the data area on the buffer left in the controller SRAM by the failed transfer. That buffer does not hold what is on the flash: the failing engine writes a bogus single-bit "correction" into it. In the 60-byte ECC mode the all-0xff content of an erased page always decodes to the same error location, so every erased page shows one stale zero bit at data offset 0x5FD, which the erased-page check then reports as a corrected bitflip. Edward Karpicz discovered this behaviour and identified the offset on a Colibri VF61; the analysis and the fix build on his finding. Measured with an instrumented driver on a Colibri VF50 (MX30LF1G18AC, 32-bit ECC): reading a 126 MiB partition with nanddump increased the corrected counter by 18035, exactly one per erased page, while raw reads of the same pages return clean 0xff. A v4.4 kernel on the VF61 (MX30LF4G28AC) accumulates the same false counts, so the behaviour follows the controller rather than the chip or the driver generation. Neither the Vybrid reference manual nor the published mask set errata (VFXXX_2N02G) document it. The 45-byte ECC mode is not affected. Restoring the known byte is not enough: on pages that fail to decode with content other than all-0xff the engine writes its correction wherever the syndrome points (measured at a different offset on such a page), so the check has to run on what the flash holds. Re-read the data area with the ECC engine bypassed, exactly as already done for the OOB area. The corrected counter then stays at zero on both boards. Reported-by: Edward Karpicz Link: https://community.toradex.com/t/colibri-vf50-vf61-on-the-current-bsp-mainline-u-boot-v2026-07-and-linux-6-18-lts/30735 Signed-off-by: Mehmet Fide Signed-off-by: Miquel Raynal

mtd: rawnand: vf610_nfc: fix reads on chips with more than 64 bytes of OOB

2026-09-04T18:32:21Z

The controller transfers 64 spare bytes per page and the driver only implements the matching 64-byte ECC layout, so attach_chip() shrinks mtd->oobsize when the chip provides more. That clamp does not survive: nand_scan_tail() runs nanddev_init() after ->attach_chip(), and it restores mtd->oobsize from the memory organization, which still holds the value detected from the chip. The driver then transfers writesize plus the chip's full OOB size, the hardware ECC parity ends up at a different offset than the layout the controller was set up for, and every ECC-protected read fails with -EBADMSG. Measured on a Colibri VF61 (MX30LF4G28AC, 2048-byte pages, 112 bytes of OOB): with the clamp lost, UBI cannot read the erase counter headers of the pages U-Boot has just written, and the on-flash bad block table written by an older kernel reads back with ECC errors, so the board does not boot. Kernels before commit a7ab085d7c16 ("mtd: rawnand: Initialize the nand_device object") are not affected because nothing overwrote the clamp there, which is why the same chip works with a v4.4 kernel and with U-Boot, whose copy of this driver has no memory organization to restore the value from. Edward Karpicz reported that the clamp no longer takes effect on this chip; see the link below. Instead of modifying the memory organization, keep the detected OOB size and give the driver its own mtd_ooblayout_ops: the same layout the NAND core uses for large pages, but computed on the first 64 OOB bytes instead of the whole OOB, so the ECC bytes stay where U-Boot and the old kernels put them. The data paths transfer writesize plus those 64 bytes, as the controller always has. Since mtd->oobsize now reports the chip's real spare size, fill the tail of oob_poi with 0xff after the 64 transferred bytes on ECC page reads: the core may copy the full mtd->oobsize from it, which would otherwise expose whatever the buffer held before. 0xff also matches what a raw read returns from flash, since the write path only ever programs the first 64 spare bytes. Reported-by: Edward Karpicz Link: https://community.toradex.com/t/colibri-vf50-vf61-on-the-current-bsp-mainline-u-boot-v2026-07-and-linux-6-18-lts/30735 Suggested-by: Miquel Raynal Fixes: a7ab085d7c16 ("mtd: rawnand: Initialize the nand_device object") Cc: stable@vger.kernel.org Signed-off-by: Mehmet Fide Signed-off-by: Miquel Raynal

mtd: spinand: fix zero oobavail when no ECC engine is used

2026-09-04T18:32:21Z

Commit 00c15b78b4b4 ("mtd: spinand: Allow the case where there is no ECC engine") made the OOB free bytes count conditional on having an ECC engine so that probing would not fail when none is requested. However mtd->oobavail is still assigned from ret just after that block, and ret is 0 there, so the device ends up advertising no available OOB bytes at all. mtd_oobavail() returns mtd->oobavail for MTD_OPS_AUTO_OOB, so a zero value makes every automatic OOB access fail with -EINVAL. JFFS2 fares worse: it keeps its cleanmarker in the OOB area on NAND and refuses to mount outright, reporting "inconsistent device description". No ECC engine also means no ooblayout was ever installed, which would make the count return -ENOTSUPP, so install the same fallback layout the on-die path already uses before counting unconditionally. Fixes: 00c15b78b4b4 ("mtd: spinand: Allow the case where there is no ECC engine") Cc: stable@vger.kernel.org Signed-off-by: Nuno Sá Signed-off-by: Miquel Raynal

mtd: spinand: fix NULL pointer dereference with no ECC engine

2026-09-04T18:32:21Z

When "nand-no-ecc-engine" is set in DT, nanddev_get_ecc_engine() takes the NAND_ECC_ENGINE_TYPE_NONE path and returns success while leaving nand->ecc.engine NULL. The SPI-NAND code nevertheless dereferences it unconditionally to test for a pipelined engine, so probing such a device oopses immediately. Rather than open-coding the test three times, add a nand_ecc_is_pipelined() helper to the NAND core that folds the NULL check into the integration comparison, and use it everywhere. Future callers then cannot reintroduce the problem. Fixes: f9d7c7265bcf ("mtd: spinand: Create direct mapping descriptors for ECC operations") Cc: stable@vger.kernel.org Signed-off-by: Nuno Sá Signed-off-by: Miquel Raynal

mtd: spinand: Enable QE on all dies

2026-09-04T17:05:22Z

The QUAD ENABLE (QE) bit is stored in a per-die configuration register on some SPI-NAND devices. When a device contains multiple dies, updating the QE bit only on the currently selected die can leave the remaining dies operating in non-quad mode. Iterate over all targets and update the QE setting on each die during initialization to ensure consistent quad I/O operation across the entire device. Tested on ISSI IS38SMW04G8B. Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs") Cc: stable@vger.kernel.org Signed-off-by: Han Xu Signed-off-by: Miquel Raynal

Merge tag 'mtd/for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux

2026-08-23T16:11:21Z

Pull mtd updates from Miquel Raynal: "Raw NAND changes: - Sunxi: Support added for the H616 compatible - Qcom: Support added for the MDM9607 compatible - Support for the Toshiba TC58NVG1S3H part - GPMI: New debugfs entry to expose the chip geometry - PL353: Timing updates and software ECC support have been fixed SPI NAND changes: - fmsh: Support added for FM25G{01,02}B chips - HeYangTek: Support added for HYF1GQ4UDACAE Aside from these main changes, there is a high load of misc fixes and hardening changes, and exceptionally no SPI NOR change" * tag 'mtd/for-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (30 commits) mtd: rawnand: sunxi: fix H6/H616 controller timings mtd: rawnand: sunxi: describe tADL and tWHR delays mtd: rawnand: sunxi: group controller delay tables mtd: maps: remove dead select of MTD_CFI_BE_BYTE_SWAP mtd: rawnand: gpmi: add debugfs entry for BCH geometry mtd: rawnand: validate ONFI extended parameter page sections mtd: rawnand: sunxi: add H616 MBUS DMA support mtd: spinand: fmsh: fix FM25G01B/FM25G02B Quad I/O read dummy cycles mtd: part: reject MTDPART_OFS_RETAIN in mtd_add_partition() mtd: mpc5121_nfc: use platform for irq and ioremap mtd: mtdoops: free page bitmap when the backing MTD is removed mtd: mtdswap: Avoid freeing registered blktrans device twice mtd: afs: validate v2 image info bounds mtd: intel-dg: Fix runtime PM error path in probe mtd: nand-omap2: Move omap_nand_ids[] to raw nand driver mtd: rawnand: add Toshiba TC58NVG1S3H mtd: nand: realtek-ecc: add missing MODULE_DEVICE_TABLE() mtd: rawnand: qcom: Add MDM9607 compatible mtd: rawnand: qcom: Make has_onfi_read_op separate from qpic_version2 mtd: rawnand: qcom: Make "aon" clock optional ...

Merge tag 'nand/for-7.3' into mtd/next

2026-08-23T12:30:31Z

* Raw NAND changes - Sunxi: Support added for the H616 compatible - Qcom: Support added for the MDM9607 compatible - Support for the Toshiba TC58NVG1S3H part - GPMI: New debugfs entry to expose the chip geometry - PL353: Timing updates and software ECC support have been fixed * SPI NAND changes - fmsh: Support added for FM25G{01,02}B chips - HeYangTek: Support added for HYF1GQ4UDACAE Aside from these main changes, there is the usual load of misc fixes and hardening changes.

mtd: rawnand: sunxi: fix H6/H616 controller timings

2026-08-10T14:24:26Z

The NAND timing calculation assumes that command and address setup and hold intervals T1-T4, T7 and T11 each take one controller clock. It also uses the original A10 delay encodings for tWB, tADL, tWHR and tRHW. The H6/H616 NDFC defines the setup and hold intervals as two internal clock cycles and uses different delay encodings. Add the H616 timing characteristics and select them through the controller capability data so the clock solver and timing fields match the hardware. Fixes: 88fd4e4deae8 ("mtd: rawnand: sunxi: Add support for H616 nand controller") Cc: stable@vger.kernel.org Signed-off-by: James Hilliard Signed-off-by: Miquel Raynal