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 14:34:33 +0200 [thread overview]
Message-ID: <87zewxmwfa.fsf@bootlin.com> (raw)
In-Reply-To: <eeef96a.1a8e.1a0f74ef8cf.Coremail.a929244872@163.com> (wang wei's message of "Thu, 1 Oct 2026 19:52:22 +0800 (CST)")
>>> + 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)
>
> The override cannot be moved before nand_scan(): In nand_detect(),
> chip ->chipushift will be set to the actual flash size. In addition,
> In addition, expressed in erase blocks (new_size = nsmtd->erasesize << overridesize)
> and erasesize is what nand_scan_ident() decodes from the ID bytes, so
> the override has a hard data dependency on the scan.
Ok, fine then.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2026-10-01 12:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 10:33 [PATCH] drivers/mtd: rawnand: nandsim: Fix stale NAND_ROW_ADDR_3 with overridesize wang wei
2026-10-01 10:54 ` Miquel Raynal
[not found] ` <eeef96a.1a8e.1a0f74ef8cf.Coremail.a929244872@163.com>
2026-10-01 12:34 ` Miquel Raynal [this message]
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=87zewxmwfa.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.