[PATCH 6.6.y] mtd: spi-nor: macronix: Add post_sfdp fixups for Quad Input Page Program

[PATCH 6.6.y] mtd: spi-nor: macronix: Add post_sfdp fixups for Quad Input Page Program

[Cheng Ming Lin]

From: Cheng Ming Lin <chengminglin@mxic.com.tw>

commit 798aafeffb369c5eb36e406b18970ef27baa820d upstream.

Although certain Macronix NOR flash support the Quad Input Page Program
feature, the corresponding information in the 4-byte Address Instruction
Table of these flash is not properly filled. As a result, this feature
cannot be enabled as expected.

To address this issue, a post_sfdp fixups implementation is required to
correct the missing information.

Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw>
Link: https://lore.kernel.org/r/20250211063028.382169-2-linchengming884@gmail.com
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
 drivers/mtd/spi-nor/macronix.c | 33 ++++++++++++++++++++++++++++-----
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c
index eb149e517c1f..b676a71822a3 100644
--- a/drivers/mtd/spi-nor/macronix.c
+++ b/drivers/mtd/spi-nor/macronix.c
@@ -28,8 +28,26 @@ mx25l25635_post_bfpt_fixups(struct spi_nor *nor,
 	return 0;
 }
 
+static int
+macronix_qpp4b_post_sfdp_fixups(struct spi_nor *nor)
+{
+	/* PP_1_1_4_4B is supported but missing in 4BAIT. */
+	struct spi_nor_flash_parameter *params = nor->params;
+
+	params->hwcaps.mask |= SNOR_HWCAPS_PP_1_1_4;
+	spi_nor_set_pp_settings(&params->page_programs[SNOR_CMD_PP_1_1_4],
+				SPINOR_OP_PP_1_1_4_4B, SNOR_PROTO_1_1_4);
+
+	return 0;
+}
+
 static const struct spi_nor_fixups mx25l25635_fixups = {
 	.post_bfpt = mx25l25635_post_bfpt_fixups,
+	.post_sfdp = macronix_qpp4b_post_sfdp_fixups,
+};
+
+static const struct spi_nor_fixups macronix_qpp4b_fixups = {
+	.post_sfdp = macronix_qpp4b_post_sfdp_fixups,
 };
 
 static const struct flash_info macronix_nor_parts[] = {
@@ -81,7 +99,8 @@ static const struct flash_info macronix_nor_parts[] = {
 		FIXUP_FLAGS(SPI_NOR_4B_OPCODES) },
 	{ "mx25u51245g", INFO(0xc2253a, 0, 64 * 1024, 1024)
 		NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
-		FIXUP_FLAGS(SPI_NOR_4B_OPCODES) },
+		FIXUP_FLAGS(SPI_NOR_4B_OPCODES)
+		.fixups = &macronix_qpp4b_fixups },
 	{ "mx25uw51245g", INFOB(0xc2813a, 0, 0, 0, 4)
 		PARSE_SFDP
 		FLAGS(SPI_NOR_RWW) },
@@ -91,18 +110,22 @@ static const struct flash_info macronix_nor_parts[] = {
 	{ "mx25l25655e", INFO(0xc22619, 0, 64 * 1024, 512) },
 	{ "mx66l51235f", INFO(0xc2201a, 0, 64 * 1024, 1024)
 		NO_SFDP_FLAGS(SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
-		FIXUP_FLAGS(SPI_NOR_4B_OPCODES) },
+		FIXUP_FLAGS(SPI_NOR_4B_OPCODES)
+		.fixups = &macronix_qpp4b_fixups },
 	{ "mx66u51235f", INFO(0xc2253a, 0, 64 * 1024, 1024)
 		NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
-		FIXUP_FLAGS(SPI_NOR_4B_OPCODES) },
+		FIXUP_FLAGS(SPI_NOR_4B_OPCODES)
+		.fixups = &macronix_qpp4b_fixups },
 	{ "mx66l1g45g",  INFO(0xc2201b, 0, 64 * 1024, 2048)
 		NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ |
-			      SPI_NOR_QUAD_READ) },
+			      SPI_NOR_QUAD_READ)
+		.fixups = &macronix_qpp4b_fixups },
 	{ "mx66l1g55g",  INFO(0xc2261b, 0, 64 * 1024, 2048)
 		NO_SFDP_FLAGS(SPI_NOR_QUAD_READ) },
 	{ "mx66u2g45g",	 INFO(0xc2253c, 0, 64 * 1024, 4096)
 		NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
-		FIXUP_FLAGS(SPI_NOR_4B_OPCODES) },
+		FIXUP_FLAGS(SPI_NOR_4B_OPCODES)
+		.fixups = &macronix_qpp4b_fixups },
 };
 
 static void macronix_nor_default_init(struct spi_nor *nor)
