[PATCH v3] mtd: spi-nor: clear the default read_sr2 opcode for xSPI Profile 1.0 flashes

[PATCH v3] mtd: spi-nor: clear the default read_sr2 opcode for xSPI Profile 1.0 flashes

[haibo.chen]

From: Haibo Chen <haibo.chen@nxp.com>

The core defaults opcodes.read_sr2 to the legacy RDCR opcode (0x35), and
spi_nor_cache_sr_lock_bits() reads SR2 during spi_nor_init(), i.e. after
the flash has been switched to its runtime protocol. On an octal flash
running in 8D-8D-8D mode the opcode is extended per cmd_ext_type (e.g.
0x3535), but RDCR is not a valid register read there: these parts access
their status/configuration registers through a vendor-specific indirect
space, if at all. The flash does not answer, the register read times out
and probe fails (on i.MX FlexSPI: -ETIMEDOUT and a controller WARN(),
seen with a Micron MT35XU01G and a Macronix MX25UW51345G).

A flash that supports 8D-8D-8D publishes the xSPI Profile 1.0 SFDP table,
and that table does not describe any SR2/RDCR read. Clear read_sr2 in
spi_nor_parse_profile1(): it runs only for octal-capable parts and before
the manufacturer late_init hooks, so spi_nor_read_sr1_and_sr2() degrades
to an SR1-only read and no unsupported command is issued. A manufacturer
driver that genuinely needs an SR2 read in this mode can still install
its own opcode in a later fixup.

CMP (the only user of SR2 beyond quad-enable in the locking code) is
Winbond-specific and is not placed in SR2 on their 8D-capable parts, so
no octal flash loses a usable SR2 read because of this change.

Fixes: b7b63475903c ("mtd: spi-nor: Create a local SR cache")
Fixes: 63489002d397 ("mtd: spi-nor: Refactor Read Status/Write Status support")
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
---
Changes in v3:
- Clear opcodes.read_sr2 in spi_nor_parse_profile1() (capability based)
  instead of in spi_nor_set_octal_dtr() (runtime-protocol based), as
  suggested by Miquel and Michael. It runs for octal-capable parts and
  before the manufacturer late_init, so a driver can still install its
  own SR2 opcode afterwards.
- Confirmed on a Micron MT35XU01G (i.MX95) and a Macronix MX25UW51345G
  (i.MX8ULP): both publish the xSPI Profile 1.0 table, and 0x35 is not a
  valid SR2 read in 8D mode on either.
- Drop the Assisted-by tag (removed upstream for 7.3).
- Link to v2: https://lore.kernel.org/r/20260929-spi-nor-fix-v2-1-75440cfe4e76@nxp.com

Changes in v2:
- Rework the fix following review: instead of guarding the read at runtime
  in spi_nor_read_sr2(), clear the default RDCR opcode.read_sr2 once, at the
  point the switch to Octal DTR succeeds (spi_nor_set_octal_dtr()).
- Key the clear off the real runtime protocol so a flash that advertises
  Octal DTR but runs in (x)STR (host without 8D support) keeps its RDCR.
- Drop the swp.c change and the -EOPNOTSUPP handling; a cleared read_sr2
  already means "no SR2 read", handled by the existing debugfs caching path.
