mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH v2 0/4] mtdchar: keep data and OOB aligned across ioctl chunks
@ 2026-11-08 23:49 James Hilliard
  2026-11-08 23:49 ` [PATCH v2 1/4] mtdchar: calculate OOB capacity from the starting column James Hilliard
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: James Hilliard @ 2026-11-08 23:49 UTC (permalink / raw)
  To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
	Michał Kępień
  Cc: linux-mtd, linux-kernel, James Hilliard, stable

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>


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2026-11-08 23:49 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-11-08 23:49 [PATCH v2 0/4] mtdchar: keep data and OOB aligned across ioctl chunks James Hilliard
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

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®