-- 
2.25.1


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

[PATCH 6.6.y] mtd: spi-nor: macronix: add support for mx66{l2, u1}g45g

[Cheng Ming Lin]

From: Cheng Ming Lin <chengminglin@mxic.com.tw>

commit 797bbaa7531f75985b199e484451fa3f954382b3 upstream.

Due to incorrect values in the 4-BAIT table for these two flash IDs,
it is necessary to add these two flash IDs with fixups.

Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw>
Link: https://lore.kernel.org/r/20250211063028.382169-3-linchengming884@gmail.com
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
 drivers/mtd/spi-nor/macronix.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c
index b676a71822a3..b3ba7ad94711 100644
--- a/drivers/mtd/spi-nor/macronix.c
+++ b/drivers/mtd/spi-nor/macronix.c
@@ -116,10 +116,16 @@ static const struct flash_info macronix_nor_parts[] = {
 		NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
 		FIXUP_FLAGS(SPI_NOR_4B_OPCODES)
 		.fixups = &macronix_qpp4b_fixups },
+	/* MX66U1G45G */
+	{ INFO(0xc2253b, 0, 0, 0)
+		.fixups = &macronix_qpp4b_fixups },
 	{ "mx66l1g45g",  INFO(0xc2201b, 0, 64 * 1024, 2048)
 		NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ |
 			      SPI_NOR_QUAD_READ)
 		.fixups = &macronix_qpp4b_fixups },
+	/* MX66L2G45G */
+	{ INFO(0xc2201c, 0, 0, 0)
+		.fixups = &macronix_qpp4b_fixups },
 	{ "mx66l1g55g",  INFO(0xc2261b, 0, 64 * 1024, 2048)
 		NO_SFDP_FLAGS(SPI_NOR_QUAD_READ) },
 	{ "mx66u2g45g",	 INFO(0xc2253c, 0, 64 * 1024, 4096)
-- 
2.25.1


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

Re: [PATCH 6.6.y] mtd: spi-nor: macronix: Add post_sfdp fixups for Quad Input Page Program

[Sasha Levin]

I can't take this series for 6.6.y: patch 2 adds flash_info entries
with a NULL .name, and 6.6's spi_nor_match_name() has no NULL guard
(only added upstream in ac5bfa968b60), so the legacy probe-by-name
path can oops at boot.

Please send a v2 that either names the new entries or backports
ac5bfa968b60 first.

The 6.12.y series is queued, thanks.

-- 
Thanks,
Sasha

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

Re: [PATCH 6.6.y] mtd: spi-nor: macronix: Add post_sfdp fixups for Quad Input Page Program

[Cheng Ming Lin]

Hi Sasha,

Sasha Levin <sashal@kernel.org> 於 2026年7月2日週四 上午8:38寫道：
>
> I can't take this series for 6.6.y: patch 2 adds flash_info entries
> with a NULL .name, and 6.6's spi_nor_match_name() has no NULL guard
> (only added upstream in ac5bfa968b60), so the legacy probe-by-name
> path can oops at boot.

Thank you for pointing this out and catching the potential issue.

I have verified this, and you are absolutely right. The issue stems from
the strcmp(name, manufacturers[i]->parts[j].name) evaluation within the
legacy probe path. Since 6.6.y lacks the null guard, passing a NULL .name
will result in a null pointer dereference in strcmp() and cause a kernel
oops during boot.

I will add the .name to the new flash entries and submit a v2 series.

>
> Please send a v2 that either names the new entries or backports
> ac5bfa968b60 first.
>
> The 6.12.y series is queued, thanks.
>
> --
> Thanks,
> Sasha

Thanks,
Cheng Ming Lin

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

Re: [PATCH 6.6.y] mtd: spi-nor: macronix: Add post_sfdp fixups for Quad Input Page Program

[Michael Walle]

[-- Attachment #1.1: Type: text/plain, Size: 1437 bytes --]

On Thu Jul 2, 2026 at 4:13 AM CEST, Cheng Ming Lin wrote:
> Hi Sasha,
>
> Sasha Levin <sashal@kernel.org> 於 2026年7月2日週四 上午8:38寫道：
>>
>> I can't take this series for 6.6.y: patch 2 adds flash_info entries
>> with a NULL .name, and 6.6's spi_nor_match_name() has no NULL guard
>> (only added upstream in ac5bfa968b60), so the legacy probe-by-name
>> path can oops at boot.
>
> Thank you for pointing this out and catching the potential issue.
>
> I have verified this, and you are absolutely right. The issue stems from
> the strcmp(name, manufacturers[i]->parts[j].name) evaluation within the
> legacy probe path. Since 6.6.y lacks the null guard, passing a NULL .name
> will result in a null pointer dereference in strcmp() and cause a kernel
> oops during boot.
>
> I will add the .name to the new flash entries and submit a v2 series.

No, please backport the needed patches. The reason is that the name
shouldn't become something an application relies on (it is also
exposed via sysfs).

For all people not too involved: we are dropping the name for new
flash additions, because it is almost always wrong, due to flash id
reuse among almost all flash vendors.

-michael

>
>>
>> Please send a v2 that either names the new entries or backports
>> ac5bfa968b60 first.
>>
>> The 6.12.y series is queued, thanks.
>>
>> --
>> Thanks,
>> Sasha
>
> Thanks,
> Cheng Ming Lin


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]

