From: "Michael Walle" <mwalle@kernel.org>
To: "Sanjaikumar V S" <sanjaikumarvs@gmail.com>, <pratyush@kernel.org>
Cc: <hd@os-cillation.de>, <linux-kernel@vger.kernel.org>,
<linux-mtd@lists.infradead.org>, <miquel.raynal@bootlin.com>,
<richard@nod.at>, <sanjaikumar.vs@dicortech.com>,
<stable@vger.kernel.org>, <tudor.ambarus@linaro.org>,
<vigneshr@ti.com>
Subject: Re: [PATCH v5] mtd: spi-nor: Fix SST AAI write mode opcode handling
Date: Fri, 11 Sep 2026 10:09:27 +0200 [thread overview]
Message-ID: <DLCC1HX0HX8Z.1X4CEDDDVRQ58@kernel.org> (raw)
In-Reply-To: <20260331095026.38-1-sanjaikumarvs@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1355 bytes --]
On Tue Mar 31, 2026 at 11:50 AM CEST, Sanjaikumar V S wrote:
> From: Sanjaikumar V S <sanjaikumar.vs@dicortech.com>
>
> When the SPI controller lacks direct mapping support, the fallback path
> in spi_nor_spimem_write_data() uses nor->write_proto based operation
> template. However, this template uses the standard page program opcode
> set during probe, not the AAI opcode required for SST flash.
So it looks like that mtd->_write override in sst.c is rather
hacky..
> Additionally, controllers that do support direct mapping will also use
> the wrong opcode since the dirmap template is created at probe time
> with the standard page program opcode.
>
> Fix this by:
> 1. Checking the nodirmap flag in spi_nor_spimem_write_data() to ensure
> the code falls through to spi_nor_spimem_exec_op() path which builds
> the operation at runtime with the correct program_opcode.
> 2. Setting nodirmap=true for SST AAI devices in sst_nor_late_init() to
> disable dirmap and force the runtime opcode path.
I'd be fine with disabling dirmap support as a workaround. But I'm
not sure if we are supposed to change the nodirmap property as that
is a property owned/set by the controller.
Could we just compare the mtd->_write == spi_nor_write and then skip
the dirmap support? With a big here be dragons warning.
-michael
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
[-- Attachment #2: Type: text/plain, Size: 144 bytes --]
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
prev parent reply other threads:[~2026-09-11 8:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-31 9:50 [PATCH v5] mtd: spi-nor: Fix SST AAI write mode opcode handling Sanjaikumar V S
2026-03-31 9:50 ` Sanjaikumar V S
2026-04-01 15:53 ` Hendrik Donner
2026-04-01 15:53 ` Hendrik Donner
2026-04-20 9:02 ` Sanjaikumar V S
2026-04-20 9:02 ` Sanjaikumar V S
2026-09-11 8:09 ` Michael Walle [this message]
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=DLCC1HX0HX8Z.1X4CEDDDVRQ58@kernel.org \
--to=mwalle@kernel.org \
--cc=hd@os-cillation.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=sanjaikumar.vs@dicortech.com \
--cc=sanjaikumarvs@gmail.com \
--cc=stable@vger.kernel.org \
--cc=tudor.ambarus@linaro.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.