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

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

[Russell Senior]

I am running OpenWrt (master branch) on a Buffalo WZR600DHP. This
particular instance has MX25L12845E SPI NOR chips (I have another
WZR600DHP with Winbond W25Q128BVFG, but haven't tested there, just to
say they don't all necessarily use the same flash).

I just built a new firmware version last night, and it started
unhappily boot looping. The most recent previous build I had done was
from June. Boot looping messages look like this:

[...]
[    0.752843] printk: legacy bootconsole [early0] disabled
[    0.778756] spi-nor spi0.0: supply vcc not found, using dummy regulator
[    0.785909] spi-nor spi0.0: BFPT parsing failed. Please consider
using SPI_NOR_SKIP_SFDP when declaring the flash
[    0.796238] spi-nor spi0.0: probe with driver spi-nor failed with error -22
[    0.804457] spi-nor spi0.1: supply vcc not found, using dummy regulator
[    0.824085] i2c_dev: i2c /dev entries driver
[    0.830852] NET: Registered PF_INET6 protocol family
[    0.872875] Segment Routing with IPv6
[    0.876671] In-situ OAM (IOAM) with IPv6
[    0.880798] NET: Registered PF_PACKET protocol family
[    0.886278] 8021q: 802.1Q VLAN Support v1.8
[    0.921429] clk: Disabling unused clocks
[    0.925661] check access for rdinit=/init failed: -2, ignoring
[    0.932181] MTD: Couldn't look up '': -22
[    0.936335] /dev/root: Can't open blockdev
[    0.940520] VFS: Cannot open root device "" or unknown-block(0,0): error -6
[    0.947472] Please append a correct "root=" boot option; here are
the available partitions:
[    0.955831] 1f00           16384 mtdblock0
[    0.955843]  (driver?)
[    0.962379] List of all bdev filesystems:
[    0.966374]  squashfs
[    0.966379]
[    0.970139] Kernel panic - not syncing: VFS: Unable to mount root
fs on unknown-block(0,0)
[    0.978392] Rebooting in 1 seconds..

Between June and last night, OpenWrt had switched their kernel from a
6.12.x to a 6.18.x, so I immediately suspected something in that
transition was the culprit and demonstrated that by building the last
commit before the change to the 6.18.x kernel, and it worked. Then
tested the commit of the change to the 6.18.x kernel and it
bootlooped.

Then I started looking through the mtd changes between 6.12.x and
6.18.x and spotted 947c86e481a.

  commit 947c86e481a027ed5948434096e506f307bd7114
  Author: Cheng Ming Lin <chengminglin@mxic.com.tw>
  Date:   Mon Apr 7 15:53:58 2025 +0800

      mtd: spi-nor: macronix: Drop the redundant flash info fields

The following revert of just the part that affected my chip made the
bootloop vanish:

diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c
index e97f5cbd9aad2..3524ed08ff85d 100644
--- a/drivers/mtd/spi-nor/macronix.c
+++ b/drivers/mtd/spi-nor/macronix.c
@@ -132,7 +132,10 @@ static const struct flash_info macronix_nor_parts[] = {
        }, {
                /* MX25L12805D */
                .id = SNOR_ID(0xc2, 0x20, 0x18),
+               .name = "mx25l12805d",
+               .size = SZ_16M,
                .flags = SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP,
+               .no_sfdp_flags = SECT_4K,
        }, {
                /* MX25L25635E, MX25L25645G */
                .id = SNOR_ID(0xc2, 0x20, 0x19),
-- 
2.55.0


-- 
Russell Senior
russell@personaltelco.net

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

Re: 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

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

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

[Michael Walle]

Hi Russell,

Thanks for testing and reporting! Did you know

 ./scripts/get_maintainer.pl -f drivers/mtd/spi-nor/macronix.c

That way you get all mail addresses of the maintainers you can add
to your mail. Not everyone is subscribed to the mailinglist.

On Sat Aug 15, 2026 at 12:48 PM CEST, Russell Senior wrote:
> I am running OpenWrt (master branch) on a Buffalo WZR600DHP. This
> particular instance has MX25L12845E SPI NOR chips (I have another
> WZR600DHP with Winbond W25Q128BVFG, but haven't tested there, just to
> say they don't all necessarily use the same flash).

Did you actually look at the chip or do you just know because linux
is printing the name? FWIW, the name linux is printing isn't always
correct due to flash ID reuse. I'm just curious.

> I just built a new firmware version last night, and it started
> unhappily boot looping. The most recent previous build I had done was
> from June. Boot looping messages look like this:
>
> [...]
> [    0.752843] printk: legacy bootconsole [early0] disabled
> [    0.778756] spi-nor spi0.0: supply vcc not found, using dummy regulator
> [    0.785909] spi-nor spi0.0: BFPT parsing failed. Please consider
> using SPI_NOR_SKIP_SFDP when declaring the flash
> [    0.796238] spi-nor spi0.0: probe with driver spi-nor failed with error -22
> [    0.804457] spi-nor spi0.1: supply vcc not found, using dummy regulator
> [    0.824085] i2c_dev: i2c /dev entries driver
> [    0.830852] NET: Registered PF_INET6 protocol family
> [    0.872875] Segment Routing with IPv6
> [    0.876671] In-situ OAM (IOAM) with IPv6
> [    0.880798] NET: Registered PF_PACKET protocol family
> [    0.886278] 8021q: 802.1Q VLAN Support v1.8
> [    0.921429] clk: Disabling unused clocks
> [    0.925661] check access for rdinit=/init failed: -2, ignoring
> [    0.932181] MTD: Couldn't look up '': -22
> [    0.936335] /dev/root: Can't open blockdev
> [    0.940520] VFS: Cannot open root device "" or unknown-block(0,0): error -6
> [    0.947472] Please append a correct "root=" boot option; here are
> the available partitions:
> [    0.955831] 1f00           16384 mtdblock0
> [    0.955843]  (driver?)
> [    0.962379] List of all bdev filesystems:
> [    0.966374]  squashfs
> [    0.966379]
> [    0.970139] Kernel panic - not syncing: VFS: Unable to mount root
> fs on unknown-block(0,0)
> [    0.978392] Rebooting in 1 seconds..
>
> Between June and last night, OpenWrt had switched their kernel from a
> 6.12.x to a 6.18.x, so I immediately suspected something in that
> transition was the culprit and demonstrated that by building the last
> commit before the change to the 6.18.x kernel, and it worked. Then
> tested the commit of the change to the 6.18.x kernel and it
> bootlooped.
>
> Then I started looking through the mtd changes between 6.12.x and
> 6.18.x and spotted 947c86e481a.
>
>   commit 947c86e481a027ed5948434096e506f307bd7114
>   Author: Cheng Ming Lin <chengminglin@mxic.com.tw>
>   Date:   Mon Apr 7 15:53:58 2025 +0800
>
>       mtd: spi-nor: macronix: Drop the redundant flash info fields
>
> The following revert of just the part that affected my chip made the
> bootloop vanish:
>
> diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c
> index e97f5cbd9aad2..3524ed08ff85d 100644
> --- a/drivers/mtd/spi-nor/macronix.c
> +++ b/drivers/mtd/spi-nor/macronix.c
> @@ -132,7 +132,10 @@ static const struct flash_info macronix_nor_parts[] = {
>         }, {
>                 /* MX25L12805D */
>                 .id = SNOR_ID(0xc2, 0x20, 0x18),
> +               .name = "mx25l12805d",
> +               .size = SZ_16M,
>                 .flags = SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP,
> +               .no_sfdp_flags = SECT_4K,
>         }, {
>                 /* MX25L25635E, MX25L25645G */
>                 .id = SNOR_ID(0xc2, 0x20, 0x19),

Yeah, that commit removed the size assuming there will only be parts
with SFDP for that ID.

There is already a patch series which addresses that issue, but it
wasn't picked up yet.

  https://lore.kernel.org/all/20260605084837.1875896-1-linchengming884@gmail.com/

Russell, could you try to apply that series to your tree and try
again? If it works, give that series a Tested-by tag?

If you didn't know, there is a tool called b4
(https://b4.docs.kernel.org/en/latest/), which can be used to fetch
the patches from the mailingist (b4 am). Also, if you want to reply
to that patches, you can import the thread into your mailbox using
the "lei" (https://korg.docs.kernel.org/lore-lei.html).

Thanks,
-michael

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