mtd: spinand: Disable continuous read during probe
Subsystems (2)
PATCH v2 1/1 mtd: spinand: Disable continuous read during probe
Macronix serial NAND devices with continuous read support do not clear the configuration register on soft reset and lack a hardware reset pin. When continuous read is interrupted (e.g., during reboot), the feature remains enabled at the device level.
With continuous read enabled, the OOB area becomes inaccessible and all reads are instead directed to the main area. As a result, during partition allocation as part of MTD device registration, the first two bytes of the main area for the master block are read and indicate that the block is bad. This process repeats for every subsequent block for the partition.
All reads and writes that reference the BBT find no good blocks and fail.
The only paths for recovery from this state are triggering the continuous read feature by way of raw MTD reads or through a NAND device power drain.
Disable continuous read explicitly during spinand probe to ensure quiescent feature state.
---
Changes in V2:
- Added comments to explain why cont_read is disabled here
- Link to v1: https://lore.kernel.org/all/[email protected]/
---
Testing details:
- Instrumented feature enablement and verified fix on internal kernel v6.12.64 build with affected Macronix MX35UF4GE4AD-Z4I hardware:
warm reboot without patch marks all 2048 blocks bad during partition allocation; with patch applied, device registers cleanly with no bad blocks marked
- Patch cherry-picks cleanly to mainline v6.19-rc6 and builds without warnings
- Boot tested mainline + patch on aarch64 host without SPI interface
--- drivers/mtd/nand/spi/core.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/mtd/nand/spi/core.c +8 -0
@@ -859,6 +859,14 @@ static void spinand_cont_read_init(struct spinand_device *spinand) (engine_type == NAND_ECC_ENGINE_TYPE_ON_DIE || engine_type == NAND_ECC_ENGINE_TYPE_NONE)) { spinand->cont_read_possible = true; + +/* +* Ensure continuous read is disabled on probe. +* Some devices retain this state across soft reset, +* which leaves the OOB area inaccessible and results +* in false positive returns from spinand_isbad(). +*/ +spinand_cont_read_enable (spinand, false); } }
--
2.43.0
Quoted 65 lines · David LaPorte
[You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
Macronix serial NAND devices with continuous read support do not clear the configuration register on soft reset and lack a hardware reset pin. When continuous read is interrupted (e.g., during reboot), the feature remains enabled at the device level.
With continuous read enabled, the OOB area becomes inaccessible and all reads are instead directed to the main area. As a result, during partition allocation as part of MTD device registration, the first two bytes of the main area for the master block are read and indicate that the block is bad. This process repeats for every subsequent block for the partition.
All reads and writes that reference the BBT find no good blocks and fail.
The only paths for recovery from this state are triggering the continuous read feature by way of raw MTD reads or through a NAND device power drain.
Disable continuous read explicitly during spinand probe to ensure quiescent feature state.
Fixes 631cfdd0520d ("mtd: spi-nand: Add continuous read support")Signed-off-by David LaPorte <[email protected]>Reviewed-by Gunnar Kudrjavets <[email protected]>---
Changes in V2:
- Added comments to explain whycont_readis disabled here
- Link to v1: https://lore.kernel.org/all/[email protected]/
---
Testing details:
- Instrumented feature enablement and verified fix on internal kernel v6.12.64 build with affected Macronix MX35UF4GE4AD-Z4I hardware:
warm reboot without patch marks all 2048 blocks bad during partition allocation; with patch applied, device registers cleanly with no bad blocks marked
- Patch cherry-picks cleanly to mainline v6.19-rc6 and builds without warnings
- Boot tested mainline + patch on aarch64 host without SPI interface--- drivers/mtd/nand/spi/core.c | 8 ++++++++ 1 file changed, 8 insertions(+)drivers/mtd/nand/spi/core.c +8
-1@@ -859,6 +859,14 @@ static void spinand_cont_read_init(struct spinand_device *spinand) (engine_type == NAND_ECC_ENGINE_TYPE_ON_DIE || engine_type == NAND_ECC_ENGINE_TYPE_NONE)) { spinand->cont_read_possible = true; + +/* +* Ensure continuous read is disabled on probe. +* Some devices retain this state across soft reset, +* which leaves the OOB area inaccessible and results +* in false positive returns from spinand_isbad(). +*/ +spinand_cont_read_enable (spinand, false); } } --
Quoted 2 lines
2.43.0
LGTM,
Quoted 5 lines · David LaPorte
Macronix serial NAND devices with continuous read support do not clear the configuration register on soft reset and lack a hardware reset pin. When continuous read is interrupted (e.g., during reboot), the feature remains enabled at the device level.
Quoted 8 lines
With continuous read enabled, the OOB area becomes inaccessible and all reads are instead directed to the main area. As a result, during partition allocation as part of MTD device registration, the first two bytes of the main area for the master block are read and indicate that the block is bad. This process repeats for every subsequent block for the partition.
[...]
Applied to nand/next, thanks!
[1/1] mtd: spinand: Disable continuous read during probe
commit: d47034c840c3965cc51572d69ecf634c908e8fac
Patche(s) should be available on mtd/linux.git and will be part of the next PR (provided that no robot complains by then).
Kind regards,
Miquèl
Could you submit the same to u-boot?
Quoted 67 lines · David LaPorte
[You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
Macronix serial NAND devices with continuous read support do not clear the configuration register on soft reset and lack a hardware reset pin. When continuous read is interrupted (e.g., during reboot), the feature remains enabled at the device level.
With continuous read enabled, the OOB area becomes inaccessible and all reads are instead directed to the main area. As a result, during partition allocation as part of MTD device registration, the first two bytes of the main area for the master block are read and indicate that the block is bad. This process repeats for every subsequent block for the partition.
All reads and writes that reference the BBT find no good blocks and fail.
The only paths for recovery from this state are triggering the continuous read feature by way of raw MTD reads or through a NAND device power drain.
Disable continuous read explicitly during spinand probe to ensure quiescent feature state.
Fixes 631cfdd0520d ("mtd: spi-nand: Add continuous read support")Signed-off-by David LaPorte <[email protected]>Reviewed-by Gunnar Kudrjavets <[email protected]>---
Changes in V2:
- Added comments to explain whycont_readis disabled here
- Link to v1: https://lore.kernel.org/all/[email protected]/
---
Testing details:
- Instrumented feature enablement and verified fix on internal kernel v6.12.64 build with affected Macronix MX35UF4GE4AD-Z4I hardware:
warm reboot without patch marks all 2048 blocks bad during partition allocation; with patch applied, device registers cleanly with no bad blocks marked
- Patch cherry-picks cleanly to mainline v6.19-rc6 and builds without warnings
- Boot tested mainline + patch on aarch64 host without SPI interface--- drivers/mtd/nand/spi/core.c | 8 ++++++++ 1 file changed, 8 insertions(+)drivers/mtd/nand/spi/core.c +8
-1@@ -859,6 +859,14 @@ static void spinand_cont_read_init(struct spinand_device *spinand) (engine_type == NAND_ECC_ENGINE_TYPE_ON_DIE || engine_type == NAND_ECC_ENGINE_TYPE_NONE)) { spinand->cont_read_possible = true; + +/* +* Ensure continuous read is disabled on probe. +* Some devices retain this state across soft reset, +* which leaves the OOB area inaccessible and results +* in false positive returns from spinand_isbad(). +*/ +spinand_cont_read_enable (spinand, false); } } --2.43.0
Quoted 1 line · Mikhail Kshevetskiy
Could you submit the same to u-boot?
Yes, I'll prepare a patch for u-boot as well.
Thanks,
David