linux.git/drivers/mtd/nand/spi/core.c, branch master

mtd: spinand: initialize ret in regular page reads

2026-06-29T14:40:36Z

spinand_mtd_regular_page_read() returns ret after iterating over the requested pages. If the request contains no data or OOB bytes, the iterator does not run and ret is not assigned. Initialize it to 0 for the empty request path. Signed-off-by: Ruoyu Wang Signed-off-by: Miquel Raynal

mtd: spinand: Add support for randomizer

2026-05-27T09:07:06Z

This patch adds support for the randomizer feature. It introduces a 'set_randomizer' callback in 'struct spinand_info' and 'struct spinand_device'. If a driver implements this callback, the core will invoke it during device initialization (spinand_init) to enable or disable the randomizer feature based on the device tree configuration. Signed-off-by: Cheng Ming Lin Signed-off-by: Miquel Raynal

mtd: spinand: Prevent continuous reads on some controllers

2026-05-04T13:27:03Z

Some controllers do not have full control over the CS line state and may deassert it under certain conditions in the middle of a (long) transfer. Continuous reads are stopped with a CS deassert, hence both features cannot live together. Whenever a controller flags that it cannot maintain the CS state reliably, disable continuous reads entirely. Signed-off-by: Miquel Raynal

mtd: spinand: Make sure continuous read is always disabled during probe

2026-05-04T13:27:03Z

Recent changes made sure whenever we were using continuous reads, we would first start by disabling the feature to ensure a well proven and stable probe sequence. For development purposes, it might also matter to make sure we always disable continuous reads at first, in case the ECC configuration would change. Doing this "automatically" will become even more relevant when we add extra controller flags to prevent continuous reads at all. Ensure we disable continuous reads if the feature is available on the chip, regardless of whether it will be used or not. Signed-off-by: Miquel Raynal

mtd: spinand: Use secondary ops for continuous reads

2026-05-04T13:15:47Z

In case a chip supports continuous reads, but uses a slightly different cache operation for these, it may provide a secondary operation template which will be used only during continuous cache read operations. From a vendor driver point of view, enabling this feature implies providing a new set of templates for these continuous read operations. The core will automatically pick the fastest variant, depending on the hardware capabilities. Signed-off-by: Miquel Raynal

Merge tag 'mtd/spi-mem-cont-read-for-7.2' into nand/next

2026-05-04T13:14:36Z

Aside from preparation changes in the SPI NAND core, the changes carried here focus on the shared spi-mem layer which is enhanced in order to bring two new features: - The possibility to fill a primary and a secondary operation template in the direct mapping structure in order to support continuous reads in SPI NAND, which may require two different read operations. - SPI controllers may indicate possible CS instabilities over long transfers by setting a boolean. This capability is related to the previous one, the need for it has arised while testing SPI NAND continuous reads with the Cadence QSPI controller which cannot, under certain conditions, keep the CS asserted for the length of an eraseblock-large transfer.

spi: spi-mem: Transform the read operation template

2026-05-04T13:02:07Z

As of now, we only use a single operation template when creating SPI memory direct mappings. With the idea to extend this possibility to 2, rename the template to reflect that we are currently setting the "primary" operation, and create a pointer in the same structure to point to it. From a user point of view, the op_tmpl name remains but becomes a pointer, leading to minor changes in both the SPI NAND and SPI NOR cores. There is no functional change. Acked-by: Mark Brown Signed-off-by: Miquel Raynal

mtd: spinand: Drop ECC dirmaps

2026-05-04T13:02:07Z

Direct mappings are very static concepts, which allow us to reuse a template to perform reads or writes in a very efficient manner after a single initialization. With the introduction of pipelined ECC engines for SPI controllers, the need to differentiate between an operation with and without correction has arised. The chosen solution at that time has been to create new direct mappings for these operations, jumping from 2 to 4 dirmaps per target. Enabling ECC was done by choosing the correct dirmap. Today, we need to further parametrize dirmaps. With the goal to enable continuous reads on a wider range of devices, we will need more flexibility regarding the read from cache operation template to pick at run time, for instance to use shorter "continuous read from cache" variants. We could create other direct mappings, but it would increase the matrix by a power of two, bringing the theoretical number of dirmaps to 8 (read/write, ecc, shorter read variants) per target. This grow is not sustainable, so let's change how dirmaps work - a little bit. Operations already carry an ECC parameter, use it to indicate whether error correction is required or not. In practice this change happens only at the core level, SPI controller drivers do not care about the direct mapping structure in this case, they just pick whatever is in the template as a base. As a result, we allow the core to dynamically change the content of the templates. He who can do more can do less, so during the checking steps, make sure to enable the ECC requirement just for the time of the checks. Signed-off-by: Miquel Raynal

mtd: spinand: Expose spinand_op_is_odtr()

2026-05-04T13:02:07Z

This helper is going to be needed in a vendor driver, so expose it. Signed-off-by: Miquel Raynal

mtd: spinand: Drop a too strong limitation

2026-05-04T13:02:06Z

Since continuous reads may sometimes not be able to go past an erase block boundary, it has been decided not to attempt longer reads and if the user request is bigger, it will be split across eraseblocks. As these request will anyway be handled correctly, there is no reason to filter out cases where we would go over a target or a die, so drop this limitation which had a side effect: any request to read more than the content of an eraseblock would simply not benefit from the continuous read feature. Signed-off-by: Miquel Raynal