kernel/include/linux/mtd/spinand.h, branch linux-6.16.y

mtd: spinand: winbond: Enable high-speed modes on w25n0xjw

2025-09-19T14:37:33Z

[ Upstream commit f1a91175faaab02a45d1ceb313a315a5bfeb5416 ] w25n0xjw chips have a high-speed capability hidden in a configuration register. Once enabled, dual/quad SDR reads may be performed at a much higher frequency. Implement the new ->configure_chip() hook for this purpose and configure the SR4 register accordingly. Signed-off-by: Miquel Raynal Stable-dep-of: 4550d33e1811 ("mtd: spinand: winbond: Fix oob_layout for W25N01JW") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

mtd: spinand: Add a ->configure_chip() hook

2025-09-19T14:37:33Z

[ Upstream commit da55809ebb45d1d80b7a388ffef841ed683e1a6f ] There is already a manufacturer hook, which is manufacturer specific but not chip specific. We no longer have access to the actual NAND identity at this stage so let's add a per-chip configuration hook to align the chip configuration (if any) with the core's setting. Signed-off-by: Miquel Raynal Stable-dep-of: 4550d33e1811 ("mtd: spinand: winbond: Fix oob_layout for W25N01JW") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants

2025-06-18T09:18:45Z

Dual and quad capable chips natively support dual and quad I/O variants at up to 104MHz (1-2-2 and 1-4-4 operations). Reaching the maximum speed of 166MHz is theoretically possible (while still unsupported in the field) by adding a few more dummy cycles. Let's be accurate and clearly state this limit. Setting a maximum frequency implies adding the frequency parameter to the macro, which is done using a variadic argument to avoid impacting all the other drivers which already make use of this macro. Fixes: 1ea808b4d15b ("mtd: spinand: winbond: Update the *JW chip definitions") Signed-off-by: Miquel Raynal

mtd: spinand: Define octal operations

2025-04-29T09:05:34Z

SPI NAND chips may support octal "read from cache" and "program load" transfers. List the opcodes by defining the relevant macros describing these operations. However, due to the hardware available I had, 0x82 and 0xc2 are untested and given as reference, only 0xc4 could be (successfully) tested. Controllers supporting operations mixing SDR and DTR operations might even leverage octal DTR data I/O transfers. Acked-by: Tudor Ambarus Signed-off-by: Miquel Raynal

mtd: spinand: Use more specific naming for the (quad) program load op

2025-04-29T09:05:34Z

SPI operations have been initially described through macros implicitly implying the use of a single SPI SDR bus. Macros for supporting dual and quad I/O transfers have been added on top, generally inspired by vendor naming, followed by DTR operations. Soon we might see octal and even octal DTR operations as well (including the opcode byte). Let's clarify what the macro really means by describing the expected bus topology in the (quad) program load macro name. While at modifying it, better add the missing_ OP suffix to align with all the other macros of the same kind. Acked-by: Tudor Ambarus Signed-off-by: Miquel Raynal

mtd: spinand: Use more specific naming for the (single) program load op

2025-04-29T09:05:34Z

SPI operations have been initially described through macros implicitly implying the use of a single SPI SDR bus. Macros for supporting dual and quad I/O transfers have been added on top, generally inspired by vendor naming, followed by DTR operations. Soon we might see octal and even octal DTR operations as well (including the opcode byte). Let's clarify what the macro really means by describing the expected bus topology in the (single) program load macro name. While at modifying it, better add the missing_ OP suffix to align with all the other macros of the same kind. Acked-by: Tudor Ambarus Signed-off-by: Miquel Raynal

mtd: spinand: Use more specific naming for the program execution op

2025-04-29T09:05:34Z

SPI operations have been initially described through macros implicitly implying the use of a single SPI SDR bus. Macros for supporting dual and quad I/O transfers have been added on top, generally inspired by vendor naming, followed by DTR operations. Soon we might see octal and even octal DTR operations as well (including the opcode byte). Let's clarify what the macro really means by describing the expected bus topology in the program execution macro name. Acked-by: Tudor Ambarus [Miquel: Fixed conflicts with -next by updating esmt and micron drivers] Signed-off-by: Miquel Raynal

mtd: spinand: Use more specific naming for the (quad IO) read from cache ops

2025-04-29T09:05:34Z

SPI operations have been initially described through macros implicitly implying the use of a single SPI SDR bus. Macros for supporting dual and quad I/O transfers have been added on top, generally inspired by vendor naming, followed by DTR operations. Soon we might see octal and even octal DTR operations as well (including the opcode byte). Let's clarify what the macro really mean by describing the expected bus topology in the (quad IO) read from cache macro names. Acked-by: Tudor Ambarus Signed-off-by: Miquel Raynal

mtd: spinand: Use more specific naming for the (quad output) read from cache ops

2025-04-29T09:05:34Z

SPI operations have been initially described through macros implicitly implying the use of a single SPI SDR bus. Macros for supporting dual and quad I/O transfers have been added on top, generally inspired by vendor naming, followed by DTR operations. Soon we might see octal and even octal DTR operations as well (including the opcode byte). Let's clarify what the macro really mean by describing the expected bus topology in the (quad output) read from cache macro names. Acked-by: Tudor Ambarus Signed-off-by: Miquel Raynal

mtd: spinand: Use more specific naming for the (dual IO) read from cache ops

2025-04-29T09:05:34Z

SPI operations have been initially described through macros implicitly implying the use of a single SPI SDR bus. Macros for supporting dual and quad I/O transfers have been added on top, generally inspired by vendor naming, followed by DTR operations. Soon we might see octal and even octal DTR operations as well (including the opcode byte). Let's clarify what the macro really mean by describing the expected bus topology in the (dual IO) read from cache macro names. While at modifying them, better reordering the macros to group them all by bus topology which now feels more intuitive. Acked-by: Tudor Ambarus Signed-off-by: Miquel Raynal