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

[Tudor.Ambarus at microchip.com]

On 6/23/21 10:17 AM, jaimeliao at mxic.com.tw wrote:
> You don't often get email from jaimeliao at 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?