From: James Hilliard <james.hilliard1@gmail.com>
To: "Miquel Raynal" <miquel.raynal@bootlin.com>,
"Richard Weinberger" <richard@nod.at>,
"Vignesh Raghavendra" <vigneshr@ti.com>,
"Michał Kępień" <kernel@kempniu.pl>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
James Hilliard <james.hilliard1@gmail.com>,
stable@vger.kernel.org
Subject: [PATCH v2 0/4] mtdchar: keep data and OOB aligned across ioctl chunks
Date: Sun, 08 Nov 2026 16:49:11 -0700 [thread overview]
Message-ID: <20261108-submit-mtdchar-page-chunking-v1-v2-0-838cf8934ba6@gmail.com> (raw)
MEMREAD and MEMWRITE split requests into bounded data and OOB buffers.
Their chunk lengths and flash-address updates must keep both streams
associated with the same pages.
An intermediate read can consume OOB from pages beyond its data chunk.
OOB-only requests do not advance the flash address between chunks, while
a buffer ending within a page's OOB can leave the next operation starting
at the wrong page. When the OOB buffer is the limiting factor, the data
chunk must stop at the same page boundary.
The OOB-limited case was found while testing a proposed BootROM-format
MTD view with 1024 data bytes and 1152 OOB bytes per page. A 64-page
request has 65536 data bytes and 73728 OOB bytes, but the original
65536-byte buffer limit lets the first operation consume all the data
while transferring only part of the OOB.
First simplify the page-capacity calculation, then bound OOB in
intermediate reads to their data pages. Keep non-final OOB chunks
page-aligned and limit their accompanying data. Finish any remaining OOB
as OOB-only operations once the data is exhausted, including when the
last data fragment ends partway through a page. Advance by the pages
consumed by either stream and limit OOB-only writes to one page per call
for raw NAND.
Assisted-by: Codex:gpt-6-astra
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
---
Changes in v2:
- Add a fourth patch to finish requests whose OOB extends past the data,
following Sashiko's review of patch 3.
- Switch to OOB-only operations once the data runs out, including when
the original non-NULL data buffer has zero remaining length.
- Advance beyond the final data page when OOB was consumed there, and
keep raw-NAND OOB-only writes to one page per backend operation.
- Link to v1: https://patch.msgid.link/20261106-submit-mtdchar-page-chunking-v1-v1-0-2973a03531bc@gmail.com
To: Miquel Raynal <miquel.raynal@bootlin.com>
To: Richard Weinberger <richard@nod.at>
To: Vignesh Raghavendra <vigneshr@ti.com>
To: Michał Kępień <kernel@kempniu.pl>
Cc: linux-mtd@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
James Hilliard (4):
mtdchar: calculate OOB capacity from the starting column
mtdchar: bound OOB reads to the data in intermediate chunks
mtdchar: keep OOB chunks aligned with their data pages
mtdchar: finish OOB transfers after the data runs out
drivers/mtd/mtdchar.c | 82 +++++++++++++++++++++++++++++++++++++++++----------
1 file changed, 67 insertions(+), 15 deletions(-)
---
base-commit: 1c1a342aceec79528b3ba51f376eca2be5928fe7
change-id: 20261106-submit-mtdchar-page-chunking-v1-668636b0becd
Best regards,
--
James Hilliard <james.hilliard1@gmail.com>
next reply other threads:[~2026-11-08 23:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-08 23:49 James Hilliard [this message]
2026-11-08 23:49 ` [PATCH v2 1/4] mtdchar: calculate OOB capacity from the starting column James Hilliard
2026-11-08 23:49 ` [PATCH v2 2/4] mtdchar: bound OOB reads to the data in intermediate chunks James Hilliard
2026-11-08 23:49 ` [PATCH v2 3/4] mtdchar: keep OOB chunks aligned with their data pages James Hilliard
2026-11-08 23:49 ` [PATCH v2 4/4] mtdchar: finish OOB transfers after the data runs out James Hilliard
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=20261108-submit-mtdchar-page-chunking-v1-v2-0-838cf8934ba6@gmail.com \
--to=james.hilliard1@gmail.com \
--cc=kernel@kempniu.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
--cc=stable@vger.kernel.org \
--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®