From: Miquel Raynal <miquel.raynal@bootlin.com>
To: fzz <1768315307@qq.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>,
Richard Weinberger <richard@nod.at>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mtd: spinand: cache the last read page to avoid redundant SPI operations
Date: Tue, 08 Sep 2026 11:39:49 +0200 [thread overview]
Message-ID: <87bja8ulne.fsf@bootlin.com> (raw)
In-Reply-To: <tencent_4C47F17C98F6F164274CEE84638558D62308@qq.com> (fzz's message of "Tue, 8 Sep 2026 11:25:30 +0800")
Hello Zongzhen,
On 08/09/2026 at 11:25:30 +08, fzz <1768315307@qq.com> wrote:
> From: Zongzhen Feng <1768315307@qq.com>
>
> When squashfs reads files through mtdblock, the mtdblock layer
> splits I/O into 512-byte sectors. For a 4K-page SPI NAND, this
> means reading the same page 8 times (4096 / 512), generating 7x
> redundant SPI read-from-cache operations. Each such operation
> involves a full SPI bus transaction, significantly slowing down
> boot time and file access.
>
> Cache the last successfully read page in spinand_device to avoid
> these redundant operations. When the same {target, eraseblock,
> page} is requested consecutively, the data is served directly
> from the bounce buffer (databuf) via memcpy, skipping the SPI
> transaction entirely.
>
> The cache is invalidated on write and erase operations. RAW reads,
> OOB reads, and continuous reads are excluded from caching to
> maintain correctness.
>
> Signed-off-by: Zongzhen Feng <1768315307@qq.com>
Sashiko reports interesting warnings, can you please address them?
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] The page caching mechanism uses the shared bounce buffer
`spinand->databuf` to store cached data, but fails to unconditionally
invalidate the cache when this buffer is overwritten by other
operations, leading to severe cross-page data corruption.
- [Critical] Pages with uncorrectable ECC errors are prematurely cached
as valid, causing subsequent reads to bypass ECC checks and silently
return corrupted data as successful.
Thanks,
Miquèl
next prev parent reply other threads:[~2026-09-08 9:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-08 3:25 fzz
2026-09-08 9:39 ` Miquel Raynal [this message]
2026-09-08 10:28 ` Zongzhen Feng
2026-09-08 10:19 ` [PATCH v3] " Zongzhen Feng
2026-09-08 14:22 ` Miquel Raynal
2026-09-09 6:29 ` Zongzhen Feng
2026-09-10 4:08 ` [PATCH v4] " Zongzhen Feng
2026-09-10 4:26 ` sashiko-bot
2026-09-10 12:42 ` Miquel Raynal
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=87bja8ulne.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=1768315307@qq.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=vigneshr@ti.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®