Re: [PATCH v2] mtd: spi-nor: clear the default RDCR opcode when entering Octal DTR

["Michael Walle" <michael@walle.cc>]

On Tue Sep 29, 2026 at 10:23 AM CEST, Miquel Raynal wrote:
> On 29/09/2026 at 14:53:07 +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). In
>> 8D-8D-8D mode the opcode is extended to two bytes per cmd_ext_type, but
>> the resulting command is not a valid SR2 read for these flashes, which
>> access their status/config registers through a vendor-specific indirect
>> register space. Since spi_nor_cache_sr_lock_bits() now reads SR2 during
>> init, i.e. after the switch to Octal DTR, the extended RDCR gets no data
>> back and the read times out (on i.MX FlexSPI: -ETIMEDOUT and a controller
>> WARN() during probe with Micron MT35xU and Macronix octal parts).
>>
>> Clear read_sr2 when the switch to Octal DTR actually succeeds, so the SR2
>> read is skipped (a cleared opcode already means "unsupported"). Doing it
>> in spi_nor_set_octal_dtr() keys off the real runtime protocol: a flash
>> that advertises Octal DTR but runs in (x)STR because the host lacks
>> support keeps its usable RDCR.
>>
>> Assisted-by: LLM
>> 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 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()).
>
> I don't get that choice. Why switching when Octal DTR succeeds only? SR2
> is either supported or not supported, I don't think it is anyway
> different when entering octal DTR mode, is it? So I would expect SR2 to
> be cleared earlier than that, once we know the chip is octal DTR
> capable. And this must be early enough so that manufacturer drivers can
> still set their own value.
>
> I am wondering whether we should simply drop sr2 opcode in the QER SFDP
> parsing entirely for octal DTR devices (Michael?).

This should probably be put into spi_nor_parse_profile1() and check
if command 15h (read configuration register according to JESD251D)
is supported or not. Would that work, Haibo Chen?

Honestly, I haven't done much with these high density NOR flashes,
so my knowledge is rather sparse. I've just skimmed over the JEDEC
docs.

-michael

>> - 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.
>
> Are you sure this is a valid case?