- Trim the code comment; move the details to the commit message.
- Link to v1: https://lore.kernel.org/r/20260928-spi-nor-fix-v1-1-ce65ba90cfbd@nxp.com
---
 drivers/mtd/spi-nor/sfdp.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index 4a3f82e97cef8a76c9704918aa6558ca4e2f2b97..722eeff71d0df8c47ec7bdd795c08ba1bdf5e9cc 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -1344,6 +1344,17 @@ static int spi_nor_parse_profile1(struct spi_nor *nor,
 	 */
 	nor->params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
 
+	/*
+	 * The xSPI Profile 1.0 table does not describe a Read Configuration
+	 * Register (RDCR, 35h) instruction, and the single-byte RDCR default
+	 * is not usable in 8D-8D-8D mode. Drop the SR2 read opcode for these
+	 * octal-capable flashes so spi_nor_read_sr1_and_sr2() degrades to an
+	 * SR1-only read and spi_nor_init() does not issue an unsupported
+	 * command that the flash never answers. A manufacturer driver that
+	 * actually needs SR2 can install its own opcode in a later fixup.
+	 */
+	nor->params->opcodes.read_sr2 = 0;
+
 out:
 	kfree(dwords);
 	return ret;

---
base-commit: 9a482184d910775cf648863148944945b74e2815
change-id: 20260928-spi-nor-fix-eb7ebe22a740

Best regards,
-- 
Haibo Chen <haibo.chen@nxp.com>


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v3] mtd: spi-nor: clear the default read_sr2 opcode for xSPI Profile 1.0 flashes

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] mtd: spi-nor: read_sr2 left set for 8D-8D-8D flashes without Profile 1.0
--

commit ef4079e3aea2014890e08df31ea4d8775a392f81
Author: Haibo Chen <haibo.chen@nxp.com>

mtd: spi-nor: clear the default read_sr2 opcode for xSPI Profile 1.0 flashes

This commit clears params->opcodes.read_sr2 in spi_nor_parse_profile1() so
that flashes with an xspi profile 1.0 table do not issue an unsupported
0x35 register read when running in octal dtr mode.

> diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
> index 4a3f82e97cef8..722eeff71d0df 100644
> --- a/drivers/mtd/spi-nor/sfdp.c
> +++ b/drivers/mtd/spi-nor/sfdp.c
> @@ -1344,6 +1344,17 @@ static int spi_nor_parse_profile1(struct spi_nor *nor,
>  	 */
>  	nor->params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
>  
> +	/*
> +	 * The xSPI Profile 1.0 table does not describe a Read Configuration
> +	 * Register (RDCR, 35h) instruction, and the single-byte RDCR default
> +	 * is not usable in 8D-8D-8D mode. Drop the SR2 read opcode for these
> +	 * octal-capable flashes so spi_nor_read_sr1_and_sr2() degrades to an
> +	 * SR1-only read and spi_nor_init() does not issue an unsupported
> +	 * command that the flash never answers. A manufacturer driver that
> +	 * actually needs SR2 can install its own opcode in a later fixup.
> +	 */
> +	nor->params->opcodes.read_sr2 = 0;

[Severity: Medium]
What happens on octal dtr flashes that do not publish an xspi profile 1.0
table, so spi_nor_parse_profile1() is never called?

Specifically, some batches of the Micron mt35xu512aba lack the profile 1.0
table and instead configure SNOR_PROTO_8_8_8_DTR in
drivers/mtd/spi-nor/micron-st.c:mt35xu512aba_post_sfdp_fixup():

	nor->params->hwcaps.mask |= SNOR_HWCAPS_READ_8_8_8_DTR;
	spi_nor_set_read_settings(&nor->params->reads[SNOR_CMD_READ_8_8_8_DTR],
				  0, 20, SPINOR_OP_MT_DTR_RD,
				  SNOR_PROTO_8_8_8_DTR);
	...
	nor->params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
	spi_nor_set_pp_settings(&nor->params->page_programs[SNOR_CMD_PP_8_8_8_DTR],
				SPINOR_OP_PP_4B, SNOR_PROTO_8_8_8_DTR);

In drivers/mtd/spi-nor/sfdp.c:spi_nor_parse_bfpt(), params->opcodes.read_sr2
is initialized to SPINOR_OP_RDCR (0x35) and remains set when the quad enable
requirements field contains a reserved value (which
mt35xu512aba_post_sfdp_fixup() notes is the case on this part) or
BFPT_DWORD15_QER_NONE:

	params->opcodes.read_sr1 = SPINOR_OP_RDSR;
	params->opcodes.read_sr2 = SPINOR_OP_RDCR;
	...
	default:
		dev_dbg(nor->dev, "BFPT QER reserved value used\n");
		break;

Similarly, non-sfdp flashes initialized with SPI_NOR_OCTAL_DTR_READ in
drivers/mtd/spi-nor/core.c:spi_nor_no_sfdp_init_params() enable
SNOR_HWCAPS_READ_8_8_8_DTR while leaving params->opcodes.read_sr2 set to
SPINOR_OP_RDCR from spi_nor_init_default_params().

When spi_nor_init() switches these flashes to SNOR_PROTO_8_8_8_DTR via
spi_nor_set_octal_dtr() and then runs:

  spi_nor_init()
    -> spi_nor_cache_sr_lock_bits()
      -> spi_nor_read_sr1_and_sr2_careful()
        -> spi_nor_read_sr2_careful()
          -> spi_nor_read_sr_ll()

wouldn't this still issue the unsupported 0x3535 register read in
SNOR_PROTO_8_8_8_DTR mode and fail probe or resume with a controller
timeout?

> +
>  out:
>  	kfree(dwords);
>  	return ret;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261022-spi-nor-fix-v3-1-bffa00b75c27@nxp.com?part=1

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

RE: [PATCH v3] mtd: spi-nor: clear the default read_sr2 opcode for xSPI Profile 1.0 flashes

[Bough Chen (OSS)]

> -----Original Message-----
> From: sashiko-bot@kernel.org <sashiko-bot@kernel.org>
> Sent: Thursday, October 22, 2026 4:21 PM
> To: Bough Chen (OSS) <haibo.chen@oss.nxp.com>; Pratyush Yadav
> <pratyush@kernel.org>; Michael Walle <mwalle@kernel.org>; Takahiro
> Kuwano <takahiro.kuwano@infineon.com>; Miquel Raynal
> <miquel.raynal@bootlin.com>; Richard Weinberger <richard@nod.at>;
> Vignesh Raghavendra <vigneshr@ti.com>
> Cc: linux-mtd@lists.infradead.org; imx@lists.linux.dev; michael@walle.cc;
> Bough Chen <haibo.chen@nxp.com>; Frank.Li@kernel.org
> Subject: Re: [PATCH v3] mtd: spi-nor: clear the default read_sr2 opcode for
> xSPI Profile 1.0 flashes
> 
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s)
> to consider:
> - [Medium] mtd: spi-nor: read_sr2 left set for 8D-8D-8D flashes without
> Profile 1.0
> --
> 
> commit ef4079e3aea2014890e08df31ea4d8775a392f81
> Author: Haibo Chen <haibo.chen@nxp.com>
> 
> mtd: spi-nor: clear the default read_sr2 opcode for xSPI Profile 1.0 flashes
> 
> This commit clears params->opcodes.read_sr2 in spi_nor_parse_profile1() so
> that flashes with an xspi profile 1.0 table do not issue an unsupported
> 0x35 register read when running in octal dtr mode.
> 
> > diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
> > index 4a3f82e97cef8..722eeff71d0df 100644
> > --- a/drivers/mtd/spi-nor/sfdp.c
> > +++ b/drivers/mtd/spi-nor/sfdp.c
> > @@ -1344,6 +1344,17 @@ static int spi_nor_parse_profile1(struct spi_nor
> *nor,
> >  	 */
> >  	nor->params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
> >
> > +	/*
> > +	 * The xSPI Profile 1.0 table does not describe a Read Configuration
> > +	 * Register (RDCR, 35h) instruction, and the single-byte RDCR default
> > +	 * is not usable in 8D-8D-8D mode. Drop the SR2 read opcode for
> these
> > +	 * octal-capable flashes so spi_nor_read_sr1_and_sr2() degrades to
> an
> > +	 * SR1-only read and spi_nor_init() does not issue an unsupported
> > +	 * command that the flash never answers. A manufacturer driver that
> > +	 * actually needs SR2 can install its own opcode in a later fixup.
> > +	 */
> > +	nor->params->opcodes.read_sr2 = 0;
> 
> [Severity: Medium]
> What happens on octal dtr flashes that do not publish an xspi profile 1.0
> table, so spi_nor_parse_profile1() is never called?
> 
> Specifically, some batches of the Micron mt35xu512aba lack the profile 1.0
> table and instead configure SNOR_PROTO_8_8_8_DTR in
> drivers/mtd/spi-nor/micron-st.c:mt35xu512aba_post_sfdp_fixup():
> 
> 	nor->params->hwcaps.mask |= SNOR_HWCAPS_READ_8_8_8_DTR;
> 	spi_nor_set_read_settings(&nor->params-
> >reads[SNOR_CMD_READ_8_8_8_DTR],
> 				  0, 20, SPINOR_OP_MT_DTR_RD,
> 				  SNOR_PROTO_8_8_8_DTR);
> 	...
> 	nor->params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
> 	spi_nor_set_pp_settings(&nor->params-
> >page_programs[SNOR_CMD_PP_8_8_8_DTR],
> 				SPINOR_OP_PP_4B,
> SNOR_PROTO_8_8_8_DTR);
> 
> In drivers/mtd/spi-nor/sfdp.c:spi_nor_parse_bfpt(), params-
> >opcodes.read_sr2 is initialized to SPINOR_OP_RDCR (0x35) and remains set
> when the quad enable requirements field contains a reserved value (which
> mt35xu512aba_post_sfdp_fixup() notes is the case on this part) or
> BFPT_DWORD15_QER_NONE:
> 
> 	params->opcodes.read_sr1 = SPINOR_OP_RDSR;
> 	params->opcodes.read_sr2 = SPINOR_OP_RDCR;
> 	...
> 	default:
> 		dev_dbg(nor->dev, "BFPT QER reserved value used\n");
> 		break;
> 
> Similarly, non-sfdp flashes initialized with SPI_NOR_OCTAL_DTR_READ in
> drivers/mtd/spi-nor/core.c:spi_nor_no_sfdp_init_params() enable
> SNOR_HWCAPS_READ_8_8_8_DTR while leaving params->opcodes.read_sr2
> set to SPINOR_OP_RDCR from spi_nor_init_default_params().
> 
> When spi_nor_init() switches these flashes to SNOR_PROTO_8_8_8_DTR via
> spi_nor_set_octal_dtr() and then runs:
> 
>   spi_nor_init()
>     -> spi_nor_cache_sr_lock_bits()
>       -> spi_nor_read_sr1_and_sr2_careful()
>         -> spi_nor_read_sr2_careful()
>           -> spi_nor_read_sr_ll()
> 
> wouldn't this still issue the unsupported 0x3535 register read in
> SNOR_PROTO_8_8_8_DTR mode and fail probe or resume with a controller
> timeout?

Hi Miquel,

The Sashiko AI review raised a valid point on v3.

I see three ways to go, which do you prefer?

1, Keep the v3 approach (clear in spi_nor_parse_profile1()) and fix the remaining
    cases one by one, clearing read_sr2 in each relevant fixup 
    (e.g. mt35xu512aba_post_sfdp_fixup) / no-SFDP path.

2, Move the clear into spi_nor_late_init_params(), gated on the 8D read capability
    (hwcaps & SNOR_HWCAPS_READ_8_8_8_DTR) and read_sr2 == RDCR, so all 8D 
    paths are covered in one place. 
    The downside: late_init runs after the manufacturer fixups, so if a vendor later
    wants to set its own SR2 opcode for 8D it would be clobbered here and overriding
     it cleanly becomes awkward.

3, Go back to the v2 approach (clear in spi_nor_set_octal_dtr() when the switch to 8D
    actually succeeds). This covers every path that ends up in 8D regardless of how the 
    capability was discovered, but it is runtime-protocol based rather than capability 
    based, which you didn't prefer earlier. And this method has the same downside as
    method 2.

Regards
Haibo Chen
> 
> > +
> >  out:
> >  	kfree(dwords);
> >  	return ret;
> 
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20261022-spi-nor-fix-v3-1-
> bffa00b75c27@nxp.com?part=1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v3] mtd: spi-nor: clear the default read_sr2 opcode for xSPI Profile 1.0 flashes

