From: Orgad Shaneh <orgads@gmail.com>
To: miquel.raynal@bootlin.com, richard@nod.at, vigneshr@ti.com
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: [PATCH v2] mtd: cfi_cmdset_0002: cap the write-buffer chunk at 256 bytes on an x8 device
Date: Tue, 15 Sep 2026 07:50:03 +0000 [thread overview]
Message-ID: <20260915075028.21658-1-orgads@gmail.com> (raw)
In-Reply-To: <20260915071339.15172-1-orgads@gmail.com>
The word count of the Write to Buffer command is a single bus word per
device, so an x8 device can be told to program at most 256 bytes
regardless of the buffer size it advertises.
A Micron M29EW (an x16 part wired in x8 mode) advertises a 512-byte
write buffer. cfi_amdstd_write_buffers() used the full 512, CMD(511)
truncated the count to 0xff on the way out, and the chip aborted the
program on the 257th data byte. Every full-size chunk failed while the
partial ones at the start of a write went through:
MTD do_write_buffer_wait(): software timeout, address:0x03278bff.
jffs2: Write of 4164 bytes at 0x02c789b4 failed. returned -5, retlen 68
jffs2: No space for garbage collection. Aborting GC thread
Clamp MaxBufWriteSize in the write-buffer fixup for x8 devices, and keep
mtd->writebufsize (computed before the fixups run) consistent with it.
The bug predates the git history, so there is no Fixes: tag.
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Signed-off-by: Orgad Shaneh <orgads@gmail.com>
---
v2: test the device width (cfi->device_type) instead of the aggregate bus
width. map_bankwidth_is_1() is false for x8 devices interleaved on a
wider bus, which have the same 256-byte ceiling: do_write_buffer()
sends CMD(words - 1), and CMD() replicates that count into each
device's lane, where it is truncated to 8 bits - so two x8 chips with
a 512-byte buffer are told 255 words and are still sent 512 bytes
each. device_type is also immune to map_bankwidth_is_1() compiling to
a constant 0 when CONFIG_MTD_MAP_BANK_WIDTH_1 is off. Caught by the
Sashiko review bot.
diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -283,6 +283,21 @@ static void fixup_use_write_buffers(struct mtd_info *mtd)
pr_debug("Using buffer write method\n");
mtd->_write = cfi_amdstd_write_buffers;
}
+
+ /*
+ * The word count of the Write to Buffer command is a single bus
+ * word per device, so an x8 device can be told to program at most
+ * 256 bytes however large a buffer it advertises - including when
+ * several of them are interleaved on a wider bus, where CMD()
+ * replicates the count into each device's lane and it is truncated
+ * there.
+ */
+ if (cfi->device_type == CFI_DEVICETYPE_X8 &&
+ cfi->cfiq->MaxBufWriteSize > 8) {
+ cfi->cfiq->MaxBufWriteSize = 8;
+ mtd->writebufsize = cfi_interleave(cfi) <<
+ cfi->cfiq->MaxBufWriteSize;
+ }
}
#endif /* !FORCE_WORD_WRITE */
--
2.47.0
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2026-09-15 7:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 7:13 [PATCH] mtd: cfi_cmdset_0002: cap the write-buffer chunk at 256 bytes on an 8-bit bus Orgad Shaneh
2026-09-15 7:30 ` sashiko-bot
2026-09-15 7:50 ` Orgad Shaneh [this message]
2026-09-16 15:12 ` [PATCH v2] mtd: cfi_cmdset_0002: cap the write-buffer chunk at 256 bytes on an x8 device Miquel Raynal
2026-09-16 16:27 ` Orgad Shaneh
2026-09-17 12:46 ` Miquel Raynal
2026-09-16 16:27 ` [PATCH v3] " Orgad Shaneh
2026-09-25 14:28 ` Miquel Raynal
2026-10-06 5:24 ` [PATCH] mtd: cfi_cmdset_0002: also clamp the write buffer of an x16 part strapped to x8 Orgad Shaneh
2026-10-12 18:28 ` Miquel Raynal
2026-10-13 18:45 ` Orgad Shaneh
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=20260915075028.21658-1-orgads@gmail.com \
--to=orgads@gmail.com \
--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 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.