Skip to contentSkip to conversation

mtd: spi-nor: core: Ignore -ENOTSUPP in spi_nor_init()

PATCH Applied Mika Westerberg 4 participants 9 messages Sep 23, 2022 – Oct 18, 2022

Subsystems (2)
Memory technology devices (MTD) SPI NOR
lore
Share & tools
lore

Mika Westerberg

author
#0 lore raw

PATCH v2 1/1 mtd: spi-nor: core: Ignore -ENOTSUPP in spi_nor_init()

The Intel SPI-NOR controller does not support the 4-byte address opcode so ->set_4byte_addr_mode() ends up returning -ENOTSUPP and the SPI flash chip probe fail like this:

  [ 12.291082] spi-nor: probe of spi0.0 failed with error -524

Whereas previously before commit 08412e72afba ("mtd: spi-nor: core:
Return error code from set_4byte_addr_mode()") it worked just fine.

Fix this by ignoring -ENOTSUPP in spi_nor_init().

Fixes 08412e72afba ("mtd: spi-nor: core: Return error code from set_4byte_addr_mode()")
Cc [email protected]
Reported-by Hongyu Ning <[email protected]>
Signed-off-by Mika Westerberg <[email protected]>

---
The previous version of the patch (the revert) can be found here:

https://lore.kernel.org/linux-mtd/[email protected]/

In this version we ignore -ENOTSUPP but the other error codes will be passed to the caller.

 drivers/mtd/spi-nor/core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/mtd/spi-nor/core.c +3 -1
index f2c64006f8d7..bee8fc4c9f07 100644
@@ -2724,7 +2724,9 @@ static int spi_nor_init(struct spi_nor *nor)
 		 */
 		WARN_ONCE(nor->flags & SNOR_F_BROKEN_RESET,
 			  "enabling reset hack; may not recover from unexpected reboots\n");
-		return nor->params->set_4byte_addr_mode(nor, true);
+		err = nor->params->set_4byte_addr_mode(nor, true);
+		if (err && err != -ENOTSUPP)
+			return err;
 	}
 
 	return 0;
Signature · 6 lines
2.35.1


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Reviewed-by on v2 1/1
#1 lore raw

Am 2022-09-23 11:34, schrieb Mika Westerberg:

Quoted 9 lines

The Intel SPI-NOR controller does not support the 4-byte address opcode so ->set_4byte_addr_mode() ends up returning -ENOTSUPP and the SPI flash chip probe fail like this:

  [ 12.291082] spi-nor: probe of spi0.0 failed with error -524

