From: Miquel Raynal <miquel.raynal@bootlin.com>
To: wang wei <a929244872@163.com>
Cc: richard@nod.at, vigneshr@ti.com, bbrezillon@kernel.org,
yamada.masahiro@socionext.com, wenyou.yang@microchip.com,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers/mtd: rawnand: nandsim: Fix stale NAND_ROW_ADDR_3 with overridesize
Date: Thu, 01 Oct 2026 12:54:28 +0200 [thread overview]
Message-ID: <875wzlofmj.fsf@bootlin.com> (raw)
In-Reply-To: <20261001103359.20216-1-a929244872@163.com> (wang wei's message of "Thu, 1 Oct 2026 18:33:59 +0800")
Hi Wang,
On 01/10/2026 at 18:33:59 +08, wang wei <a929244872@163.com> wrote:
> The overridesize module parameter changes the size of the simulated
> device after nand_scan() has completed. It updates nsmtd->size,
> memorg->eraseblocks_per_lun, chip->chip_shift and chip->pagemask to
> match the new geometry, but leaves the NAND_ROW_ADDR_3 option
> untouched, even though nand_scan_ident() set it from the geometry
> decoded out of the ID bytes.
>
> When the ID bytes describe a device larger than 128 MiB and
> overridesize shrinks the simulation to 128 MiB or less, the stale
> option makes the core emit one extra row address byte (page >> 16,
> always zero given the reduced page count) in every read, program and
> erase operation, while the simulator state machine expects one byte
> less. All accesses then fail with:
>
> nandsim: error: write_byte: address (0x0) isn't expected, expected
> state is STATE_CMD_READSTART, switch to STATE_READY
>
> The opposite direction is equally broken: growing a small device past
> 128 MiB keeps NAND_ROW_ADDR_3 cleared, so the third row address byte
> is dropped and the wrong pages are silently addressed.
Fine until here.
> This used to work before commit 14157f861437 ("mtd: nand: introduce
> NAND_ROW_ADDR_3 flag"). Back then nandsim kept chip->chipsize in sync
,
> with the override, and nand_command_lp() decided at run time, per
> command, whether the third row address cycle was needed by testing
> chip->chipsize against 128 MiB. The decision thus always saw the
"The decision"?
> overridden size. The above commit moved the decision to
> nand_scan_ident(), which encodes it once into NAND_ROW_ADDR_3 at
> scan time -- before nandsim applies the override -- and the
> overridesize path was never taught to re-evaluate the flag. The
> commit that introduced the regression is:
>
> https://git.kernel.org/torvalds/c/14157f861437ebe2d624b0a845b91bbdf8ca9a2d
This is not needed, you mention it above and below already.
> Re-evaluate NAND_ROW_ADDR_3 right after overriding chip_shift, using
> the same test as nand_scan_ident(), so that the address width emitted
> by the core always matches ns->geom.pgaddrbytes, which ns_init()
> derives from the overridden total size.
>
> Fixes: 14157f861437 ("mtd: nand: introduce NAND_ROW_ADDR_3 flag")
Cc: stable
> Signed-off-by: wang wei <a929244872@163.com>
> ---
> drivers/mtd/nand/raw/nandsim.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/nandsim.c b/drivers/mtd/nand/raw/nandsim.c
> index fe96803..176db89 100644
> --- a/drivers/mtd/nand/raw/nandsim.c
> +++ b/drivers/mtd/nand/raw/nandsim.c
> @@ -2359,6 +2359,18 @@ static int __init ns_init_module(void)
> targetsize = nanddev_target_size(&chip->base);
> chip->chip_shift = ffs(nsmtd->erasesize) + overridesize - 1;
> chip->pagemask = (targetsize >> chip->page_shift) - 1;
> +
> + /*
> + * NAND_ROW_ADDR_3 was set by nand_scan_ident() from the
> + * geometry decoded out of the ID bytes, which the size
> + * override has just made stale. Re-evaluate it against
> + * the new geometry, otherwise the core emits one more (or
> + * one less) row address byte than the simulator expects.
> + */
Everything above this line can just be deleted. Tell your LLM that this
is obvious enough and does not require any particular comment.
> + if (chip->chip_shift - chip->page_shift > 16)
> + chip->options |= NAND_ROW_ADDR_3;
> + else
> + chip->options &= ~NAND_ROW_ADDR_3;
> }
>
> ret = ns_setup_wear_reporting(nsmtd);
Instead of repeating the operation in nandsim, why not calling
nand_scan() after over writing the size? (inverting the two blocks)
Thanks,
Miquèl
next prev parent reply other threads:[~2026-10-01 10:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 10:33 wang wei
2026-10-01 10:54 ` Miquel Raynal [this message]
[not found] ` <eeef96a.1a8e.1a0f74ef8cf.Coremail.a929244872@163.com>
2026-10-01 12:34 ` Miquel Raynal
2026-10-01 12:36 ` wang wei
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=875wzlofmj.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=a929244872@163.com \
--cc=bbrezillon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=vigneshr@ti.com \
--cc=wenyou.yang@microchip.com \
--cc=yamada.masahiro@socionext.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®