From: sashiko-bot@kernel.org
To: "Orgad Shaneh" <orgads@gmail.com>,
vigneshr@ti.com, miquel.raynal@bootlin.com, richard@nod.at
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] mtd: cfi_cmdset_0002: cap the write-buffer chunk at 256 bytes on an 8-bit bus
Date: Tue, 15 Sep 2026 07:30:33 +0000 [thread overview]
Message-ID: <20260915073034.269261F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260915071339.15172-1-orgads@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mtd: incomplete write-buffer size clamp for interleaved 8-bit chips
--
commit efef65c6e8de323e4294fd157f7f865d12e35292
Author: Orgad Shaneh <orgads@gmail.com>
mtd: cfi_cmdset_0002: cap the write-buffer chunk at 256 bytes on an 8-bit bus
This commit limits the write buffer chunk size to 256 bytes when the bank
width is exactly one byte. It prevents program aborts on 8-bit buses where
the chip advertises a larger write buffer than the single bus word can hold.
> diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
> index 517db2f2707f4..64fde81191d15 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
> @@ -283,6 +283,17 @@ static void fixup_use_write_buffers(struct mtd_info *mtd)
[ ... ]
> + /*
> + * The word count of the Write to Buffer command is a single bus
> + * word, so on an 8-bit bus a chunk holds at most 256 bytes no
> + * matter how large a buffer the chip advertises.
> + */
> + if (map_bankwidth_is_1(map) && cfi->cfiq->MaxBufWriteSize > 8) {
[Severity: High]
Does this condition properly handle interleaved configurations where multiple
8-bit chips are used on a wider bus?
The map_bankwidth_is_1() macro checks if the total aggregate system bus width
is 1 byte. If two 8-bit chips are interleaved on a 16-bit bus, the aggregate
bus width is 2 bytes, causing map_bankwidth_is_1() to evaluate to false and
bypass the clamp.
When writing a large buffer in an interleaved setup (e.g., MaxBufWriteSize = 9
and interleave = 2), cfi_amdstd_write_buffers() will pass up to 1024 bytes to
do_write_buffer(). The loop divides this by map_bankwidth to compute 512 words.
It writes a command of 511 (0x1FF) to the bus, which cfi_build_cmd()
duplicates to 0x1FFFF. This gets truncated to 0xFFFF on the 16-bit bus, so
each 8-bit chip receives 0xFF (255) as the word count. They will expect exactly
256 words (bytes).
However, the subsequent data loop in do_write_buffer() would write 512 words
to each chip, causing them to abort the program on the 257th byte.
Should this condition check the per-chip data width instead of the aggregate
system bus width? For example, checking if
map_bankwidth(map) / cfi_interleave(cfi) == 1?
> + cfi->cfiq->MaxBufWriteSize = 8;
> + mtd->writebufsize = cfi_interleave(cfi) <<
> + cfi->cfiq->MaxBufWriteSize;
> + }
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260915071339.15172-1-orgads@gmail.com?part=1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2026-09-15 7:30 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 [this message]
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
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=20260915073034.269261F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=orgads@gmail.com \
--cc=richard@nod.at \
--cc=sashiko-reviews@lists.linux.dev \
--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.