Re: [PATCH v2 2/2] mtd: spi-nor: macronix: enable quad/dual speed for mx25l3205d chips

[Esben Haabendal]

Tudor Ambarus <tudor.ambarus@xxxxxxxxxx> writes:

> On 6/3/24 14:09, Esben Haabendal wrote:
>> Macronix engineers apparantly do not understand the purpose of having
>> an ID actually identify the chip and its capabilities. Sigh.
>> 
>> The original Macronix SPI NOR flash that identifies itself as 0xC22016
>> with RDID was MX25L3205D. This chip does not support SFDP, but does
>> support the 2READ command (1-2-2).
>> 
>> When Macronix announced EoL for MX25L3205D, the recommended
>> replacement part was MX25L3206E, which conveniently also identifies
>> itself as 0xC22016. It does not support 2READ, but supports DREAD
>> (1-1-2) instead, and supports SFDP for discovering this.
>> 
>> When Macronix announced EoL for MX25L3206E, the recommended
>> replacement part was MX25L3233F, which also identifies itself as
>> 0xC22016. It supports DREAD, 2READ, and the quad modes QREAD (1-1-4)
>> and 4READ (1-4-4). This also support SFDP.
>> 
>> So far, all of these chips have been handled the same way by the Linux
>> driver. The SFDP information have not been read, and no dual and quad
>> read modes have been enabled.
>> 
>> The trouble begins when we want to enable the faster read modes. The
>> RDID command only return the same 3 bytes for all 3 chips, so that
>> doesn't really help.
>> 
>> Instead, we can use the SPI_NOR_TRY_SFDP flag, which forces the spi-nor
>> system to try using SFDP, but fallback to the parameters specified in
>> struct flash_info.
>> 
>> This way, boards using MX25L3205D will continue as before this change.
>> That is without taking advantage of the 1-2-2 that it supports.
>> 
>> For MX25L3206E and MX25L3233F, the SFDP parameters are used, and they will
>> therefore be using the optimal dual or quad mode supported by the flash
>> and the SPI controller it is attached to.
>> 
>> Signed-off-by: Esben Haabendal <esben@xxxxxxxxxx>
>> ---
>>  drivers/mtd/spi-nor/macronix.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c
>> index ea6be95e75a5..090f28e05a5d 100644
>> --- a/drivers/mtd/spi-nor/macronix.c
>> +++ b/drivers/mtd/spi-nor/macronix.c
>> @@ -61,7 +61,7 @@ static const struct flash_info macronix_nor_parts[] = {
>>  		.id = SNOR_ID(0xc2, 0x20, 0x16),
>>  		.name = "mx25l3205d",
>>  		.size = SZ_4M,
>> -		.no_sfdp_flags = SECT_4K,
>> +		.no_sfdp_flags = SECT_4K | SPI_NOR_TRY_SFDP,
>>  	}, {
>
> let's remove support for MX25L3205D. You'll then be able to drop the
> flash entry altogether and instead rely on SFDP to discover the flash's
> capabilities.

So anybody updating their Linux kernel for boards using MX25L3205D will
get a bad surprise? While in the embedded world, upgrading Linux kernel
is not the common case, it doesn't seem right to knowingly make it
difficult to those few who actually tries to do the right thing.

/Esben