mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  reply	other threads:[~2026-09-15  7:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-15  7:13 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

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 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®