[PATCH 0/2] mtd: rawnand: vf610_nfc: two fixes for chips with large OOB and for erased pages
Mehmet Fide <[email protected]>
| Newsgroups | gmane.linux.kernel,gmane.linux.drivers.mtd |
|---|---|
| Message-ID | <[email protected]> |
From: Mehmet Fide <[email protected]> Two independent fixes for the Vybrid NAND flash controller, both found while bringing a Colibri VF61 up on mainline and both verified on hardware. Patch 1 is a regression. The driver clamps mtd->oobsize to the 64 bytes its ECC layout uses, but since commit a7ab085d7c16 ("mtd: rawnand: Initialize the nand_device object") nand_scan_tail() restores the value from the memory organization right after ->attach_chip(), so the clamp is silently lost. On a chip with more than 64 bytes of OOB every ECC-protected read then fails and the board does not boot. Clamping the memory organization as well is what the rest of the tree does when a driver has to change the OOB size (nand_samsung.c, nand_onfi.c, nand_jedec.c and denali.c all write memorg->oobsize); mpc5121_nfc.c touches mtd->oobsize directly but does so before nand_scan(), so it is not affected. Doing this in ->attach_chip() is deliberate: the chip really does have 112 spare bytes, it is this controller that can only use 64, and ->attach_chip() is where a controller adapts to the detected chip. The patch also touches the memory organization because nanddev_init(), which runs later in nand_scan_tail(), re-derives mtd->{erasesize, writesize, writebufsize, oobsize, size} from it, so an adjustment made only in mtd does not survive. If you would rather have the core preserve what ->attach_chip() set up, or a dedicated way for a driver to declare that it uses fewer OOB bytes than the chip provides, I am happy to respin; I went with the minimal form because this is a regression fix that should be backportable. Patch 2 makes the erased-page check look at the flash instead of at the controller buffer. When the ECC engine fails to decode a page it leaves a bogus single-bit "correction" in that buffer, which the check counts as a real bitflip; on the 60-byte ECC mode every erased page is reported with one corrected bitflip, which renders the MTD statistics useless for flash health monitoring. Testing, all booting from NAND on an Iris carrier with Linux 6.18.44 and U-Boot 2026.07: 0010 Colibri VF50 128MB V1.2A Macronix MX30LF1G08AA, 64-byte OOB 0013 Colibri VF50 128MB IT V1.2B Macronix MX30LF1G18AC, 64-byte OOB 0012 Colibri VF61 256MB IT V1.2B Macronix MX30LF4G28AC, 112-byte OOB Without patch 1 the VF61 cannot attach UBI at all. With the series all three boot, mtd oobsize stays 64, the bad block table written by an older kernel reads back without ECC errors and the corrected-bitflip counter stays at zero over a full-partition nanddump. The clamp only triggers on the VF61 chip, so both patches are a no-op on the two VF50 revisions, which is what I wanted to confirm before sending them. The credit for spotting both problems goes to Edward Karpicz, who reported them on the Toradex community forum. 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 | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) base-commit: 15a3cbce32994141252bb4ecfe3ff3a5d22d0b4f -- 2.54.0