From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
Tudor Ambarus <tudor.ambarus@linaro.org>,
Mark Brown <broonie@kernel.org>, Sasha Levin <sashal@kernel.org>,
linux-spi@vger.kernel.org
Subject: [PATCH AUTOSEL 6.19-6.6] spi: spi-mem: Limit octal DTR constraints to octal DTR situations
Date: Fri, 13 Feb 2026 19:58:20 -0500 [thread overview]
Message-ID: <20260214010245.3671907-20-sashal@kernel.org> (raw)
In-Reply-To: <20260214010245.3671907-1-sashal@kernel.org>
From: Miquel Raynal <miquel.raynal@bootlin.com>
[ Upstream commit 8618271887ca10ac5108fe7e1d82ba8f1b152cf9 ]
In this helper, any operation with a single DTR cycle (like 1S-1S-8D) is
considered requiring a duplicated command opcode. This is wrong as this
constraint only applies to octal DTR operations (8D-8D-8D).
Narrow the application of this constraint to the concerned bus
interface.
Note: none of the possible XD-XD-XD pattern, with X being one of {1, 2,
4} would benefit from this check either as there is only in octal DTR
mode that a single clock edge would be enough to transmit the full
opcode.
Make sure the constraint of expecting two bytes for the command is
applied to the relevant bus interface.
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20260109-winbond-v6-17-rc1-oddr-v2-3-1fff6a2ddb80@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
The core of the fix — moving the `op->cmd.nbytes != 2` check inside a
tighter condition — is self-contained. It doesn't depend on the `swap16`
feature (that's a separate, pre-existing check). The new even-byte
checks for addr/dummy/data in 8D-8D-8D mode are a tightening of
validation that could also be backported.
However, the presence of the `swap16` check in the surrounding context
means the patch won't apply cleanly to older stable trees that lack
commit `030ace430afcf` (from 6.12 cycle). The fix would need minor
adaptation for older stable trees, but the logic change itself is
independent.
### 7. Assessment Summary
**What the bug is:** `spi_mem_default_supports_op()` incorrectly rejects
valid non-8D-8D-8D DTR operations (like 1S-1S-8D) by requiring
`cmd.nbytes == 2` for ALL DTR operations, not just 8D-8D-8D ones.
**Impact:** Real functional bug — any SPI memory device using mixed DTR
modes (where only the data phase is DTR but not the command phase) would
have its operations rejected. This prevents legitimate device
operations.
**Scope of the fix:** The change is confined to a single function in one
file. It narrows a condition check and adds additional validation only
for the specific 8D-8D-8D case.
**Risk:** Low. The fix is logically correct — it restricts a previously
over-broad check. It can't introduce new failures for 8D-8D-8D mode
(those checks are preserved and even strengthened), and it unblocks
mixed-DTR modes that were incorrectly blocked.
**Who benefits:** Users with SPI memory devices that use non-8D-8D-8D
DTR modes (e.g., some flash chips using 1S-1S-8D for certain
operations).
**Concerns:**
- Part of a larger patch series (v2-3), but the fix to
`spi_mem_default_supports_op()` is self-contained
- May need minor context adjustment for older stable trees (due to
`swap16` context)
- The even-byte-count validation is technically a new constraint for
8D-8D-8D mode, but it enforces existing hardware requirements that
were previously unchecked
This is a clear correctness fix for a real bug that has existed since
kernel 5.18. It's small, contained, well-reviewed (Reviewed-by from
Tudor Ambarus, a key MTD maintainer), and fixes incorrect rejection of
valid SPI operations.
**YES**
drivers/spi/spi-mem.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index c8b2add2640e5..6c7921469b90b 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -178,8 +178,19 @@ bool spi_mem_default_supports_op(struct spi_mem *mem,
if (op->data.swap16 && !spi_mem_controller_is_capable(ctlr, swap16))
return false;
- if (op->cmd.nbytes != 2)
- return false;
+ /* Extra 8D-8D-8D limitations */
+ if (op->cmd.dtr && op->cmd.buswidth == 8) {
+ if (op->cmd.nbytes != 2)
+ return false;
+
+ if ((op->addr.nbytes % 2) ||
+ (op->dummy.nbytes % 2) ||
+ (op->data.nbytes % 2)) {
+ dev_err(&ctlr->dev,
+ "Even byte numbers not allowed in octal DTR operations\n");
+ return false;
+ }
+ }
} else {
if (op->cmd.nbytes != 1)
return false;
--
2.51.0
next prev parent reply other threads:[~2026-02-14 1:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260214010245.3671907-1-sashal@kernel.org>
2026-02-14 0:58 ` [PATCH AUTOSEL 6.19-6.1] spi-geni-qcom: initialize mode related registers to 0 Sasha Levin
2026-02-14 0:58 ` [PATCH AUTOSEL 6.19-6.18] spi: cadence-qspi: Try hard to disable the clocks Sasha Levin
2026-02-14 0:58 ` Sasha Levin [this message]
2026-02-14 0:58 ` [PATCH AUTOSEL 6.19-5.15] spi: stm32: fix Overrun issue at < 8bpw Sasha Levin
2026-02-14 0:58 ` [PATCH AUTOSEL 6.19-6.6] spi-geni-qcom: use xfer->bits_per_word for can_dma() Sasha Levin
2026-02-14 0:59 ` [PATCH AUTOSEL 6.19-6.18] spi: cadence-quadspi: Parse DT for flashes with the rest of the DT parsing Sasha Levin
2026-02-14 0:59 ` [PATCH AUTOSEL 6.19] spi: cadence-qspi: Fix probe error path and remove Sasha Levin
2026-02-14 0:59 ` [PATCH AUTOSEL 6.19-6.12] spi: geni-qcom: Fix abort sequence execution for serial engine errors Sasha Levin
2026-02-14 1:00 ` [PATCH AUTOSEL 6.19-5.10] spi: spi-mem: Protect dirmap_create() with spi_mem_access_start/end Sasha Levin
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=20260214010245.3671907-20-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=broonie@kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=miquel.raynal@bootlin.com \
--cc=patches@lists.linux.dev \
--cc=stable@vger.kernel.org \
--cc=tudor.ambarus@linaro.org \
/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