Re: Regression: mx25l12845e stops working on my device after commit 947c86e481a

From: Cheng Ming Lin <linchengming884@gmail.com>
To: Russell Senior <russell@personaltelco.net>
Cc: linux-mtd@lists.infradead.org,
	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>,
	Takahiro Kuwano <takahiro.kuwano@infineon.com>
Subject: Re: Regression: mx25l12845e stops working on my device after commit 947c86e481a
Date: Tue, 18 Aug 2026 13:29:16 +0800	[thread overview]
Message-ID: <20260818052916.135931-1-chengminglin@mxic.com.tw> (raw)
In-Reply-To: <CAHP3WfMMK8GU3jpwxv4=C=Pc_9H4ZkmqAJqxZ0gN_rYqPDU3XQ@mail.gmail.com>

Hi Russell,

Thanks for the report, and for narrowing it down to that commit.

Some background on commit 947c86e481a0 ("mtd: spi-nor: macronix: Drop
the redundant flash info fields"): it dropped .name/.size/.no_sfdp_flags
from that entry, because from that point on all of those parameters are
supposed to come from the flash's SFDP tables. spi_nor_needs_sfdp() keys
off .size being zero:

  static inline bool spi_nor_needs_sfdp(const struct spi_nor *nor)
  {
          return !nor->info->size;
  }

so once .size is gone, SFDP parsing becomes mandatory and any failure is
fatal (-EINVAL) instead of silently falling back to the legacy values.
That is exactly the path you are hitting:

  spi-nor spi0.0: BFPT parsing failed. Please consider using
  SPI_NOR_SKIP_SFDP when declaring the flash
  spi-nor spi0.0: probe with driver spi-nor failed with error -22

MX25L12845E does have an SFDP table, so in principle the entry without
.size should work. Please see the datasheet:

Link: https://www.mxic.com.tw/Lists/Datasheet/Attachments/8693/MX25L12845E,%203V,%20128Mb,%20v1.9.pdf

section "(33) Read SFDP Mode (RDSFDP)". It documents SFDP as per JEDEC
JESD216 v1.0: signature "SFDP" (50444653h) at offset 00h, two parameter
headers (the JEDEC Basic Flash Parameter Table, 9 DWORDs at PTP 30h, and
a Macronix vendor table, 4 DWORDs at PTP 60h), and the flash density
field at 37h:34h reads 07FFFFFFh, i.e. 128Mb / 16MB. So a part that
answers RDSFDP correctly should get its size discovered just fine.

This makes me suspect that the part on your board is not returning a
valid SFDP table, so the driver ends up with no flash size at all and
bails out.

In my opinion the best way forward here is a local patch for the single
flash that is affected: just add the size back in your own tree, and
your board will boot again.

Thanks,
Cheng Ming Lin

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