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

[Bough Chen (OSS)]

> -----Original Message-----
> From: Miquel Raynal <miquel.raynal at bootlin.com>
> Sent: Thursday, October 22, 2026 6:51 PM
> To: Bough Chen (OSS) <haibo.chen at oss.nxp.com>
> Cc: Pratyush Yadav <pratyush at kernel.org>; Michael Walle
> <mwalle at kernel.org>; Takahiro Kuwano <takahiro.kuwano at infineon.com>;
> Richard Weinberger <richard at nod.at>; Vignesh Raghavendra
> <vigneshr at ti.com>; linux-mtd at lists.infradead.org; linux-
> kernel at vger.kernel.org; imx at lists.linux.dev; michael at walle.cc; Bough Chen
> <haibo.chen at nxp.com>
> Subject: Re: [PATCH v4] mtd: spi-nor: clear the default read_sr2 opcode for
> Octal DTR flashes
> 
> On 22/10/2026 at 18:45:16 +08, haibo.chen at oss.nxp.com wrote:
> 
> > From: Haibo Chen <haibo.chen at 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?

It just trigger the issue, but not the root cause.
I will remove it in next version.

> 
> > Fixes: 63489002d397 ("mtd: spi-nor: Refactor Read Status/Write Status
> > support")
> 
> Will be merged in the next cycle, so Cc: stable is probably required.

Yes, will add it.

> 
> > Signed-off-by: Haibo Chen <haibo.chen at nxp.com>
> > ---
> 
> Reviewed-by: Miquel Raynal <miquel.raynal at bootlin.com>

Thanks!

Regards
Haibo Chen
> 
> > 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