From: David LaPorte <dalaport@amazon.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Tudor Ambarus <tudor.ambarus@linaro.org>,
Martin Kurbanov <mmkurbanov@salutedevices.com>,
Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>,
Cheng Ming Lin <chengminglin@mxic.com.tw>,
Pratyush Yadav <pratyush@kernel.org>,
<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>
Cc: David LaPorte <dalaport@amazon.com>,
Gunnar Kudrjavets <gunnarku@amazon.com>
Subject: [PATCH v2] mtd: spinand: Disable continuous read during probe
Date: Thu, 29 Jan 2026 17:33:22 -0800 [thread overview]
Message-ID: <20260130013334.72135-1-dalaport@amazon.com> (raw)
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 <dalaport@amazon.com>
Reviewed-by: Gunnar Kudrjavets <gunnarku@amazon.com>
---
Changes in V2:
- Added comments to explain why cont_read is disabled here
- Link to v1: https://lore.kernel.org/all/20260129221606.35158-1-dalaport@amazon.com/
---
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(+)
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index d207286572d8..9540fd04156c 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -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
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next reply other threads:[~2026-01-30 1:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-30 1:33 David LaPorte [this message]
2026-01-30 4:20 ` [PATCH v2] mtd: spinand: Disable continuous read during probe Mikhail Kshevetskiy
2026-01-30 14:20 ` Miquel Raynal
2026-01-30 14:21 ` Mikhail Kshevetskiy
2026-02-03 1:16 ` David LaPorte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260130013334.72135-1-dalaport@amazon.com \
--to=dalaport@amazon.com \
--cc=chengminglin@mxic.com.tw \
--cc=gunnarku@amazon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=mikhail.kshevetskiy@iopsys.eu \
--cc=miquel.raynal@bootlin.com \
--cc=mmkurbanov@salutedevices.com \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=tudor.ambarus@linaro.org \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox