From: Mehmet Fide <mehmet.fide@gmail.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Stefan Agner <stefan@agner.ch>,
Vignesh Raghavendra <vigneshr@ti.com>,
Boris Brezillon <bbrezillon@kernel.org>,
Frieder Schrempf <frieder.schrempf@kontron.de>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
Mehmet Fide <mehmet.fide@screeningeagle.com>
Subject: [PATCH v3 0/2] mtd: rawnand: vf610_nfc: fix reads on chips with more than 64 bytes of OOB
Date: Tue, 1 Sep 2026 09:39:05 +0200 [thread overview]
Message-ID: <20260901073907.2443698-1-mehmet.fide@gmail.com> (raw)
From: Mehmet Fide <mehmet.fide@screeningeagle.com>
The driver only implements the 64-byte OOB format the controller
transfers, so chips with a larger OOB (the Colibri VF61's MX30LF4G28AC
has 112 bytes) stopped working when nanddev_init() began restoring
mtd->oobsize after ->attach_chip(): the parity moved and every
ECC-protected read failed, including the BBT and everything UBI needs.
The detected OOB size stays, the driver gets its own mtd_ooblayout_ops
computed on the first 64 OOB bytes, and the data paths keep
transferring exactly those 64 spare bytes, so the on-flash format stays
identical to U-Boot and to the kernels that clamped.
v3 addresses Miquel's review and the confirmed finding from the Sashiko
report: ECC page reads now fill the tail of oob_poi with 0xff, since
mtd->oobsize bytes of it may reach userspace while only 64 are
transferred. Retested on both boards. Colibri VF61 (112 bytes of OOB):
BBT found and read clean, UBI attaches and the UBIFS root mounts, 8 MiB
write/read-back intact, and OOB reads return 0xff in the 48 bytes past
the transferred area on every page sampled (6000+ pages, written and
erased). Colibri VF50 (64-byte chip, tail fill is a no-op): layout
unchanged, corrected counter stays zero across a full dump.
v2: https://lore.kernel.org/linux-mtd/20260828085337.3916199-1-mehmet.fide@gmail.com/
v1: https://lore.kernel.org/linux-mtd/20260818114208.2780311-1-mehmet.fide@gmail.com/
Mehmet Fide (2):
mtd: rawnand: vf610_nfc: fix reads on chips with more than 64 bytes of
OOB
mtd: rawnand: vf610_nfc: fix false bitflips on reads of erased pages
drivers/mtd/nand/raw/vf610_nfc.c | 85 ++++++++++++++++++++++++++------
1 file changed, 70 insertions(+), 15 deletions(-)
--
2.54.0
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next reply other threads:[~2026-09-01 7:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 7:39 Mehmet Fide [this message]
2026-09-01 7:39 ` [PATCH v3 1/2] mtd: rawnand: vf610_nfc: fix reads on chips with more than 64 bytes of OOB Mehmet Fide
2026-09-01 7:39 ` [PATCH v3 2/2] mtd: rawnand: vf610_nfc: fix false bitflips on reads of erased pages Mehmet Fide
2026-09-04 17:38 ` [PATCH v3 0/2] mtd: rawnand: vf610_nfc: fix reads on chips with more than 64 bytes of OOB Miquel Raynal
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=20260901073907.2443698-1-mehmet.fide@gmail.com \
--to=mehmet.fide@gmail.com \
--cc=bbrezillon@kernel.org \
--cc=frieder.schrempf@kontron.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=mehmet.fide@screeningeagle.com \
--cc=miquel.raynal@bootlin.com \
--cc=stefan@agner.ch \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.