linux-next.git/drivers/mtd, branch master

mtd: spi-nor: Unprepare legacy controllers upon RWW wait interruption

2026-09-04T08:54:18+00:00

All the parallel locking helpers (spi_nor_prep_and_lock(), spi_nor_prep_and_lock_pe() and spi_nor_prep_and_lock_rd()) call spi_nor_prep() then wait with a killable sleep. If the sleep gets killed, we leave the controller in its prepared state. Call ->unprepare() in these cases. Fixes: 74df43b3f626 ("mtd: spi-nor: Enhance locking to support reads while writes") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Reviewed-by: Michael Walle Acked-by: Tudor Ambarus Signed-off-by: Michael Walle

mtd: spi-nor: xmc: add locking to XM25QH128A

2026-09-04T08:54:18+00:00

Add support for locking to the XM25QH128A part. Reported-by: Wei, Takino Tested-by: Wei, Takino # on Fedora 44 / 7.1.6-201 Reviewed-by: Takahiro Kuwano Signed-off-by: Michael Walle

mtd: spi-nor: remove unused NO_OP_CHIP_ERASE flag

2026-09-04T08:54:18+00:00

NO_OP_CHIP_ERASE flag is no longer used. Remove definition and references of the flag in core and debugfs. Reviewed-by: Tudor Ambarus Signed-off-by: Takahiro Kuwano Reviewed-by: Miquel Raynal Reviewed-by: Michael Walle [mw: rebased onto spi-nor/next] Signed-off-by: Michael Walle

mtd: spi-nor: sfdp: check the length of the SCCR map

2026-09-04T08:30:06+00:00

The spi_nor_parse_sccr() sizes its buffer from the table length the flash reports in the SFDP parameter header. But it then reads DWORD1 and DWORD22 without ever checking the table is that long. So if a flash reports a length of one, the buffer is only four bytes while DWORD22 sits at byte offset 84. With a length of zero kmalloc() returns ZERO_SIZE_PTR rather than an error, so the NULL check doesn't catch it and the first read dereferences it. To fix this, reject a table that's too short for the highest DWORD the parser reads, the way spi_nor_parse_4bait() already does. The table is optional, so this isn't fatal. The spi_nor_parse_sfdp() warns and carries on. The spi_nor_parse_sccr_mc() doesn't need the same check. It works out the number of dice from the length it allocated with, so its highest index stays inside the buffer. Fixes: 7ab8b810757a ("mtd: spi-nor: sfdp: Add support for SCCR map for multi-chip device") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Signed-off-by: Michael Walle

mtd: spi-nor: sfdp: check the length of the xSPI Profile 1.0 table

2026-09-04T08:30:01+00:00

The spi_nor_parse_profile1() sizes its buffer from the table length the flash reports in the SFDP parameter header. But it then reads DWORD1, DWORD4 and DWORD5 without ever checking the table is that long. So if a flash reports a length of one, the buffer is only four bytes while DWORD4 and DWORD5 sit at byte offsets 12 and 16. With a length of zero kmalloc() returns ZERO_SIZE_PTR rather than an error, so the NULL check doesn't catch it and the first read dereferences it. And the value doesn't just get thrown away. It ends up as the dummy cycle count for 8D-8D-8D fast reads. To fix this, reject a table that's too short for the highest DWORD the parser reads, the way spi_nor_parse_4bait() already does. The table is optional, so this isn't fatal. The spi_nor_parse_sfdp() warns and carries on. Fixes: fb27f198971a ("mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Signed-off-by: Michael Walle

mtd: spi-nor: rework flash parameter initialization

2026-09-04T08:29:57+00:00

Rework how the flash parameters are initialized. It used to make a difference whether a flash is in the in-kernel database, whether it supports multi I/O and so on. Recently, that makes more and more problems because flash IDs are reused among legacy flashes (w/o SFDP support) and newer flashes [1,2,3,4]. Simplify the whole parameter initialization, by starting with the parameters we have in the in-kernel database and the try to parse SFDP (and let it override any settings). This has the consequence that all the flashes now get a RDSFPD opcode which might be an unknown opcode from the perspective of the flash. With the generic SPI NOR flash driver, this was already the case for any flashes not listed in the in-kernel database. So far, there was not a single complaint. [1] https://lore.kernel.org/linux-mtd/CAAyq3SYX9UPwhC_Ume_S2yxhQwimRvB=Y6O_+FFqokhNmw7jQg@mail.gmail.com/ [2] https://lore.kernel.org/linux-mtd/DGB4745HRCFI.1DRYTHXURWZJO@kernel.org/ [3] https://lore.kernel.org/linux-mtd/DD10GE4EOCD7.CPTN7198QFUV@kernel.org/ [4] https://lore.kernel.org/linux-mtd/DD6SI06QNEE4.2YCRTWJHEAAQM@kernel.org/ Tested-by: Cheng Ming Lin Tested-by: Miquel Raynal # w/ W25Q02JVFIM Tested-by: Takahiro Kuwano # w/ s25fl128s0, s25fl128s1, s25fl256s0 Signed-off-by: Michael Walle

mtd: spi-nor: push the rollback mechanism into the sfdp module

2026-09-04T08:29:55+00:00

Right now, the core is handling the rollback of the parameters. But it doesn't have the knowledge what has to be rolled back. And in fact, havent rolled back everything. Push it down to the called function and make it mandatory, that this function has no side effects if it fails. Funny enough, there is a comment in the SFDP table handling code that each table parser is responsible to roll back any changes. But none of them did. So while add it, expand the logic to that and roll it back for them. There is one simple rule though: SFDP parsing and fixups may only modify the spi_nor_flash_parameters. Reviewed-by: Miquel Raynal Signed-off-by: Michael Walle

mtd: spi-nor: spansion: s25fs256t: move ARCFN check into .late_init

2026-09-04T08:29:53+00:00

The SFPD parsing is optional. It not meant to fail if something is wrong with the chip (except for the SFDP itself). Thus it doesn't make any sense to return -ENODEV. Move that check to late_init(), which might fail and abort the flash probing. Tested-by: Takahiro Kuwano Signed-off-by: Michael Walle

mtd: spi-nor: move spi_nor_post_bfpt_fixups() into sfdp

2026-09-04T08:29:51+00:00

Move spi_nor_post_bfpt_fixups() into the sfdp module because it's really only needed there. While at it, add some documentation. Reviewed-by: Miquel Raynal Signed-off-by: Michael Walle

mtd: spi-nor: move flags into spi_nor_flash_parameter

2026-09-04T08:29:50+00:00

Right now the SFDP parsing code is modifying both members of struct spi_nor_flash_parameter and struct spi_nor. This may lead to inconsistencies if the parsing fails because only the flash parameters are rolled back. To fix this, move the flags into the struct spi_nor_flash_parameter. Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260601125438.3481722-1-mwalle%40kernel.org?part=3 Signed-off-by: Michael Walle