drivers/mtd/spi-nor/core.c | 67 +++++++++++----------------------- drivers/mtd/spi-nor/core.h | 1 - drivers/mtd/spi-nor/spansion.c | 2 +- 3 files changed, 23 insertions(+), 47 deletions(-)
Try to simplify the flash initialization and get rid of the legacy handling. As default, all the flags of the in-kernel database are taken and amended with the SFDP data. This might have the consequence that all the flashes now get a RDSFPD opcode which might be an unknown opcode. But that was already the case for any flashes which were unknown to the linux kernel. So far, there was not a single complaint. See patch 3 for more information. If feedback is positive, this is intended to be applied to the spi-nor tree after the next merge window, so it will sit around in -next for quite some time and get some testing. That being said, I've just did a quick test on my boards. Please give it a test on your boards. Michael Walle (3): mtd: spi-nor: spansion: s25fl256s0: remove SKIP_SFDP flag mtd: spi-nor: don't clear the SNOR_F_4B_OPCODES flag on failure mtd: spi-nor: rework flash parameter initialization drivers/mtd/spi-nor/core.c | 67 +++++++++++----------------------- drivers/mtd/spi-nor/core.h | 1 - drivers/mtd/spi-nor/spansion.c | 2 +- 3 files changed, 23 insertions(+), 47 deletions(-) -- 2.47.3
Hi Michael, On 01/06/2026 at 14:52:42 +02, Michael Walle <mwalle@kernel.org> wrote: > Try to simplify the flash initialization and get rid of the legacy > handling. As default, all the flags of the in-kernel database are > taken and amended with the SFDP data. > > This might have the consequence that all the flashes now get a > RDSFPD opcode which might be an unknown opcode. But that was already > the case for any flashes which were unknown to the linux kernel. So > far, there was not a single complaint. > > See patch 3 for more information. If feedback is positive, this is > intended to be applied to the spi-nor tree after the next merge > window, so it will sit around in -next for quite some time and get > some testing. > > That being said, I've just did a quick test on my boards. Please > give it a test on your boards. Interesting cleanup, thanks for pushing it. I'll run some tests with some old and newer SFDP based flashes. I do not have chips without SFDP though. Thanks, Miquèl
Hi, > Hi Michael, > > On 01/06/2026 at 14:52:42 +02, Michael Walle <mwalle@kernel.org> wrote: > > > Try to simplify the flash initialization and get rid of the legacy > > handling. As default, all the flags of the in-kernel database are > > taken and amended with the SFDP data. > > > > This might have the consequence that all the flashes now get a > > RDSFPD opcode which might be an unknown opcode. But that was already > > the case for any flashes which were unknown to the linux kernel. So > > far, there was not a single complaint. > > > > See patch 3 for more information. If feedback is positive, this is > > intended to be applied to the spi-nor tree after the next merge > > window, so it will sit around in -next for quite some time and get > > some testing. > > > > That being said, I've just did a quick test on my boards. Please > > give it a test on your boards. > > Interesting cleanup, thanks for pushing it. I'll run some tests with > some old and newer SFDP based flashes. I do not have chips without SFDP > though. > I do have some non-SFDP chips (S25FL-S). Will get back to you with test result. Thanks, Takahiro
> Hi, > > > Hi Michael, > > > > On 01/06/2026 at 14:52:42 +02, Michael Walle <mwalle@kernel.org> wrote: > > > > > Try to simplify the flash initialization and get rid of the legacy > > > handling. As default, all the flags of the in-kernel database are > > > taken and amended with the SFDP data. > > > > > > This might have the consequence that all the flashes now get a > > > RDSFPD opcode which might be an unknown opcode. But that was already > > > the case for any flashes which were unknown to the linux kernel. So > > > far, there was not a single complaint. > > > > > > See patch 3 for more information. If feedback is positive, this is > > > intended to be applied to the spi-nor tree after the next merge > > > window, so it will sit around in -next for quite some time and get > > > some testing. > > > > > > That being said, I've just did a quick test on my boards. Please > > > give it a test on your boards. > > > > Interesting cleanup, thanks for pushing it. I'll run some tests with > > some old and newer SFDP based flashes. I do not have chips without SFDP > > though. > > > I do have some non-SFDP chips (S25FL-S). Will get back to you with test > result. With my AMD Zynq-7000 & Infineon internal SPI controller, s25fl128s0, s25fl128s1, and s25fl256s0 work fine. Here is the test log of s25fl256s0: zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/partname s25fl256s0 zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/jedec_id 0102194d0080 zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/manufacturer spansion zynq> xxd -p /sys/bus/spi/devices/spi0.0/spi-nor/sfdp xxd: /sys/bus/spi/devices/spi0.0/spi-nor/sfdp: No such file or directory xxd: /sys/bus/spi/devices/spi0.0/spi-nor/sfdp: Bad file descriptor zynq> md5sum /sys/bus/spi/devices/spi0.0/spi-nor/sfdp md5sum: can't open '/sys/bus/spi/devices/spi0.0/spi-nor/sfdp': No such file or directory zynq> test_spi.sh 2+0 records in 2+0 records out 2097152 bytes (2.0MB) copied, 0.074296 seconds, 26.9MB/s Erased 2097152 bytes from address 0x00000000 in flash Copied 2097152 bytes from address 0x00000000 in flash to spi_read 0000000 ffff ffff ffff ffff ffff ffff ffff ffff * 0200000 4bda3a28f4ffe603c0ec1258c0034d65a1a0d35ab7bd523a834608adabf03cc5 spi_read Copied 2097152 bytes from spi_test to address 0x00000000 in flash Copied 2097152 bytes from address 0x00000000 in flash to spi_read 1565a9e729e432053d204d569952d5ee6d669e0ace84a88d681b20e4600df356 spi_read 1565a9e729e432053d204d569952d5ee6d669e0ace84a88d681b20e4600df356 spi_test Erased 2097152 bytes from address 0x00000000 in flash Copied 2097152 bytes from address 0x00000000 in flash to spi_read 4bda3a28f4ffe603c0ec1258c0034d65a1a0d35ab7bd523a834608adabf03cc5 spi_read 1565a9e729e432053d204d569952d5ee6d669e0ace84a88d681b20e4600df356 spi_test zynq> cat /sys/kernel/debug/spi-nor/spi0.0/params name s25fl256s0 id 01 02 19 4d 00 80 size 32.0 MiB write size 1 page size 256 address nbytes 4 flags 4B_OPCODES | HAS_16BIT_SR opcodes read 0x6c dummy cycles 8 erase 0xdc program 0x12 8D extension none protocols read 1S-1S-4S write 1S-1S-1S register 1S-1S-1S erase commands d8 (256 KiB) [0] c7 (32.0 MiB) sector map region (in hex) | erase mask | overlaid ------------------+------------+---------- 00000000-01ffffff | [0 ] | no zynq> cat /sys/kernel/debug/spi-nor/spi0.0/capabilities Supported read modes by the flash 1S-1S-1S opcode 0x03 mode cycles 0 dummy cycles 0 1S-1S-1S (fast read) opcode 0x0b mode cycles 0 dummy cycles 8 1S-1S-2S opcode 0x3b mode cycles 0 dummy cycles 8 1S-1S-4S opcode 0x6b mode cycles 0 dummy cycles 8 Supported page program modes by the flash 1S-1S-1S opcode 0x02
© 2016 - 2026 Red Hat, Inc.