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.

Add check for nodirmap flag to ensure the code falls through to
spi_nor_spimem_exec_op() path which builds the operation at runtime
with the correct program_opcode set by sst_nor_write_data().

Fixes: df5c21002cf4 ("mtd: spi-nor: use spi-mem dirmap API")
Cc: stable@vger.kernel.org
Signed-off-by: Sanjaikumar V S <sanjaikumar.vs@dicortech.com>
---
 drivers/mtd/spi-nor/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 8ffeb41c3e08..cb7f4d447156 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -281,7 +281,7 @@ static ssize_t spi_nor_spimem_write_data(struct spi_nor *nor, loff_t to,
 	if (spi_nor_spimem_bounce(nor, &op))
 		memcpy(nor->bouncebuf, buf, op.data.nbytes);
 
-	if (nor->dirmap.wdesc) {
+	if (nor->dirmap.wdesc && !nor->dirmap.wdesc->nodirmap) {
 		nbytes = spi_mem_dirmap_write(nor->dirmap.wdesc, op.addr.val,
 					      op.data.nbytes, op.data.buf.out);
 	} else {
-- 
2.43.0

On Wed, Mar 11 2026, 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.

But if the controller does support direct mapping, won't it end up using
the wrong opcode? Would it be a better idea to update the dirmap_info
with the right opcodes?

>
> Add check for nodirmap flag to ensure the code falls through to
> spi_nor_spimem_exec_op() path which builds the operation at runtime
> with the correct program_opcode set by sst_nor_write_data().
>
> Fixes: df5c21002cf4 ("mtd: spi-nor: use spi-mem dirmap API")
> Cc: stable@vger.kernel.org
> Signed-off-by: Sanjaikumar V S <sanjaikumar.vs@dicortech.com>
> ---
>  drivers/mtd/spi-nor/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 8ffeb41c3e08..cb7f4d447156 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -281,7 +281,7 @@ static ssize_t spi_nor_spimem_write_data(struct spi_nor *nor, loff_t to,
>  	if (spi_nor_spimem_bounce(nor, &op))
>  		memcpy(nor->bouncebuf, buf, op.data.nbytes);
>  
> -	if (nor->dirmap.wdesc) {
> +	if (nor->dirmap.wdesc && !nor->dirmap.wdesc->nodirmap) {
>  		nbytes = spi_mem_dirmap_write(nor->dirmap.wdesc, op.addr.val,
>  					      op.data.nbytes, op.data.buf.out);
>  	} else {

-- 
Regards,
Pratyush Yadav

Hi,

> But if the controller does support direct mapping, won't it end up
> using the wrong opcode? Would it be a better idea to update the
> dirmap_info with the right opcodes?

You're right. If the controller supports direct mapping, it would still
use the wrong opcode from the template created at probe time.

Updating dirmap_info at runtime is problematic because SST AAI mode
requires dynamic changes per write:
- cmd.opcode: SPINOR_OP_BP (single byte) vs SPINOR_OP_AAI_WP (word)
- addr.nbytes: must be 0 for subsequent AAI writes

Controllers may also cache the template at dirmap_create time, so
modifying it at runtime could cause issues.

A cleaner approach is to disable dirmap for SST AAI devices by setting
nodirmap=1 in sst_nor_late_init(). This ensures all writes go through
spi_nor_spimem_exec_op() which uses the runtime opcode.

This only affects devices with SST_WRITE flag (sst25wf*, sst25vf016b,
sst25vf032b, sst25vf040b, sst25vf080b). Other SST devices that use
standard page program can still benefit from dirmap.

I'll send a v5 with this change.

Thanks,
Sanjaikumar

Hello,

On 3/11/26 11:30, 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.
> 
> Add check for nodirmap flag to ensure the code falls through to
> spi_nor_spimem_exec_op() path which builds the operation at runtime
> with the correct program_opcode set by sst_nor_write_data().
> 
> Fixes: df5c21002cf4 ("mtd: spi-nor: use spi-mem dirmap API")
> Cc: stable@vger.kernel.org
> Signed-off-by: Sanjaikumar V S <sanjaikumar.vs@dicortech.com>
> ---
>   drivers/mtd/spi-nor/core.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 8ffeb41c3e08..cb7f4d447156 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -281,7 +281,7 @@ static ssize_t spi_nor_spimem_write_data(struct spi_nor *nor, loff_t to,
>   	if (spi_nor_spimem_bounce(nor, &op))
>   		memcpy(nor->bouncebuf, buf, op.data.nbytes);
>   
> -	if (nor->dirmap.wdesc) {
> +	if (nor->dirmap.wdesc && !nor->dirmap.wdesc->nodirmap) {
>   		nbytes = spi_mem_dirmap_write(nor->dirmap.wdesc, op.addr.val,
>   					      op.data.nbytes, op.data.buf.out);
>   	} else {

found a board with

   spi-nor spi0.0: sst25vf032b (4096 Kbytes)

for testing. Tests are on top of

   94645aa41bf9e (mtd/spi-nor/next)

This patch fixes write errors, easily seen with flashcp, which tries to
verify writes:

   flashcp: verification mismatch at 0x0

Tested-by: Hendrik Donner <hd@os-cillation.de>
Reviewed-by: Hendrik Donner <hd@os-cillation.de>

Regards,
Hendrik