From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Orgad Shaneh <orgads@gmail.com>
Cc: richard@nod.at, vigneshr@ti.com, linux-mtd@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2] mtd: cfi_cmdset_0002: cap the write-buffer chunk at 256 bytes on an x8 device
Date: Wed, 16 Sep 2026 17:12:11 +0200 [thread overview]
Message-ID: <8733v9mdro.fsf@bootlin.com> (raw)
In-Reply-To: <20260915075028.21658-1-orgads@gmail.com> (Orgad Shaneh's message of "Tue, 15 Sep 2026 07:50:03 +0000")
On 15/09/2026 at 07:50:03 GMT, Orgad Shaneh <orgads@gmail.com> wrote:
> 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.
This sentence does not mean anything, I'm sorry.
> Every full-size chunk failed while the
failed? do you have hardware that actually triggered that issue?
> 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.
That's incorrect. It indicates until when we need to backport it. So if
it's the first Git commit, it's the first Git commit.
> 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;
Ideally, I'd like feedback from Vignesh on this.
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2026-09-16 15:12 UTC|newest]
Thread overview: 10+ 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 ` [PATCH v2] mtd: cfi_cmdset_0002: cap the write-buffer chunk at 256 bytes on an x8 device Orgad Shaneh
2026-09-16 15:12 ` Miquel Raynal [this message]
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
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=8733v9mdro.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=orgads@gmail.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.