From: Esben Haabendal <esben@geanix.com>
To: Tudor Ambarus <tudor.ambarus@linaro.org>
Cc: Pratyush Yadav <pratyush@kernel.org>,
Michael Walle <mwalle@kernel.org>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Subject: Re: [PATCH v2 2/2] mtd: spi-nor: macronix: enable quad/dual speed for mx25l3205d chips
Date: Thu, 06 Jun 2024 19:23:25 +0200 [thread overview]
Message-ID: <87v82m9e9e.fsf@geanix.com> (raw)
In-Reply-To: <cdd6bc25-6282-4e43-9909-16ab918ed983@linaro.org> (Tudor Ambarus's message of "Thu, 6 Jun 2024 14:33:16 +0100")
Tudor Ambarus <tudor.ambarus@linaro.org> 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@geanix.com>
>> ---
>> 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
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Esben Haabendal <esben@geanix.com>
To: Tudor Ambarus <tudor.ambarus@linaro.org>
Cc: Pratyush Yadav <pratyush@kernel.org>,
Michael Walle <mwalle@kernel.org>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Subject: Re: [PATCH v2 2/2] mtd: spi-nor: macronix: enable quad/dual speed for mx25l3205d chips
Date: Thu, 06 Jun 2024 19:23:25 +0200 [thread overview]
Message-ID: <87v82m9e9e.fsf@geanix.com> (raw)
In-Reply-To: <cdd6bc25-6282-4e43-9909-16ab918ed983@linaro.org> (Tudor Ambarus's message of "Thu, 6 Jun 2024 14:33:16 +0100")
Tudor Ambarus <tudor.ambarus@linaro.org> 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@geanix.com>
>> ---
>> 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
next prev parent reply other threads:[~2024-06-06 17:23 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-03 13:09 [PATCH v2 0/2] mtd: spi-nor: macronix: workaround for device id re-use Esben Haabendal
2024-06-03 13:09 ` Esben Haabendal
2024-06-03 13:09 ` [PATCH v2 1/2] mtd: spi-nor: core: add flag for doing optional SFDP Esben Haabendal
2024-06-03 13:09 ` Esben Haabendal
2024-06-06 13:31 ` Tudor Ambarus
2024-06-06 13:31 ` Tudor Ambarus
2024-06-06 13:59 ` Michael Walle
2024-06-06 13:59 ` Michael Walle
2024-06-06 14:52 ` Tudor Ambarus
2024-06-06 14:52 ` Tudor Ambarus
2024-06-06 15:06 ` Michael Walle
2024-06-06 15:06 ` Michael Walle
2024-06-06 17:20 ` Esben Haabendal
2024-06-06 17:20 ` Esben Haabendal
2024-06-07 9:22 ` Tudor Ambarus
2024-06-07 9:22 ` Tudor Ambarus
2024-06-07 13:30 ` Esben Haabendal
2024-06-07 13:30 ` Esben Haabendal
2024-06-12 8:51 ` Michael Walle
2024-06-12 8:51 ` Michael Walle
2024-06-06 17:20 ` Esben Haabendal
2024-06-06 17:20 ` Esben Haabendal
2024-07-10 18:42 ` Esben Haabendal
2024-07-10 18:42 ` Esben Haabendal
2024-07-11 9:02 ` Michael Walle
2024-07-11 9:02 ` Michael Walle
2024-07-11 11:55 ` Esben Haabendal
2024-07-11 11:55 ` Esben Haabendal
2024-06-06 17:13 ` Esben Haabendal
2024-06-06 17:13 ` Esben Haabendal
2024-06-03 13:09 ` [PATCH v2 2/2] mtd: spi-nor: macronix: enable quad/dual speed for mx25l3205d chips Esben Haabendal
2024-06-03 13:09 ` Esben Haabendal
2024-06-06 13:33 ` Tudor Ambarus
2024-06-06 13:33 ` Tudor Ambarus
2024-06-06 17:23 ` Esben Haabendal [this message]
2024-06-06 17:23 ` Esben Haabendal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v82m9e9e.fsf@geanix.com \
--to=esben@geanix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=mwalle@kernel.org \
--cc=pratyush@kernel.org \
--cc=rasmus.villemoes@prevas.dk \
--cc=richard@nod.at \
--cc=tudor.ambarus@linaro.org \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.