[v7,06/16] mtd: rawnand: sunxi: select the pattern ID for the current ECC step

Message ID 20261014-submit-sunxi-nand-vendor-oob-layout-v1-v7-6-5d3fc6ad2da1@gmail.com (mailing list archive)
State New
Headers
Series mtd: rawnand: sunxi: fix transfers and support randomized OOB |

Commit Message

James Hilliard Oct. 15, 2026, 1:33 a.m. UTC
ECC exception mode recognizes physical all-zero and all-ones data
blocks. For each hardware ECC step, a pattern-found bit says whether
this happened and the corresponding pattern-ID bit distinguishes zero
from 0xff. The correction helper checks the current step's pattern-found
bit but always reads pattern-ID bit zero.

PIO processes one step at a time in hardware slot zero, so it is
unaffected. DMA processes several steps at once. For example, if step
one is all 0xff but pattern-ID bit zero is clear, the helper treats step
one as all zero. On scrambled DMA reads it fills that step's main data
with zeros and reports success. Requested OOB is also filled using the
wrong pattern. Conversely, a zero step can be classified as erased when
bit zero is set.

Test BIT(step) in the pattern-ID register, matching the error and
pattern-found bits already selected for that hardware step.

Fixes: 614049a8d904 ("mtd: nand: sunxi: add support for DMA assisted operations")
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
---
 drivers/mtd/nand/raw/sunxi_nand.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

Comments

sashiko-bot@kernel.org Oct. 15, 2026, 1:50 a.m. UTC | #1
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] mtd: rawnand: sunxi: PIO mode overwrites zero pattern with SRAM garbage
--

commit 6c354ef3bc88ac95cdf40b092e5c146de75aa789
Author: James Hilliard <james.hilliard1@gmail.com>
Subject: mtd: rawnand: sunxi: select the pattern ID for the current ECC step

This commit fixes the pattern-ID register check during ECC exception mode.
It updates the correction helper to test the bit corresponding to the
current hardware step rather than always checking bit zero, which ensures
DMA processing classifies physical all-zero and all-ones data blocks
correctly.

> diff --git a/drivers/mtd/nand/raw/sunxi_nand.c b/drivers/mtd/nand/raw/sunxi_nand.c
> index 57df88099206a..8256982d1d565 100644
> --- a/drivers/mtd/nand/raw/sunxi_nand.c
> +++ b/drivers/mtd/nand/raw/sunxi_nand.c
> @@ -1101,7 +1101,7 @@ static int sunxi_nfc_hw_ecc_correct(struct nand_chip *nand, u8 *data, u8 *oob,
>  	if (pattern_found & BIT(step)) {
>  		u8 pattern;
>  
> -		if (unlikely(!(readl(nfc->regs + NFC_REG_PAT_ID(nfc)) & 0x1))) {
> +		if (unlikely(!(readl(nfc->regs + NFC_REG_PAT_ID(nfc)) & BIT(step)))) {
>  			pattern = 0x0;

[Severity: Medium]
When the pattern is identified as 0x0, the *erased out parameter remains
false. Later in sunxi_nfc_oob_read_batch(), the code checks this boolean
and handles PIO mode (!read->dma) by copying directly from SRAM:

sunxi_nfc_oob_read_batch() {
    ...
    if (erased) {
        read->has_erased_chunk = true;
        continue;
    }

    if (!read->dma)
        memcpy_fromio(data, nfc->regs + NFC_RAM0_BASE, ecc->size);
    ...
}

If scrambling is enabled for a physical all-zero block read in PIO mode,
will this memcpy_fromio() overwrite the valid zeros populated in
sunxi_nfc_hw_ecc_correct() with descrambled pseudo-random garbage from
the SRAM?

It appears this regression leaves PIO broken while fixing DMA zero
pattern reads.

>  		} else {
>  			pattern = 0xff;
  

Patch

diff --git a/drivers/mtd/nand/raw/sunxi_nand.c b/drivers/mtd/nand/raw/sunxi_nand.c
index 57df88099206..8256982d1d56 100644
--- a/drivers/mtd/nand/raw/sunxi_nand.c
+++ b/drivers/mtd/nand/raw/sunxi_nand.c
@@ -1101,7 +1101,7 @@  static int sunxi_nfc_hw_ecc_correct(struct nand_chip *nand, u8 *data, u8 *oob,
 	if (pattern_found & BIT(step)) {
 		u8 pattern;
 
-		if (unlikely(!(readl(nfc->regs + NFC_REG_PAT_ID(nfc)) & 0x1))) {
+		if (unlikely(!(readl(nfc->regs + NFC_REG_PAT_ID(nfc)) & BIT(step)))) {
 			pattern = 0x0;
 		} else {
 			pattern = 0xff;