Re: [PATCH v5 10/18] mtd: rawnand: sunxi: bound DMA batches by the user-data register bank
From: sashiko-bot@kernel.org
Date: 2026-09-14 03:19:37
Also in:
linux-sunxi
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] DMA batching breaks because the hardware's internal chunk counter resets for each batch, causing it to generate incorrect flash column addresses for main data chunks after the first in subsequent batches.
--
commit fcea2b1acac181df9bb3db6577c776b8c30250b9
Author: James Hilliard [off-list ref]
mtd: rawnand: sunxi: bound DMA batches by the user-data register bank
This commit splits DMA transfers into batches whose aggregate user data
fits the hardware's user-data register bank. It reuses hardware slots
from zero in each batch while maintaining logical offsets.
Fixes: 54dcd6aa69db ("mtd: rawnand: sunxi: introduce maximize variable user data length")
quoted hunk ↗ jump to hunk
diff --git a/drivers/mtd/nand/raw/sunxi_nand.c b/drivers/mtd/nand/raw/sunxi_nand.c index e29638c828caf..fbea6f16ea9d7 100644 --- a/drivers/mtd/nand/raw/sunxi_nand.c +++ b/drivers/mtd/nand/raw/sunxi_nand.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -1761,69 +1776,88 @@ static int sunxi_nfc_hw_ecc_write_page_dma(struct nand_chip *nand,
[ ... ]
- writel(NFC_PAGE_OP | NFC_DATA_SWAP_METHOD | - NFC_DATA_TRANS | NFC_ACCESS_DIR, - nfc->regs + NFC_REG_CMD); + writel(NFC_PAGE_OP | NFC_DATA_SWAP_METHOD | + NFC_DATA_TRANS | NFC_ACCESS_DIR, + nfc->regs + NFC_REG_CMD);
[Severity: High] Does this batching approach cause a regression where the controller's autonomous state machine generates incorrect flash column addresses? When a page is split into multiple DMA batches, both sunxi_nfc_hw_ecc_read_batch_dma() and sunxi_nfc_hw_ecc_write_page_dma() iterate over the batches with first_step > 0. Because the hardware is reprogrammed for each batch, it appears the controller's internal chunk counter resets to 0. While the first chunk of a batch is read or written correctly due to the manual column change beforehand, won't the NFC_PAGE_OP state machine automatically issue a 0x05/0x85 column change to jump back to main data for the second chunk of the batch? If the internal counter is reset, would the hardware calculate the return column address as 1 * ecc_size instead of (first_step + 1) * ecc_size? Could this cause the controller to read or write over the wrong flash offsets for all chunks after the first in subsequent batches, leading to data corruption? -- Sashiko AI review · https://sashiko.dev/#/patchset/20260913-submit-sunxi-nand-vendor-oob-layout-v1-v5-0-7d711076a6f7@gmail.com?part=10