Re: 回信: Re: [RFC 2/3] mtd: spi-nor: core: compare JEDEC bytes to already found flash_info

From: <Tudor.Ambarus@microchip.com>
To: <jaimeliao@mxic.com.tw>, <michael@walle.cc>
Cc: <bbrezillon@kernel.org>, <esben@geanix.com>,
	<frieder.schrempf@kontron.de>, <linux@rasmusvillemoes.dk>,
	<linux-kernel@vger.kernel.org>, <linux-mtd@lists.infradead.org>,
	<masonccyang@mxic.com.tw>, <p.yadav@ti.com>, <ycllin@mxic.com.tw>,
	<zhengxunli@mxic.com.tw>
Subject: Re: 回信: Re: [RFC 2/3] mtd: spi-nor: core: compare JEDEC bytes to already found flash_info
Date: Wed, 23 Jun 2021 08:33:15 +0000	[thread overview]
Message-ID: <dcd4e64f-348c-fadd-1044-61c7b6fa93c8@microchip.com> (raw)
In-Reply-To: <OF7CD5328D.D33B2BE2-ON482586FD.0027BCF2-482586FD.00280249@mxic.com.tw>

On 6/23/21 10:17 AM, jaimeliao@mxic.com.tw wrote:
> You don't often get email from jaimeliao@mxic.com.tw. Learn why this is important<http://aka.ms/LearnAboutSenderIdentification>
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> Hi Michael and Rasmus
> 
> 
>>
>> Re: [RFC 2/3] mtd: spi-nor: core: compare JEDEC bytes to already
>> found flash_info
>>
>> [+ some people from MXIC as they are ones who posted to the ML
>> lately. Feel free to forward this mail to the corresponding people.]
>>
>> Am 2021-06-21 17:23, schrieb Rasmus Villemoes:
>>> Macronix engineers, in their infinite wisdom, have a habit of reusing
>>> JEDEC ids for different chips. There's already one
>>> workaround (MX25L25635F v MX25L25635E), but the same problem exists
>>> for MX25L3205D v MX25L3233F, the latter of which is not currently
>>> supported by linux.
>>>
>>> AFAICT, that case cannot really be handled with any of the ->fixup
>>> machinery: The correct entry for the MX25L3233F would read
>>>
>>>         { "mx25l3233f",  INFO(0xc22016, 0, 64 * 1024,  64, SECT_4K |
>>> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ ) },
>>>
>>> while the existing one is
>>>
>>>    { "mx25l3205d",  INFO(0xc22016, 0, 64 * 1024,  64, SECT_4K) },
>>>
>>> So in spi_nor_init_params(), we won't even try reading the sfdp
>>> info (i.e. call spi_nor_sfdp_init_params), and hence
>>> spi_nor_post_sfdp_fixups() has no way of distinguishing the
>>> chips.
>>>
>>> Replacing the existing entry with the mx25l3233f one to coerce the
>>> core into issuing the SPINOR_OP_RDSFDP is also not really an option,
>>> because the data sheet for the mx25l3205d explicitly says not to issue
>>> any commands not listed ("It is not recommended to adopt any other
>>> code not in the command definition table, which will potentially enter
>>> the hidden mode.", whatever that means).
>>
>> Maybe we should ask Macronix if it is safe to send the RDSFDP command.
>> Can anyone from MXIC comment this?
> 
> For this part, we have validate RDSFDP command on some different chips which
> are not support SFDP mode. The conclusion is that Flash didn't reply anything.
> But we still not suggest to using commands which are not supported on the Flash.
> 
>> This is also interesting because we are discussing reading the SFDP
>> without reading the ID first.
> 
> I think this idea is good but I am not sure how other vendor chips will react
> after getting the commands which are not supported on the flash.

Do any of these flashed define an extended ID, i.e. more that 3 bytes of ID?
Rasmus, would you please try to read more bytes of ID?

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