Whereas previously before commit 08412e72afba ("mtd: spi-nor: core:
Return error code from set_4byte_addr_mode()") it worked just fine.

Quoted 7 lines

Fix this by ignoring -ENOTSUPP in spi_nor_init().

Fixes 08412e72afba ("mtd: spi-nor: core: Return error code from

set_4byte_addr_mode()")

Cc [email protected]
Reported-by Hongyu Ning <[email protected]>
Signed-off-by Mika Westerberg <[email protected]>
Reviewed-by Michael Walle <[email protected]>

-michael

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

#2 lore raw
In reply to Mika Westerberg

On 9/23/22 12:34, Mika Westerberg wrote:

Hi, Mika,

Quoted 33 lines

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

The Intel SPI-NOR controller does not support the 4-byte address opcode so ->set_4byte_addr_mode() ends up returning -ENOTSUPP and the SPI flash chip probe fail like this:

  [ 12.291082] spi-nor: probe of spi0.0 failed with error -524

Whereas previously before commit 08412e72afba ("mtd: spi-nor: core:
Return error code from set_4byte_addr_mode()") it worked just fine.

Fix this by ignoring -ENOTSUPP in spi_nor_init().

Fixes 08412e72afba ("mtd: spi-nor: core: Return error code from set_4byte_addr_mode()")
Cc [email protected]
Reported-by Hongyu Ning <[email protected]>
Signed-off-by Mika Westerberg <[email protected]>

---
The previous version of the patch (the revert) can be found here:

https://lore.kernel.org/linux-mtd/[email protected]/

In this version we ignore -ENOTSUPP but the other error codes will be passed to the caller.

 drivers/mtd/spi-nor/core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/mtd/spi-nor/core.c +0 -0
index f2c64006f8d7..bee8fc4c9f07 100644

drivers/mtd/spi-nor/core.c static int spi_nor_init(struct spi_nor *nor) · line 2730

Quoted 8 lines
drivers/mtd/spi-nor/core.c +3 -1
@@ -2724,7 +2724,9 @@ static int spi_nor_init(struct spi_nor *nor)
                 */
                WARN_ONCE(nor->flags & SNOR_F_BROKEN_RESET,
                          "enabling reset hack; may not recover from unexpected reboots\n");
-               return nor->params->set_4byte_addr_mode(nor, true);
+               err = nor->params->set_4byte_addr_mode(nor, true);
+               if (err && err != -ENOTSUPP)
+                       return err;
        }

So as of now if you use a flash larger than 16 MBytes, you can't access above 16 MBytes, right? What happens at the controller side when it receives a nor->addr_nbytes of value 4?

Shouldn't spi_mem_supports_op() trim the 4-byte ops?

The better fix to me would be to extend the SPI NOR core to support the Extended Address Register which consists of the 4th byte of memory address when the flash is operated in 3-byte address mode.

Signature · 5 lines
Cheers,
ta
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
author
#3 lore raw

Hi,

Quoted 41 lines · On Mon, Oct 03, 2022 at 05:04:26AM +0000, [email protected] wrote:

On 9/23/22 12:34, Mika Westerberg wrote:

Hi, Mika,

Quoted 37 lines

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

The Intel SPI-NOR controller does not support the 4-byte address opcode so ->set_4byte_addr_mode() ends up returning -ENOTSUPP and the SPI flash chip probe fail like this:

  [ 12.291082] spi-nor: probe of spi0.0 failed with error -524

Whereas previously before commit 08412e72afba ("mtd: spi-nor: core:
Return error code from set_4byte_addr_mode()") it worked just fine.

Fix this by ignoring -ENOTSUPP in spi_nor_init().

Fixes 08412e72afba ("mtd: spi-nor: core: Return error code from set_4byte_addr_mode()")
Cc [email protected]
Reported-by Hongyu Ning <[email protected]>
Signed-off-by Mika Westerberg <[email protected]>

---
The previous version of the patch (the revert) can be found here:

https://lore.kernel.org/linux-mtd/[email protected]/

In this version we ignore -ENOTSUPP but the other error codes will be passed to the caller.

 drivers/mtd/spi-nor/core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/mtd/spi-nor/core.c +0 -1
index f2c64006f8d7..bee8fc4c9f07 100644
@@ -2724,7 +2724,9 @@ static int spi_nor_init(struct spi_nor *nor)
                 */
                WARN_ONCE(nor->flags & SNOR_F_BROKEN_RESET,
                          "enabling reset hack; may not recover from unexpected reboots\n");
-               return nor->params->set_4byte_addr_mode(nor, true);
Quoted 8 lines

drivers/mtd/spi-nor/core.c static int spi_nor_init(struct spi_nor *nor) · line 2730

Quoted 4 lines
drivers/mtd/spi-nor/core.c +3 -0
+               err = nor->params->set_4byte_addr_mode(nor, true);
+               if (err && err != -ENOTSUPP)
+                       return err;
        }

So as of now if you use a flash larger than 16 MBytes, you can't access above 16 MBytes, right? What happens at the controller side when it receives a nor->addr_nbytes of value 4?

The Intel controller does not really expose any of these operations to the CPU so the only thing the driver can do is to tell the SPI-NOR core that this is not supported.

Quoted 6 lines

Shouldn't spi_mem_supports_op() trim the 4-byte ops?

The better fix to me would be to extend the SPI NOR core to support the Extended Address Register which consists of the 4th byte of memory address when the flash is operated in 3-byte address mode.

This is also something the Intel controller does not expose to the CPU so I'm not sure if I have any means to test this approach.

My point is that currently all the Intel SPI users are basically broken in v6.0 because of the commit 08412e72afba so shouldn't that be dealt first and then look at any possible improments?

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

#4 lore raw
Quoted 55 lines · Mika Westerberg

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

Hi,

Quoted 41 lines · On Mon, Oct 03, 2022 at 05:04:26AM +0000, [email protected] wrote:

On 9/23/22 12:34, Mika Westerberg wrote:

Hi, Mika,

Quoted 37 lines

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

The Intel SPI-NOR controller does not support the 4-byte address opcode so ->set_4byte_addr_mode() ends up returning -ENOTSUPP and the SPI flash chip probe fail like this:

  [ 12.291082] spi-nor: probe of spi0.0 failed with error -524

Whereas previously before commit 08412e72afba ("mtd: spi-nor: core:
Return error code from set_4byte_addr_mode()") it worked just fine.

Fix this by ignoring -ENOTSUPP in spi_nor_init().

Fixes 08412e72afba ("mtd: spi-nor: core: Return error code from set_4byte_addr_mode()")
Cc [email protected]
Reported-by Hongyu Ning <[email protected]>
Signed-off-by Mika Westerberg <[email protected]>

---
The previous version of the patch (the revert) can be found here:

https://lore.kernel.org/linux-mtd/[email protected]/

In this version we ignore -ENOTSUPP but the other error codes will be passed to the caller.

 drivers/mtd/spi-nor/core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/mtd/spi-nor/core.c +0 -1
index f2c64006f8d7..bee8fc4c9f07 100644
@@ -2724,7 +2724,9 @@ static int spi_nor_init(struct spi_nor *nor)
                 */
                WARN_ONCE(nor->flags & SNOR_F_BROKEN_RESET,
                          "enabling reset hack; may not recover from unexpected reboots\n");
-               return nor->params->set_4byte_addr_mode(nor, true);
Quoted 8 lines

drivers/mtd/spi-nor/core.c static int spi_nor_init(struct spi_nor *nor) · line 2730

Quoted 4 lines
drivers/mtd/spi-nor/core.c +3 -0
+               err = nor->params->set_4byte_addr_mode(nor, true);
+               if (err && err != -ENOTSUPP)
+                       return err;
        }

So as of now if you use a flash larger than 16 MBytes, you can't access above 16 MBytes, right? What happens at the controller side when it receives a nor->addr_nbytes of value 4?

Quoted 3 lines

The Intel controller does not really expose any of these operations to the CPU so the only thing the driver can do is to tell the SPI-NOR core that this is not supported.

That would be good. And you'll get a non-working flash anyway. But I was asking something else. There should be an address register in the controller. If you write 4 address bytes, the forth is ignored, or why does it work? You'll at least get inconsistent results and always write in the first 16 Mbytes regardless of the value of the 4th byte of address.

Quoted 10 lines
Quoted 7 lines

Shouldn't spi_mem_supports_op() trim the 4-byte ops?

The better fix to me would be to extend the SPI NOR core to support the Extended Address Register which consists of the 4th byte of memory address when the flash is operated in 3-byte address mode.

This is also something the Intel controller does not expose to the CPU so I'm not sure if I have any means to test this approach.

would you please remind me what you mean with "expose to the CPU"? I thought about that the intel-spi controller can inform the SPI NOR core that it doesn't support 4-byte addresses and then the core to take that information and use the EAR register. Would that be possible?

Quoted 4 lines

My point is that currently all the Intel SPI users are basically broken in v6.0 because of the commit 08412e72afba so shouldn't that be dealt first and then look at any possible improments?

Right, I got you from the first time, I just wanted to highlight that the intel-spi controller and the SPI NOR core behave badly, and they should be fixed. Your patch fixes a regression of a somewhat working flash, so probably it should be applied for the time being. But I'd really love a proper fix.

Signature · 5 lines
Cheers,
ta
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
author
#5 lore raw

Hi,

Quoted 60 lines · On Mon, Oct 03, 2022 at 05:52:42AM +0000, [email protected] wrote:
Quoted 55 lines · Mika Westerberg

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

Hi,

Quoted 41 lines · On Mon, Oct 03, 2022 at 05:04:26AM +0000, [email protected] wrote:

On 9/23/22 12:34, Mika Westerberg wrote:

Hi, Mika,

Quoted 37 lines

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

The Intel SPI-NOR controller does not support the 4-byte address opcode so ->set_4byte_addr_mode() ends up returning -ENOTSUPP and the SPI flash chip probe fail like this:

  [ 12.291082] spi-nor: probe of spi0.0 failed with error -524

Whereas previously before commit 08412e72afba ("mtd: spi-nor: core:
Return error code from set_4byte_addr_mode()") it worked just fine.

Fix this by ignoring -ENOTSUPP in spi_nor_init().

Fixes 08412e72afba ("mtd: spi-nor: core: Return error code from set_4byte_addr_mode()")
Cc [email protected]
Reported-by Hongyu Ning <[email protected]>
Signed-off-by Mika Westerberg <[email protected]>

---
The previous version of the patch (the revert) can be found here:

https://lore.kernel.org/linux-mtd/[email protected]/

In this version we ignore -ENOTSUPP but the other error codes will be passed to the caller.

 drivers/mtd/spi-nor/core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/mtd/spi-nor/core.c +0 -1
index f2c64006f8d7..bee8fc4c9f07 100644
@@ -2724,7 +2724,9 @@ static int spi_nor_init(struct spi_nor *nor)
                 */
                WARN_ONCE(nor->flags & SNOR_F_BROKEN_RESET,
                          "enabling reset hack; may not recover from unexpected reboots\n");
-               return nor->params->set_4byte_addr_mode(nor, true);
Quoted 8 lines

drivers/mtd/spi-nor/core.c static int spi_nor_init(struct spi_nor *nor) · line 2730

Quoted 4 lines
drivers/mtd/spi-nor/core.c +3 -0
+               err = nor->params->set_4byte_addr_mode(nor, true);
+               if (err && err != -ENOTSUPP)
+                       return err;
        }

So as of now if you use a flash larger than 16 MBytes, you can't access above 16 MBytes, right? What happens at the controller side when it receives a nor->addr_nbytes of value 4?

Quoted 3 lines

The Intel controller does not really expose any of these operations to the CPU so the only thing the driver can do is to tell the SPI-NOR core that this is not supported.

Quoted 5 lines

That would be good. And you'll get a non-working flash anyway. But I was asking something else. There should be an address register in the controller. If you write 4 address bytes, the forth is ignored, or why does it work? You'll at least get inconsistent results and always write in the first 16 Mbytes regardless of the value of the 4th byte of address.

It works because the Intel SPI controller is not a real "SPI" controller so instead of all the low lever operations it simply exposes bunch of high-level commands such as read and write. All the rest is handled internally by the controller so it knows (I think based on the SFDP information and possibly something else part of the BIOS image) the supported address length.

Quoted 7 lines
Quoted 7 lines
Quoted 6 lines

Shouldn't spi_mem_supports_op() trim the 4-byte ops?

The better fix to me would be to extend the SPI NOR core to support the Extended Address Register which consists of the 4th byte of memory address when the flash is operated in 3-byte address mode.

Quoted 7 lines
Quoted 2 lines

This is also something the Intel controller does not expose to the CPU so I'm not sure if I have any means to test this approach.

would you please remind me what you mean with "expose to the CPU"? I thought about that the intel-spi controller can inform the SPI NOR core that it doesn't support 4-byte addresses and then the core to take that information and use the EAR register. Would that be possible?

The controller only exposes a couple of high-level operations that we can perform in software through the register interface. There is no way to access EAR register or anything like that. This high-level commands to read and write status register but that's pretty much all.

For completeness here are all the possible commands it supports (in hardware sequencig mode which is the one used with the modern chips):

0 Read (1 up to 64 bytes by setting FDBC)
1 Reserved
2 Write (1 up to 64 bytes by setting FDBC)
3 4k Block Erase
4 64k Sector erase
5 Read SFDP
6 Read JEDEC ID
7 write status
8 read status
9 RPMC Op1
A RPMC Op2

Quoted 9 lines
Quoted 4 lines

My point is that currently all the Intel SPI users are basically broken in v6.0 because of the commit 08412e72afba so shouldn't that be dealt first and then look at any possible improments?

Right, I got you from the first time, I just wanted to highlight that the intel-spi controller and the SPI NOR core behave badly, and they should be fixed. Your patch fixes a regression of a somewhat working flash, so probably it should be applied for the time being. But I'd really love a proper fix.

I'm fine to have a "proper" fix but just wanted to mention that this is real regression that is currently visible to users.

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

Acked-by on v2 1/1
#6 lore raw
In reply to Mika Westerberg

Hi, Miquel,

It's too late for me to queue patches for next, but I'd like to have this patch integrated as it solves a regression. Would you queue it to mtd/next?

Thanks,
ta

Quoted 11 lines · Mika Westerberg

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

The Intel SPI-NOR controller does not support the 4-byte address opcode so ->set_4byte_addr_mode() ends up returning -ENOTSUPP and the SPI flash chip probe fail like this:

  [ 12.291082] spi-nor: probe of spi0.0 failed with error -524

Whereas previously before commit 08412e72afba ("mtd: spi-nor: core:
Return error code from set_4byte_addr_mode()") it worked just fine.

Quoted 6 lines

Fix this by ignoring -ENOTSUPP in spi_nor_init().

Fixes 08412e72afba ("mtd: spi-nor: core: Return error code from set_4byte_addr_mode()")
Cc [email protected]
Reported-by Hongyu Ning <[email protected]>
Signed-off-by Mika Westerberg <[email protected]>
Acked-by Tudor Ambarus <[email protected]>
Quoted 29 lines

---
The previous version of the patch (the revert) can be found here:

https://lore.kernel.org/linux-mtd/[email protected]/

In this version we ignore -ENOTSUPP but the other error codes will be passed to the caller.

 drivers/mtd/spi-nor/core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/mtd/spi-nor/core.c +3 -2
index f2c64006f8d7..bee8fc4c9f07 100644
@@ -2724,7 +2724,9 @@ static int spi_nor_init(struct spi_nor *nor)
                 */
                WARN_ONCE(nor->flags & SNOR_F_BROKEN_RESET,
                          "enabling reset hack; may not recover from unexpected reboots\n");
-               return nor->params->set_4byte_addr_mode(nor, true);
+               err = nor->params->set_4byte_addr_mode(nor, true);
+               if (err && err != -ENOTSUPP)
+                       return err;
        }
 
        return 0;
--

2.35.1

Signature · 6 lines
Cheers,
ta

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
#7 lore raw
Quoted 7 lines · On 10/6/22 07:41, [email protected] wrote:

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

Hi, Miquel,

It's too late for me to queue patches for next, but I'd like to have this patch integrated as it solves a regression. Would you queue it to mtd/next?

A bit of context. You'll see the following checkpatch warning:
WARNING: ENOTSUPP is not a SUSV4 error code, prefer EOPNOTSUPP

It comes from SPI. We should evaluate if we can s/ENOTSUPP/EOPNOTSUPP in SPI, but we can do it later on. I prefer this patch instead of reverting the offending commit, as it does not ignore other errors.

Quoted 59 lines · Mika Westerberg
Quoted 11 lines

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

The Intel SPI-NOR controller does not support the 4-byte address opcode so ->set_4byte_addr_mode() ends up returning -ENOTSUPP and the SPI flash chip probe fail like this:

  [ 12.291082] spi-nor: probe of spi0.0 failed with error -524

Whereas previously before commit 08412e72afba ("mtd: spi-nor: core:
Return error code from set_4byte_addr_mode()") it worked just fine.

Quoted 6 lines

Fix this by ignoring -ENOTSUPP in spi_nor_init().

Fixes 08412e72afba ("mtd: spi-nor: core: Return error code from set_4byte_addr_mode()")
Cc [email protected]
Reported-by Hongyu Ning <[email protected]>
Signed-off-by Mika Westerberg <[email protected]>
Acked-by Tudor Ambarus <[email protected]>
Quoted 27 lines

---
The previous version of the patch (the revert) can be found here:

https://lore.kernel.org/linux-mtd/[email protected]/

In this version we ignore -ENOTSUPP but the other error codes will be passed to the caller.

 drivers/mtd/spi-nor/core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/mtd/spi-nor/core.c +3 -2
index f2c64006f8d7..bee8fc4c9f07 100644
@@ -2724,7 +2724,9 @@ static int spi_nor_init(struct spi_nor *nor)
                 */
                WARN_ONCE(nor->flags & SNOR_F_BROKEN_RESET,
                          "enabling reset hack; may not recover from unexpected reboots\n");
-               return nor->params->set_4byte_addr_mode(nor, true);
+               err = nor->params->set_4byte_addr_mode(nor, true);
+               if (err && err != -ENOTSUPP)
+                       return err;
        }
 
        return 0;
--
Quoted 2 lines

2.35.1

--
Cheers,
ta

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

Signature · 6 lines
Cheers,
ta

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
maintainer Applied
#8 lore raw
In reply to Mika Westerberg
Quoted 9 lines · Mika Westerberg

The Intel SPI-NOR controller does not support the 4-byte address opcode so ->set_4byte_addr_mode() ends up returning -ENOTSUPP and the SPI flash chip probe fail like this:

  [ 12.291082] spi-nor: probe of spi0.0 failed with error -524

Whereas previously before commit 08412e72afba ("mtd: spi-nor: core:
Return error code from set_4byte_addr_mode()") it worked just fine.

Quoted 8 lines

Fix this by ignoring -ENOTSUPP in spi_nor_init().

Fixes 08412e72afba ("mtd: spi-nor: core: Return error code from set_4byte_addr_mode()")
Cc [email protected]
Reported-by Hongyu Ning <[email protected]>
Signed-off-by Mika Westerberg <[email protected]>
Reviewed-by Michael Walle <[email protected]>
Acked-by Tudor Ambarus <[email protected]>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/fixes, thanks.

Miquel

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