mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Orgad Shaneh <orgads@gmail.com>
To: miquel.raynal@bootlin.com, richard@nod.at, vigneshr@ti.com,
	tsbogend@alpha.franken.de
Cc: linux-mtd@lists.infradead.org, linux-mips@vger.kernel.org,
	linux-kernel@vger.kernel.org, linusw@kernel.org,
	kaloz@openwrt.org, ulli.kroll@googlemail.com, john@phrozen.org,
	nico@fluxnic.net, dwmw2@infradead.org, corbet@lwn.net,
	linux-doc@vger.kernel.org
Subject: [PATCH v3 0/3] mtd: point() for cfi_cmdset_0002, on simple maps only
Date: Sun, 11 Oct 2026 06:29:05 +0000	[thread overview]
Message-ID: <20261011062908.2365879-1-orgads@gmail.com> (raw)
In-Reply-To: <20261010172142.2138956-1-orgads@gmail.com>

jffs2 scans a flash in place through mtd_point() when the chip driver
offers it, and copies every used eraseblock through mtd_read()
otherwise. cfi_cmdset_0002 never had point(), so every jffs2 mount on
an AMD-style NOR copies the whole used area. On an Octeon CN6635 board
with a 100 MB jffs2 partition on an 8-bit M29EW that takes 15-30 s at
every boot.

1/3 tightens the existing gate first. map_is_linear() only checks for
a physical address, so cfi_cmdset_0001 already points at maps whose
own accessors swap bytes (IXP4xx), switch pins (Gemini) or lock the
bus (lantiq). The new map_is_simple() also requires the simple
accessors.

2/3 adds point()/unpoint() to cfi_cmdset_0002 behind the same gate,
modeled on cfi_cmdset_0001, and lists it in the cramfs documentation.

3/3 lets the Octeon flash map use the simple accessors when no eMMC
host shares its boot bus. Without it, 2/3 changes nothing on Octeon.
It builds without 1/3 and 2/3 but only pays off once they are in, so
taking all three through mtd with an ack from Thomas seems simplest.

Tested on that board with 7.2.9: the mount drops to 0.6-0.8 s. The
md5s of the images on the jffs2 partition held across reboots and
across ten 8 MB write/delete rounds. The series applies to v7.3-rc4
and to mtd/next.