[Miquel Raynal]

Hello,

On 22/10/2026 at 08:56:03 GMT, "Bough Chen (OSS)" <haibo.chen@oss.nxp.com> wrote:

>> -----Original Message-----
>> From: sashiko-bot@kernel.org <sashiko-bot@kernel.org>
>> Sent: Thursday, October 22, 2026 4:21 PM
>> To: Bough Chen (OSS) <haibo.chen@oss.nxp.com>; Pratyush Yadav
>> <pratyush@kernel.org>; Michael Walle <mwalle@kernel.org>; Takahiro
>> Kuwano <takahiro.kuwano@infineon.com>; Miquel Raynal
>> <miquel.raynal@bootlin.com>; Richard Weinberger <richard@nod.at>;
>> Vignesh Raghavendra <vigneshr@ti.com>
>> Cc: linux-mtd@lists.infradead.org; imx@lists.linux.dev; michael@walle.cc;
>> Bough Chen <haibo.chen@nxp.com>; Frank.Li@kernel.org
>> Subject: Re: [PATCH v3] mtd: spi-nor: clear the default read_sr2 opcode for
>> xSPI Profile 1.0 flashes
>> 
>> Thank you for your contribution! Sashiko AI review found 1 potential issue(s)
>> to consider:
>> - [Medium] mtd: spi-nor: read_sr2 left set for 8D-8D-8D flashes without
>> Profile 1.0
>> --
>> 
>> commit ef4079e3aea2014890e08df31ea4d8775a392f81
>> Author: Haibo Chen <haibo.chen@nxp.com>
>> 
>> mtd: spi-nor: clear the default read_sr2 opcode for xSPI Profile 1.0 flashes
>> 
>> This commit clears params->opcodes.read_sr2 in spi_nor_parse_profile1() so
>> that flashes with an xspi profile 1.0 table do not issue an unsupported
>> 0x35 register read when running in octal dtr mode.
>> 
>> > diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
>> > index 4a3f82e97cef8..722eeff71d0df 100644
>> > --- a/drivers/mtd/spi-nor/sfdp.c
>> > +++ b/drivers/mtd/spi-nor/sfdp.c
>> > @@ -1344,6 +1344,17 @@ static int spi_nor_parse_profile1(struct spi_nor
>> *nor,
>> >  	 */
>> >  	nor->params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
>> >
>> > +	/*
>> > +	 * The xSPI Profile 1.0 table does not describe a Read Configuration
>> > +	 * Register (RDCR, 35h) instruction, and the single-byte RDCR default
>> > +	 * is not usable in 8D-8D-8D mode. Drop the SR2 read opcode for
>> these
>> > +	 * octal-capable flashes so spi_nor_read_sr1_and_sr2() degrades to
>> an
>> > +	 * SR1-only read and spi_nor_init() does not issue an unsupported
>> > +	 * command that the flash never answers. A manufacturer driver that
>> > +	 * actually needs SR2 can install its own opcode in a later fixup.
>> > +	 */
>> > +	nor->params->opcodes.read_sr2 = 0;
>> 
>> [Severity: Medium]
>> What happens on octal dtr flashes that do not publish an xspi profile 1.0
>> table, so spi_nor_parse_profile1() is never called?
>> 
>> Specifically, some batches of the Micron mt35xu512aba lack the profile 1.0
>> table and instead configure SNOR_PROTO_8_8_8_DTR in
>> drivers/mtd/spi-nor/micron-st.c:mt35xu512aba_post_sfdp_fixup():
>> 
>> 	nor->params->hwcaps.mask |= SNOR_HWCAPS_READ_8_8_8_DTR;
>> 	spi_nor_set_read_settings(&nor->params-
>> >reads[SNOR_CMD_READ_8_8_8_DTR],
>> 				  0, 20, SPINOR_OP_MT_DTR_RD,
>> 				  SNOR_PROTO_8_8_8_DTR);
>> 	...
>> 	nor->params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
>> 	spi_nor_set_pp_settings(&nor->params-
>> >page_programs[SNOR_CMD_PP_8_8_8_DTR],
>> 				SPINOR_OP_PP_4B,
>> SNOR_PROTO_8_8_8_DTR);
>> 
>> In drivers/mtd/spi-nor/sfdp.c:spi_nor_parse_bfpt(), params-
>> >opcodes.read_sr2 is initialized to SPINOR_OP_RDCR (0x35) and remains set
>> when the quad enable requirements field contains a reserved value (which
>> mt35xu512aba_post_sfdp_fixup() notes is the case on this part) or
>> BFPT_DWORD15_QER_NONE:
>> 
>> 	params->opcodes.read_sr1 = SPINOR_OP_RDSR;
>> 	params->opcodes.read_sr2 = SPINOR_OP_RDCR;
>> 	...
>> 	default:
>> 		dev_dbg(nor->dev, "BFPT QER reserved value used\n");
>> 		break;
>> 
>> Similarly, non-sfdp flashes initialized with SPI_NOR_OCTAL_DTR_READ in
>> drivers/mtd/spi-nor/core.c:spi_nor_no_sfdp_init_params() enable
>> SNOR_HWCAPS_READ_8_8_8_DTR while leaving params->opcodes.read_sr2
>> set to SPINOR_OP_RDCR from spi_nor_init_default_params().
>> 
>> When spi_nor_init() switches these flashes to SNOR_PROTO_8_8_8_DTR via
>> spi_nor_set_octal_dtr() and then runs:
>> 
>>   spi_nor_init()
>>     -> spi_nor_cache_sr_lock_bits()
>>       -> spi_nor_read_sr1_and_sr2_careful()
>>         -> spi_nor_read_sr2_careful()
>>           -> spi_nor_read_sr_ll()
>> 
>> wouldn't this still issue the unsupported 0x3535 register read in
>> SNOR_PROTO_8_8_8_DTR mode and fail probe or resume with a controller
>> timeout?
>
> Hi Miquel,
>
> The Sashiko AI review raised a valid point on v3.

Is it a valid point? Only Winbond flashes have something in SR2. It is
mentioning non SFDP compliant Micron devices. So this case never
actually happens.

> I see three ways to go, which do you prefer?
>
> 1, Keep the v3 approach (clear in spi_nor_parse_profile1()) and fix the remaining
>     cases one by one, clearing read_sr2 in each relevant fixup 
>     (e.g. mt35xu512aba_post_sfdp_fixup) / no-SFDP path.

This is my favorite option, as you can guess.

> 2, Move the clear into spi_nor_late_init_params(), gated on the 8D read capability
>     (hwcaps & SNOR_HWCAPS_READ_8_8_8_DTR) and read_sr2 == RDCR, so all 8D 
>     paths are covered in one place. 
>     The downside: late_init runs after the manufacturer fixups, so if a vendor later
>     wants to set its own SR2 opcode for 8D it would be clobbered here and overriding
>      it cleanly becomes awkward.
>
> 3, Go back to the v2 approach (clear in spi_nor_set_octal_dtr() when the switch to 8D
>     actually succeeds). This covers every path that ends up in 8D regardless of how the 
>     capability was discovered, but it is runtime-protocol based rather than capability 
>     based, which you didn't prefer earlier. And this method has the same downside as
>     method 2.

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/