Re: [PATCH v4] mtd: spi-nor: clear the default read_sr2 opcode for Octal DTR flashes

[Miquel Raynal <miquel.raynal@bootlin.com>]

On 22/10/2026 at 18:45:16 +08, haibo.chen@oss.nxp.com wrote:

> 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 (or resume) fails (on i.MX FlexSPI: -ETIMEDOUT and a controller
> WARN(), seen with a Micron MT35XU01G and a Macronix MX25UW51345G).
>
> Clear read_sr2 on every path that enables 8D-8D-8D, so that
> 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.
>
> - spi_nor_parse_profile1(): the common case. The xSPI Profile 1.0 table
>   does not describe any SR2/RDCR read, and it runs before the
>   manufacturer late_init.
> - mt35xu512aba_post_sfdp_fixup(): some mt35xu512aba batches lack the
>   Profile 1.0 table and enable 8D here instead, with the BFPT QER field
>   left at a reserved value so read_sr2 keeps its RDCR default.
> - spi_nor_no_sfdp_init_params(): non-SFDP parts that enable 8D via
>   SPI_NOR_OCTAL_DTR_READ keep the RDCR default too.
>
> 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")

Is this still relevant?

> Fixes: 63489002d397 ("mtd: spi-nor: Refactor Read Status/Write Status
> support")

Will be merged in the next cycle, so Cc: stable is probably required.

> Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
> ---

Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>

> Changes in v4:
> - Following the Sashiko review and Miquel's preference, keep the
>   capability-based clear but cover every path that enables 8D-8D-8D, not
>   only the xSPI Profile 1.0 one:
>     - spi_nor_parse_profile1() (the common case, already in v3),
>     - mt35xu512aba_post_sfdp_fixup(): some batches lack the 8D command
>       info in SFDP so Profile 1.0 parsing may not clear it,
>     - spi_nor_no_sfdp_init_params(): non-SFDP parts using
>       SPI_NOR_OCTAL_DTR_READ.
> - Checked all vendor drivers; Micron is the only one that enables 8D
>   outside Profile 1.0 parsing. Macronix and Cypress rely on Profile
> 1.0.

Winbond as well (see my W25QxxPW series).

Thanks,
Miquèl