mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Rosen Penev <rosenp@gmail.com>
To: linux-spi@vger.kernel.org
Cc: Mark Brown <broonie@kernel.org>,
	Mauro Lima <mauro.lima@eclypsium.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Pratyush Yadav <p.yadav@ti.com>,
	Tudor Ambarus <tudor.ambarus@linaro.org>,
	linux-kernel@vger.kernel.org (open list)
Subject: [PATCH v2] spi: intel: only check locked opmenu for SW sequencer operations
Date: Sun,  8 Nov 2026 12:37:28 -0800	[thread overview]
Message-ID: <20261108203728.25735-1-rosenp@gmail.com> (raw)

On controllers that use the software sequencer for register access (LPT
and BYT), intel_spi_supports_mem_op() rejects any operation whose opcode
is not in the BIOS-locked OPMENU. However the check is applied to every
operation, including normal data reads and writes which are always
executed by the hardware sequencer and never consult the OPMENU.

On a Dell Precision M4800 (Lynx Point) the BIOS locks OPMENU to
{02, 3b, 20, 05, 9f, 9f, 00, 00}, which lacks both READ (0x03) and
FAST_READ (0x0b). As a result every read op is rejected and spi-nor
fails to probe both flash components:

  intel-spi intel-spi: 0x3 not supported
  intel-spi intel-spi: 0xb not supported
  spi-nor spi0.0: can't select read settings supported by both the SPI controller and memory.
  spi-nor spi0.0: probe with driver spi-nor failed with error -22

Only enforce the OPMENU check for operations that actually go through
the software sequencer: register reads/writes when swseq_reg is set and
erase when swseq_erase is set.

Write Enable (0x06) and Write Disable (0x04) are excluded as well, even
though they are register writes. WREN is never issued from the OPMENU:
intel_spi_write_reg() verifies it is in PREOP_OPTYPE and uses it as the
atomic preopcode of the next cycle. WRDI is not sent to the flash at
all. Rejecting them whenever they are missing from the OPMENU, as on the
M4800 where 0x06 is only in PREOP_OPTYPE, makes every program and erase
fail with -EOPNOTSUPP.

With this both flash chips (W25Q64 and W25Q32) probe and read back
correctly.

Fixes: e23e5a05d1fd ("mtd: spi-nor: intel-spi: Convert to SPI MEM")
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 v2: exclude SPINOR_OP_WREN and SPINOR_OP_WRDI
 drivers/spi/spi-intel.c | 28 ++++++++++++++++++++++++++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-intel.c b/drivers/spi/spi-intel.c
index 7494b921a743..391e79fa4678 100644
--- a/drivers/spi/spi-intel.c
+++ b/drivers/spi/spi-intel.c
@@ -754,6 +754,28 @@ intel_spi_match_mem_op(struct intel_spi *ispi, const struct spi_mem_op *op)
 	return NULL;
 }
 
+static bool intel_spi_op_uses_opmenu(const struct intel_spi *ispi,
+				     const struct intel_spi_mem_op *iop,
+				     const struct spi_mem_op *op)
+{
+	if (iop->exec_op == intel_spi_read_reg)
+		return ispi->swseq_reg;
+	if (iop->exec_op == intel_spi_write_reg) {
+		/*
+		 * WREN is issued through PREOP_OPTYPE as an atomic
+		 * preopcode and WRDI is a no-op, so neither uses the opmenu.
+		 */
+		if (op->cmd.opcode == SPINOR_OP_WREN ||
+		    op->cmd.opcode == SPINOR_OP_WRDI)
+			return false;
+		return ispi->swseq_reg;
+	}
+	if (iop->exec_op == intel_spi_erase)
+		return ispi->swseq_erase;
+	/* Data reads and writes always use the HW sequencer */
+	return false;
+}
+
 static bool intel_spi_supports_mem_op(struct spi_mem *mem,
 				      const struct spi_mem_op *op)
 {
@@ -768,9 +790,11 @@ static bool intel_spi_supports_mem_op(struct spi_mem *mem,
 
 	/*
 	 * For software sequencer check that the opcode is actually
-	 * present in the opmenu if it is locked.
+	 * present in the opmenu if it is locked. Operations executed by
+	 * the hardware sequencer, as well as WREN and WRDI, do not use the
+	 * opmenu so skip the check for them.
 	 */
-	if (ispi->swseq_reg && ispi->locked) {
+	if (ispi->locked && intel_spi_op_uses_opmenu(ispi, iop, op)) {
 		int i;
 
 		/* Check if it is in the locked opcodes list */
-- 
2.56.0


                 reply	other threads:[~2026-11-08 20:37 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20261108203728.25735-1-rosenp@gmail.com \
    --to=rosenp@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=mauro.lima@eclypsium.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=p.yadav@ti.com \
    --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

all inboxes | Powered by JetHome®