Re: [PATCH v4 3/6] mtd: spi-nor: macronix: Handle ID collision b/w MX25L3233F and MX25L3205D

From: Michael Walle <michael@walle.cc>
To: Tudor.Ambarus@microchip.com
Cc: sr@denx.de, vigneshr@ti.com, jaimeliao@mxic.com.tw,
	richard@nod.at, esben@geanix.com, linux@rasmusvillemoes.dk,
	knaerzche@gmail.com, Nicolas.Ferre@microchip.com,
	linux-mtd@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, macromorgan@hotmail.com,
	miquel.raynal@bootlin.com, heiko.thiery@gmail.com,
	zhengxunli@mxic.com.tw, p.yadav@ti.com, mail@david-bauer.net,
	code@reto-schneider.ch
Subject: Re: [PATCH v4 3/6] mtd: spi-nor: macronix: Handle ID collision b/w MX25L3233F and MX25L3205D
Date: Thu, 03 Mar 2022 16:33:14 +0100	[thread overview]
Message-ID: <6bb1aafe7e156db8dfcf77f04a9d100e@walle.cc> (raw)
In-Reply-To: <d6e3dae6-fc46-1697-e496-33ab11469807@microchip.com>

Am 2022-03-03 16:28, schrieb Tudor.Ambarus@microchip.com:
> On 3/1/22 23:57, Michael Walle wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know 
>> the content is safe
>> 
>> Am 2022-02-28 14:45, schrieb Tudor Ambarus:
>>> Macronix has a bad habbit of reusing flash IDs. While MX25L3233F
>>> supports
>>> RDSFDP opcode, MX25L3205D does not support it and does not recommend
>>> issuing opcodes that are not supported ("It is not recommended to 
>>> adopt
>>> any other code not in the command definition table, which will
>>> potentially
>>> enter the hidden mode.").
>>> 
>>> We tested the RDSFDP on the MX25L3205D and the conclusion is that the
>>> flash didn't reply anything. Given that it is unlikely that RDSFDP 
>>> will
>>> cause any problems for the old MX25L3205D, differentiate between the
>>> two
>>> flashes by parsing SFDP.
>>> 
>>> Tested MX25L3233F. Generated a 256 Kbyte random data and did an 
>>> erase,
>>> write, read back and compare test. The flash uses for reads
>>> SPINOR_OP_READ_1_4_4 0xeb, for erases SPINOR_OP_BE_4K 0x20, and for
>>> writes
>>> SPINOR_OP_PP 0x02.
>>> 
>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
>>> Acked-by: Pratyush Yadav <p.yadav@ti.com>
>>> ---
>>> #  cat
>>> /sys/devices/platform/ahb/ahb:apb/f0020000.spi/spi_master/spi1/spi1.0/spi-nor/jedec_id
>>> c22016
>>> # cat
>>> /sys/devices/platform/ahb/ahb:apb/f0020000.spi/spi_master/spi1/spi1.0/spi-nor/manufacturer
>>> macronix
>>> # cat
>>> /sys/devices/platform/ahb/ahb:apb/f0020000.spi/spi_master/spi1/spi1.0/spi-nor/partname
>>> mx25l3233f
>>> # cat
>>> /sys/devices/platform/ahb/ahb:apb/f0020000.spi/spi_master/spi1/spi1.0/spi-nor/sfdp
>>> > mx25l3233f-sfdp
>>> 
>>> 
>>> # xxd -p mx25l3233f-sfdp
>>> 53464450000101ff00000109300000ffc2000104600000ffffffffffffff
>>> ffffffffffffffffffffffffffffffffffffe520f1ffffffff0144eb086b
>>> 083b04bbeeffffffffff00ffffff00ff0c200f5210d800ffffffffffffff
>>> ffffffffffff003650269cf97764fecfffffffffffff
>> 
>> Is quad enable working or has this the same problem as
>> the macronix flash in patch 4? Judging by the length of the SFDP
>> this also lacks the required information to select an
>> appropriate enable method. I haven't had closer look though.
> 
> it worked, yes. As I specified in the commit message, I tested it and 
> it used
> SPINOR_OP_READ_1_4_4 0xeb opcode for reads.

I'm confused, why is Heiko reporting that the CR/SR writing isn't
working because a wrong quad_enable method is chosen, but here it
will work. What am I missing?

-michael

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