From: Cheng Ming Lin <chengminglin@mxic.com.tw>

The current code uses spi_nor_spimem_check_op() to check if the SPI
controller supports the Read CR operation. However, this leads to a
false positive where capable controllers are wrongly flagged with
SNOR_F_NO_READ_CR.

SPI_NOR_RDCR_OP defines an operation without an address phase
(addr.nbytes = 0, addr.buswidth = 0). When this operation is passed
to spi_nor_spimem_check_op(), the function overwrites op->addr.nbytes
to 3 or 4 to test addressing capabilities (as it was originally designed
for data read/write ops).

This modified operation is then rejected by spi_mem_check_op() in the
core spi-mem.c because it has a non-zero address length but a zero address
buswidth, which is an invalid combination.

Fix this by bypassing spi_nor_spimem_check_op() for register operations.
Instead, directly call spi_mem_supports_op() to test the exact operation
without altering its address phase.

Fixes: 5008c3ec3f89 ("mtd: spi-nor: core: Check read CR support")
Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw>
---
 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..13201908a69f 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2466,7 +2466,7 @@ spi_nor_spimem_adjust_hwcaps(struct spi_nor *nor, u32 *hwcaps)
 
 		spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
 
-		if (spi_nor_spimem_check_op(nor, &op))
+		if (!spi_mem_supports_op(nor->spimem, &op))
 			nor->flags |= SNOR_F_NO_READ_CR;
 	}
 }
-- 
2.25.1

Hi Cheng Ming,

On 24/02/2026 at 10:55:50 +08, Cheng Ming Lin <linchengming884@gmail.com> wrote:

> From: Cheng Ming Lin <chengminglin@mxic.com.tw>
>
> The current code uses spi_nor_spimem_check_op() to check if the SPI
> controller supports the Read CR operation. However, this leads to a
> false positive where capable controllers are wrongly flagged with
> SNOR_F_NO_READ_CR.
>
> SPI_NOR_RDCR_OP defines an operation without an address phase
> (addr.nbytes = 0, addr.buswidth = 0). When this operation is passed
> to spi_nor_spimem_check_op(), the function overwrites op->addr.nbytes
> to 3 or 4 to test addressing capabilities (as it was originally designed
> for data read/write ops).
>
> This modified operation is then rejected by spi_mem_check_op() in the
> core spi-mem.c because it has a non-zero address length but a zero address
> buswidth, which is an invalid combination.
>
> Fix this by bypassing spi_nor_spimem_check_op() for register operations.
> Instead, directly call spi_mem_supports_op() to test the exact operation
> without altering its address phase.
>
> Fixes: 5008c3ec3f89 ("mtd: spi-nor: core: Check read CR support")
> Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw>

That is indeed a problem, I already sent a patch for that but there is a
bit of turnover in the spi-nor team. It hasn't been acked so I didn't
took it through the final MR. The problem now exists in 7.0-rc1, see:

https://lore.kernel.org/linux-mtd/20260108121430.1096844-1-miquel.raynal@bootlin.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..13201908a69f 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -2466,7 +2466,7 @@ spi_nor_spimem_adjust_hwcaps(struct spi_nor *nor, u32 *hwcaps)
>  
>  		spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
>  
> -		if (spi_nor_spimem_check_op(nor, &op))
> +		if (!spi_mem_supports_op(nor->spimem, &op))
>  			nor->flags |= SNOR_F_NO_READ_CR;
>  	}
>  }

Hi Miquel,

Miquel Raynal <miquel.raynal@bootlin.com> 於 2026年2月24日週二 下午4:24寫道：
>
> Hi Cheng Ming,
>
> On 24/02/2026 at 10:55:50 +08, Cheng Ming Lin <linchengming884@gmail.com> wrote:
>
> > From: Cheng Ming Lin <chengminglin@mxic.com.tw>
> >
> > The current code uses spi_nor_spimem_check_op() to check if the SPI
> > controller supports the Read CR operation. However, this leads to a
> > false positive where capable controllers are wrongly flagged with
> > SNOR_F_NO_READ_CR.
> >
> > SPI_NOR_RDCR_OP defines an operation without an address phase
> > (addr.nbytes = 0, addr.buswidth = 0). When this operation is passed
> > to spi_nor_spimem_check_op(), the function overwrites op->addr.nbytes
> > to 3 or 4 to test addressing capabilities (as it was originally designed
> > for data read/write ops).
> >
> > This modified operation is then rejected by spi_mem_check_op() in the
> > core spi-mem.c because it has a non-zero address length but a zero address
> > buswidth, which is an invalid combination.
> >
> > Fix this by bypassing spi_nor_spimem_check_op() for register operations.
> > Instead, directly call spi_mem_supports_op() to test the exact operation
> > without altering its address phase.
> >
> > Fixes: 5008c3ec3f89 ("mtd: spi-nor: core: Check read CR support")
> > Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw>
>
> That is indeed a problem, I already sent a patch for that but there is a
> bit of turnover in the spi-nor team. It hasn't been acked so I didn't
> took it through the final MR. The problem now exists in 7.0-rc1, see:
>
> https://lore.kernel.org/linux-mtd/20260108121430.1096844-1-miquel.raynal@bootlin.com/

Understood, thank you for pointing that out. I completely missed your
previous patch when I was looking into this issue.

Thanks again for the clarification!

>
> > ---
> >  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..13201908a69f 100644
> > --- a/drivers/mtd/spi-nor/core.c
> > +++ b/drivers/mtd/spi-nor/core.c
> > @@ -2466,7 +2466,7 @@ spi_nor_spimem_adjust_hwcaps(struct spi_nor *nor, u32 *hwcaps)
> >
> >               spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
> >
> > -             if (spi_nor_spimem_check_op(nor, &op))
> > +             if (!spi_mem_supports_op(nor->spimem, &op))
> >                       nor->flags |= SNOR_F_NO_READ_CR;
> >       }
> >  }

Best regards,
Cheng Ming Lin