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

[Cheng Ming Lin]

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