[-- Attachment #2: Type: text/plain, Size: 144 bytes --]

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

Re: [PATCH 6.6.y] mtd: spi-nor: macronix: Add post_sfdp fixups for Quad Input Page Program

[Cheng Ming Lin]

Hi Michael,

Michael Walle <mwalle@kernel.org> 於 2026年7月2日週四 下午2:44寫道：
>
> On Thu Jul 2, 2026 at 4:13 AM CEST, Cheng Ming Lin wrote:
> > Hi Sasha,
> >
> > Sasha Levin <sashal@kernel.org> 於 2026年7月2日週四 上午8:38寫道：
> >>
> >> I can't take this series for 6.6.y: patch 2 adds flash_info entries
> >> with a NULL .name, and 6.6's spi_nor_match_name() has no NULL guard
> >> (only added upstream in ac5bfa968b60), so the legacy probe-by-name
> >> path can oops at boot.
> >
> > Thank you for pointing this out and catching the potential issue.
> >
> > I have verified this, and you are absolutely right. The issue stems from
> > the strcmp(name, manufacturers[i]->parts[j].name) evaluation within the
> > legacy probe path. Since 6.6.y lacks the null guard, passing a NULL .name
> > will result in a null pointer dereference in strcmp() and cause a kernel
> > oops during boot.
> >
> > I will add the .name to the new flash entries and submit a v2 series.
>
> No, please backport the needed patches. The reason is that the name
> shouldn't become something an application relies on (it is also
> exposed via sysfs).
>
> For all people not too involved: we are dropping the name for new
> flash additions, because it is almost always wrong, due to flash id
> reuse among almost all flash vendors.

Thank you for the clarification regarding the upstream policy on dropping
flash names. That makes perfect sense given the ID reuse issues.

Unfortunately, our emails crossed paths, and I had already submitted the
v2 series (which adds the .name back) just before seeing your message.
Please disregard the v2 submission.

To follow your guidance, I will prepare a v3 series.
My plan is to:

1. Backport commit ac5bfa968b60 ("mtd: spi-nor: fix flash probing") as the
first patch in the v3 series to resolve the NULL pointer dereference issue
in 6.6.y.

2. Send my flash addition patches (without the .name field, using comments
instead) as the subsequent patches in the series.

Does this structure for the v3 series look good to you?

>
> -michael
>
> >
> >>
> >> Please send a v2 that either names the new entries or backports
> >> ac5bfa968b60 first.
> >>
> >> The 6.12.y series is queued, thanks.
> >>
> >> --
> >> Thanks,
> >> Sasha
> >
> > Thanks,
> > Cheng Ming Lin
>

Thanks,
Cheng Ming Lin

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

Re: [PATCH 6.6.y] mtd: spi-nor: macronix: Add post_sfdp fixups for Quad Input Page Program

[Michael Walle]

[-- Attachment #1.1: Type: text/plain, Size: 483 bytes --]

Hi,

> To follow your guidance, I will prepare a v3 series.
> My plan is to:
>
> 1. Backport commit ac5bfa968b60 ("mtd: spi-nor: fix flash probing") as the
> first patch in the v3 series to resolve the NULL pointer dereference issue
> in 6.6.y.
>
> 2. Send my flash addition patches (without the .name field, using comments
> instead) as the subsequent patches in the series.
>
> Does this structure for the v3 series look good to you?

Sounds good to me.

-michael

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]

[-- Attachment #2: Type: text/plain, Size: 144 bytes --]

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