Separately, for the MTD maintainers to judge: the write-buffer count
truncation that cfc5ebc9540e ("mtd: cfi_cmdset_0002: cap the
write-buffer chunk at 256 bytes on an x8 device") fixed in
cfi_cmdset_0002 has two siblings. do_write_buffer() in cfi_cmdset_0001
writes CMD(words) and the one in cfi_cmdset_0020 writes
CMD(len / map_bankwidth(map) - 1). On an x8 device CMD() keeps only
the low 8 bits of the count in each device lane, so a write buffer
larger than 256 bytes per device would be programmed with a truncated
count. I have no x8 Intel or ST part to test on, so I have not touched
either; I do not know whether such a part exists.

Changes in v3, from sashiko's review of v2:
- 2/3: an XIP erase (FL_XIP_WHILE_ERASING) no longer lets a point
  through either; v2 only covered FL_ERASING.
- 2/3: the changelog now states the cost of that rule: jffs2 points at
  a data node the first time it checks its CRC, so a read that meets a
  garbage-collection erase waits for that sector erase instead of
  suspending it. It also names what really blocks behind a cramfs
  point: jffs2's umount calls mtd_sync(); sync(2) does not reach the
  chip driver.
- Assisted-by in the form Documentation/process/coding-assistants.rst
  now asks for.
- Not changed: sashiko notes that 3/3 keeps the static flash_map,
  which a second probe overwrites, and leaks the mapping when
  do_map_probe() fails. Both are as in mainline today; v2 removed the
  iounmap() v1 added because, with the shared instance, it could unmap
  a registered device's window. Making the map per device would fix
  both, and I can send that separately if wanted.

Changes in v2, all from sashiko's review of v1:
- 2/3: a point no longer suspends an erase in progress. cramfs holds its
  point for the whole mount, so the erase - and the task waiting on it,
  and the reboot reset - would stay suspended until umount.
- 3/3: the bank width is checked before ioremap(), and the iounmap()
  calls v1 added are gone; flash_map is a single static instance, so
  on a second probe they could unmap what the first one registered.
- Not changed: sashiko also asked about writers sleeping
  uninterruptibly behind a long-held point. That is how
  cfi_cmdset_0001 has always behaved, and 2/3 describes the cramfs
  consequence: a cramfs mounted from /dev/mtdblockN on AMD flash
  today falls back to the block device, and after this series it
  takes the direct path, so writes to other partitions of the same
  chip wait until it is unmounted. If you would rather not change
  that, I can make point() in cfi_cmdset_0002 opt-in.

v2: https://lore.kernel.org/all/20261010180840.2152492-1-orgads@gmail.com/
v1: https://lore.kernel.org/all/20261010172142.2138956-1-orgads@gmail.com/

Orgad Shaneh (3):
  mtd: maps: only point() maps read through the simple accessors
  mtd: cfi_cmdset_0002: implement point() for simple linear maps
  MIPS: Octeon: flash: use the simple map accessors without a shared
    eMMC

 Documentation/filesystems/cramfs.rst  |  11 +-
 arch/mips/cavium-octeon/flash_setup.c |  36 +++++-
 drivers/mtd/chips/cfi_cmdset_0001.c   |   2 +-
 drivers/mtd/chips/cfi_cmdset_0002.c   | 167 +++++++++++++++++++++++++-
 drivers/mtd/maps/map_funcs.c          |  12 ++
 include/linux/mtd/map.h               |   2 +
 6 files changed, 214 insertions(+), 16 deletions(-)

-- 
2.53.0


  parent reply	other threads:[~2026-10-11  6:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-10 17:21 [PATCH " Orgad Shaneh
2026-10-10 17:21 ` [PATCH 1/3] mtd: maps: only point() maps read through the simple accessors Orgad Shaneh
2026-10-10 17:21 ` [PATCH 2/3] mtd: cfi_cmdset_0002: implement point() for simple linear maps Orgad Shaneh
2026-10-10 17:31   ` sashiko-bot
2026-10-10 17:21 ` [PATCH 3/3] MIPS: Octeon: flash: use the simple map accessors without a shared eMMC Orgad Shaneh
2026-10-10 17:32   ` sashiko-bot
2026-10-10 18:08 ` [PATCH v2 0/3] mtd: point() for cfi_cmdset_0002, on simple maps only Orgad Shaneh
2026-10-10 18:08   ` [PATCH v2 1/3] mtd: maps: only point() maps read through the simple accessors Orgad Shaneh
2026-10-10 18:08   ` [PATCH v2 2/3] mtd: cfi_cmdset_0002: implement point() for simple linear maps Orgad Shaneh
2026-10-10 18:18     ` sashiko-bot
2026-10-10 18:08   ` [PATCH v2 3/3] MIPS: Octeon: flash: use the simple map accessors without a shared eMMC Orgad Shaneh
2026-10-10 18:18     ` sashiko-bot
2026-10-11  6:29 ` Orgad Shaneh [this message]
2026-10-11  6:29   ` [PATCH v3 1/3] mtd: maps: only point() maps read through the simple accessors Orgad Shaneh
2026-10-11  6:29   ` [PATCH v3 2/3] mtd: cfi_cmdset_0002: implement point() for simple linear maps Orgad Shaneh
2026-10-11  6:29   ` [PATCH v3 3/3] MIPS: Octeon: flash: use the simple map accessors without a shared eMMC Orgad Shaneh
2026-10-11  6:39     ` sashiko-bot

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=20261011062908.2365879-1-orgads@gmail.com \
    --to=orgads@gmail.com \
    --cc=corbet@lwn.net \
    --cc=dwmw2@infradead.org \
    --cc=john@phrozen.org \
    --cc=kaloz@openwrt.org \
    --cc=linusw@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=nico@fluxnic.net \
    --cc=richard@nod.at \
    --cc=tsbogend@alpha.franken.de \
    --cc=ulli.kroll@googlemail.com \
    --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®