Some SPI controllers like Intel's one on the PCI bus do not support
opcode 35h. This opcode is used to read the Configuration Register on
SPI-NOR chips that have 16-bit Status Register configured regardless
of the controller support for it. Adding a check call in the setup step
allows disabling use of the 35h opcode and falling back to the manual
Status Registers management.

Before:
openat(AT_FDCWD, "/dev/mtd0", O_RDWR)   = 4
ioctl(4, MIXER_WRITE(6) or MEMUNLOCK, {start=0, length=0x2000000}) = -1
EOPNOTSUPP

After:
openat(AT_FDCWD, "/dev/mtd0", O_RDWR)   = 4
ioctl(4, MIXER_WRITE(6) or MEMUNLOCK, {start=0, length=0x2000000}) = 0
ioctl(4, MIXER_WRITE(5) or MEMLOCK, {start=0x1800000, length=0x800000}) = 0

Suggested-by: Adeel Arshad <adeel.arshad@intel.com>
Signed-off-by: Jakub Czapiga <czapiga@google.com>
---
Changes since v1:
- Use spi_nor_spimem_setup_op instead of spi_nor_read_cr to test opcode
- Check only for spi-mem devices
- Move check from spi_nor_setup to spi_nor_spimem_adjust_hwcaps

 drivers/mtd/spi-nor/core.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index ac4b960101cc..0c43fcca3d0a 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2318,6 +2318,16 @@ spi_nor_spimem_adjust_hwcaps(struct spi_nor *nor, u32 *hwcaps)
 					    &params->page_programs[ppidx]))
 			*hwcaps &= ~BIT(cap);
 	}
+
+	/* Some SPI controllers might not support CR read opcode. */
+	if (!(nor->flags & SNOR_F_NO_READ_CR)) {
+		struct spi_mem_op op = SPI_NOR_RDCR_OP(nor->bouncebuf);
+
+		spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
+
+		if (spi_nor_spimem_check_op(nor, &op))
+			nor->flags |= SNOR_F_NO_READ_CR;
+	}
 }
 
 /**
-- 
2.51.0.534.gc79095c0ca-goog

On Fri, Sep 19 2025, Jakub Czapiga wrote:

> Some SPI controllers like Intel's one on the PCI bus do not support
> opcode 35h. This opcode is used to read the Configuration Register on
> SPI-NOR chips that have 16-bit Status Register configured regardless
> of the controller support for it. Adding a check call in the setup step
> allows disabling use of the 35h opcode and falling back to the manual
> Status Registers management.
>
> Before:
> openat(AT_FDCWD, "/dev/mtd0", O_RDWR)   = 4
> ioctl(4, MIXER_WRITE(6) or MEMUNLOCK, {start=0, length=0x2000000}) = -1
> EOPNOTSUPP
>
> After:
> openat(AT_FDCWD, "/dev/mtd0", O_RDWR)   = 4
> ioctl(4, MIXER_WRITE(6) or MEMUNLOCK, {start=0, length=0x2000000}) = 0
> ioctl(4, MIXER_WRITE(5) or MEMLOCK, {start=0x1800000, length=0x800000}) = 0
>
> Suggested-by: Adeel Arshad <adeel.arshad@intel.com>
> Signed-off-by: Jakub Czapiga <czapiga@google.com>

Reviewed-by: Pratyush Yadav <pratyush@kernel.org>

Applied to spi-nor/next. Thanks!

BTW, b4 complains that DKIM fails on your email. Please check.

[...]

-- 
Regards,
Pratyush Yadav

On Tue, Nov 18, 2025 at 01:34:59PM +0100, Pratyush Yadav wrote:
> BTW, b4 complains that DKIM fails on your email. Please check.

This is due to Google's policy of setting very short expiration dates in their
DKIM headers:

    t=1758305794; x=1758910594;

It's set to invalidate after 1 week:

    $ date -d '@1758305794'
    Fri 19 Sep 2025 02:16:34 PM EDT
    $ date -d '@1758910594'
    Fri 26 Sep 2025 02:16:34 PM EDT

-K

On Tue, Nov 18 2025, Konstantin Ryabitsev wrote:

> On Tue, Nov 18, 2025 at 01:34:59PM +0100, Pratyush Yadav wrote:
>> BTW, b4 complains that DKIM fails on your email. Please check.
>
> This is due to Google's policy of setting very short expiration dates in their
> DKIM headers:
>
>     t=1758305794; x=1758910594;
>
> It's set to invalidate after 1 week:
>
>     $ date -d '@1758305794'
>     Fri 19 Sep 2025 02:16:34 PM EDT
>     $ date -d '@1758910594'
>     Fri 26 Sep 2025 02:16:34 PM EDT

I see. Thanks for explaining!

-- 
Regards,
Pratyush Yadav