Re: [spi-nor] Macronix MX25L requires CR read opcode 0x15 (not 0x35)

From: Pratyush Yadav <pratyush@kernel.org>
To: Maarten Zanders <maarten@zanders.be>
Cc: Tudor Ambarus <tudor.ambarus@microchip.com>,
	 Pratyush Yadav <pratyush@kernel.org>,
	 linux-mtd@lists.infradead.org
Subject: Re: [spi-nor] Macronix MX25L requires CR read opcode 0x15 (not 0x35)
Date: Mon, 01 Sep 2025 16:46:02 +0200	[thread overview]
Message-ID: <mafs0plcaw7rp.fsf@kernel.org> (raw)
In-Reply-To: <CAPB_pELpdie+=VB3h3tqZCkdTd9cKyhnYNmXjeP1vYODDricLw@mail.gmail.com>

Hi,

On Fri, Aug 22 2025, Maarten Zanders wrote:

> Hi all,
>
> On the Macronix MX25L12833F (ID 0xC22018) & others of this family/mfg,
> the CR (condition register) must be read with opcode 0x15. The driver
> currently uses 0x35, which the chip does not recognize.

Is it one of those devices for which Macronix has re-used the flash IDs?
I vaguely recall reading that somewhere. If so, then we also need to be
careful of breaking the older variants of the flash.

>
> Datasheet: https://www.macronix.com/Lists/Datasheet/Attachments/8934/MX25L12833F,%203V,%20128Mb,%20v1.0.pdf
> (p.27, RDCR).
>
> With 0x35 the data line floats and the driver reads CR as 0xFF
> (depending on previous state of the line or pull up/down). This value
> is then written back in spi_nor_write_16bit_sr_and_check(), setting CR
> to 0xFF. One consequence is flipping the OTP Top/Bottom protection
> bit, so from then on, locking the top block actually locks the bottom
> sector. This breaks bootloader updates (in my case) and similar flows.
>
> Possible fixes:

Is it at all possible to discover the opcode from the flash SFDP table
(SCCR map perhaps)? If so, I think that would be the best way forward
since it would be generic.

There is the SNOR_F_NO_READ_CR flag that seems to do what you want. In
spi_nor_write_16bit_sr_and_check(), if the flag is set it does not issue
the read CR command and either sets the second byte to 0 or to
SR2_QUAD_EN_BIT1. The flag can be discovered via BFPT (see
spi_nor_parse_bfpt()). Is the BFPT table on the flash incorrect? In that
case, perhaps we should add a post-BFPT fixup?

> - Make CR read opcode configurable per device.
> - Force Macronix parts to 8-bit SR accesses (clear SNOR_F_HAS_16BIT_SR).
> - Implement T/B bit handling for Macronix (needed for already-fielded
> devices with flipped OTP bit, but complicated by non-uniform
> protection blocks).
>
> What would be the preferred approach? Other ideas? Anyone seen similar
> with Macronix parts?
> A quick fix which can be backported easily and the full implementation
> later on would be beneficial IMHO.
>
> Thanks,
> Maarten

-- 
Regards,
Pratyush Yadav

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