Re: [PATCH v5 10/18] mtd: rawnand: sunxi: bound DMA batches by the user-data register bank

[sashiko-bot@kernel.org]

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 <james.hilliard1@gmail.com>

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")

> 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
[ ... ]
> @@ -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