Skip to contentSkip to conversation

SF: Migrate to Linux SPI NOR framework

PATCH New Vignesh R 10 participants 71 messages Dec 12, 2018 – Jan 28, 2019

Subsystems (11)
lore
Share & tools
lore

Vignesh R

author maintainer
#0 lore raw

cover SF: Migrate to Linux SPI NOR framework

U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
This patch series syncs SPI NOR framework from Linux v4.19. It also adds spi-mem support on top.
So, we gain 4byte addressing support and SFDP support. This makes migrating to U-Boot MTD framework easier.

Tested with few Spansion, micron and macronix flashes with TI's dra7xx, k2g, am43xx EVMs. I dont have access to flashes from other vendors. So, I would greatly appreciate testing on other platforms. Complete series with dependencies here[1]

For clean build on some platforms, depends on CONFIG_SPI_FLASH migration to defconfigs [2]

[1] https://github.com/r-vignesh/u-boot.git branch: spi-nor-mig-patch-v1
[2] https://patchwork.ozlabs.org/patch/1007485/

Patch 12-15 are compile tested.

Change log:
Since RFC v2:
Fix issues reported by Simon Goldschmidt wrt 4 use of byte addressing opcode Fix issues in compiling SFDP code
Re organize file names and Makefile to simply spi-nor-tiny inclusion Remove SPI_FLASH_BAR and SF_DUAL_FLASH as these are no longer used RFC v2: https://patchwork.ozlabs.org/cover/1007589/

Since RFC v1:
Add lightweight SPI flash stack for boards with SPL size constraints Provide non DM version of spi-mem
Fix build issues on different platforms as reported by travis-ci on v1

RFC v1: https://patchwork.ozlabs.org/cover/1004689/

Vignesh R (16):
spi: spi-mem: Allow use of spi_mem_exec_op for all SPI modes
spi-mem: Claim SPI bus before spi mem access
spi: Add non DM version of SPI_MEM
sh: bitops: add hweight*() macros
mtd: spi: Port SPI NOR framework from Linux
mtd: spi: Switch to new SPI NOR framework
mtd: spi: Remove unused files
mtd: spi: Add lightweight SPI flash stack for SPL
sf_mtd: Simply mtd operations
configs: Get rid of SPI_FLASH_BAR
configs: Remove SF_DUAL_FLASH
axm_defconfig: Enable simple malloc in SPL
taurus_defconfig: Enable simple malloc in SPL
da850_am18xxevm: Enable tiny printf
turris_omnia_defconfig: Enable tiny printf
MAINTAINERS: Add an entry for SPI NOR

 MAINTAINERS                                   |    8 +
 arch/arm/mach-omap2/am33xx/Kconfig            |    1 -
 arch/sh/include/asm/bitops.h                  |    4 +
 common/spl/Kconfig                            |   21 +-
 configs/alt_defconfig                         |    1 -
 configs/am57xx_evm_defconfig                  |    1 -
 configs/am57xx_hs_evm_defconfig               |    1 -
 configs/ap121_defconfig                       |    1 -
 configs/ap143_defconfig                       |    1 -
 configs/avnet_ultra96_rev1_defconfig          |    1 -
 configs/axm_defconfig                         |    1 +
 configs/axs101_defconfig                      |    1 -
 configs/axs103_defconfig                      |    1 -
 configs/bg0900_defconfig                      |    1 -
 configs/blanche_defconfig                     |    1 -
 configs/cl-som-am57x_defconfig                |    1 -
 configs/clearfog_defconfig                    |    1 -
 configs/cm_t43_defconfig                      |    1 -
 configs/da850_am18xxevm_defconfig             |    1 +
 configs/db-88f6820-amc_defconfig              |    1 -
 configs/display5_defconfig                    |    1 -
 configs/display5_factory_defconfig            |    1 -
 configs/dra7xx_evm_defconfig                  |    1 -
 configs/dra7xx_hs_evm_defconfig               |    1 -
 configs/ds109_defconfig                       |    1 -
 configs/ds414_defconfig                       |    1 -
 configs/evb-rv1108_defconfig                  |    1 -
 configs/gose_defconfig                        |    1 -
 configs/helios4_defconfig                     |    1 -
 configs/k2g_evm_defconfig                     |    1 -
 configs/k2g_hs_evm_defconfig                  |    1 -
 configs/koelsch_defconfig                     |    1 -
 configs/lager_defconfig                       |    1 -
 configs/maxbcm_defconfig                      |    1 -
 configs/mt7629_rfb_defconfig                  |    1 -
 configs/mx6sxsabreauto_defconfig              |    1 -
 configs/mx6sxsabresd_defconfig                |    1 -
 configs/mx6ul_14x14_evk_defconfig             |    1 -
 configs/mx6ul_9x9_evk_defconfig               |    1 -
 configs/mx6ull_14x14_evk_defconfig            |    1 -
 configs/mx6ull_14x14_evk_plugin_defconfig     |    1 -
 configs/mx7dsabresd_qspi_defconfig            |    1 -
 configs/porter_defconfig                      |    1 -
 configs/r8a77970_eagle_defconfig              |    1 -
 configs/silk_defconfig                        |    1 -
 configs/socfpga_arria5_defconfig              |    1 -
 configs/socfpga_cyclone5_defconfig            |    1 -
 configs/socfpga_is1_defconfig                 |    1 -
 configs/socfpga_sockit_defconfig              |    1 -
 configs/socfpga_socrates_defconfig            |    1 -
 configs/socfpga_sr1500_defconfig              |    1 -
 configs/socfpga_stratix10_defconfig           |    1 -
 configs/stout_defconfig                       |    1 -
 configs/taurus_defconfig                      |    1 +
 configs/topic_miami_defconfig                 |    1 -
 configs/topic_miamilite_defconfig             |    2 -
 configs/topic_miamiplus_defconfig             |    2 -
 configs/turris_omnia_defconfig                |    2 +-
 configs/xilinx_versal_virt_defconfig          |    1 -
 configs/xilinx_zynqmp_mini_qspi_defconfig     |    2 -
 configs/xilinx_zynqmp_zc1232_revA_defconfig   |    2 -
 configs/xilinx_zynqmp_zc1254_revA_defconfig   |    2 -
 configs/xilinx_zynqmp_zc1275_revA_defconfig   |    2 -
 configs/xilinx_zynqmp_zc1275_revB_defconfig   |    2 -
 .../xilinx_zynqmp_zc1751_xm015_dc1_defconfig  |    1 -
 .../xilinx_zynqmp_zc1751_xm016_dc2_defconfig  |    1 -
 .../xilinx_zynqmp_zc1751_xm018_dc4_defconfig  |    1 -
 configs/xilinx_zynqmp_zcu100_revC_defconfig   |    1 -
 configs/xilinx_zynqmp_zcu102_rev1_0_defconfig |    1 -
 configs/xilinx_zynqmp_zcu102_revA_defconfig   |    1 -
 configs/xilinx_zynqmp_zcu102_revB_defconfig   |    1 -
 configs/xilinx_zynqmp_zcu104_revA_defconfig   |    2 -
 configs/xilinx_zynqmp_zcu104_revC_defconfig   |    2 -
 configs/xilinx_zynqmp_zcu106_revA_defconfig   |    2 -
 configs/xilinx_zynqmp_zcu111_revA_defconfig   |    1 -
 configs/zynq_cc108_defconfig                  |    1 -
 configs/zynq_cse_qspi_defconfig               |    1 -
 configs/zynq_dlc20_rev1_0_defconfig           |    1 -
 configs/zynq_microzed_defconfig               |    1 -
 configs/zynq_minized_defconfig                |    1 -
 configs/zynq_z_turn_defconfig                 |    1 -
 configs/zynq_zc702_defconfig                  |    1 -
 configs/zynq_zc706_defconfig                  |    1 -
 configs/zynq_zc770_xm010_defconfig            |    1 -
 configs/zynq_zc770_xm013_defconfig            |    1 -
 configs/zynq_zed_defconfig                    |    1 -
 configs/zynq_zybo_defconfig                   |    1 -
 configs/zynq_zybo_z7_defconfig                |    1 -
 doc/SPI/README.dual-flash                     |   92 -
 doc/SPI/README.ti_qspi_dra_test               |    1 -
 drivers/mtd/spi/Kconfig                       |   22 +-
 drivers/mtd/spi/Makefile                      |   12 +-
 drivers/mtd/spi/sandbox.c                     |   36 +-
 drivers/mtd/spi/sf_dataflash.c                |   11 +-
 drivers/mtd/spi/sf_internal.h                 |  230 +-
 drivers/mtd/spi/sf_mtd.c                      |   52 +-
 drivers/mtd/spi/sf_probe.c                    |   38 +-
 drivers/mtd/spi/spi-nor-core.c                | 2334 +++++++++++++++++
 drivers/mtd/spi/spi-nor-ids.c                 |  294 +++
 drivers/mtd/spi/spi-nor-tiny.c                |  810 ++++++
 drivers/mtd/spi/spi_flash.c                   | 1337 ----------
 drivers/mtd/spi/spi_flash_ids.c               |  211 --
 drivers/spi/Kconfig                           |    4 +-
 drivers/spi/Makefile                          |    1 +
 drivers/spi/spi-mem-nodm.c                    |   89 +
 drivers/spi/spi-mem.c                         |   15 +-
 drivers/spi/stm32_qspi.c                      |    4 +-
 include/configs/T102xQDS.h                    |    1 -
 include/configs/T102xRDB.h                    |    1 -
 include/configs/T104xRDB.h                    |    1 -
 include/configs/T208xQDS.h                    |    1 -
 include/configs/T208xRDB.h                    |    1 -
 include/configs/gw_ventana.h                  |    1 -
 include/configs/km/kmp204x-common.h           |    1 -
 include/configs/ls1021aiot.h                  |    1 -
 include/configs/socfpga_stratix10_socdk.h     |    1 -
 include/linux/mtd/cfi.h                       |   32 +
 include/linux/mtd/spi-nor.h                   |  421 +++
 include/spi_flash.h                           |  105 +-
 119 files changed, 4179 insertions(+), 2110 deletions(-)
 delete mode 100644 doc/SPI/README.dual-flash
 create mode 100644 drivers/mtd/spi/spi-nor-core.c
 create mode 100644 drivers/mtd/spi/spi-nor-ids.c
 create mode 100644 drivers/mtd/spi/spi-nor-tiny.c
 delete mode 100644 drivers/mtd/spi/spi_flash.c
 delete mode 100644 drivers/mtd/spi/spi_flash_ids.c
 create mode 100644 drivers/spi/spi-mem-nodm.c
 create mode 100644 include/linux/mtd/cfi.h
 create mode 100644 include/linux/mtd/spi-nor.h
Signature · 1 line
2.19.2
author maintainer
#1 lore raw

PATCH 1/16 spi: spi-mem: Allow use of spi_mem_exec_op for all SPI modes

SPI controllers support all types of SPI modes including dual/quad bus widths. Therefore remove constraint wrt SPI mode from spi-mem layer.

---
 drivers/spi/spi-mem.c | 9 ---------
 1 file changed, 9 deletions(-)
drivers/spi/spi-mem.c +0 -9
index af9aef009a73..1da20b8de5c4 100644
@@ -323,15 +323,6 @@ int spi_mem_exec_op(struct spi_slave *slave, const struct spi_mem_op *op)
 		return -EIO;
 #else
 
-	/* U-Boot does not support parallel SPI data lanes */
-	if ((op->cmd.buswidth != 1) ||
-	    (op->addr.nbytes && op->addr.buswidth != 1) ||
-	    (op->dummy.nbytes && op->dummy.buswidth != 1) ||
-	    (op->data.nbytes && op->data.buswidth != 1)) {
-		printf("Dual/Quad raw SPI transfers not supported\n");
-		return -ENOTSUPP;
-	}
-
 	if (op->data.nbytes) {
 		if (op->data.dir == SPI_MEM_DATA_IN)
 			rx_buf = op->data.buf.in;
Signature · 1 line
2.19.2
author maintainer
#2 lore raw

PATCH 2/16 spi-mem: Claim SPI bus before spi mem access

In reply to Vignesh R

It is necessary to call spi_claim_bus() before starting any SPI transactions and this restriction would also apply when calling spi-mem operationss. Therefore claim and release bus before requesting transfer via exec_op.

---
 drivers/spi/spi-mem.c | 6 ++++++
 1 file changed, 6 insertions(+)
drivers/spi/spi-mem.c +6 -0
index 1da20b8de5c4..4c1463118ab2 100644
@@ -231,7 +231,13 @@ int spi_mem_exec_op(struct spi_slave *slave, const struct spi_mem_op *op)
 		mutex_lock(&ctlr->bus_lock_mutex);
 		mutex_lock(&ctlr->io_mutex);
 #endif
+		ret = spi_claim_bus(slave);
+		if (ret < 0)
+			return ret;
+
 		ret = ops->mem_ops->exec_op(slave, op);
+
+		spi_release_bus(slave);
 #ifndef __UBOOT__
 		mutex_unlock(&ctlr->io_mutex);
 		mutex_unlock(&ctlr->bus_lock_mutex);
Signature · 1 line
2.19.2
author maintainer
#3 lore raw

PATCH 3/16 spi: Add non DM version of SPI_MEM

In reply to Vignesh R

Add non DM version of SPI_MEM to support easy migration to new SPI NOR framework. This can be removed once DM_SPI conversion is complete.

---
 drivers/spi/Kconfig        |  4 +-
 drivers/spi/Makefile       |  1 +
 drivers/spi/spi-mem-nodm.c | 89 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 92 insertions(+), 2 deletions(-)
 create mode 100644 drivers/spi/spi-mem-nodm.c
drivers/spi/Kconfig +2 -2
index a7bb5b35c294..5ee855fc5319 100644
@@ -16,8 +16,6 @@ config DM_SPI
 	  typically use driver-private data instead of extending the
 	  spi_slave structure.
 
-if DM_SPI
-
 config SPI_MEM
 	bool "SPI memory extension"
 	help
@@ -25,6 +23,8 @@ config SPI_MEM
 	  This extension is meant to simplify interaction with SPI memories
 	  by providing an high-level interface to send memory-like commands.
 
+if DM_SPI
+
 config ALTERA_SPI
 	bool "Altera SPI driver"
 	help
drivers/spi/Makefile +1 -0
index 392a92579578..32ba3b61f70d 100644
@@ -11,6 +11,7 @@ obj-$(CONFIG_SOFT_SPI) += soft_spi.o
 obj-$(CONFIG_SPI_MEM) += spi-mem.o
 else
 obj-y += spi.o
+obj-$(CONFIG_SPI_MEM) += spi-mem-nodm.o
 obj-$(CONFIG_SOFT_SPI) += soft_spi_legacy.o
 endif
 
drivers/spi/spi-mem-nodm.c new file +89 -0

89 lines not on this page · raw message

Signature · 1 line
2.19.2
#4 lore raw

PATCH 3/16 spi: Add non DM version of SPI_MEM

Quoted 3 lines · Vignesh R

Add non DM version of SPI_MEM to support easy migration to new SPI NOR framework. This can be removed once DM_SPI conversion is complete.

Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?

#5 lore raw

PATCH 3/16 spi: Add non DM version of SPI_MEM

Hi Jagan,

Quoted 7 lines · On Thu, 13 Dec 2018 01:55:08 +0530 Jagan Teki <[email protected]>…
Quoted 3 lines · Vignesh R

Add non DM version of SPI_MEM to support easy migration to new SPI NOR framework. This can be removed once DM_SPI conversion is complete.

Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?

Looks like we're having the same discussion over and over. Vignesh is dropping spi_flash.c which AFAICT was not depending on DM_SPI, so, if we want to keep everyone happy while getting rid of some legacy code, that's the only solution. DM conversion is a nice goal, but it's kind of orthogonal to what Vignesh is working on. If DM_SPI conversion happens before the spi-nor stuff is merged (which I doubt) then this patch can simply be dropped.

#6 lore raw

PATCH 3/16 spi: Add non DM version of SPI_MEM

Quoted 14 lines · Boris Brezillon

Hi Jagan,

Quoted 7 lines · On Thu, 13 Dec 2018 01:55:08 +0530 Jagan Teki <[email protected]>…
Quoted 3 lines · Vignesh R

Add non DM version of SPI_MEM to support easy migration to new SPI NOR framework. This can be removed once DM_SPI conversion is complete.

Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?

Quoted 7 lines

Looks like we're having the same discussion over and over. Vignesh is dropping spi_flash.c which AFAICT was not depending on DM_SPI, so, if we want to keep everyone happy while getting rid of some legacy code, that's the only solution. DM conversion is a nice goal, but it's kind of orthogonal to what Vignesh is working on. If DM_SPI conversion happens before the spi-nor stuff is merged (which I doubt) then this patch can simply be dropped.

spi_flash.c is a core code not a specific driver it belongs. spi-mem is new feature driver how come new driver will support legacy non-dm do we have legacy use for that(ie what I'm asking about usecase)

#7 lore raw

PATCH 3/16 spi: Add non DM version of SPI_MEM

Quoted 24 lines · On Thu, 13 Dec 2018 02:15:16 +0530 Jagan Teki <[email protected]>…
Quoted 14 lines · Boris Brezillon

Hi Jagan,

Quoted 7 lines · On Thu, 13 Dec 2018 01:55:08 +0530 Jagan Teki <[email protected]>…
Quoted 3 lines · Vignesh R

Add non DM version of SPI_MEM to support easy migration to new SPI NOR framework. This can be removed once DM_SPI conversion is complete.

Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?

Quoted 7 lines

Looks like we're having the same discussion over and over. Vignesh is dropping spi_flash.c which AFAICT was not depending on DM_SPI, so, if we want to keep everyone happy while getting rid of some legacy code, that's the only solution. DM conversion is a nice goal, but it's kind of orthogonal to what Vignesh is working on. If DM_SPI conversion happens before the spi-nor stuff is merged (which I doubt) then this patch can simply be dropped.

Quoted 3 lines

spi_flash.c is a core code not a specific driver it belongs. spi-mem is new feature driver how come new driver will support legacy non-dm do we have legacy use for that(ie what I'm asking about usecase)

I recommend that you read the spi-mem code carefully. spi-mem is not driver specific, it's a thin layer on top of spi and driver *can* (but are not forced to) provide optimized methods to execute spi-mem operations. When that's not the case, the implementation falls back to regular spi transfers. AFAIK, both DM and non-DM drivers support regular spi transfers, right? So why should we depend on DM_SPI? And more importantly, if we do that, that means we can't get rid of spi_flash.c since some users might still have non-DM SPI drivers, which in turn means we keep more legacy code for no good reasons.

You want non-DM SPI controller drivers to go away, then remove them, instead of blocking other changes using this excuse.

#8 lore raw

PATCH 3/16 spi: Add non DM version of SPI_MEM

Quoted 34 lines · On Wed 12 Dec, 2018, 10:02 PM Boris Brezillon <[email protected]…
Quoted 9 lines · On Thu, 13 Dec 2018 02:15:16 +0530 Jagan Teki <[email protected]>…
Quoted 7 lines · Boris Brezillon

Hi Jagan,

Quoted 1 line · On Thu, 13 Dec 2018 01:55:08 +0530 Jagan Teki <[email protected]>…

On Wed, Dec 12, 2018 at 11:08 PM Vignesh R <[email protected]>

Quoted 2 lines · wrote:
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

Add non DM version of SPI_MEM to support easy migration to new SPI

NOR

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

framework. This can be removed once DM_SPI conversion is

complete.

Quoted 12 lines
Quoted 11 lines
Quoted 3 lines

Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?

Looks like we're having the same discussion over and over. Vignesh is dropping spi_flash.c which AFAICT was not depending on DM_SPI, so, if we want to keep everyone happy while getting rid of some legacy code, that's the only solution. DM conversion is a nice goal, but it's kind of orthogonal to what Vignesh is working on. If DM_SPI conversion happens before the spi-nor stuff is merged (which I doubt) then this patch can simply be dropped.

Quoted 3 lines

spi_flash.c is a core code not a specific driver it belongs. spi-mem is new feature driver how come new driver will support legacy non-dm do we have legacy use for that(ie what I'm asking about usecase)

Quoted 10 lines

I recommend that you read the spi-mem code carefully. spi-mem is not driver specific, it's a thin layer on top of spi and driver *can* (but are not forced to) provide optimized methods to execute spi-mem operations. When that's not the case, the implementation falls back to regular spi transfers. AFAIK, both DM and non-DM drivers support regular spi transfers, right? So why should we depend on DM_SPI? And more importantly, if we do that, that means we can't get rid of spi_flash.c since some users might still have non-DM SPI drivers, which in turn means we keep more legacy code for no good reasons.

I understand spi-mem is core file, but new code too.

Quoted 3 lines

You want non-DM SPI controller drivers to go away, then remove them, instead of blocking other changes using this excuse.

Please understand uboot development flow, legacy driver can be removed if possible once migration expire and NEW drivers or code must be dm driven.

Quoted 1 line
#9 lore raw

PATCH 3/16 spi: Add non DM version of SPI_MEM

Quoted 48 lines · On Wed, 12 Dec 2018 22:07:44 +0100 Jagan Teki <[email protected]>…
Quoted 34 lines · On Wed 12 Dec, 2018, 10:02 PM Boris Brezillon <[email protected]…
Quoted 9 lines · On Thu, 13 Dec 2018 02:15:16 +0530 Jagan Teki <[email protected]>…
Quoted 7 lines · Boris Brezillon

Hi Jagan,

Quoted 1 line · On Thu, 13 Dec 2018 01:55:08 +0530 Jagan Teki <[email protected]>…

On Wed, Dec 12, 2018 at 11:08 PM Vignesh R <[email protected]>

Quoted 2 lines · wrote:
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

Add non DM version of SPI_MEM to support easy migration to new SPI

NOR

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

framework. This can be removed once DM_SPI conversion is

complete.

Quoted 12 lines
Quoted 11 lines
Quoted 3 lines

Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?

Looks like we're having the same discussion over and over. Vignesh is dropping spi_flash.c which AFAICT was not depending on DM_SPI, so, if we want to keep everyone happy while getting rid of some legacy code, that's the only solution. DM conversion is a nice goal, but it's kind of orthogonal to what Vignesh is working on. If DM_SPI conversion happens before the spi-nor stuff is merged (which I doubt) then this patch can simply be dropped.

Quoted 3 lines

spi_flash.c is a core code not a specific driver it belongs. spi-mem is new feature driver how come new driver will support legacy non-dm do we have legacy use for that(ie what I'm asking about usecase)

Quoted 10 lines

I recommend that you read the spi-mem code carefully. spi-mem is not driver specific, it's a thin layer on top of spi and driver *can* (but are not forced to) provide optimized methods to execute spi-mem operations. When that's not the case, the implementation falls back to regular spi transfers. AFAIK, both DM and non-DM drivers support regular spi transfers, right? So why should we depend on DM_SPI? And more importantly, if we do that, that means we can't get rid of spi_flash.c since some users might still have non-DM SPI drivers, which in turn means we keep more legacy code for no good reasons.

Quoted 1 line

I understand spi-mem is core file, but new code too.

Sorry, I don't get it.

Quoted 8 lines
Quoted 5 lines

You want non-DM SPI controller drivers to go away, then remove them, instead of blocking other changes using this excuse.

Please understand uboot development flow, legacy driver can be removed if possible once migration expire and NEW drivers or code must be dm driven.

Sorry, but I think you're the one misunderstanding what we are trying to do here. Vignesh changes have simply no impact on the DM SPI conversion you're aiming at. All Vignesh does is provide a dummy wrapper for non-DM drivers, which would probably have been implemented by Miquel if you had not been so insistent on your precious DM_SPI conversion. That was not really a problem for spi-nand, as we were adding support for a new feature. This is not the case here. SPI NORs are already partially supported by the u-boot spi flash layer, and we need to keep things in a working state for those that were using it and didn't have their SPI controller drivers converted to the DM. This leaves us 2 options:

1/ keep the sf_flash code as is and add a new spi-nor code base 2/ replace spi_flash code by the spi-nor layer imported from Linux

Vignesh chose option #2 which has the benefit of avoiding code duplication. Given the discussion we're having right now, I'm wondering if it wouldn't be easier to go for option #1 in order to avoid those endless discussions...

#10 lore raw

PATCH 3/16 spi: Add non DM version of SPI_MEM

Quoted 65 lines · Boris Brezillon
Quoted 48 lines · On Wed, 12 Dec 2018 22:07:44 +0100 Jagan Teki <[email protected]>…
Quoted 34 lines · On Wed 12 Dec, 2018, 10:02 PM Boris Brezillon <[email protected]…
Quoted 9 lines · On Thu, 13 Dec 2018 02:15:16 +0530 Jagan Teki <[email protected]>…
Quoted 7 lines · Boris Brezillon

Hi Jagan,

Quoted 1 line · On Thu, 13 Dec 2018 01:55:08 +0530 Jagan Teki <[email protected]>…

On Wed, Dec 12, 2018 at 11:08 PM Vignesh R <[email protected]>

Quoted 2 lines · wrote:
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

Add non DM version of SPI_MEM to support easy migration to new SPI

NOR

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

framework. This can be removed once DM_SPI conversion is

complete.

Quoted 12 lines
Quoted 11 lines
Quoted 3 lines

Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?

Looks like we're having the same discussion over and over. Vignesh is dropping spi_flash.c which AFAICT was not depending on DM_SPI, so, if we want to keep everyone happy while getting rid of some legacy code, that's the only solution. DM conversion is a nice goal, but it's kind of orthogonal to what Vignesh is working on. If DM_SPI conversion happens before the spi-nor stuff is merged (which I doubt) then this patch can simply be dropped.

Quoted 3 lines

spi_flash.c is a core code not a specific driver it belongs. spi-mem is new feature driver how come new driver will support legacy non-dm do we have legacy use for that(ie what I'm asking about usecase)

Quoted 10 lines

I recommend that you read the spi-mem code carefully. spi-mem is not driver specific, it's a thin layer on top of spi and driver *can* (but are not forced to) provide optimized methods to execute spi-mem operations. When that's not the case, the implementation falls back to regular spi transfers. AFAIK, both DM and non-DM drivers support regular spi transfers, right? So why should we depend on DM_SPI? And more importantly, if we do that, that means we can't get rid of spi_flash.c since some users might still have non-DM SPI drivers, which in turn means we keep more legacy code for no good reasons.

Quoted 1 line

I understand spi-mem is core file, but new code too.

Sorry, I don't get it.

Quoted 8 lines
Quoted 5 lines

You want non-DM SPI controller drivers to go away, then remove them, instead of blocking other changes using this excuse.

Please understand uboot development flow, legacy driver can be removed if possible once migration expire and NEW drivers or code must be dm driven.

Quoted 6 lines

Sorry, but I think you're the one misunderstanding what we are trying to do here. Vignesh changes have simply no impact on the DM SPI conversion you're aiming at. All Vignesh does is provide a dummy wrapper for non-DM drivers, which would probably have been implemented by Miquel if you had not been so insistent on your precious DM_SPI conversion. That was not really a problem for spi-nand, as we were

I'm sure, I'm in right direction.

This is what I asked in the first mail,

"Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?"

and I have the answer on this thread about the use case.

I do really understand your intention about the real question.
- Any code or generic code will add in U-Boot should be driver-model driven, are you agree this point?
Yes- thanks.
No - we need to have separate discussion.

Any code that related to spi, or spi-flash should be driver-model driven, ie what my AIM as a Maintainer (ie only reason for my spi-nor changes resist for long time to fit).

#11 lore raw

PATCH 3/16 spi: Add non DM version of SPI_MEM

Quoted 89 lines · Jagan Teki
Quoted 65 lines · Boris Brezillon
Quoted 48 lines · On Wed, 12 Dec 2018 22:07:44 +0100 Jagan Teki <[email protected]>…
Quoted 34 lines · On Wed 12 Dec, 2018, 10:02 PM Boris Brezillon <[email protected]…
Quoted 9 lines · On Thu, 13 Dec 2018 02:15:16 +0530 Jagan Teki <[email protected]>…
Quoted 7 lines · Boris Brezillon

Hi Jagan,

Quoted 1 line · On Thu, 13 Dec 2018 01:55:08 +0530 Jagan Teki <[email protected]>…

On Wed, Dec 12, 2018 at 11:08 PM Vignesh R <[email protected]>

Quoted 2 lines · wrote:
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

Add non DM version of SPI_MEM to support easy migration to new SPI

NOR

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

framework. This can be removed once DM_SPI conversion is

complete.

Quoted 12 lines
Quoted 11 lines
Quoted 3 lines

Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?

Looks like we're having the same discussion over and over. Vignesh is dropping spi_flash.c which AFAICT was not depending on DM_SPI, so, if we want to keep everyone happy while getting rid of some legacy code, that's the only solution. DM conversion is a nice goal, but it's kind of orthogonal to what Vignesh is working on. If DM_SPI conversion happens before the spi-nor stuff is merged (which I doubt) then this patch can simply be dropped.

Quoted 3 lines

spi_flash.c is a core code not a specific driver it belongs. spi-mem is new feature driver how come new driver will support legacy non-dm do we have legacy use for that(ie what I'm asking about usecase)

Quoted 10 lines

I recommend that you read the spi-mem code carefully. spi-mem is not driver specific, it's a thin layer on top of spi and driver *can* (but are not forced to) provide optimized methods to execute spi-mem operations. When that's not the case, the implementation falls back to regular spi transfers. AFAIK, both DM and non-DM drivers support regular spi transfers, right? So why should we depend on DM_SPI? And more importantly, if we do that, that means we can't get rid of spi_flash.c since some users might still have non-DM SPI drivers, which in turn means we keep more legacy code for no good reasons.

Quoted 1 line

I understand spi-mem is core file, but new code too.

Sorry, I don't get it.

Quoted 8 lines
Quoted 5 lines

You want non-DM SPI controller drivers to go away, then remove them, instead of blocking other changes using this excuse.

Please understand uboot development flow, legacy driver can be removed if possible once migration expire and NEW drivers or code must be dm driven.

Quoted 6 lines

Sorry, but I think you're the one misunderstanding what we are trying to do here. Vignesh changes have simply no impact on the DM SPI conversion you're aiming at. All Vignesh does is provide a dummy wrapper for non-DM drivers, which would probably have been implemented by Miquel if you had not been so insistent on your precious DM_SPI conversion. That was not really a problem for spi-nand, as we were

I'm sure, I'm in right direction.

This is what I asked in the first mail,

"Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?"

and I have the answer on this thread about the use case.

I do really understand your intention about the real question.
- Any code or generic code will add in U-Boot should be driver-model driven, are you agree this point?
Yes- thanks.
No - we need to have separate discussion.

Quoted 3 lines

Any code that related to spi, or spi-flash should be driver-model driven, ie what my AIM as a Maintainer (ie only reason for my spi-nor changes resist for long time to fit).

And since we have both been "stuck" for so very long and a clear commitment from a few people to follow through on the "and DM it after" part, I'm OK with bending the rules.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181212/d41e7ec4/attachment.sig>
#12 lore raw

PATCH 3/16 spi: Add non DM version of SPI_MEM

In reply to Jagan Teki
Quoted 6 lines · On Thu, 13 Dec 2018 04:40:30 +0530 Jagan Teki <[email protected]>…

I do really understand your intention about the real question.
- Any code or generic code will add in U-Boot should be driver-model driven, are you agree this point?
Yes- thanks.
No - we need to have separate discussion.

Depends on what you mean by driver-model driven. Yes, applying the DM sometimes makes sense, but blindly trying to push it everywhere just for the sake of being "DM compliant" is a huge mistake IMO. One example of the thing you suggested which didn't make sense at all: force MTD users to manipulate udevice objects instead of mtd_info ones.

Quoted 4 lines

Any code that related to spi, or spi-flash should be driver-model driven, ie what my AIM as a Maintainer (ie only reason for my spi-nor changes resist for long time to fit).

You seem to use the term "driver-model" a lot without clearly explaining what you have in mind. The driver-model should be used where it makes sense, but some of your suggestions don't make any sense to me. Like the proposal to add a SPI NOR uclass while we already have an MTD uclass which works just fine for all kind of flash devices.

Oh, and this strict rule that says "don't provide wrappers to handle non-DM compliant cases" is just wrong. As I said, none of these dummy wrappers prevent you from enforcing DM_SPI conversion, and it allows us to support existing HW while getting rid of the old code base. Plus, I suggested to declare the spi-nor driver as an MTD uclass so it's not like we're completely ignoring your comments :P.

#13 lore raw

PATCH 3/16 spi: Add non DM version of SPI_MEM

Quoted 11 lines · Boris Brezillon
Quoted 6 lines · On Thu, 13 Dec 2018 04:40:30 +0530 Jagan Teki <[email protected]>…

I do really understand your intention about the real question.
- Any code or generic code will add in U-Boot should be driver-model driven, are you agree this point?
Yes- thanks.
No - we need to have separate discussion.

Quoted 5 lines

Depends on what you mean by driver-model driven. Yes, applying the DM sometimes makes sense, but blindly trying to push it everywhere just for the sake of being "DM compliant" is a huge mistake IMO. One example of the thing you suggested which didn't make sense at all: force MTD users to manipulate udevice objects instead of mtd_info ones.

(+ Simon)
ie How we proceed when DM is introduced in U-Boot. May be you can ask Simon or Other DM fellow developers if my statement doesn't make sense to you. ie whole reason of spi-nor changes last for year.

Quoted 11 lines
Quoted 5 lines

Any code that related to spi, or spi-flash should be driver-model driven, ie what my AIM as a Maintainer (ie only reason for my spi-nor changes resist for long time to fit).

You seem to use the term "driver-model" a lot without clearly explaining what you have in mind. The driver-model should be used where it makes sense, but some of your suggestions don't make any sense to me. Like the proposal to add a SPI NOR uclass while we already have an MTD uclass which works just fine for all kind of flash devices.

You better read the thread carefully. read what I'm saying on the thread[1]

" So, if no driver should be part of spi-nor and all can be handle spi-mem even-though they have controller specific features, yes we can skip SPI_NOR_UCLASS otherwise we need spi-nor uclass that can be child uclass of MTD"

Did it state insisting SPI-NOR uclass, I was clearly giving if condition here.

[1] https://patchwork.ozlabs.org/cover/1007589/

#14 lore raw

PATCH 3/16 spi: Add non DM version of SPI_MEM

Hi,

Quoted 20 lines · Jagan Teki
Quoted 11 lines · Boris Brezillon
Quoted 6 lines · On Thu, 13 Dec 2018 04:40:30 +0530 Jagan Teki <[email protected]>…

I do really understand your intention about the real question.
- Any code or generic code will add in U-Boot should be driver-model driven, are you agree this point?
Yes- thanks.
No - we need to have separate discussion.

Quoted 5 lines

Depends on what you mean by driver-model driven. Yes, applying the DM sometimes makes sense, but blindly trying to push it everywhere just for the sake of being "DM compliant" is a huge mistake IMO. One example of the thing you suggested which didn't make sense at all: force MTD users to manipulate udevice objects instead of mtd_info ones.

Quoted 4 lines

(+ Simon)
ie How we proceed when DM is introduced in U-Boot. May be you can ask Simon or Other DM fellow developers if my statement doesn't make sense to you. ie whole reason of spi-nor changes last for year.

I generally prefer to use DM fully. I am not sure what an mtd_info is if it isn't a device.

Quoted 15 lines
Quoted 7 lines
Quoted 6 lines

Any code that related to spi, or spi-flash should be driver-model driven, ie what my AIM as a Maintainer (ie only reason for my spi-nor changes resist for long time to fit).

Quoted 5 lines

You seem to use the term "driver-model" a lot without clearly explaining what you have in mind. The driver-model should be used where it makes sense, but some of your suggestions don't make any sense to me. Like the proposal to add a SPI NOR uclass while we already have an MTD uclass which works just fine for all kind of flash devices.

You better read the thread carefully. read what I'm saying on the thread[1]

Quoted 8 lines

" So, if no driver should be part of spi-nor and all can be handle spi-mem even-though they have controller specific features, yes we can skip SPI_NOR_UCLASS otherwise we need spi-nor uclass that can be child uclass of MTD"

Did it state insisting SPI-NOR uclass, I was clearly giving if condition here.

[1] https://patchwork.ozlabs.org/cover/1007589/

Regards,
Simon

author maintainer
#15 lore raw

PATCH 3/16 spi: Add non DM version of SPI_MEM

In reply to Boris Brezillon
Quoted 76 lines · Boris Brezillon
Quoted 48 lines · On Wed, 12 Dec 2018 22:07:44 +0100 Jagan Teki <[email protected]>…
Quoted 34 lines · On Wed 12 Dec, 2018, 10:02 PM Boris Brezillon <[email protected]…
Quoted 9 lines · On Thu, 13 Dec 2018 02:15:16 +0530 Jagan Teki <[email protected]>…
Quoted 7 lines · Boris Brezillon

Hi Jagan,

Quoted 1 line · On Thu, 13 Dec 2018 01:55:08 +0530 Jagan Teki <[email protected]>…

On Wed, Dec 12, 2018 at 11:08 PM Vignesh R <[email protected]>

Quoted 2 lines · wrote:
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

Add non DM version of SPI_MEM to support easy migration to new SPI

NOR

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

framework. This can be removed once DM_SPI conversion is

complete.

Quoted 12 lines
Quoted 11 lines
Quoted 3 lines

Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?

Looks like we're having the same discussion over and over. Vignesh is dropping spi_flash.c which AFAICT was not depending on DM_SPI, so, if we want to keep everyone happy while getting rid of some legacy code, that's the only solution. DM conversion is a nice goal, but it's kind of orthogonal to what Vignesh is working on. If DM_SPI conversion happens before the spi-nor stuff is merged (which I doubt) then this patch can simply be dropped.

Quoted 3 lines

spi_flash.c is a core code not a specific driver it belongs. spi-mem is new feature driver how come new driver will support legacy non-dm do we have legacy use for that(ie what I'm asking about usecase)

Quoted 10 lines

I recommend that you read the spi-mem code carefully. spi-mem is not driver specific, it's a thin layer on top of spi and driver *can* (but are not forced to) provide optimized methods to execute spi-mem operations. When that's not the case, the implementation falls back to regular spi transfers. AFAIK, both DM and non-DM drivers support regular spi transfers, right? So why should we depend on DM_SPI? And more importantly, if we do that, that means we can't get rid of spi_flash.c since some users might still have non-DM SPI drivers, which in turn means we keep more legacy code for no good reasons.

Quoted 1 line

I understand spi-mem is core file, but new code too.

Sorry, I don't get it.

Quoted 8 lines
Quoted 5 lines

You want non-DM SPI controller drivers to go away, then remove them, instead of blocking other changes using this excuse.

Please understand uboot development flow, legacy driver can be removed if possible once migration expire and NEW drivers or code must be dm driven.

Sorry, but I think you're the one misunderstanding what we are trying to do here. Vignesh changes have simply no impact on the DM SPI conversion you're aiming at. All Vignesh does is provide a dummy wrapper for non-DM drivers, which would probably have been implemented by Miquel if you had not been so insistent on your precious DM_SPI conversion. That was not really a problem for spi-nand, as we were adding support for a new feature. This is not the case here. SPI NORs are already partially supported by the u-boot spi flash layer, and we need to keep things in a working state for those that were using it and didn't have their SPI controller drivers converted to the DM. This leaves us 2 options:

Quoted 8 lines

1/ keep the sf_flash code as is and add a new spi-nor code base 2/ replace spi_flash code by the spi-nor layer imported from Linux

Vignesh chose option #2 which has the benefit of avoiding code duplication. Given the discussion we're having right now, I'm wondering if it wouldn't be easier to go for option #1 in order to avoid those endless discussions...

Boris, thanks for chiming in! This is exactly what I had in mind.

To add, I did start with #1 by simply adding support for 4 byte addressing. But, then released I need spi-mem to communicate this protocol info to SPI drivers, then found Quad Enable detection logic to be incomplete and so on.. Finally released I would end up with code exactly similar to Linux SPI-NOR(with addition of SFDP logic). Therefore switched to #2 ;)

Signature · 2 lines
Regards
Vignesh
maintainer
#16 lore raw

PATCH 3/16 spi: Add non DM version of SPI_MEM

Hi Vignesh,

Vignesh R <[email protected]> wrote on Thu, 13 Dec 2018 15:08:32 +0530:

Quoted 86 lines · Boris Brezillon
Quoted 76 lines
Quoted 48 lines · On Wed, 12 Dec 2018 22:07:44 +0100 Jagan Teki <[email protected]>…
Quoted 34 lines · On Wed 12 Dec, 2018, 10:02 PM Boris Brezillon <[email protected]…
Quoted 9 lines · On Thu, 13 Dec 2018 02:15:16 +0530 Jagan Teki <[email protected]>…
Quoted 7 lines · Boris Brezillon

Hi Jagan,

Quoted 1 line · On Thu, 13 Dec 2018 01:55:08 +0530 Jagan Teki <[email protected]>…

On Wed, Dec 12, 2018 at 11:08 PM Vignesh R <[email protected]>

Quoted 2 lines · wrote:
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

Add non DM version of SPI_MEM to support easy migration to new SPI

NOR

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

framework. This can be removed once DM_SPI conversion is

complete.

Quoted 12 lines
Quoted 11 lines
Quoted 3 lines

Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?

Looks like we're having the same discussion over and over. Vignesh is dropping spi_flash.c which AFAICT was not depending on DM_SPI, so, if we want to keep everyone happy while getting rid of some legacy code, that's the only solution. DM conversion is a nice goal, but it's kind of orthogonal to what Vignesh is working on. If DM_SPI conversion happens before the spi-nor stuff is merged (which I doubt) then this patch can simply be dropped.

Quoted 3 lines

spi_flash.c is a core code not a specific driver it belongs. spi-mem is new feature driver how come new driver will support legacy non-dm do we have legacy use for that(ie what I'm asking about usecase)

Quoted 10 lines

I recommend that you read the spi-mem code carefully. spi-mem is not driver specific, it's a thin layer on top of spi and driver *can* (but are not forced to) provide optimized methods to execute spi-mem operations. When that's not the case, the implementation falls back to regular spi transfers. AFAIK, both DM and non-DM drivers support regular spi transfers, right? So why should we depend on DM_SPI? And more importantly, if we do that, that means we can't get rid of spi_flash.c since some users might still have non-DM SPI drivers, which in turn means we keep more legacy code for no good reasons.

Quoted 1 line

I understand spi-mem is core file, but new code too.

Sorry, I don't get it.

Quoted 8 lines
Quoted 5 lines

You want non-DM SPI controller drivers to go away, then remove them, instead of blocking other changes using this excuse.

Please understand uboot development flow, legacy driver can be removed if possible once migration expire and NEW drivers or code must be dm driven.

Sorry, but I think you're the one misunderstanding what we are trying to do here. Vignesh changes have simply no impact on the DM SPI conversion you're aiming at. All Vignesh does is provide a dummy wrapper for non-DM drivers, which would probably have been implemented by Miquel if you had not been so insistent on your precious DM_SPI conversion. That was not really a problem for spi-nand, as we were adding support for a new feature. This is not the case here. SPI NORs are already partially supported by the u-boot spi flash layer, and we need to keep things in a working state for those that were using it and didn't have their SPI controller drivers converted to the DM. This leaves us 2 options:

Quoted 8 lines

1/ keep the sf_flash code as is and add a new spi-nor code base 2/ replace spi_flash code by the spi-nor layer imported from Linux

Vignesh chose option #2 which has the benefit of avoiding code duplication. Given the discussion we're having right now, I'm wondering if it wouldn't be easier to go for option #1 in order to avoid those endless discussions...

Quoted 10 lines

Boris, thanks for chiming in! This is exactly what I had in mind.

To add, I did start with #1 by simply adding support for 4 byte addressing. But, then released I need spi-mem to communicate this protocol info to SPI drivers, then found Quad Enable detection logic to be incomplete and so on.. Finally released I would end up with code exactly similar to Linux SPI-NOR(with addition of SFDP logic). Therefore switched to #2 ;)

I also share (strongly) the same point of view: #2 is the best way IMHO.

Thanks,
Miquèl

author maintainer
#17 lore raw

PATCH 3/16 spi: Add non DM version of SPI_MEM

In reply to Jagan Teki
Quoted 8 lines · Jagan Teki
Quoted 3 lines · Vignesh R

Add non DM version of SPI_MEM to support easy migration to new SPI NOR framework. This can be removed once DM_SPI conversion is complete.

Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?

As said by others, AFAICS, DM_SPI migration is not going to be complete anytime soon. There are many boards and configs that don't enable DM_SPI. I propose you add a patch to print _warning during build_ for boards that don't have DM_SPI enabled (like DM_MMC and DM_USB) targeting v2019.07 or v2019.04 as deadline for removal. At the deadline you can remove spi-mem-nodm.c along with all other non DM code in SPI core.

Else, I need to reintroduce code that uses wrappers in sf.c which means two separate code paths/logics in spi-nor-core.c that adds to SPL code size

I don't think it makes sense to block new development for majority of folks who are already migrated to DM_SPI. If we end up completing DM_SPI migration before merging this series, this patch can be dropped w/o any side effects.

Signature · 2 lines
Regards
Vignesh
#18 lore raw

PATCH 3/16 spi: Add non DM version of SPI_MEM

Quoted 13 lines · Vignesh R
Quoted 8 lines · Jagan Teki
Quoted 3 lines · Vignesh R

Add non DM version of SPI_MEM to support easy migration to new SPI NOR framework. This can be removed once DM_SPI conversion is complete.

Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?

Quoted 6 lines

As said by others, AFAICS, DM_SPI migration is not going to be complete anytime soon. There are many boards and configs that don't enable DM_SPI. I propose you add a patch to print _warning during build_ for boards that don't have DM_SPI enabled (like DM_MMC and DM_USB) targeting v2019.07 or v2019.04 as deadline for removal. At the deadline you can remove spi-mem-nodm.c along with all other non DM code in SPI core.

I don't understand why DM_SPI migration came to this topic? It's a separate thread/issue.

Do you think any development opensource project will agree to push the code which may remove it in future? ie what my point here.

author maintainer
#19 lore raw

PATCH 3/16 spi: Add non DM version of SPI_MEM

Hi,

Quoted 21 lines · Jagan Teki
Quoted 13 lines · Vignesh R
Quoted 8 lines · Jagan Teki
Quoted 3 lines · Vignesh R

Add non DM version of SPI_MEM to support easy migration to new SPI NOR framework. This can be removed once DM_SPI conversion is complete.

Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?

Quoted 6 lines

As said by others, AFAICS, DM_SPI migration is not going to be complete anytime soon. There are many boards and configs that don't enable DM_SPI. I propose you add a patch to print _warning during build_ for boards that don't have DM_SPI enabled (like DM_MMC and DM_USB) targeting v2019.07 or v2019.04 as deadline for removal. At the deadline you can remove spi-mem-nodm.c along with all other non DM code in SPI core.

Quoted 3 lines

I don't understand why DM_SPI migration came to this topic? It's a separate thread/issue.

I respectfully disagree. If DM_SPI migration was complete then SPI_MEM would be available for use by all subsystem. This patch wouldn't have been needed.

Quoted 3 lines

Do you think any development opensource project will agree to push the code which may remove it in future? ie what my point here.

Do you agree some code needs to be added to spi-nor layer so as not to break non DM_SPI converted boards but make use spi-mem APIs in spi-nor? If yes, then that code is spi-mem-nodm.c. I can rename it as spi_mem_emulation.c or something, but that does not change the fact.

Else, are you proposing to do following in spi-nor-core like in rfc v1[1]?

#if defined(CONFIG_DM_SPI) && defined(CONFIG_SPI_MEM) /* call spi_mem_*_ops() */
#else
/* call SPI ops like spi_xfer() etc
#endif

I am not seeing any solution here. Please have a look at spi-mem.c and spi-nor.c interaction. What do you propose as a solution to use spi-mem APIs but not break non DM_SPI drivers?

[1]https://patchwork.ozlabs.org/patch/1004836/

Signature · 2 lines
Regards
Vignesh
#20 lore raw

PATCH 3/16 spi: Add non DM version of SPI_MEM

Quoted 25 lines · Vignesh R

Hi,

Quoted 21 lines · Jagan Teki
Quoted 19 lines · Vignesh R
Quoted 8 lines · Jagan Teki
Quoted 3 lines · Vignesh R

Add non DM version of SPI_MEM to support easy migration to new SPI NOR framework. This can be removed once DM_SPI conversion is complete.

Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?

As said by others, AFAICS, DM_SPI migration is not going to be complete anytime soon. There are many boards and configs that don't enable DM_SPI. I propose you add a patch to print _warning during build_ for boards that don't have DM_SPI enabled (like DM_MMC and DM_USB) targeting v2019.07 or v2019.04 as deadline for removal. At the deadline you can remove spi-mem-nodm.c along with all other non DM code in SPI core.

Quoted 8 lines
Quoted 3 lines

I don't understand why DM_SPI migration came to this topic? It's a separate thread/issue.

I respectfully disagree. If DM_SPI migration was complete then SPI_MEM would be available for use by all subsystem. This patch wouldn't have been needed.

I have given my comment if spi-mem handle only DM.

Okay, lets move your approach of having spi-mem-nondm.c

#21 lore raw

PATCH 3/16 spi: Add non DM version of SPI_MEM

In reply to Vignesh R
Quoted 130 lines · Vignesh R

Add non DM version of SPI_MEM to support easy migration to new SPI NOR framework. This can be removed once DM_SPI conversion is complete.

---
 drivers/spi/Kconfig        |  4 +-
 drivers/spi/Makefile       |  1 +
 drivers/spi/spi-mem-nodm.c | 89 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 92 insertions(+), 2 deletions(-)
 create mode 100644 drivers/spi/spi-mem-nodm.c
drivers/spi/Kconfig +2 -2
index a7bb5b35c294..5ee855fc5319 100644
@@ -16,8 +16,6 @@ config DM_SPI
          typically use driver-private data instead of extending the
          spi_slave structure.
 
-if DM_SPI
-
 config SPI_MEM
        bool "SPI memory extension"
        help
@@ -25,6 +23,8 @@ config SPI_MEM
          This extension is meant to simplify interaction with SPI memories
          by providing an high-level interface to send memory-like commands.
 
+if DM_SPI
+
 config ALTERA_SPI
        bool "Altera SPI driver"
        help
drivers/spi/Makefile +1 -0
index 392a92579578..32ba3b61f70d 100644
@@ -11,6 +11,7 @@ obj-$(CONFIG_SOFT_SPI) += soft_spi.o
 obj-$(CONFIG_SPI_MEM) += spi-mem.o
 else
 obj-y += spi.o
+obj-$(CONFIG_SPI_MEM) += spi-mem-nodm.o
 obj-$(CONFIG_SOFT_SPI) += soft_spi_legacy.o
 endif
 
drivers/spi/spi-mem-nodm.c new file +78 -0
new file mode 100644
index 000000000000..4d91761f56d3
@@ -0,0 +1,89 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include <spi.h>
+#include <spi-mem.h>
+
+int spi_mem_exec_op(struct spi_slave *slave,
+                   const struct spi_mem_op *op)
+{
+       unsigned int pos = 0;
+       const u8 *tx_buf = NULL;
+       u8 *rx_buf = NULL;
+       u8 *op_buf;
+       int op_len;
+       u32 flag;
+       int ret;
+       int i;
+
+       if (op->data.nbytes) {
+               if (op->data.dir == SPI_MEM_DATA_IN)
+                       rx_buf = op->data.buf.in;
+               else
+                       tx_buf = op->data.buf.out;
+       }
+
+       op_len = sizeof(op->cmd.opcode) + op->addr.nbytes + op->dummy.nbytes;
+       op_buf = calloc(1, op_len);
+
+       ret = spi_claim_bus(slave);
+       if (ret < 0)
+               return ret;
+
+       op_buf[pos++] = op->cmd.opcode;
+
+       if (op->addr.nbytes) {
+               for (i = 0; i < op->addr.nbytes; i++)
+                       op_buf[pos + i] = op->addr.val >>
+                               (8 * (op->addr.nbytes - i - 1));
+
+               pos += op->addr.nbytes;
+       }
+
+       if (op->dummy.nbytes)
+               memset(op_buf + pos, 0xff, op->dummy.nbytes);
+
+       /* 1st transfer: opcode + address + dummy cycles */
+       flag = SPI_XFER_BEGIN;
+       /* Make sure to set END bit if no tx or rx data messages follow */
+       if (!tx_buf && !rx_buf)
+               flag |= SPI_XFER_END;
+
+       ret = spi_xfer(slave, op_len * 8, op_buf, NULL, flag);
+       if (ret)
+               return ret;
+
+       /* 2nd transfer: rx or tx data path */
+       if (tx_buf || rx_buf) {
+               ret = spi_xfer(slave, op->data.nbytes * 8, tx_buf,
+                              rx_buf, SPI_XFER_END);
+               if (ret)
+                       return ret;
+       }
+
+       spi_release_bus(slave);
+
+       for (i = 0; i < pos; i++)
+               debug("%02x ", op_buf[i]);
+       debug("| [%dB %s] ",
+             tx_buf || rx_buf ? op->data.nbytes : 0,
+             tx_buf || rx_buf ? (tx_buf ? "out" : "in") : "-");
+       for (i = 0; i < op->data.nbytes; i++)
+               debug("%02x ", tx_buf ? tx_buf[i] : rx_buf[i]);
+       debug("[ret %d]\n", ret);
+
+       free(op_buf);
+

drivers/spi/spi-mem-nodm.c line 88

Quoted 10 lines
drivers/spi/spi-mem-nodm.c new file +10 -0
+       if (ret < 0)
+               return ret;
+
+       return 0;
+}
+
+int spi_mem_adjust_op_size(struct spi_slave *slave,
+                          struct spi_mem_op *op)
+{
+       return 0;

Does it not return data size of SPI mem, or not need for non-dm?

author maintainer
#22 lore raw

PATCH 3/16 spi: Add non DM version of SPI_MEM

Quoted 13 lines · Jagan Teki
Quoted 12 lines · Vignesh R

Add non DM version of SPI_MEM to support easy migration to new SPI NOR framework. This can be removed once DM_SPI conversion is complete.

---
 drivers/spi/Kconfig        |  4 +-
 drivers/spi/Makefile       |  1 +
 drivers/spi/spi-mem-nodm.c | 89 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 92 insertions(+), 2 deletions(-)
 create mode 100644 drivers/spi/spi-mem-nodm.c

[...]

Quoted 7 lines

drivers/spi/spi-mem-nodm.c line 88

Quoted 4 lines
drivers/spi/spi-mem-nodm.c new file +4 -0
+int spi_mem_adjust_op_size(struct spi_slave *slave,
+                          struct spi_mem_op *op)
+{
+       return 0;

Does it not return data size of SPI mem, or not need for non-dm?

/**
* spi_mem_adjust_op_size() - Adjust the data size of a SPI mem operation to
* match controller limitations
* @slave: the SPI device
* @op: the operation to adjust
*
* Some controllers have FIFO limitations and must split a data transfer
* operation into multiple ones, others require a specific alignment for
* optimized accesses. This function allows SPI mem drivers to split a single
* operation into multiple sub-operations when required.
*
* Return: a negative error code if the controller can't properly adjust @op,
* 0 otherwise. Note that @op->data.nbytes will be updated if @op
* can't be handled in a single step.
*/

I will modify the function to take care of spi->max_write_size and spi->max_read_size in DM and non-DM case (instead of spi-nor-core.c).

Signature · 2 lines
Regards
Vignesh
author maintainer
#23 lore raw

PATCH 4/16 sh: bitops: add hweight*() macros

In reply to Vignesh R

Add hweight*() macros required for moving to new SF layer

---
 arch/sh/include/asm/bitops.h | 4 ++++
 1 file changed, 4 insertions(+)
arch/sh/include/asm/bitops.h +4 -0
index 8cb8385d76db..765f28f116bc 100644
@@ -153,6 +153,10 @@ static inline int ffs (int x)
 }
 #define PLATFORM_FFS
 
+#define hweight32(x) generic_hweight32(x)
+#define hweight16(x) generic_hweight16(x)
+#define hweight8(x) generic_hweight8(x)
+
 #endif /* __KERNEL__ */
 
 #endif /* __ASM_SH_BITOPS_H */
Signature · 1 line
2.19.2
author maintainer
#24 lore raw

PATCH 5/16 mtd: spi: Port SPI NOR framework from Linux

In reply to Vignesh R

Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top. in order to gain 4 byte addressing support, SFDP support and a way to support SPI controllers with MMIO flash interface.

---
 drivers/mtd/spi/spi-nor-core.c | 2647 ++++++++++++++++++++++++++++++++
 include/linux/mtd/cfi.h        |   32 +
 include/linux/mtd/spi-nor.h    |  421 +++++
 3 files changed, 3100 insertions(+)
 create mode 100644 drivers/mtd/spi/spi-nor-core.c
 create mode 100644 include/linux/mtd/cfi.h
 create mode 100644 include/linux/mtd/spi-nor.h
drivers/mtd/spi/spi-nor-core.c new file +2647 -0
new file mode 100644
index 000000000000..4563cd74c2e8
@@ -0,0 +1,2647 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Based on m25p80.c, by Mike Lavender (mike at steroidmicros.com), with
+ * influence from lart.c (Abraham Van Der Merwe) and mtd_dataflash.c
+ *
+ * Copyright (C) 2005, Intec Automation Inc.
+ * Copyright (C) 2014, Freescale Semiconductor, Inc.
+ *
+ * Synced from Linux v4.19
+ */
+
+#include <common.h>
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/log2.h>
+#include <linux/math64.h>
+#include <linux/sizes.h>
+
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/spi-nor.h>
+#include <spi-mem.h>
+#include <spi.h>
+
+/* Define max times to check status register before we give up. */
+
+/*
+ * For everything but full-chip erase; probably could be much smaller, but kept
+ * around for safety for now
+ */
+
+#define HZ					CONFIG_SYS_HZ
+
+#define DEFAULT_READY_WAIT_JIFFIES		(40UL * HZ)
+
+#define SPI_NOR_MAX_ID_LEN	6
+#define SPI_NOR_MAX_ADDR_WIDTH	4
+
+struct flash_info {
+	char		*name;
+
+	/*
+	 * This array stores the ID bytes.
+	 * The first three bytes are the JEDIC ID.
+	 * JEDEC ID zero means "no ID" (mostly older chips).
+	 */
+	u8		id[SPI_NOR_MAX_ID_LEN];
+	u8		id_len;
+
+	/* The size listed here is what works with SPINOR_OP_SE, which isn't
+	 * necessarily called a "sector" by the vendor.
+	 */
+	unsigned int	sector_size;
+	u16		n_sectors;
+
+	u16		page_size;
+	u16		addr_width;
+
+	u16		flags;
+#define SECT_4K			BIT(0)	/* SPINOR_OP_BE_4K works uniformly */
+#define SPI_NOR_NO_ERASE	BIT(1)	/* No erase command needed */
+#define SST_WRITE		BIT(2)	/* use SST byte programming */
+#define SPI_NOR_NO_FR		BIT(3)	/* Can't do fastread */
+#define SECT_4K_PMC		BIT(4)	/* SPINOR_OP_BE_4K_PMC works uniformly */
+#define SPI_NOR_DUAL_READ	BIT(5)	/* Flash supports Dual Read */
+#define SPI_NOR_QUAD_READ	BIT(6)	/* Flash supports Quad Read */
+#define USE_FSR			BIT(7)	/* use flag status register */
+#define SPI_NOR_HAS_LOCK	BIT(8)	/* Flash supports lock/unlock via SR */
+#define SPI_NOR_HAS_TB		BIT(9)	/*
+					 * Flash SR has Top/Bottom (TB) protect
+					 * bit. Must be used with
+					 * SPI_NOR_HAS_LOCK.
+					 */
+#define	SPI_S3AN		BIT(10)	/*
+					 * Xilinx Spartan 3AN In-System Flash
+					 * (MFR cannot be used for probing
+					 * because it has the same value as
+					 * ATMEL flashes)
+					 */
+#define SPI_NOR_4B_OPCODES	BIT(11)	/*
+					 * Use dedicated 4byte address op codes
+					 * to support memory size above 128Mib.
+					 */
+#define NO_CHIP_ERASE		BIT(12) /* Chip does not support chip erase */
+#define SPI_NOR_SKIP_SFDP	BIT(13)	/* Skip parsing of SFDP tables */
+#define USE_CLSR		BIT(14)	/* use CLSR command */
+
+	int	(*quad_enable)(struct spi_nor *nor);
+};
+
+#define JEDEC_MFR(info)	((info)->id[0])
+
+static int spi_nor_read_write_reg(struct spi_nor *nor, struct spi_mem_op
+		*op, void *buf)
+{
+	if (op->data.dir == SPI_MEM_DATA_IN)
+		op->data.buf.in = buf;
+	else
+		op->data.buf.out = buf;
+	return spi_mem_exec_op(nor->spi, op);
+}
+
+static int spi_nor_read_reg(struct spi_nor *nor, u8 code, u8 *val, int len)
+{
+	struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(code, 1),
+					  SPI_MEM_OP_NO_ADDR,
+					  SPI_MEM_OP_NO_DUMMY,
+					  SPI_MEM_OP_DATA_IN(len, NULL, 1));
+	int ret;
+
+	ret = spi_nor_read_write_reg(nor, &op, val);
+	if (ret < 0)
+		dev_dbg(&flash->spimem->spi->dev, "error %d reading %x\n", ret,
+			code);
+
+	return ret;
+}
+
+static int spi_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
+{
+	struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 1),
+					  SPI_MEM_OP_NO_ADDR,
+					  SPI_MEM_OP_NO_DUMMY,
+					  SPI_MEM_OP_DATA_OUT(len, NULL, 1));
+
+	return spi_nor_read_write_reg(nor, &op, buf);
+}
+
+static ssize_t spi_nor_read_data(struct spi_nor *nor, loff_t from, size_t len,
+				 u_char *buf)
+{
+	struct spi_mem_op op =
+			SPI_MEM_OP(SPI_MEM_OP_CMD(nor->read_opcode, 1),
+				   SPI_MEM_OP_ADDR(nor->addr_width, from, 1),
+				   SPI_MEM_OP_DUMMY(nor->read_dummy, 1),
+				   SPI_MEM_OP_DATA_IN(len, buf, 1));
+	size_t remaining = len;
+	int ret;
+
+	/* get transfer protocols. */
+	op.cmd.buswidth = spi_nor_get_protocol_inst_nbits(nor->read_proto);
+	op.addr.buswidth = spi_nor_get_protocol_addr_nbits(nor->read_proto);
+	op.dummy.buswidth = op.addr.buswidth;
+	op.data.buswidth = spi_nor_get_protocol_data_nbits(nor->read_proto);
+
+	/* convert the dummy cycles to the number of bytes */
+	op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8;
+
+	while (remaining) {
+		op.data.nbytes = remaining < UINT_MAX ? remaining : UINT_MAX;
+		ret = spi_mem_adjust_op_size(nor->spi, &op);
+		if (ret)
+			return ret;
+
+		ret = spi_mem_exec_op(nor->spi, &op);
+		if (ret)
+			return ret;
+
+		op.addr.val += op.data.nbytes;
+		remaining -= op.data.nbytes;
+		op.data.buf.in += op.data.nbytes;
+	}
+
+	return len;
+}
+
+static ssize_t spi_nor_write_data(struct spi_nor *nor, loff_t to, size_t len,
+				  const u_char *buf)
+{
+	struct spi_mem_op op =
+			SPI_MEM_OP(SPI_MEM_OP_CMD(nor->program_opcode, 1),
+				   SPI_MEM_OP_ADDR(nor->addr_width, to, 1),
+				   SPI_MEM_OP_NO_DUMMY,
+				   SPI_MEM_OP_DATA_OUT(len, buf, 1));
+	size_t remaining = len;
+	int ret;
+
+	/* get transfer protocols. */
+	op.cmd.buswidth = spi_nor_get_protocol_inst_nbits(nor->write_proto);
+	op.addr.buswidth = spi_nor_get_protocol_addr_nbits(nor->write_proto);
+	op.data.buswidth = spi_nor_get_protocol_data_nbits(nor->write_proto);
+
+	if (nor->program_opcode == SPINOR_OP_AAI_WP && nor->sst_write_second)
+		op.addr.nbytes = 0;
+
+	while (remaining) {
+		op.data.nbytes = remaining < UINT_MAX ? remaining : UINT_MAX;
+		ret = spi_mem_adjust_op_size(nor->spi, &op);
+		if (ret)
+			return ret;
+
+		ret = spi_mem_exec_op(nor->spi, &op);
+		if (ret)
+			return ret;
+
+		op.addr.val += op.data.nbytes;
+		remaining -= op.data.nbytes;
+		op.data.buf.out += op.data.nbytes;
+	}
+
+	return len;
+}
+
+/*
+ * Read the status register, returning its value in the location
+ * Return the status register value.
+ * Returns negative if error occurred.
+ */
+static int read_sr(struct spi_nor *nor)
+{
+	int ret;
+	u8 val;
+
+	ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val, 1);
+	if (ret < 0) {
+		pr_debug("error %d reading SR\n", (int)ret);
+		return ret;
+	}
+
+	return val;
+}
+
+/*
+ * Read the flag status register, returning its value in the location
+ * Return the status register value.
+ * Returns negative if error occurred.
+ */
+static int read_fsr(struct spi_nor *nor)
+{
+	int ret;
+	u8 val;
+
+	ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val, 1);
+	if (ret < 0) {
+		pr_debug("error %d reading FSR\n", ret);
+		return ret;
+	}
+
+	return val;
+}
+
+/*
+ * Read configuration register, returning its value in the
+ * location. Return the configuration register value.
+ * Returns negative if error occurred.
+ */
+#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
+static int read_cr(struct spi_nor *nor)
+{
+	int ret;
+	u8 val;
+
+	ret = nor->read_reg(nor, SPINOR_OP_RDCR, &val, 1);
+	if (ret < 0) {
+		dev_dbg(nor->dev, "error %d reading CR\n", ret);
+		return ret;
+	}
+
+	return val;
+}
+#endif
+
+/*
+ * Write status register 1 byte
+ * Returns negative if error occurred.
+ */
+static inline int write_sr(struct spi_nor *nor, u8 val)
+{
+	nor->cmd_buf[0] = val;
+	return nor->write_reg(nor, SPINOR_OP_WRSR, nor->cmd_buf, 1);
+}
+
+/*
+ * Set write enable latch with Write Enable command.
+ * Returns negative if error occurred.
+ */
+static inline int write_enable(struct spi_nor *nor)
+{
+	return nor->write_reg(nor, SPINOR_OP_WREN, NULL, 0);
+}
+
+/*
+ * Send write disable instruction to the chip.
+ */
+static inline int write_disable(struct spi_nor *nor)
+{
+	return nor->write_reg(nor, SPINOR_OP_WRDI, NULL, 0);
+}
+
+static inline struct spi_nor *mtd_to_spi_nor(struct mtd_info *mtd)
+{
+	return mtd->priv;
+}
+
+static u8 spi_nor_convert_opcode(u8 opcode, const u8 table[][2], size_t size)
+{
+	size_t i;
+
+	for (i = 0; i < size; i++)
+		if (table[i][0] == opcode)
+			return table[i][1];
+
+	/* No conversion found, keep input op code. */
+	return opcode;
+}
+
+static inline u8 spi_nor_convert_3to4_read(u8 opcode)
+{
+	static const u8 spi_nor_3to4_read[][2] = {
+		{ SPINOR_OP_READ,	SPINOR_OP_READ_4B },
+		{ SPINOR_OP_READ_FAST,	SPINOR_OP_READ_FAST_4B },
+		{ SPINOR_OP_READ_1_1_2,	SPINOR_OP_READ_1_1_2_4B },
+		{ SPINOR_OP_READ_1_2_2,	SPINOR_OP_READ_1_2_2_4B },
+		{ SPINOR_OP_READ_1_1_4,	SPINOR_OP_READ_1_1_4_4B },
+		{ SPINOR_OP_READ_1_4_4,	SPINOR_OP_READ_1_4_4_4B },
+	};
+
+	return spi_nor_convert_opcode(opcode, spi_nor_3to4_read,
+				      ARRAY_SIZE(spi_nor_3to4_read));
+}
+
+static inline u8 spi_nor_convert_3to4_program(u8 opcode)
+{
+	static const u8 spi_nor_3to4_program[][2] = {
+		{ SPINOR_OP_PP,		SPINOR_OP_PP_4B },
+		{ SPINOR_OP_PP_1_1_4,	SPINOR_OP_PP_1_1_4_4B },
+		{ SPINOR_OP_PP_1_4_4,	SPINOR_OP_PP_1_4_4_4B },
+	};
+
+	return spi_nor_convert_opcode(opcode, spi_nor_3to4_program,
+				      ARRAY_SIZE(spi_nor_3to4_program));
+}
+
+static inline u8 spi_nor_convert_3to4_erase(u8 opcode)
+{
+	static const u8 spi_nor_3to4_erase[][2] = {
+		{ SPINOR_OP_BE_4K,	SPINOR_OP_BE_4K_4B },
+		{ SPINOR_OP_BE_32K,	SPINOR_OP_BE_32K_4B },
+		{ SPINOR_OP_SE,		SPINOR_OP_SE_4B },
+	};
+
+	return spi_nor_convert_opcode(opcode, spi_nor_3to4_erase,
+				      ARRAY_SIZE(spi_nor_3to4_erase));
+}
+
+static void spi_nor_set_4byte_opcodes(struct spi_nor *nor,
+				      const struct flash_info *info)
+{
+	/* Do some manufacturer fixups first */
+	switch (JEDEC_MFR(info)) {
+	case SNOR_MFR_SPANSION:
+		/* No small sector erase for 4-byte command set */
+		nor->erase_opcode = SPINOR_OP_SE;
+		nor->mtd.erasesize = info->sector_size;
+		break;
+
+	default:
+		break;
+	}
+
+	nor->read_opcode = spi_nor_convert_3to4_read(nor->read_opcode);
+	nor->program_opcode = spi_nor_convert_3to4_program(nor->program_opcode);
+	nor->erase_opcode = spi_nor_convert_3to4_erase(nor->erase_opcode);
+}
+
+/* Enable/disable 4-byte addressing mode. */
+static inline int set_4byte(struct spi_nor *nor, const struct flash_info *info,
+			    int enable)
+{
+	int status;
+	bool need_wren = false;
+	u8 cmd;
+
+	switch (JEDEC_MFR(info)) {
+	case SNOR_MFR_ST:
+	case SNOR_MFR_MICRON:
+		/* Some Micron need WREN command; all will accept it */
+		need_wren = true;
+	case SNOR_MFR_MACRONIX:
+	case SNOR_MFR_WINBOND:
+		if (need_wren)
+			write_enable(nor);
+
+		cmd = enable ? SPINOR_OP_EN4B : SPINOR_OP_EX4B;
+		status = nor->write_reg(nor, cmd, NULL, 0);
+		if (need_wren)
+			write_disable(nor);
+
+		if (!status && !enable &&
+		    JEDEC_MFR(info) == SNOR_MFR_WINBOND) {
+			/*
+			 * On Winbond W25Q256FV, leaving 4byte mode causes
+			 * the Extended Address Register to be set to 1, so all
+			 * 3-byte-address reads come from the second 16M.
+			 * We must clear the register to enable normal behavior.
+			 */
+			write_enable(nor);
+			nor->cmd_buf[0] = 0;
+			nor->write_reg(nor, SPINOR_OP_WREAR, nor->cmd_buf, 1);
+			write_disable(nor);
+		}
+
+		return status;
+	default:
+		/* Spansion style */
+		nor->cmd_buf[0] = enable << 7;
+		return nor->write_reg(nor, SPINOR_OP_BRWR, nor->cmd_buf, 1);
+	}
+}
+
+static int spi_nor_sr_ready(struct spi_nor *nor)
+{
+	int sr = read_sr(nor);
+
+	if (sr < 0)
+		return sr;
+
+#ifndef CONFIG_SPL_BUILD
+	if (nor->flags & SNOR_F_USE_CLSR && sr & (SR_E_ERR | SR_P_ERR)) {
+		if (sr & SR_E_ERR)
+			dev_dbg(nor->dev, "Erase Error occurred\n");
+		else
+			dev_dbg(nor->dev, "Programming Error occurred\n");
+
+		nor->write_reg(nor, SPINOR_OP_CLSR, NULL, 0);
+		return -EIO;
+	}
+#endif
+
+	return !(sr & SR_WIP);
+}
+
+static int spi_nor_fsr_ready(struct spi_nor *nor)
+{
+	int fsr = read_fsr(nor);
+
+	if (fsr < 0)
+		return fsr;
+#ifndef CONFIG_SPL_BUILD
+	if (fsr & (FSR_E_ERR | FSR_P_ERR)) {
+		if (fsr & FSR_E_ERR)
+			dev_dbg(nor->dev, "Erase operation failed.\n");
+		else
+			dev_dbg(nor->dev, "Program operation failed.\n");
+
+		if (fsr & FSR_PT_ERR)
+			dev_dbg(nor->dev,
+				"Attempted to modify a protected sector.\n");
+
+		nor->write_reg(nor, SPINOR_OP_CLFSR, NULL, 0);
+		return -EIO;
+	}
+#endif
+	return fsr & FSR_READY;
+}
+
+static int spi_nor_ready(struct spi_nor *nor)
+{
+	int sr, fsr;
+
+	sr = spi_nor_sr_ready(nor);
+	if (sr < 0)
+		return sr;
+	fsr = nor->flags & SNOR_F_USE_FSR ? spi_nor_fsr_ready(nor) : 1;
+	if (fsr < 0)
+		return fsr;
+	return sr && fsr;
+}
+
+/*
+ * Service routine to read status register until ready, or timeout occurs.
+ * Returns non-zero if error.
+ */
+static int spi_nor_wait_till_ready_with_timeout(struct spi_nor *nor,
+						unsigned long timeout)
+{
+	unsigned long timebase;
+	int ret;
+
+	timebase = get_timer(0);
+
+	while (get_timer(timebase) < timeout) {
+		ret = spi_nor_ready(nor);
+		if (ret < 0)
+			return ret;
+		if (ret)
+			return 0;
+	}
+
+	dev_err(nor->dev, "flash operation timed out\n");
+
+	return -ETIMEDOUT;
+}
+
+static int spi_nor_wait_till_ready(struct spi_nor *nor)
+{
+	return spi_nor_wait_till_ready_with_timeout(nor,
+						    DEFAULT_READY_WAIT_JIFFIES);
+}
+
+/*
+ * Initiate the erasure of a single sector
+ */
+static int spi_nor_erase_sector(struct spi_nor *nor, u32 addr)
+{
+	u8 buf[SPI_NOR_MAX_ADDR_WIDTH];
+	int i;
+
+	if (nor->erase)
+		return nor->erase(nor, addr);
+
+	/*
+	 * Default implementation, if driver doesn't have a specialized HW
+	 * control
+	 */
+	for (i = nor->addr_width - 1; i >= 0; i--) {
+		buf[i] = addr & 0xff;
+		addr >>= 8;
+	}
+
+	return nor->write_reg(nor, nor->erase_opcode, buf, nor->addr_width);
+}
+
+/*
+ * Erase an address range on the nor chip.  The address range may extend
+ * one or more erase sectors.  Return an error is there is a problem erasing.
+ */
+static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
+{
+	struct spi_nor *nor = mtd_to_spi_nor(mtd);
+	u32 addr, len, rem;
+	int ret;
+
+	dev_dbg(nor->dev, "at 0x%llx, len %lld\n", (long long)instr->addr,
+		(long long)instr->len);
+
+	div_u64_rem(instr->len, mtd->erasesize, &rem);
+	if (rem)
+		return -EINVAL;
+
+	addr = instr->addr;
+	len = instr->len;
+
+	while (len) {
+		write_enable(nor);
+
+		ret = spi_nor_erase_sector(nor, addr);
+		if (ret)
+			goto erase_err;
+
+		addr += mtd->erasesize;
+		len -= mtd->erasesize;
+
+		ret = spi_nor_wait_till_ready(nor);
+		if (ret)
+			goto erase_err;
+	}
+
+	write_disable(nor);
+
+erase_err:
+	return ret;
+}
+
+#if defined(CONFIG_SPI_FLASH_STMICRO) || defined(CONFIG_SPI_FLASH_SST)
+/* Write status register and ensure bits in mask match written values */
+static int write_sr_and_check(struct spi_nor *nor, u8 status_new, u8 mask)
+{
+	int ret;
+
+	write_enable(nor);
+	ret = write_sr(nor, status_new);
+	if (ret)
+		return ret;
+
+	ret = spi_nor_wait_till_ready(nor);
+	if (ret)
+		return ret;
+
+	ret = read_sr(nor);
+	if (ret < 0)
+		return ret;
+
+	return ((ret & mask) != (status_new & mask)) ? -EIO : 0;
+}
+
+static void stm_get_locked_range(struct spi_nor *nor, u8 sr, loff_t *ofs,
+				 uint64_t *len)
+{
+	struct mtd_info *mtd = &nor->mtd;
+	u8 mask = SR_BP2 | SR_BP1 | SR_BP0;
+	int shift = ffs(mask) - 1;
+	int pow;
+
+	if (!(sr & mask)) {
+		/* No protection */
+		*ofs = 0;
+		*len = 0;
+	} else {
+		pow = ((sr & mask) ^ mask) >> shift;
+		*len = mtd->size >> pow;
+		if (nor->flags & SNOR_F_HAS_SR_TB && sr & SR_TB)
+			*ofs = 0;
+		else
+			*ofs = mtd->size - *len;
+	}
+}
+
+/*
+ * Return 1 if the entire region is locked (if @locked is true) or unlocked (if
+ * @locked is false); 0 otherwise
+ */
+static int stm_check_lock_status_sr(struct spi_nor *nor, loff_t ofs, u64 len,
+				    u8 sr, bool locked)
+{
+	loff_t lock_offs;
+	uint64_t lock_len;
+
+	if (!len)
+		return 1;
+
+	stm_get_locked_range(nor, sr, &lock_offs, &lock_len);
+
+	if (locked)
+		/* Requested range is a sub-range of locked range */
+		return (ofs + len <= lock_offs + lock_len) && (ofs >= lock_offs);
+	else
+		/* Requested range does not overlap with locked range */
+		return (ofs >= lock_offs + lock_len) || (ofs + len <= lock_offs);
+}
+
+static int stm_is_locked_sr(struct spi_nor *nor, loff_t ofs, uint64_t len,
+			    u8 sr)
+{
+	return stm_check_lock_status_sr(nor, ofs, len, sr, true);
+}
+
+static int stm_is_unlocked_sr(struct spi_nor *nor, loff_t ofs, uint64_t len,
+			      u8 sr)
+{
+	return stm_check_lock_status_sr(nor, ofs, len, sr, false);
+}
+
+/*
+ * Lock a region of the flash. Compatible with ST Micro and similar flash.
+ * Supports the block protection bits BP{0,1,2} in the status register
+ * (SR). Does not support these features found in newer SR bitfields:
+ *   - SEC: sector/block protect - only handle SEC=0 (block protect)
+ *   - CMP: complement protect - only support CMP=0 (range is not complemented)
+ *
+ * Support for the following is provided conditionally for some flash:
+ *   - TB: top/bottom protect
+ *
+ * Sample table portion for 8MB flash (Winbond w25q64fw):
+ *
+ *   SEC  |  TB   |  BP2  |  BP1  |  BP0  |  Prot Length  | Protected Portion
+ *  --------------------------------------------------------------------------
+ *    X   |   X   |   0   |   0   |   0   |  NONE         | NONE
+ *    0   |   0   |   0   |   0   |   1   |  128 KB       | Upper 1/64
+ *    0   |   0   |   0   |   1   |   0   |  256 KB       | Upper 1/32
+ *    0   |   0   |   0   |   1   |   1   |  512 KB       | Upper 1/16
+ *    0   |   0   |   1   |   0   |   0   |  1 MB         | Upper 1/8
+ *    0   |   0   |   1   |   0   |   1   |  2 MB         | Upper 1/4
+ *    0   |   0   |   1   |   1   |   0   |  4 MB         | Upper 1/2
+ *    X   |   X   |   1   |   1   |   1   |  8 MB         | ALL
+ *  ------|-------|-------|-------|-------|---------------|-------------------
+ *    0   |   1   |   0   |   0   |   1   |  128 KB       | Lower 1/64
+ *    0   |   1   |   0   |   1   |   0   |  256 KB       | Lower 1/32
+ *    0   |   1   |   0   |   1   |   1   |  512 KB       | Lower 1/16
+ *    0   |   1   |   1   |   0   |   0   |  1 MB         | Lower 1/8
+ *    0   |   1   |   1   |   0   |   1   |  2 MB         | Lower 1/4
+ *    0   |   1   |   1   |   1   |   0   |  4 MB         | Lower 1/2
+ *
+ * Returns negative on errors, 0 on success.
+ */
+static int stm_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
+{
+	struct mtd_info *mtd = &nor->mtd;
+	int status_old, status_new;
+	u8 mask = SR_BP2 | SR_BP1 | SR_BP0;
+	u8 shift = ffs(mask) - 1, pow, val;
+	loff_t lock_len;
+	bool can_be_top = true, can_be_bottom = nor->flags & SNOR_F_HAS_SR_TB;
+	bool use_top;
+
+	status_old = read_sr(nor);
+	if (status_old < 0)
+		return status_old;
+
+	/* If nothing in our range is unlocked, we don't need to do anything */
+	if (stm_is_locked_sr(nor, ofs, len, status_old))
+		return 0;
+
+	/* If anything below us is unlocked, we can't use 'bottom' protection */
+	if (!stm_is_locked_sr(nor, 0, ofs, status_old))
+		can_be_bottom = false;
+
+	/* If anything above us is unlocked, we can't use 'top' protection */
+	if (!stm_is_locked_sr(nor, ofs + len, mtd->size - (ofs + len),
+			      status_old))
+		can_be_top = false;
+
+	if (!can_be_bottom && !can_be_top)
+		return -EINVAL;
+
+	/* Prefer top, if both are valid */
+	use_top = can_be_top;
+
+	/* lock_len: length of region that should end up locked */
+	if (use_top)
+		lock_len = mtd->size - ofs;
+	else
+		lock_len = ofs + len;
+
+	/*
+	 * Need smallest pow such that:
+	 *
+	 *   1 / (2^pow) <= (len / size)
+	 *
+	 * so (assuming power-of-2 size) we do:
+	 *
+	 *   pow = ceil(log2(size / len)) = log2(size) - floor(log2(len))
+	 */
+	pow = ilog2(mtd->size) - ilog2(lock_len);
+	val = mask - (pow << shift);
+	if (val & ~mask)
+		return -EINVAL;
+	/* Don't "lock" with no region! */
+	if (!(val & mask))
+		return -EINVAL;
+
+	status_new = (status_old & ~mask & ~SR_TB) | val;
+
+	/* Disallow further writes if WP pin is asserted */
+	status_new |= SR_SRWD;
+
+	if (!use_top)
+		status_new |= SR_TB;
+
+	/* Don't bother if they're the same */
+	if (status_new == status_old)
+		return 0;
+
+	/* Only modify protection if it will not unlock other areas */
+	if ((status_new & mask) < (status_old & mask))
+		return -EINVAL;
+
+	return write_sr_and_check(nor, status_new, mask);
+}
+
+/*
+ * Unlock a region of the flash. See stm_lock() for more info
+ *
+ * Returns negative on errors, 0 on success.
+ */
+static int stm_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
+{
+	struct mtd_info *mtd = &nor->mtd;
+	int status_old, status_new;
+	u8 mask = SR_BP2 | SR_BP1 | SR_BP0;
+	u8 shift = ffs(mask) - 1, pow, val;
+	loff_t lock_len;
+	bool can_be_top = true, can_be_bottom = nor->flags & SNOR_F_HAS_SR_TB;
+	bool use_top;
+
+	status_old = read_sr(nor);
+	if (status_old < 0)
+		return status_old;
+
+	/* If nothing in our range is locked, we don't need to do anything */
+	if (stm_is_unlocked_sr(nor, ofs, len, status_old))
+		return 0;
+
+	/* If anything below us is locked, we can't use 'top' protection */
+	if (!stm_is_unlocked_sr(nor, 0, ofs, status_old))
+		can_be_top = false;
+
+	/* If anything above us is locked, we can't use 'bottom' protection */
+	if (!stm_is_unlocked_sr(nor, ofs + len, mtd->size - (ofs + len),
+				status_old))
+		can_be_bottom = false;
+
+	if (!can_be_bottom && !can_be_top)
+		return -EINVAL;
+
+	/* Prefer top, if both are valid */
+	use_top = can_be_top;
+
+	/* lock_len: length of region that should remain locked */
+	if (use_top)
+		lock_len = mtd->size - (ofs + len);
+	else
+		lock_len = ofs;
+
+	/*
+	 * Need largest pow such that:
+	 *
+	 *   1 / (2^pow) >= (len / size)
+	 *
+	 * so (assuming power-of-2 size) we do:
+	 *
+	 *   pow = floor(log2(size / len)) = log2(size) - ceil(log2(len))
+	 */
+	pow = ilog2(mtd->size) - order_base_2(lock_len);
+	if (lock_len == 0) {
+		val = 0; /* fully unlocked */
+	} else {
+		val = mask - (pow << shift);
+		/* Some power-of-two sizes are not supported */
+		if (val & ~mask)
+			return -EINVAL;
+	}
+
+	status_new = (status_old & ~mask & ~SR_TB) | val;
+
+	/* Don't protect status register if we're fully unlocked */
+	if (lock_len == 0)
+		status_new &= ~SR_SRWD;
+
+	if (!use_top)
+		status_new |= SR_TB;
+
+	/* Don't bother if they're the same */
+	if (status_new == status_old)
+		return 0;
+
+	/* Only modify protection if it will not lock other areas */
+	if ((status_new & mask) > (status_old & mask))
+		return -EINVAL;
+
+	return write_sr_and_check(nor, status_new, mask);
+}
+
+/*
+ * Check if a region of the flash is (completely) locked. See stm_lock() for
+ * more info.
+ *
+ * Returns 1 if entire region is locked, 0 if any portion is unlocked, and
+ * negative on errors.
+ */
+static int stm_is_locked(struct spi_nor *nor, loff_t ofs, uint64_t len)
+{
+	int status;
+
+	status = read_sr(nor);
+	if (status < 0)
+		return status;
+
+	return stm_is_locked_sr(nor, ofs, len, status);
+}
+#endif /* CONFIG_SPI_FLASH_STMICRO */
+
+static int spi_nor_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
+{
+	struct spi_nor *nor = mtd_to_spi_nor(mtd);
+	int ret;
+
+	ret = nor->flash_lock(nor, ofs, len);
+
+	return ret;
+}
+
+static int spi_nor_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
+{
+	struct spi_nor *nor = mtd_to_spi_nor(mtd);
+	int ret;
+
+	ret = nor->flash_unlock(nor, ofs, len);
+
+	return ret;
+}
+
+static int spi_nor_is_locked(struct mtd_info *mtd, loff_t ofs, uint64_t len)
+{
+	struct spi_nor *nor = mtd_to_spi_nor(mtd);
+	int ret;
+
+	ret = nor->flash_is_locked(nor, ofs, len);
+
+	return ret;
+}
+
+/* Used when the "_ext_id" is two bytes at most */
+#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags)	\
+		.id = {							\
+			((_jedec_id) >> 16) & 0xff,			\
+			((_jedec_id) >> 8) & 0xff,			\
+			(_jedec_id) & 0xff,				\
+			((_ext_id) >> 8) & 0xff,			\
+			(_ext_id) & 0xff,				\
+			},						\
+		.id_len = (!(_jedec_id) ? 0 : (3 + ((_ext_id) ? 2 : 0))),	\
+		.sector_size = (_sector_size),				\
+		.n_sectors = (_n_sectors),				\
+		.page_size = 256,					\
+		.flags = (_flags),
+
+#define INFO6(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags)	\
+		.id = {							\
+			((_jedec_id) >> 16) & 0xff,			\
+			((_jedec_id) >> 8) & 0xff,			\
+			(_jedec_id) & 0xff,				\
+			((_ext_id) >> 16) & 0xff,			\
+			((_ext_id) >> 8) & 0xff,			\
+			(_ext_id) & 0xff,				\
+			},						\
+		.id_len = 6,						\
+		.sector_size = (_sector_size),				\
+		.n_sectors = (_n_sectors),				\
+		.page_size = 256,					\
+		.flags = (_flags),
+
+/* NOTE: double check command sets and memory organization when you add
+ * more nor chips.  This current list focusses on newer chips, which
+ * have been converging on command sets which including JEDEC ID.
+ *
+ * All newly added entries should describe *hardware* and should use SECT_4K
+ * (or SECT_4K_PMC) if hardware supports erasing 4 KiB sectors. For usage
+ * scenarios excluding small sectors there is config option that can be
+ * disabled: CONFIG_MTD_SPI_NOR_USE_4K_SECTORS.
+ * For historical (and compatibility) reasons (before we got above config) some
+ * old entries may be missing 4K flag.
+ */
+const struct flash_info spi_nor_ids[] = {
+#ifdef CONFIG_SPI_FLASH_ATMEL		/* ATMEL */
+	/* Atmel -- some are (confusingly) marketed as "DataFlash" */
+	{ "at26df321",  INFO(0x1f4700, 0, 64 * 1024, 64, SECT_4K) },
+	{ "at25df321a", INFO(0x1f4701, 0, 64 * 1024, 64, SECT_4K) },
+
+	{ "at45db011d",	INFO(0x1f2200, 0, 64 * 1024,   4, SECT_4K) },
+	{ "at45db021d",	INFO(0x1f2300, 0, 64 * 1024,   8, SECT_4K) },
+	{ "at45db041d",	INFO(0x1f2400, 0, 64 * 1024,   8, SECT_4K) },
+	{ "at45db081d", INFO(0x1f2500, 0, 64 * 1024,  16, SECT_4K) },
+	{ "at45db161d",	INFO(0x1f2600, 0, 64 * 1024,  32, SECT_4K) },
+	{ "at45db321d",	INFO(0x1f2700, 0, 64 * 1024,  64, SECT_4K) },
+	{ "at45db641d",	INFO(0x1f2800, 0, 64 * 1024, 128, SECT_4K) },
+	{ "at26df081a", INFO(0x1f4501, 0, 64 * 1024,  16, SECT_4K) },
+#endif
+#ifdef CONFIG_SPI_FLASH_EON		/* EON */
+	/* EON -- en25xxx */
+	{ "en25q32b",   INFO(0x1c3016, 0, 64 * 1024,   64, 0) },
+	{ "en25q64",    INFO(0x1c3017, 0, 64 * 1024,  128, SECT_4K) },
+	{ "en25qh128",  INFO(0x1c7018, 0, 64 * 1024,  256, 0) },
+	{ "en25s64",	INFO(0x1c3817, 0, 64 * 1024,  128, SECT_4K) },
+#endif
+#ifdef CONFIG_SPI_FLASH_GIGADEVICE	/* GIGADEVICE */
+	/* GigaDevice */
+	{
+		"gd25q16", INFO(0xc84015, 0, 64 * 1024,  32,
+			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+	},
+	{
+		"gd25q32", INFO(0xc84016, 0, 64 * 1024,  64,
+			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+	},
+	{
+		"gd25lq32", INFO(0xc86016, 0, 64 * 1024, 64,
+			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+	},
+	{
+		"gd25q64", INFO(0xc84017, 0, 64 * 1024, 128,
+			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+	},
+#endif
+#ifdef CONFIG_SPI_FLASH_ISSI		/* ISSI */
+	/* ISSI */
+	{ "is25lq040b", INFO(0x9d4013, 0, 64 * 1024,   8,
+			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+	{ "is25lp032",	INFO(0x9d6016, 0, 64 * 1024,  64, 0) },
+	{ "is25lp064",	INFO(0x9d6017, 0, 64 * 1024, 128, 0) },
+	{ "is25lp128",  INFO(0x9d6018, 0, 64 * 1024, 256,
+			SECT_4K | SPI_NOR_DUAL_READ) },
+	{ "is25lp256",  INFO(0x9d6019, 0, 64 * 1024, 512,
+			SECT_4K | SPI_NOR_DUAL_READ) },
+	{ "is25wp032",  INFO(0x9d7016, 0, 64 * 1024,  64,
+			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+	{ "is25wp064",  INFO(0x9d7017, 0, 64 * 1024, 128,
+			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+	{ "is25wp128",  INFO(0x9d7018, 0, 64 * 1024, 256,
+			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+#endif
+#ifdef CONFIG_SPI_FLASH_MACRONIX	/* MACRONIX */
+	/* Macronix */
+	{ "mx25l2005a",  INFO(0xc22012, 0, 64 * 1024,   4, SECT_4K) },
+	{ "mx25l4005a",  INFO(0xc22013, 0, 64 * 1024,   8, SECT_4K) },
+	{ "mx25l8005",   INFO(0xc22014, 0, 64 * 1024,  16, 0) },
+	{ "mx25l1606e",  INFO(0xc22015, 0, 64 * 1024,  32, SECT_4K) },
+	{ "mx25l3205d",  INFO(0xc22016, 0, 64 * 1024,  64, SECT_4K) },
+	{ "mx25l6405d",  INFO(0xc22017, 0, 64 * 1024, 128, SECT_4K) },
+	{ "mx25u2033e",  INFO(0xc22532, 0, 64 * 1024,   4, SECT_4K) },
+	{ "mx25u1635e",  INFO(0xc22535, 0, 64 * 1024,  32, SECT_4K) },
+	{ "mx25u6435f",  INFO(0xc22537, 0, 64 * 1024, 128, SECT_4K) },
+	{ "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 0) },
+	{ "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256, 0) },
+	{ "mx25l25635e", INFO(0xc22019, 0, 64 * 1024, 512, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+	{ "mx25u25635f", INFO(0xc22539, 0, 64 * 1024, 512, SECT_4K | SPI_NOR_4B_OPCODES) },
+	{ "mx25l25655e", INFO(0xc22619, 0, 64 * 1024, 512, 0) },
+	{ "mx66l51235l", INFO(0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
+	{ "mx66u51235f", INFO(0xc2253a, 0, 64 * 1024, 1024, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
+	{ "mx66l1g45g",  INFO(0xc2201b, 0, 64 * 1024, 2048, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+	{ "mx25l1633e",	 INFO(0xc22415, 0, 64 * 1024,   32, SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | SECT_4K) },
+#endif
+
+#ifdef CONFIG_SPI_FLASH_STMICRO		/* STMICRO */
+	/* Micron */
+	{ "n25q016a",	 INFO(0x20bb15, 0, 64 * 1024,   32, SECT_4K | SPI_NOR_QUAD_READ) },
+	{ "n25q032",	 INFO(0x20ba16, 0, 64 * 1024,   64, SPI_NOR_QUAD_READ) },
+	{ "n25q032a",	 INFO(0x20bb16, 0, 64 * 1024,   64, SPI_NOR_QUAD_READ) },
+	{ "n25q064",     INFO(0x20ba17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
+	{ "n25q064a",    INFO(0x20bb17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
+	{ "n25q128a11",  INFO(0x20bb18, 0, 64 * 1024,  256, SECT_4K | SPI_NOR_QUAD_READ) },
+	{ "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256, SECT_4K | SPI_NOR_QUAD_READ) },
+	{ "n25q256a",    INFO(0x20ba19, 0, 64 * 1024,  512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+	{ "n25q256ax1",  INFO(0x20bb19, 0, 64 * 1024,  512, SECT_4K | SPI_NOR_QUAD_READ) },
+	{ "n25q512a",    INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
+	{ "n25q512ax3",  INFO(0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
+	{ "n25q00",      INFO(0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
+	{ "n25q00a",     INFO(0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
+	{ "mt25qu02g",   INFO(0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
+#endif
+#ifdef CONFIG_SPI_FLASH_SPANSION	/* SPANSION */
+	/* Spansion/Cypress -- single (large) sector size only, at least
+	 * for the chips listed here (without boot sectors).
+	 */
+	{ "s25sl032p",  INFO(0x010215, 0x4d00,  64 * 1024,  64, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+	{ "s25sl064p",  INFO(0x010216, 0x4d00,  64 * 1024, 128, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+	{ "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, USE_CLSR) },
+	{ "s25fl256s1", INFO(0x010219, 0x4d01,  64 * 1024, 512, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
+	{ "s25fl512s",  INFO6(0x010220, 0x4d0081, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
+	{ "s25fl512s_256k",  INFO(0x010220, 0x4d00, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
+	{ "s25fl512s_64k",  INFO(0x010220, 0x4d01, 64 * 1024, 1024, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
+	{ "s25fl512s_512k",  INFO(0x010220, 0x4f00, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
+	{ "s25sl12800", INFO(0x012018, 0x0300, 256 * 1024,  64, 0) },
+	{ "s25sl12801", INFO(0x012018, 0x0301,  64 * 1024, 256, 0) },
+	{ "s25fl128s",  INFO6(0x012018, 0x4d0180, 64 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
+	{ "s25fl129p0", INFO(0x012018, 0x4d00, 256 * 1024,  64, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
+	{ "s25fl129p1", INFO(0x012018, 0x4d01,  64 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
+	{ "s25sl008a",  INFO(0x010213,      0,  64 * 1024,  16, 0) },
+	{ "s25sl016a",  INFO(0x010214,      0,  64 * 1024,  32, 0) },
+	{ "s25sl032a",  INFO(0x010215,      0,  64 * 1024,  64, 0) },
+	{ "s25sl064a",  INFO(0x010216,      0,  64 * 1024, 128, 0) },
+	{ "s25fl116k",  INFO(0x014015,      0,  64 * 1024,  32, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+	{ "s25fl164k",  INFO(0x014017,      0,  64 * 1024, 128, SECT_4K) },
+	{ "s25fl208k",  INFO(0x014014,      0,  64 * 1024,  16, SECT_4K | SPI_NOR_DUAL_READ) },
+	{ "s25fl128l",  INFO(0x016018,      0,  64 * 1024, 256, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
+#endif
+#ifdef CONFIG_SPI_FLASH_SST		/* SST */
+	/* SST -- large erase sizes are "overlays", "sectors" are 4K */
+	{ "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K | SST_WRITE) },
+	{ "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE) },
+	{ "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE) },
+	{ "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE) },
+	{ "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128, SECT_4K) },
+	{ "sst25wf512",  INFO(0xbf2501, 0, 64 * 1024,  1, SECT_4K | SST_WRITE) },
+	{ "sst25wf010",  INFO(0xbf2502, 0, 64 * 1024,  2, SECT_4K | SST_WRITE) },
+	{ "sst25wf020",  INFO(0xbf2503, 0, 64 * 1024,  4, SECT_4K | SST_WRITE) },
+	{ "sst25wf020a", INFO(0x621612, 0, 64 * 1024,  4, SECT_4K) },
+	{ "sst25wf040b", INFO(0x621613, 0, 64 * 1024,  8, SECT_4K) },
+	{ "sst25wf040",  INFO(0xbf2504, 0, 64 * 1024,  8, SECT_4K | SST_WRITE) },
+	{ "sst25wf080",  INFO(0xbf2505, 0, 64 * 1024, 16, SECT_4K | SST_WRITE) },
+	{ "sst26vf064b", INFO(0xbf2643, 0, 64 * 1024, 128, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+	{ "sst26wf016",  INFO(0xbf2651, 0, 64 * 1024,  32, SECT_4K) },
+	{ "sst26wf032",	 INFO(0xbf2622, 0, 64 * 1024,  64, SECT_4K) },
+	{ "sst26wf064",	 INFO(0xbf2643, 0, 64 * 1024, 128, SECT_4K) },
+#endif
+#ifdef CONFIG_SPI_FLASH_STMICRO		/* STMICRO */
+	/* ST Microelectronics -- newer production may have feature updates */
+	{ "m25p10",  INFO(0x202011,  0,  32 * 1024,   4, 0) },
+	{ "m25p20",  INFO(0x202012,  0,  64 * 1024,   4, 0) },
+	{ "m25p40",  INFO(0x202013,  0,  64 * 1024,   8, 0) },
+	{ "m25p80",  INFO(0x202014,  0,  64 * 1024,  16, 0) },
+	{ "m25p16",  INFO(0x202015,  0,  64 * 1024,  32, 0) },
+	{ "m25p32",  INFO(0x202016,  0,  64 * 1024,  64, 0) },
+	{ "m25p64",  INFO(0x202017,  0,  64 * 1024, 128, 0) },
+	{ "m25p128", INFO(0x202018,  0, 256 * 1024,  64, 0) },
+	{ "m25pe16", INFO(0x208015,  0, 64 * 1024, 32, SECT_4K) },
+	{ "m25px16",    INFO(0x207115,  0, 64 * 1024, 32, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+	{ "m25px64",    INFO(0x207117,  0, 64 * 1024, 128, 0) },
+#endif
+#ifdef CONFIG_SPI_FLASH_WINBOND		/* WINBOND */
+	/* Winbond -- w25x "blocks" are 64K, "sectors" are 4KiB */
+	{ "w25x05", INFO(0xef3010, 0, 64 * 1024,  1,  SECT_4K) },
+	{ "w25x10", INFO(0xef3011, 0, 64 * 1024,  2,  SECT_4K) },
+	{ "w25x20", INFO(0xef3012, 0, 64 * 1024,  4,  SECT_4K) },
+	{ "w25x40", INFO(0xef3013, 0, 64 * 1024,  8,  SECT_4K) },
+	{ "w25x80", INFO(0xef3014, 0, 64 * 1024,  16, SECT_4K) },
+	{ "w25x16", INFO(0xef3015, 0, 64 * 1024,  32, SECT_4K) },
+	{
+		"w25q16dw", INFO(0xef6015, 0, 64 * 1024,  32,
+			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+	},
+	{ "w25x32", INFO(0xef3016, 0, 64 * 1024,  64, SECT_4K) },
+	{ "w25q20cl", INFO(0xef4012, 0, 64 * 1024,  4, SECT_4K) },
+	{ "w25q20bw", INFO(0xef5012, 0, 64 * 1024,  4, SECT_4K) },
+	{ "w25q20ew", INFO(0xef6012, 0, 64 * 1024,  4, SECT_4K) },
+	{ "w25q32", INFO(0xef4016, 0, 64 * 1024,  64, SECT_4K) },
+	{
+		"w25q32dw", INFO(0xef6016, 0, 64 * 1024,  64,
+			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+	},
+	{
+		"w25q32jv", INFO(0xef7016, 0, 64 * 1024,  64,
+			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+	},
+	{ "w25x64", INFO(0xef3017, 0, 64 * 1024, 128, SECT_4K) },
+	{ "w25q64", INFO(0xef4017, 0, 64 * 1024, 128, SECT_4K) },
+	{
+		"w25q64dw", INFO(0xef6017, 0, 64 * 1024, 128,
+			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+	},
+	{
+		"w25q128fw", INFO(0xef6018, 0, 64 * 1024, 256,
+			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+	},
+	{ "w25q80", INFO(0xef5014, 0, 64 * 1024,  16, SECT_4K) },
+	{ "w25q80bl", INFO(0xef4014, 0, 64 * 1024,  16, SECT_4K) },
+	{ "w25q128", INFO(0xef4018, 0, 64 * 1024, 256, SECT_4K) },
+	{ "w25q256", INFO(0xef4019, 0, 64 * 1024, 512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+	{ "w25m512jv", INFO(0xef7119, 0, 64 * 1024, 1024,
+			SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_DUAL_READ) },
+#endif
+#ifdef CONFIG_SPI_FLASH_XMC
+	/* XMC (Wuhan Xinxin Semiconductor Manufacturing Corp.) */
+	{ "XM25QH64A", INFO(0x207017, 0, 64 * 1024, 128, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+	{ "XM25QH128A", INFO(0x207018, 0, 64 * 1024, 256, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+#endif
+	{ },
+};
+
+static const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
+{
+	int			tmp;
+	u8			id[SPI_NOR_MAX_ID_LEN];
+	const struct flash_info	*info;
+
+	if (!ARRAY_SIZE(spi_nor_ids))
+		return ERR_PTR(-ENODEV);
+
+	tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, SPI_NOR_MAX_ID_LEN);
+	if (tmp < 0) {
+		dev_dbg(nor->dev, "error %d reading JEDEC ID\n", tmp);
+		return ERR_PTR(tmp);
+	}
+
+	for (tmp = 0; tmp < ARRAY_SIZE(spi_nor_ids) - 1; tmp++) {
+		info = &spi_nor_ids[tmp];
+		if (info->id_len) {
+			if (!memcmp(info->id, id, info->id_len))
+				return &spi_nor_ids[tmp];
+		}
+	}
+	dev_err(nor->dev, "unrecognized JEDEC id bytes: %02x, %02x, %02x\n",
+		id[0], id[1], id[2]);
+	return ERR_PTR(-ENODEV);
+}
+
+static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len,
+			size_t *retlen, u_char *buf)
+{
+	struct spi_nor *nor = mtd_to_spi_nor(mtd);
+	int ret;
+
+	dev_dbg(nor->dev, "from 0x%08x, len %zd\n", (u32)from, len);
+
+	while (len) {
+		loff_t addr = from;
+
+		ret = nor->read(nor, addr, len, buf);
+		if (ret == 0) {
+			/* We shouldn't see 0-length reads */
+			ret = -EIO;
+			goto read_err;
+		}
+		if (ret < 0)
+			goto read_err;
+
+		*retlen += ret;
+		buf += ret;
+		from += ret;
+		len -= ret;
+	}
+	ret = 0;
+
+read_err:
+	return ret;
+}
+
+#ifdef CONFIG_SPI_FLASH_SST
+static int sst_write(struct mtd_info *mtd, loff_t to, size_t len,
+		     size_t *retlen, const u_char *buf)
+{
+	struct spi_nor *nor = mtd_to_spi_nor(mtd);
+	size_t actual;
+	int ret;
+
+	dev_dbg(nor->dev, "to 0x%08x, len %zd\n", (u32)to, len);
+
+	write_enable(nor);
+
+	nor->sst_write_second = false;
+
+	actual = to % 2;
+	/* Start write from odd address. */
+	if (actual) {
+		nor->program_opcode = SPINOR_OP_BP;
+
+		/* write one byte. */
+		ret = nor->write(nor, to, 1, buf);
+		if (ret < 0)
+			goto sst_write_err;
+		ret = spi_nor_wait_till_ready(nor);
+		if (ret)
+			goto sst_write_err;
+	}
+	to += actual;
+
+	/* Write out most of the data here. */
+	for (; actual < len - 1; actual += 2) {
+		nor->program_opcode = SPINOR_OP_AAI_WP;
+
+		/* write two bytes. */
+		ret = nor->write(nor, to, 2, buf + actual);
+		if (ret < 0)
+			goto sst_write_err;
+		ret = spi_nor_wait_till_ready(nor);
+		if (ret)
+			goto sst_write_err;
+		to += 2;
+		nor->sst_write_second = true;
+	}
+	nor->sst_write_second = false;
+
+	write_disable(nor);
+	ret = spi_nor_wait_till_ready(nor);
+	if (ret)
+		goto sst_write_err;
+
+	/* Write out trailing byte if it exists. */
+	if (actual != len) {
+		write_enable(nor);
+
+		nor->program_opcode = SPINOR_OP_BP;
+		ret = nor->write(nor, to, 1, buf + actual);
+		if (ret < 0)
+			goto sst_write_err;
+		ret = spi_nor_wait_till_ready(nor);
+		if (ret)
+			goto sst_write_err;
+		write_disable(nor);
+		actual += 1;
+	}
+sst_write_err:
+	*retlen += actual;
+	return ret;
+}
+#endif
+/*
+ * Write an address range to the nor chip.  Data must be written in
+ * FLASH_PAGESIZE chunks.  The address range may be any size provided
+ * it is within the physical boundaries.
+ */
+static int spi_nor_write(struct mtd_info *mtd, loff_t to, size_t len,
+	size_t *retlen, const u_char *buf)
+{
+	struct spi_nor *nor = mtd_to_spi_nor(mtd);
+	size_t page_offset, page_remain, i;
+	ssize_t ret;
+
+	dev_dbg(nor->dev, "to 0x%08x, len %zd\n", (u32)to, len);
+
+	for (i = 0; i < len; ) {
+		ssize_t written;
+		loff_t addr = to + i;
+
+		/*
+		 * If page_size is a power of two, the offset can be quickly
+		 * calculated with an AND operation. On the other cases we
+		 * need to do a modulus operation (more expensive).
+		 * Power of two numbers have only one bit set and we can use
+		 * the instruction hweight32 to detect if we need to do a
+		 * modulus (do_div()) or not.
+		 */
+		if (hweight32(nor->page_size) == 1) {
+			page_offset = addr & (nor->page_size - 1);
+		} else {
+			u64 aux = addr;
+
+			page_offset = do_div(aux, nor->page_size);
+		}
+		/* the size of data remaining on the first page */
+		page_remain = min_t(size_t,
+				    nor->page_size - page_offset, len - i);
+
+		write_enable(nor);
+		ret = nor->write(nor, addr, page_remain, buf + i);
+		if (ret < 0)
+			goto write_err;
+		written = ret;
+
+		ret = spi_nor_wait_till_ready(nor);
+		if (ret)
+			goto write_err;
+		*retlen += written;
+		i += written;
+		if (written != page_remain) {
+			dev_dbg(nor->dev,
+				"While writing %zu bytes written %zd bytes\n",
+				page_remain, written);
+			ret = -EIO;
+			goto write_err;
+		}
+	}
+
+write_err:
+	return ret;
+}
+
+#ifdef CONFIG_SPI_FLASH_MACRONIX
+/**
+ * macronix_quad_enable() - set QE bit in Status Register.
+ * @nor:	pointer to a 'struct spi_nor'
+ *
+ * Set the Quad Enable (QE) bit in the Status Register.
+ *
+ * bit 6 of the Status Register is the QE bit for Macronix like QSPI memories.
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int macronix_quad_enable(struct spi_nor *nor)
+{
+	int ret, val;
+
+	val = read_sr(nor);
+	if (val < 0)
+		return val;
+	if (val & SR_QUAD_EN_MX)
+		return 0;
+
+	write_enable(nor);
+
+	write_sr(nor, val | SR_QUAD_EN_MX);
+
+	ret = spi_nor_wait_till_ready(nor);
+	if (ret)
+		return ret;
+
+	ret = read_sr(nor);
+	if (!(ret > 0 && (ret & SR_QUAD_EN_MX))) {
+		dev_err(nor->dev, "Macronix Quad bit not set\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+#endif
+
+#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
+/*
+ * Write status Register and configuration register with 2 bytes
+ * The first byte will be written to the status register, while the
+ * second byte will be written to the configuration register.
+ * Return negative if error occurred.
+ */
+static int write_sr_cr(struct spi_nor *nor, u8 *sr_cr)
+{
+	int ret;
+
+	write_enable(nor);
+
+	ret = nor->write_reg(nor, SPINOR_OP_WRSR, sr_cr, 2);
+	if (ret < 0) {
+		dev_dbg(nor->dev,
+			"error while writing configuration register\n");
+		return -EINVAL;
+	}
+
+	ret = spi_nor_wait_till_ready(nor);
+	if (ret) {
+		dev_dbg(nor->dev,
+			"timeout while writing configuration register\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+/**
+ * spansion_read_cr_quad_enable() - set QE bit in Configuration Register.
+ * @nor:	pointer to a 'struct spi_nor'
+ *
+ * Set the Quad Enable (QE) bit in the Configuration Register.
+ * This function should be used with QSPI memories supporting the Read
+ * Configuration Register (35h) instruction.
+ *
+ * bit 1 of the Configuration Register is the QE bit for Spansion like QSPI
+ * memories.
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spansion_read_cr_quad_enable(struct spi_nor *nor)
+{
+	u8 sr_cr[2];
+	int ret;
+
+	/* Check current Quad Enable bit value. */
+	ret = read_cr(nor);
+	if (ret < 0) {
+		dev_dbg(dev, "error while reading configuration register\n");
+		return -EINVAL;
+	}
+
+	if (ret & CR_QUAD_EN_SPAN)
+		return 0;
+
+	sr_cr[1] = ret | CR_QUAD_EN_SPAN;
+
+	/* Keep the current value of the Status Register. */
+	ret = read_sr(nor);
+	if (ret < 0) {
+		dev_dbg(dev, "error while reading status register\n");
+		return -EINVAL;
+	}
+	sr_cr[0] = ret;
+
+	ret = write_sr_cr(nor, sr_cr);
+	if (ret)
+		return ret;
+
+	/* Read back and check it. */
+	ret = read_cr(nor);
+	if (!(ret > 0 && (ret & CR_QUAD_EN_SPAN))) {
+		dev_dbg(nor->dev, "Spansion Quad bit not set\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+#if CONFIG_IS_ENABLED(SPI_FLASH_SFDP_SUPPORT)
+/**
+ * spansion_no_read_cr_quad_enable() - set QE bit in Configuration Register.
+ * @nor:	pointer to a 'struct spi_nor'
+ *
+ * Set the Quad Enable (QE) bit in the Configuration Register.
+ * This function should be used with QSPI memories not supporting the Read
+ * Configuration Register (35h) instruction.
+ *
+ * bit 1 of the Configuration Register is the QE bit for Spansion like QSPI
+ * memories.
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spansion_no_read_cr_quad_enable(struct spi_nor *nor)
+{
+	u8 sr_cr[2];
+	int ret;
+
+	/* Keep the current value of the Status Register. */
+	ret = read_sr(nor);
+	if (ret < 0) {
+		dev_dbg(nor->dev, "error while reading status register\n");
+		return -EINVAL;
+	}
+	sr_cr[0] = ret;
+	sr_cr[1] = CR_QUAD_EN_SPAN;
+
+	return write_sr_cr(nor, sr_cr);
+}
+
+#endif /* CONFIG_SPI_FLASH_SFDP_SUPPORT */
+#endif /* CONFIG_SPI_FLASH_SPANSION */
+
+struct spi_nor_read_command {
+	u8			num_mode_clocks;
+	u8			num_wait_states;
+	u8			opcode;
+	enum spi_nor_protocol	proto;
+};
+
+struct spi_nor_pp_command {
+	u8			opcode;
+	enum spi_nor_protocol	proto;
+};
+
+enum spi_nor_read_command_index {
+	SNOR_CMD_READ,
+	SNOR_CMD_READ_FAST,
+	SNOR_CMD_READ_1_1_1_DTR,
+
+	/* Dual SPI */
+	SNOR_CMD_READ_1_1_2,
+	SNOR_CMD_READ_1_2_2,
+	SNOR_CMD_READ_2_2_2,
+	SNOR_CMD_READ_1_2_2_DTR,
+
+	/* Quad SPI */
+	SNOR_CMD_READ_1_1_4,
+	SNOR_CMD_READ_1_4_4,
+	SNOR_CMD_READ_4_4_4,
+	SNOR_CMD_READ_1_4_4_DTR,
+
+	/* Octo SPI */
+	SNOR_CMD_READ_1_1_8,
+	SNOR_CMD_READ_1_8_8,
+	SNOR_CMD_READ_8_8_8,
+	SNOR_CMD_READ_1_8_8_DTR,
+
+	SNOR_CMD_READ_MAX
+};
+
+enum spi_nor_pp_command_index {
+	SNOR_CMD_PP,
+
+	/* Quad SPI */
+	SNOR_CMD_PP_1_1_4,
+	SNOR_CMD_PP_1_4_4,
+	SNOR_CMD_PP_4_4_4,
+
+	/* Octo SPI */
+	SNOR_CMD_PP_1_1_8,
+	SNOR_CMD_PP_1_8_8,
+	SNOR_CMD_PP_8_8_8,
+
+	SNOR_CMD_PP_MAX
+};
+
+struct spi_nor_flash_parameter {
+	u64				size;
+	u32				page_size;
+
+	struct spi_nor_hwcaps		hwcaps;
+	struct spi_nor_read_command	reads[SNOR_CMD_READ_MAX];
+	struct spi_nor_pp_command	page_programs[SNOR_CMD_PP_MAX];
+
+	int (*quad_enable)(struct spi_nor *nor);
+};
+
+static void
+spi_nor_set_read_settings(struct spi_nor_read_command *read,
+			  u8 num_mode_clocks,
+			  u8 num_wait_states,
+			  u8 opcode,
+			  enum spi_nor_protocol proto)
+{
+	read->num_mode_clocks = num_mode_clocks;
+	read->num_wait_states = num_wait_states;
+	read->opcode = opcode;
+	read->proto = proto;
+}
+
+static void
+spi_nor_set_pp_settings(struct spi_nor_pp_command *pp,
+			u8 opcode,
+			enum spi_nor_protocol proto)
+{
+	pp->opcode = opcode;
+	pp->proto = proto;
+}
+
+#if CONFIG_IS_ENABLED(SPI_FLASH_SFDP_SUPPORT)
+/*
+ * Serial Flash Discoverable Parameters (SFDP) parsing.
+ */
+
+/**
+ * spi_nor_read_sfdp() - read Serial Flash Discoverable Parameters.
+ * @nor:	pointer to a 'struct spi_nor'
+ * @addr:	offset in the SFDP area to start reading data from
+ * @len:	number of bytes to read
+ * @buf:	buffer where the SFDP data are copied into (dma-safe memory)
+ *
+ * Whatever the actual numbers of bytes for address and dummy cycles are
+ * for (Fast) Read commands, the Read SFDP (5Ah) instruction is always
+ * followed by a 3-byte address and 8 dummy clock cycles.
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spi_nor_read_sfdp(struct spi_nor *nor, u32 addr,
+			     size_t len, void *buf)
+{
+	u8 addr_width, read_opcode, read_dummy;
+	int ret;
+
+	read_opcode = nor->read_opcode;
+	addr_width = nor->addr_width;
+	read_dummy = nor->read_dummy;
+
+	nor->read_opcode = SPINOR_OP_RDSFDP;
+	nor->addr_width = 3;
+	nor->read_dummy = 8;
+
+	while (len) {
+		ret = nor->read(nor, addr, len, (u8 *)buf);
+		if (!ret || ret > len) {
+			ret = -EIO;
+			goto read_err;
+		}
+		if (ret < 0)
+			goto read_err;
+
+		buf += ret;
+		addr += ret;
+		len -= ret;
+	}
+	ret = 0;
+
+read_err:
+	nor->read_opcode = read_opcode;
+	nor->addr_width = addr_width;
+	nor->read_dummy = read_dummy;
+
+	return ret;
+}
+
+struct sfdp_parameter_header {
+	u8		id_lsb;
+	u8		minor;
+	u8		major;
+	u8		length; /* in double words */
+	u8		parameter_table_pointer[3]; /* byte address */
+	u8		id_msb;
+};
+
+#define SFDP_PARAM_HEADER_ID(p)	(((p)->id_msb << 8) | (p)->id_lsb)
+#define SFDP_PARAM_HEADER_PTP(p) \
+	(((p)->parameter_table_pointer[2] << 16) | \
+	 ((p)->parameter_table_pointer[1] <<  8) | \
+	 ((p)->parameter_table_pointer[0] <<  0))
+
+#define SFDP_BFPT_ID		0xff00	/* Basic Flash Parameter Table */
+#define SFDP_SECTOR_MAP_ID	0xff81	/* Sector Map Table */
+
+#define SFDP_SIGNATURE		0x50444653U
+#define SFDP_JESD216_MAJOR	1
+#define SFDP_JESD216_MINOR	0
+#define SFDP_JESD216A_MINOR	5
+#define SFDP_JESD216B_MINOR	6
+
+struct sfdp_header {
+	u32		signature; /* Ox50444653U <=> "SFDP" */
+	u8		minor;
+	u8		major;
+	u8		nph; /* 0-base number of parameter headers */
+	u8		unused;
+
+	/* Basic Flash Parameter Table. */
+	struct sfdp_parameter_header	bfpt_header;
+};
+
+/* Basic Flash Parameter Table */
+
+/*
+ * JESD216 rev B defines a Basic Flash Parameter Table of 16 DWORDs.
+ * They are indexed from 1 but C arrays are indexed from 0.
+ */
+#define BFPT_DWORD(i)		((i) - 1)
+#define BFPT_DWORD_MAX		16
+
+/* The first version of JESB216 defined only 9 DWORDs. */
+#define BFPT_DWORD_MAX_JESD216			9
+
+/* 1st DWORD. */
+#define BFPT_DWORD1_FAST_READ_1_1_2		BIT(16)
+#define BFPT_DWORD1_ADDRESS_BYTES_MASK		GENMASK(18, 17)
+#define BFPT_DWORD1_ADDRESS_BYTES_3_ONLY	(0x0UL << 17)
+#define BFPT_DWORD1_ADDRESS_BYTES_3_OR_4	(0x1UL << 17)
+#define BFPT_DWORD1_ADDRESS_BYTES_4_ONLY	(0x2UL << 17)
+#define BFPT_DWORD1_DTR				BIT(19)
+#define BFPT_DWORD1_FAST_READ_1_2_2		BIT(20)
+#define BFPT_DWORD1_FAST_READ_1_4_4		BIT(21)
+#define BFPT_DWORD1_FAST_READ_1_1_4		BIT(22)
+
+/* 5th DWORD. */
+#define BFPT_DWORD5_FAST_READ_2_2_2		BIT(0)
+#define BFPT_DWORD5_FAST_READ_4_4_4		BIT(4)
+
+/* 11th DWORD. */
+#define BFPT_DWORD11_PAGE_SIZE_SHIFT		4
+#define BFPT_DWORD11_PAGE_SIZE_MASK		GENMASK(7, 4)
+
+/* 15th DWORD. */
+
+/*
+ * (from JESD216 rev B)
+ * Quad Enable Requirements (QER):
+ * - 000b: Device does not have a QE bit. Device detects 1-1-4 and 1-4-4
+ *         reads based on instruction. DQ3/HOLD# functions are hold during
+ *         instruction phase.
+ * - 001b: QE is bit 1 of status register 2. It is set via Write Status with
+ *         two data bytes where bit 1 of the second byte is one.
+ *         [...]
+ *         Writing only one byte to the status register has the side-effect of
+ *         clearing status register 2, including the QE bit. The 100b code is
+ *         used if writing one byte to the status register does not modify
+ *         status register 2.
+ * - 010b: QE is bit 6 of status register 1. It is set via Write Status with
+ *         one data byte where bit 6 is one.
+ *         [...]
+ * - 011b: QE is bit 7 of status register 2. It is set via Write status
+ *         register 2 instruction 3Eh with one data byte where bit 7 is one.
+ *         [...]
+ *         The status register 2 is read using instruction 3Fh.
+ * - 100b: QE is bit 1 of status register 2. It is set via Write Status with
+ *         two data bytes where bit 1 of the second byte is one.
+ *         [...]
+ *         In contrast to the 001b code, writing one byte to the status
+ *         register does not modify status register 2.
+ * - 101b: QE is bit 1 of status register 2. Status register 1 is read using
+ *         Read Status instruction 05h. Status register2 is read using
+ *         instruction 35h. QE is set via Writ Status instruction 01h with
+ *         two data bytes where bit 1 of the second byte is one.
+ *         [...]
+ */
+#define BFPT_DWORD15_QER_MASK			GENMASK(22, 20)
+#define BFPT_DWORD15_QER_NONE			(0x0UL << 20) /* Micron */
+#define BFPT_DWORD15_QER_SR2_BIT1_BUGGY		(0x1UL << 20)
+#define BFPT_DWORD15_QER_SR1_BIT6		(0x2UL << 20) /* Macronix */
+#define BFPT_DWORD15_QER_SR2_BIT7		(0x3UL << 20)
+#define BFPT_DWORD15_QER_SR2_BIT1_NO_RD		(0x4UL << 20)
+#define BFPT_DWORD15_QER_SR2_BIT1		(0x5UL << 20) /* Spansion */
+
+struct sfdp_bfpt {
+	u32	dwords[BFPT_DWORD_MAX];
+};
+
+/* Fast Read settings. */
+
+static inline void
+spi_nor_set_read_settings_from_bfpt(struct spi_nor_read_command *read,
+				    u16 half,
+				    enum spi_nor_protocol proto)
+{
+	read->num_mode_clocks = (half >> 5) & 0x07;
+	read->num_wait_states = (half >> 0) & 0x1f;
+	read->opcode = (half >> 8) & 0xff;
+	read->proto = proto;
+}
+
+struct sfdp_bfpt_read {
+	/* The Fast Read x-y-z hardware capability in params->hwcaps.mask. */
+	u32			hwcaps;
+
+	/*
+	 * The <supported_bit> bit in <supported_dword> BFPT DWORD tells us
+	 * whether the Fast Read x-y-z command is supported.
+	 */
+	u32			supported_dword;
+	u32			supported_bit;
+
+	/*
+	 * The half-word at offset <setting_shift> in <setting_dword> BFPT DWORD
+	 * encodes the op code, the number of mode clocks and the number of wait
+	 * states to be used by Fast Read x-y-z command.
+	 */
+	u32			settings_dword;
+	u32			settings_shift;
+
+	/* The SPI protocol for this Fast Read x-y-z command. */
+	enum spi_nor_protocol	proto;
+};
+
+static const struct sfdp_bfpt_read sfdp_bfpt_reads[] = {
+	/* Fast Read 1-1-2 */
+	{
+		SNOR_HWCAPS_READ_1_1_2,
+		BFPT_DWORD(1), BIT(16),	/* Supported bit */
+		BFPT_DWORD(4), 0,	/* Settings */
+		SNOR_PROTO_1_1_2,
+	},
+
+	/* Fast Read 1-2-2 */
+	{
+		SNOR_HWCAPS_READ_1_2_2,
+		BFPT_DWORD(1), BIT(20),	/* Supported bit */
+		BFPT_DWORD(4), 16,	/* Settings */
+		SNOR_PROTO_1_2_2,
+	},
+
+	/* Fast Read 2-2-2 */
+	{
+		SNOR_HWCAPS_READ_2_2_2,
+		BFPT_DWORD(5),  BIT(0),	/* Supported bit */
+		BFPT_DWORD(6), 16,	/* Settings */
+		SNOR_PROTO_2_2_2,
+	},
+
+	/* Fast Read 1-1-4 */
+	{
+		SNOR_HWCAPS_READ_1_1_4,
+		BFPT_DWORD(1), BIT(22),	/* Supported bit */
+		BFPT_DWORD(3), 16,	/* Settings */
+		SNOR_PROTO_1_1_4,
+	},
+
+	/* Fast Read 1-4-4 */
+	{
+		SNOR_HWCAPS_READ_1_4_4,
+		BFPT_DWORD(1), BIT(21),	/* Supported bit */
+		BFPT_DWORD(3), 0,	/* Settings */
+		SNOR_PROTO_1_4_4,
+	},
+
+	/* Fast Read 4-4-4 */
+	{
+		SNOR_HWCAPS_READ_4_4_4,
+		BFPT_DWORD(5), BIT(4),	/* Supported bit */
+		BFPT_DWORD(7), 16,	/* Settings */
+		SNOR_PROTO_4_4_4,
+	},
+};
+
+struct sfdp_bfpt_erase {
+	/*
+	 * The half-word at offset <shift> in DWORD <dwoard> encodes the
+	 * op code and erase sector size to be used by Sector Erase commands.
+	 */
+	u32			dword;
+	u32			shift;
+};
+
+static const struct sfdp_bfpt_erase sfdp_bfpt_erases[] = {
+	/* Erase Type 1 in DWORD8 bits[15:0] */
+	{BFPT_DWORD(8), 0},
+
+	/* Erase Type 2 in DWORD8 bits[31:16] */
+	{BFPT_DWORD(8), 16},
+
+	/* Erase Type 3 in DWORD9 bits[15:0] */
+	{BFPT_DWORD(9), 0},
+
+	/* Erase Type 4 in DWORD9 bits[31:16] */
+	{BFPT_DWORD(9), 16},
+};
+
+static int spi_nor_hwcaps2cmd(u32 hwcaps, const int table[][2], size_t size)
+{
+	size_t i;
+
+	for (i = 0; i < size; i++)
+		if (table[i][0] == (int)hwcaps)
+			return table[i][1];
+
+	return -EINVAL;
+}
+
+static int spi_nor_hwcaps_read2cmd(u32 hwcaps)
+{
+	static const int hwcaps_read2cmd[][2] = {
+		{ SNOR_HWCAPS_READ,		SNOR_CMD_READ },
+		{ SNOR_HWCAPS_READ_FAST,	SNOR_CMD_READ_FAST },
+		{ SNOR_HWCAPS_READ_1_1_1_DTR,	SNOR_CMD_READ_1_1_1_DTR },
+		{ SNOR_HWCAPS_READ_1_1_2,	SNOR_CMD_READ_1_1_2 },
+		{ SNOR_HWCAPS_READ_1_2_2,	SNOR_CMD_READ_1_2_2 },
+		{ SNOR_HWCAPS_READ_2_2_2,	SNOR_CMD_READ_2_2_2 },
+		{ SNOR_HWCAPS_READ_1_2_2_DTR,	SNOR_CMD_READ_1_2_2_DTR },
+		{ SNOR_HWCAPS_READ_1_1_4,	SNOR_CMD_READ_1_1_4 },
+		{ SNOR_HWCAPS_READ_1_4_4,	SNOR_CMD_READ_1_4_4 },
+		{ SNOR_HWCAPS_READ_4_4_4,	SNOR_CMD_READ_4_4_4 },
+		{ SNOR_HWCAPS_READ_1_4_4_DTR,	SNOR_CMD_READ_1_4_4_DTR },
+		{ SNOR_HWCAPS_READ_1_1_8,	SNOR_CMD_READ_1_1_8 },
+		{ SNOR_HWCAPS_READ_1_8_8,	SNOR_CMD_READ_1_8_8 },
+		{ SNOR_HWCAPS_READ_8_8_8,	SNOR_CMD_READ_8_8_8 },
+		{ SNOR_HWCAPS_READ_1_8_8_DTR,	SNOR_CMD_READ_1_8_8_DTR },
+	};
+
+	return spi_nor_hwcaps2cmd(hwcaps, hwcaps_read2cmd,
+				  ARRAY_SIZE(hwcaps_read2cmd));
+}
+
+/**
+ * spi_nor_parse_bfpt() - read and parse the Basic Flash Parameter Table.
+ * @nor:		pointer to a 'struct spi_nor'
+ * @bfpt_header:	pointer to the 'struct sfdp_parameter_header' describing
+ *			the Basic Flash Parameter Table length and version
+ * @params:		pointer to the 'struct spi_nor_flash_parameter' to be
+ *			filled
+ *
+ * The Basic Flash Parameter Table is the main and only mandatory table as
+ * defined by the SFDP (JESD216) specification.
+ * It provides us with the total size (memory density) of the data array and
+ * the number of address bytes for Fast Read, Page Program and Sector Erase
+ * commands.
+ * For Fast READ commands, it also gives the number of mode clock cycles and
+ * wait states (regrouped in the number of dummy clock cycles) for each
+ * supported instruction op code.
+ * For Page Program, the page size is now available since JESD216 rev A, however
+ * the supported instruction op codes are still not provided.
+ * For Sector Erase commands, this table stores the supported instruction op
+ * codes and the associated sector sizes.
+ * Finally, the Quad Enable Requirements (QER) are also available since JESD216
+ * rev A. The QER bits encode the manufacturer dependent procedure to be
+ * executed to set the Quad Enable (QE) bit in some internal register of the
+ * Quad SPI memory. Indeed the QE bit, when it exists, must be set before
+ * sending any Quad SPI command to the memory. Actually, setting the QE bit
+ * tells the memory to reassign its WP# and HOLD#/RESET# pins to functions IO2
+ * and IO3 hence enabling 4 (Quad) I/O lines.
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spi_nor_parse_bfpt(struct spi_nor *nor,
+			      const struct sfdp_parameter_header *bfpt_header,
+			      struct spi_nor_flash_parameter *params)
+{
+	struct mtd_info *mtd = &nor->mtd;
+	struct sfdp_bfpt bfpt;
+	size_t len;
+	int i, cmd, err;
+	u32 addr;
+	u16 half;
+
+	/* JESD216 Basic Flash Parameter Table length is at least 9 DWORDs. */
+	if (bfpt_header->length < BFPT_DWORD_MAX_JESD216)
+		return -EINVAL;
+
+	/* Read the Basic Flash Parameter Table. */
+	len = min_t(size_t, sizeof(bfpt),
+		    bfpt_header->length * sizeof(u32));
+	addr = SFDP_PARAM_HEADER_PTP(bfpt_header);
+	memset(&bfpt, 0, sizeof(bfpt));
+	err = spi_nor_read_sfdp(nor,  addr, len, &bfpt);
+	if (err < 0)
+		return err;
+
+	/* Fix endianness of the BFPT DWORDs. */
+	for (i = 0; i < BFPT_DWORD_MAX; i++)
+		bfpt.dwords[i] = le32_to_cpu(bfpt.dwords[i]);
+
+	/* Number of address bytes. */
+	switch (bfpt.dwords[BFPT_DWORD(1)] & BFPT_DWORD1_ADDRESS_BYTES_MASK) {
+	case BFPT_DWORD1_ADDRESS_BYTES_3_ONLY:
+		nor->addr_width = 3;
+		break;
+
+	case BFPT_DWORD1_ADDRESS_BYTES_4_ONLY:
+		nor->addr_width = 4;
+		break;
+
+	default:
+		break;
+	}
+
+	/* Flash Memory Density (in bits). */
+	params->size = bfpt.dwords[BFPT_DWORD(2)];
+	if (params->size & BIT(31)) {
+		params->size &= ~BIT(31);
+
+		/*
+		 * Prevent overflows on params->size. Anyway, a NOR of 2^64
+		 * bits is unlikely to exist so this error probably means
+		 * the BFPT we are reading is corrupted/wrong.
+		 */
+		if (params->size > 63)
+			return -EINVAL;
+
+		params->size = 1ULL << params->size;
+	} else {
+		params->size++;
+	}
+	params->size >>= 3; /* Convert to bytes. */
+
+	/* Fast Read settings. */
+	for (i = 0; i < ARRAY_SIZE(sfdp_bfpt_reads); i++) {
+		const struct sfdp_bfpt_read *rd = &sfdp_bfpt_reads[i];
+		struct spi_nor_read_command *read;
+
+		if (!(bfpt.dwords[rd->supported_dword] & rd->supported_bit)) {
+			params->hwcaps.mask &= ~rd->hwcaps;
+			continue;
+		}
+
+		params->hwcaps.mask |= rd->hwcaps;
+		cmd = spi_nor_hwcaps_read2cmd(rd->hwcaps);
+		read = &params->reads[cmd];
+		half = bfpt.dwords[rd->settings_dword] >> rd->settings_shift;
+		spi_nor_set_read_settings_from_bfpt(read, half, rd->proto);
+	}
+
+	/* Sector Erase settings. */
+	for (i = 0; i < ARRAY_SIZE(sfdp_bfpt_erases); i++) {
+		const struct sfdp_bfpt_erase *er = &sfdp_bfpt_erases[i];
+		u32 erasesize;
+		u8 opcode;
+
+		half = bfpt.dwords[er->dword] >> er->shift;
+		erasesize = half & 0xff;
+
+		/* erasesize == 0 means this Erase Type is not supported. */
+		if (!erasesize)
+			continue;
+
+		erasesize = 1U << erasesize;
+		opcode = (half >> 8) & 0xff;
+#ifdef CONFIG_MTD_SPI_NOR_USE_4K_SECTORS
+		if (erasesize == SZ_4K) {
+			nor->erase_opcode = opcode;
+			mtd->erasesize = erasesize;
+			break;
+		}
+#endif
+		if (!mtd->erasesize || mtd->erasesize < erasesize) {
+			nor->erase_opcode = opcode;
+			mtd->erasesize = erasesize;
+		}
+	}
+
+	/* Stop here if not JESD216 rev A or later. */
+	if (bfpt_header->length < BFPT_DWORD_MAX)
+		return 0;
+
+	/* Page size: this field specifies 'N' so the page size = 2^N bytes. */
+	params->page_size = bfpt.dwords[BFPT_DWORD(11)];
+	params->page_size &= BFPT_DWORD11_PAGE_SIZE_MASK;
+	params->page_size >>= BFPT_DWORD11_PAGE_SIZE_SHIFT;
+	params->page_size = 1U << params->page_size;
+
+	/* Quad Enable Requirements. */
+	switch (bfpt.dwords[BFPT_DWORD(15)] & BFPT_DWORD15_QER_MASK) {
+	case BFPT_DWORD15_QER_NONE:
+		params->quad_enable = NULL;
+		break;
+#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
+	case BFPT_DWORD15_QER_SR2_BIT1_BUGGY:
+	case BFPT_DWORD15_QER_SR2_BIT1_NO_RD:
+		params->quad_enable = spansion_no_read_cr_quad_enable;
+		break;
+#endif
+#ifdef CONFIG_SPI_FLASH_MACRONIX
+	case BFPT_DWORD15_QER_SR1_BIT6:
+		params->quad_enable = macronix_quad_enable;
+		break;
+#endif
+#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
+	case BFPT_DWORD15_QER_SR2_BIT1:
+		params->quad_enable = spansion_read_cr_quad_enable;
+		break;
+#endif
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+/**
+ * spi_nor_parse_sfdp() - parse the Serial Flash Discoverable Parameters.
+ * @nor:		pointer to a 'struct spi_nor'
+ * @params:		pointer to the 'struct spi_nor_flash_parameter' to be
+ *			filled
+ *
+ * The Serial Flash Discoverable Parameters are described by the JEDEC JESD216
+ * specification. This is a standard which tends to supported by almost all
+ * (Q)SPI memory manufacturers. Those hard-coded tables allow us to learn at
+ * runtime the main parameters needed to perform basic SPI flash operations such
+ * as Fast Read, Page Program or Sector Erase commands.
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spi_nor_parse_sfdp(struct spi_nor *nor,
+			      struct spi_nor_flash_parameter *params)
+{
+	const struct sfdp_parameter_header *param_header, *bfpt_header;
+	struct sfdp_parameter_header *param_headers = NULL;
+	struct sfdp_header header;
+	size_t psize;
+	int i, err;
+
+	/* Get the SFDP header. */
+	err = spi_nor_read_sfdp(nor, 0, sizeof(header), &header);
+	if (err < 0)
+		return err;
+
+	/* Check the SFDP header version. */
+	if (le32_to_cpu(header.signature) != SFDP_SIGNATURE ||
+	    header.major != SFDP_JESD216_MAJOR)
+		return -EINVAL;
+
+	/*
+	 * Verify that the first and only mandatory parameter header is a
+	 * Basic Flash Parameter Table header as specified in JESD216.
+	 */
+	bfpt_header = &header.bfpt_header;
+	if (SFDP_PARAM_HEADER_ID(bfpt_header) != SFDP_BFPT_ID ||
+	    bfpt_header->major != SFDP_JESD216_MAJOR)
+		return -EINVAL;
+
+	/*
+	 * Allocate memory then read all parameter headers with a single
+	 * Read SFDP command. These parameter headers will actually be parsed
+	 * twice: a first time to get the latest revision of the basic flash
+	 * parameter table, then a second time to handle the supported optional
+	 * tables.
+	 * Hence we read the parameter headers once for all to reduce the
+	 * processing time. Also we use kmalloc() instead of devm_kmalloc()
+	 * because we don't need to keep these parameter headers: the allocated
+	 * memory is always released with kfree() before exiting this function.
+	 */
+	if (header.nph) {
+		psize = header.nph * sizeof(*param_headers);
+
+		param_headers = kmalloc(psize, GFP_KERNEL);
+		if (!param_headers)
+			return -ENOMEM;
+
+		err = spi_nor_read_sfdp(nor, sizeof(header),
+					psize, param_headers);
+		if (err < 0) {
+			dev_err(dev, "failed to read SFDP parameter headers\n");
+			goto exit;
+		}
+	}
+
+	/*
+	 * Check other parameter headers to get the latest revision of
+	 * the basic flash parameter table.
+	 */
+	for (i = 0; i < header.nph; i++) {
+		param_header = &param_headers[i];
+
+		if (SFDP_PARAM_HEADER_ID(param_header) == SFDP_BFPT_ID &&
+		    param_header->major == SFDP_JESD216_MAJOR &&
+		    (param_header->minor > bfpt_header->minor ||
+		     (param_header->minor == bfpt_header->minor &&
+		      param_header->length > bfpt_header->length)))
+			bfpt_header = param_header;
+	}
+
+	err = spi_nor_parse_bfpt(nor, bfpt_header, params);
+	if (err)
+		goto exit;
+
+	/* Parse other parameter headers. */
+	for (i = 0; i < header.nph; i++) {
+		param_header = &param_headers[i];
+
+		switch (SFDP_PARAM_HEADER_ID(param_header)) {
+		case SFDP_SECTOR_MAP_ID:
+			dev_info(dev, "non-uniform erase sector maps are not supported yet.\n");
+			break;
+
+		default:
+			break;
+		}
+
+		if (err)
+			goto exit;
+	}
+
+exit:
+	kfree(param_headers);
+	return err;
+}
+#else
+static int spi_nor_parse_sfdp(struct spi_nor *nor,
+			      struct spi_nor_flash_parameter *params)
+{
+	return -EINVAL;
+}
+#endif /* SPI_FLASH_SFDP_SUPPORT */
+
+static int spi_nor_init_params(struct spi_nor *nor,
+			       const struct flash_info *info,
+			       struct spi_nor_flash_parameter *params)
+{
+	/* Set legacy flash parameters as default. */
+	memset(params, 0, sizeof(*params));
+
+	/* Set SPI NOR sizes. */
+	params->size = info->sector_size * info->n_sectors;
+	params->page_size = info->page_size;
+
+	/* (Fast) Read settings. */
+	params->hwcaps.mask |= SNOR_HWCAPS_READ;
+	spi_nor_set_read_settings(&params->reads[SNOR_CMD_READ],
+				  0, 0, SPINOR_OP_READ,
+				  SNOR_PROTO_1_1_1);
+
+	if (!(info->flags & SPI_NOR_NO_FR)) {
+		params->hwcaps.mask |= SNOR_HWCAPS_READ_FAST;
+		spi_nor_set_read_settings(&params->reads[SNOR_CMD_READ_FAST],
+					  0, 8, SPINOR_OP_READ_FAST,
+					  SNOR_PROTO_1_1_1);
+	}
+
+	if (info->flags & SPI_NOR_DUAL_READ) {
+		params->hwcaps.mask |= SNOR_HWCAPS_READ_1_1_2;
+		spi_nor_set_read_settings(&params->reads[SNOR_CMD_READ_1_1_2],
+					  0, 8, SPINOR_OP_READ_1_1_2,
+					  SNOR_PROTO_1_1_2);
+	}
+
+	if (info->flags & SPI_NOR_QUAD_READ) {
+		params->hwcaps.mask |= SNOR_HWCAPS_READ_1_1_4;
+		spi_nor_set_read_settings(&params->reads[SNOR_CMD_READ_1_1_4],
+					  0, 8, SPINOR_OP_READ_1_1_4,
+					  SNOR_PROTO_1_1_4);
+	}
+
+	/* Page Program settings. */
+	params->hwcaps.mask |= SNOR_HWCAPS_PP;
+	spi_nor_set_pp_settings(&params->page_programs[SNOR_CMD_PP],
+				SPINOR_OP_PP, SNOR_PROTO_1_1_1);
+
+	if (info->flags & SPI_NOR_QUAD_READ) {
+		params->hwcaps.mask |= SNOR_HWCAPS_PP_1_1_4;
+		spi_nor_set_pp_settings(&params->page_programs[SNOR_CMD_PP_1_1_4],
+				SPINOR_OP_PP_1_1_4, SNOR_PROTO_1_1_4);
+	}
+
+	/* Select the procedure to set the Quad Enable bit. */
+	if (params->hwcaps.mask & (SNOR_HWCAPS_READ_QUAD |
+				   SNOR_HWCAPS_PP_QUAD)) {
+		switch (JEDEC_MFR(info)) {
+#ifdef CONFIG_SPI_FLASH_MACRONIX
+		case SNOR_MFR_MACRONIX:
+			params->quad_enable = macronix_quad_enable;
+			break;
+#endif
+		case SNOR_MFR_ST:
+		case SNOR_MFR_MICRON:
+			break;
+
+		default:
+#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
+			/* Kept only for backward compatibility purpose. */
+			params->quad_enable = spansion_read_cr_quad_enable;
+#endif
+			break;
+		}
+#ifndef __UBOOT__
+		/*
+		 * Some manufacturer like GigaDevice may use different
+		 * bit to set QE on different memories, so the MFR can't
+		 * indicate the quad_enable method for this case, we need
+		 * set it in flash info list.
+		 */
+		if (info->quad_enable)
+			params->quad_enable = info->quad_enable;
+#endif
+	}
+
+	/* Override the parameters with data read from SFDP tables. */
+	nor->addr_width = 0;
+	nor->mtd.erasesize = 0;
+	if ((info->flags & (SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)) &&
+	    !(info->flags & SPI_NOR_SKIP_SFDP)) {
+		struct spi_nor_flash_parameter sfdp_params;
+
+		memcpy(&sfdp_params, params, sizeof(sfdp_params));
+		if (spi_nor_parse_sfdp(nor, &sfdp_params)) {
+			nor->addr_width = 0;
+			nor->mtd.erasesize = 0;
+		} else {
+			memcpy(params, &sfdp_params, sizeof(*params));
+		}
+	}
+
+	return 0;
+}
+
+static int spi_nor_select_read(struct spi_nor *nor,
+			       const struct spi_nor_flash_parameter *params,
+			       u32 shared_hwcaps)
+{
+	int best_match = shared_hwcaps & SNOR_HWCAPS_READ_MASK;
+	int cmd;
+	const struct spi_nor_read_command *read;
+
+	if (best_match < 0)
+		return -EINVAL;
+
+	if (best_match & SNOR_HWCAPS_READ_1_4_4)
+		cmd = SNOR_CMD_READ_1_4_4;
+	else if (best_match & SNOR_HWCAPS_READ_1_1_4)
+		cmd = SNOR_CMD_READ_1_1_4;
+	else if (best_match & SNOR_HWCAPS_READ_FAST)
+		cmd = SNOR_CMD_READ_FAST;
+	else
+		cmd = SNOR_CMD_READ;
+
+	read = &params->reads[cmd];
+	nor->read_opcode = read->opcode;
+	nor->read_proto = read->proto;
+
+	/*
+	 * In the spi-nor framework, we don't need to make the difference
+	 * between mode clock cycles and wait state clock cycles.
+	 * Indeed, the value of the mode clock cycles is used by a QSPI
+	 * flash memory to know whether it should enter or leave its 0-4-4
+	 * (Continuous Read / XIP) mode.
+	 * eXecution In Place is out of the scope of the mtd sub-system.
+	 * Hence we choose to merge both mode and wait state clock cycles
+	 * into the so called dummy clock cycles.
+	 */
+	nor->read_dummy = read->num_mode_clocks + read->num_wait_states;
+	return 0;
+}
+
+static int spi_nor_select_pp(struct spi_nor *nor,
+			     const struct spi_nor_flash_parameter *params,
+			     u32 shared_hwcaps)
+{
+	int best_match = shared_hwcaps & SNOR_HWCAPS_PP_MASK;
+	int cmd;
+	const struct spi_nor_pp_command *pp;
+
+	if (best_match < 0)
+		return -EINVAL;
+
+	if (best_match & SNOR_HWCAPS_PP_1_1_4)
+		cmd = SNOR_CMD_PP_1_1_4;
+	else
+		cmd = SNOR_CMD_PP;
+
+	pp = &params->page_programs[cmd];
+	nor->program_opcode = pp->opcode;
+	nor->write_proto = pp->proto;
+	return 0;
+}
+
+static int spi_nor_select_erase(struct spi_nor *nor,
+				const struct flash_info *info)
+{
+	struct mtd_info *mtd = &nor->mtd;
+
+	/* Do nothing if already configured from SFDP. */
+	if (mtd->erasesize)
+		return 0;
+
+#ifdef CONFIG_SPI_FLASH_USE_4K_SECTORS
+	/* prefer "small sector" erase if possible */
+	if (info->flags & SECT_4K) {
+		nor->erase_opcode = SPINOR_OP_BE_4K;
+		mtd->erasesize = 4096;
+	} else if (info->flags & SECT_4K_PMC) {
+		nor->erase_opcode = SPINOR_OP_BE_4K_PMC;
+		mtd->erasesize = 4096;
+	} else
+#endif
+	{
+		nor->erase_opcode = SPINOR_OP_SE;
+		mtd->erasesize = info->sector_size;
+	}
+	return 0;
+}
+
+static int spi_nor_setup(struct spi_nor *nor, const struct flash_info *info,
+			 const struct spi_nor_flash_parameter *params,
+			 const struct spi_nor_hwcaps *hwcaps)
+{
+	u32 ignored_mask, shared_mask;
+	bool enable_quad_io;
+	int err;
+
+	/*
+	 * Keep only the hardware capabilities supported by both the SPI
+	 * controller and the SPI flash memory.
+	 */
+	shared_mask = hwcaps->mask & params->hwcaps.mask;
+
+	/* SPI n-n-n protocols are not supported yet. */
+	ignored_mask = (SNOR_HWCAPS_READ_2_2_2 |
+			SNOR_HWCAPS_READ_4_4_4 |
+			SNOR_HWCAPS_READ_8_8_8 |
+			SNOR_HWCAPS_PP_4_4_4 |
+			SNOR_HWCAPS_PP_8_8_8);
+	if (shared_mask & ignored_mask) {
+		dev_dbg(nor->dev,
+			"SPI n-n-n protocols are not supported yet.\n");
+		shared_mask &= ~ignored_mask;
+	}
+
+	/* Select the (Fast) Read command. */
+	err = spi_nor_select_read(nor, params, shared_mask);
+	if (err) {
+		dev_dbg(nor->dev,
+			"can't select read settings supported by both the SPI controller and memory.\n");
+		return err;
+	}
+
+	/* Select the Page Program command. */
+	err = spi_nor_select_pp(nor, params, shared_mask);
+	if (err) {
+		dev_dbg(nor->dev,
+			"can't select write settings supported by both the SPI controller and memory.\n");
+		return err;
+	}
+
+	/* Select the Sector Erase command. */
+	err = spi_nor_select_erase(nor, info);
+	if (err) {
+		dev_dbg(nor->dev,
+			"can't select erase settings supported by both the SPI controller and memory.\n");
+		return err;
+	}
+
+	/* Enable Quad I/O if needed. */
+	enable_quad_io = (spi_nor_get_protocol_width(nor->read_proto) == 4 ||
+			  spi_nor_get_protocol_width(nor->write_proto) == 4);
+	if (enable_quad_io && params->quad_enable)
+		nor->quad_enable = params->quad_enable;
+	else
+		nor->quad_enable = NULL;
+
+	return 0;
+}
+
+static int spi_nor_init(struct spi_nor *nor)
+{
+	int err;
+
+	/*
+	 * Atmel, SST, Intel/Numonyx, and others serial NOR tend to power up
+	 * with the software protection bits set
+	 */
+	if (JEDEC_MFR(nor->info) == SNOR_MFR_ATMEL ||
+	    JEDEC_MFR(nor->info) == SNOR_MFR_INTEL ||
+	    JEDEC_MFR(nor->info) == SNOR_MFR_SST ||
+	    nor->info->flags & SPI_NOR_HAS_LOCK) {
+		write_enable(nor);
+		write_sr(nor, 0);
+		spi_nor_wait_till_ready(nor);
+	}
+
+	if (nor->quad_enable) {
+		err = nor->quad_enable(nor);
+		if (err) {
+			dev_dbg(nor->dev, "quad mode not supported\n");
+			return err;
+		}
+	}
+
+	if (nor->addr_width == 4 &&
+	    (JEDEC_MFR(nor->info) != SNOR_MFR_SPANSION) &&
+	    !(nor->info->flags & SPI_NOR_4B_OPCODES)) {
+		/*
+		 * If the RESET# pin isn't hooked up properly, or the system
+		 * otherwise doesn't perform a reset command in the boot
+		 * sequence, it's impossible to 100% protect against unexpected
+		 * reboots (e.g., crashes). Warn the user (or hopefully, system
+		 * designer) that this is bad.
+		 */
+		if (nor->flags & SNOR_F_BROKEN_RESET)
+			printf("enabling reset hack; may not recover from unexpected reboots\n");
+		set_4byte(nor, nor->info, 1);
+	}
+
+	return 0;
+}
+
+int spi_nor_scan(struct spi_nor *nor)
+{
+	struct spi_nor_flash_parameter params;
+	const struct flash_info *info = NULL;
+	struct mtd_info *mtd = &nor->mtd;
+	struct spi_nor_hwcaps hwcaps = {
+		.mask = SNOR_HWCAPS_READ |
+			SNOR_HWCAPS_READ_FAST |
+			SNOR_HWCAPS_PP,
+	};
+	struct spi_slave *spi = nor->spi;
+	int ret;
+
+	/* Reset SPI protocol for all commands. */
+	nor->reg_proto = SNOR_PROTO_1_1_1;
+	nor->read_proto = SNOR_PROTO_1_1_1;
+	nor->write_proto = SNOR_PROTO_1_1_1;
+	nor->read = spi_nor_read_data;
+	nor->write = spi_nor_write_data;
+	nor->read_reg = spi_nor_read_reg;
+	nor->write_reg = spi_nor_write_reg;
+
+	if (spi->mode & SPI_RX_QUAD) {
+		hwcaps.mask |= SNOR_HWCAPS_READ_1_1_4;
+
+		if (spi->mode & SPI_TX_QUAD)
+			hwcaps.mask |= (SNOR_HWCAPS_READ_1_4_4 |
+					SNOR_HWCAPS_PP_1_1_4 |
+					SNOR_HWCAPS_PP_1_4_4);
+	} else if (spi->mode & SPI_RX_DUAL) {
+		hwcaps.mask |= SNOR_HWCAPS_READ_1_1_2;
+
+		if (spi->mode & SPI_TX_DUAL)
+			hwcaps.mask |= SNOR_HWCAPS_READ_1_2_2;
+	}
+
+	info = spi_nor_read_id(nor);
+	if (IS_ERR_OR_NULL(info))
+		return -ENOENT;
+	/* Parse the Serial Flash Discoverable Parameters table. */
+	ret = spi_nor_init_params(nor, info, &params);
+	if (ret)
+		return ret;
+
+	if (!mtd->name)
+		mtd->name = info->name;
+	mtd->priv = nor;
+	mtd->type = MTD_NORFLASH;
+	mtd->writesize = 1;
+	mtd->flags = MTD_CAP_NORFLASH;
+	mtd->size = params.size;
+	mtd->_erase = spi_nor_erase;
+	mtd->_read = spi_nor_read;
+
+#if defined(CONFIG_SPI_FLASH_STMICRO) || defined(CONFIG_SPI_FLASH_SST)
+	/* NOR protection support for STmicro/Micron chips and similar */
+	if (JEDEC_MFR(info) == SNOR_MFR_ST ||
+	    JEDEC_MFR(info) == SNOR_MFR_MICRON ||
+	    JEDEC_MFR(info) == SNOR_MFR_SST ||
+			info->flags & SPI_NOR_HAS_LOCK) {
+		nor->flash_lock = stm_lock;
+		nor->flash_unlock = stm_unlock;
+		nor->flash_is_locked = stm_is_locked;
+	}
+#endif
+
+	if (nor->flash_lock && nor->flash_unlock && nor->flash_is_locked) {
+		mtd->_lock = spi_nor_lock;
+		mtd->_unlock = spi_nor_unlock;
+		mtd->_is_locked = spi_nor_is_locked;
+	}
+
+#ifdef CONFIG_SPI_FLASH_SST
+	/* sst nor chips use AAI word program */
+	if (info->flags & SST_WRITE)
+		mtd->_write = sst_write;
+	else
+#endif
+		mtd->_write = spi_nor_write;
+
+	if (info->flags & USE_FSR)
+		nor->flags |= SNOR_F_USE_FSR;
+	if (info->flags & SPI_NOR_HAS_TB)
+		nor->flags |= SNOR_F_HAS_SR_TB;
+	if (info->flags & NO_CHIP_ERASE)
+		nor->flags |= SNOR_F_NO_OP_CHIP_ERASE;
+	if (info->flags & USE_CLSR)
+		nor->flags |= SNOR_F_USE_CLSR;
+
+	if (info->flags & SPI_NOR_NO_ERASE)
+		mtd->flags |= MTD_NO_ERASE;
+
+	nor->page_size = params.page_size;
+	mtd->writebufsize = nor->page_size;
+
+	/* Some devices cannot do fast-read, no matter what DT tells us */
+	if (info->flags & SPI_NOR_NO_FR)
+		params.hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST;
+
+	/*
+	 * Configure the SPI memory:
+	 * - select op codes for (Fast) Read, Page Program and Sector Erase.
+	 * - set the number of dummy cycles (mode cycles + wait states).
+	 * - set the SPI protocols for register and memory accesses.
+	 * - set the Quad Enable bit if needed (required by SPI x-y-4 protos).
+	 */
+	ret = spi_nor_setup(nor, info, &params, &hwcaps);
+	if (ret)
+		return ret;
+
+	if (nor->addr_width) {
+		/* already configured from SFDP */
+	} else if (info->addr_width) {
+		nor->addr_width = info->addr_width;
+	} else if (mtd->size > 0x1000000) {
+		/* enable 4-byte addressing if the device exceeds 16MiB */
+		nor->addr_width = 4;
+		if (JEDEC_MFR(info) == SNOR_MFR_SPANSION ||
+		    info->flags & SPI_NOR_4B_OPCODES)
+			spi_nor_set_4byte_opcodes(nor, info);
+	} else {
+		nor->addr_width = 3;
+	}
+
+	if (nor->addr_width > SPI_NOR_MAX_ADDR_WIDTH) {
+		dev_dbg(dev, "address width is too large: %u\n",
+			nor->addr_width);
+		return -EINVAL;
+	}
+
+	/* Send all the required SPI flash commands to initialize device */
+	nor->info = info;
+	ret = spi_nor_init(nor);
+	if (ret)
+		return ret;
+
+	nor->name = mtd->name;
+	nor->size = mtd->size;
+	nor->erase_size = mtd->erasesize;
+	nor->sector_size = mtd->erasesize;
+
+#ifndef CONFIG_SPL_BUILD
+	printf("SF: Detected %s with page size ", nor->name);
+	print_size(nor->page_size, ", erase size ");
+	print_size(nor->erase_size, ", total ");
+	print_size(nor->size, "");
+	puts("\n");
+#endif
+
+#ifndef __UBOOT__
+	dev_info(dev, "%s (%lld Kbytes)\n", info->name,
+			(long long)mtd->size >> 10);
+
+	dev_dbg(dev,
+		"mtd .name = %s, .size = 0x%llx (%lldMiB), "
+		".erasesize = 0x%.8x (%uKiB) .numeraseregions = %d\n",
+		mtd->name, (long long)mtd->size, (long long)(mtd->size >> 20),
+		mtd->erasesize, mtd->erasesize / 1024, mtd->numeraseregions);
+
+	if (mtd->numeraseregions)
+		for (i = 0; i < mtd->numeraseregions; i++)
+			dev_dbg(dev,
+				"mtd.eraseregions[%d] = { .offset = 0x%llx, "
+				".erasesize = 0x%.8x (%uKiB), "
+				".numblocks = %d }\n",
+				i, (long long)mtd->eraseregions[i].offset,
+				mtd->eraseregions[i].erasesize,
+				mtd->eraseregions[i].erasesize / 1024,
+				mtd->eraseregions[i].numblocks);
+#endif
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(spi_nor_scan);
+
+/* U-Boot specific functions, need to extend MTD to support these */
+int spi_flash_cmd_get_sw_write_prot(struct spi_nor *nor)
+{
+	int sr = read_sr(nor);
+
+	if (sr < 0)
+		return sr;
+
+	return (sr >> 2) & 7;
+}
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Huang Shijie <[email protected]>");
+MODULE_AUTHOR("Mike Lavender");
+MODULE_DESCRIPTION("framework for SPI NOR");
include/linux/mtd/cfi.h new file +32 -0
new file mode 100644
index 000000000000..3555518bd3f1
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright © 2000-2010 David Woodhouse <[email protected]> et al.
+ *
+ */
+
+#ifndef __MTD_CFI_H__
+#define __MTD_CFI_H__
+
+#define CFI_MFR_ANY		0xFFFF
+#define CFI_ID_ANY		0xFFFF
+#define CFI_MFR_CONTINUATION	0x007F
+
+#define CFI_MFR_AMD		0x0001
+#define CFI_MFR_AMIC		0x0037
+#define CFI_MFR_ATMEL		0x001F
+#define CFI_MFR_EON		0x001C
+#define CFI_MFR_FUJITSU		0x0004
+#define CFI_MFR_HYUNDAI		0x00AD
+#define CFI_MFR_INTEL		0x0089
+#define CFI_MFR_MACRONIX	0x00C2
+#define CFI_MFR_NEC		0x0010
+#define CFI_MFR_PMC		0x009D
+#define CFI_MFR_SAMSUNG		0x00EC
+#define CFI_MFR_SHARP		0x00B0
+#define CFI_MFR_SST		0x00BF
+#define CFI_MFR_ST		0x0020 /* STMicroelectronics */
+#define CFI_MFR_MICRON		0x002C	/* Micron */
+#define CFI_MFR_TOSHIBA		0x0098
+#define CFI_MFR_WINBOND		0x00DA
+
+#endif /* __MTD_CFI_H__ */
include/linux/mtd/spi-nor.h new file +421 -0

321 lines not on this page · raw message

The rest of this diff is not shown. View the raw message.

Signature · 1 line
2.19.2

Part of the diff is not shown here. View the raw message.

#25 lore raw

PATCH 5/16 mtd: spi: Port SPI NOR framework from Linux

Quoted 13 lines · Vignesh R

Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top. in order to gain 4 byte addressing support, SFDP support and a way to support SPI controllers with MMIO flash interface.

Quoted 5 lines
---
 drivers/mtd/spi/spi-nor-core.c | 2647 ++++++++++++++++++++++++++++++++
 include/linux/mtd/cfi.h        |   32 +
 include/linux/mtd/spi-nor.h    |  421 +++++

Please refer many mails about this comment. I don't look for carbon copy of the code from Linux, you can use the implementation and even macro names etc but the end code would be the code that require U-Boot.

- no __UBOOT ifdef
- file names in u-boot should have _ other than few uclass drivers

#26 lore raw

PATCH 5/16 mtd: spi: Port SPI NOR framework from Linux

Quoted 20 lines · Jagan Teki
Quoted 13 lines · Vignesh R

Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top. in order to gain 4 byte addressing support, SFDP support and a way to support SPI controllers with MMIO flash interface.

Quoted 5 lines
---
 drivers/mtd/spi/spi-nor-core.c | 2647 ++++++++++++++++++++++++++++++++
 include/linux/mtd/cfi.h        |   32 +
 include/linux/mtd/spi-nor.h    |  421 +++++
Quoted 6 lines

Please refer many mails about this comment. I don't look for carbon copy of the code from Linux, you can use the implementation and even macro names etc but the end code would be the code that require U-Boot.

- no __UBOOT ifdef

What? This is the exact opposite of what we're doing in several other areas, with a large amount of success precisely because it allows us to leverage developer base to catch and fix problems. Dropping in the code and minor and obvious deviations make for easier re-sync.

Quoted 1 line

- file names in u-boot should have _ other than few uclass drivers

There is no consistent naming scheme really. I see ~1500 "_" C files and ~500 "-" files.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181212/449ece1e/attachment.sig>
#27 lore raw

PATCH 5/16 mtd: spi: Port SPI NOR framework from Linux

Quoted 27 lines · Tom Rini
Quoted 25 lines · Jagan Teki
Quoted 13 lines · Vignesh R

Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top. in order to gain 4 byte addressing support, SFDP support and a way to support SPI controllers with MMIO flash interface.

Quoted 5 lines
---
 drivers/mtd/spi/spi-nor-core.c | 2647 ++++++++++++++++++++++++++++++++
 include/linux/mtd/cfi.h        |   32 +
 include/linux/mtd/spi-nor.h    |  421 +++++

Please refer many mails about this comment. I don't look for carbon copy of the code from Linux, you can use the implementation and even macro names etc but the end code would be the code that require U-Boot.

Quoted 6 lines
Quoted 1 line

- no __UBOOT ifdef

What? This is the exact opposite of what we're doing in several other areas, with a large amount of success precisely because it allows us to leverage developer base to catch and fix problems. Dropping in the code and minor and obvious deviations make for easier re-sync.

Several areas, but not spi-flash or spi. ie what I'm maintaining from long. I'm always looking for persistent code to be IN. May be it can't be syn-cable but we can work it more maintainable in u-boot way like other opensource project. Well this is my experience with the U-Boot project development so-far, I never ever hold any features but if u-boot need the same features, better to add then like new code.

Quoted 5 lines
Quoted 2 lines

- file names in u-boot should have _ other than few uclass drivers

There is no consistent naming scheme really. I see ~1500 "_" C files and ~500 "-" files.

I have the same experience when I rename spi_flash.c with spi-flash.c.

#28 lore raw

PATCH 5/16 mtd: spi: Port SPI NOR framework from Linux

Quoted 35 lines · Jagan Teki
Quoted 27 lines · Tom Rini
Quoted 25 lines · Jagan Teki
Quoted 13 lines · Vignesh R

Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top. in order to gain 4 byte addressing support, SFDP support and a way to support SPI controllers with MMIO flash interface.

Quoted 5 lines
---
 drivers/mtd/spi/spi-nor-core.c | 2647 ++++++++++++++++++++++++++++++++
 include/linux/mtd/cfi.h        |   32 +
 include/linux/mtd/spi-nor.h    |  421 +++++

Please refer many mails about this comment. I don't look for carbon copy of the code from Linux, you can use the implementation and even macro names etc but the end code would be the code that require U-Boot.

Quoted 6 lines
Quoted 1 line

- no __UBOOT ifdef

What? This is the exact opposite of what we're doing in several other areas, with a large amount of success precisely because it allows us to leverage developer base to catch and fix problems. Dropping in the code and minor and obvious deviations make for easier re-sync.

Quoted 6 lines

Several areas, but not spi-flash or spi. ie what I'm maintaining from long. I'm always looking for persistent code to be IN. May be it can't be syn-cable but we can work it more maintainable in u-boot way like other opensource project. Well this is my experience with the U-Boot project development so-far, I never ever hold any features but if u-boot need the same features, better to add then like new code.

I think that for flash related SPI we should follow the lead of the rest of MTD/NAND and adapt the kernel code.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181212/827053e0/attachment.sig>
#29 lore raw

PATCH 5/16 mtd: spi: Port SPI NOR framework from Linux

Quoted 43 lines · Tom Rini
Quoted 35 lines · Jagan Teki
Quoted 27 lines · Tom Rini
Quoted 25 lines · Jagan Teki
Quoted 13 lines · Vignesh R

Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top. in order to gain 4 byte addressing support, SFDP support and a way to support SPI controllers with MMIO flash interface.

Quoted 5 lines
---
  drivers/mtd/spi/spi-nor-core.c | 2647 ++++++++++++++++++++++++++++++++
  include/linux/mtd/cfi.h        |   32 +
  include/linux/mtd/spi-nor.h    |  421 +++++

Please refer many mails about this comment. I don't look for carbon copy of the code from Linux, you can use the implementation and even macro names etc but the end code would be the code that require U-Boot.

Quoted 6 lines
Quoted 1 line

- no __UBOOT ifdef

What? This is the exact opposite of what we're doing in several other areas, with a large amount of success precisely because it allows us to leverage developer base to catch and fix problems. Dropping in the code and minor and obvious deviations make for easier re-sync.

Quoted 6 lines

Several areas, but not spi-flash or spi. ie what I'm maintaining from long. I'm always looking for persistent code to be IN. May be it can't be syn-cable but we can work it more maintainable in u-boot way like other opensource project. Well this is my experience with the U-Boot project development so-far, I never ever hold any features but if u-boot need the same features, better to add then like new code.

Quoted 2 lines

I think that for flash related SPI we should follow the lead of the rest of MTD/NAND and adapt the kernel code.

Yes, we should have learned this lesson from the past. So full ACK from me.

Thanks,
Stefan

author maintainer
#30 lore raw

PATCH 5/16 mtd: spi: Port SPI NOR framework from Linux

In reply to Tom Rini
Quoted 43 lines · Tom Rini
Quoted 35 lines · Jagan Teki
Quoted 27 lines · Tom Rini
Quoted 25 lines · Jagan Teki
Quoted 13 lines · Vignesh R

Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top. in order to gain 4 byte addressing support, SFDP support and a way to support SPI controllers with MMIO flash interface.

Quoted 5 lines
---
 drivers/mtd/spi/spi-nor-core.c | 2647 ++++++++++++++++++++++++++++++++
 include/linux/mtd/cfi.h        |   32 +
 include/linux/mtd/spi-nor.h    |  421 +++++

Please refer many mails about this comment. I don't look for carbon copy of the code from Linux, you can use the implementation and even macro names etc but the end code would be the code that require U-Boot.

Quoted 6 lines
Quoted 1 line

- no __UBOOT ifdef

What? This is the exact opposite of what we're doing in several other areas, with a large amount of success precisely because it allows us to leverage developer base to catch and fix problems. Dropping in the code and minor and obvious deviations make for easier re-sync.

Quoted 6 lines

Several areas, but not spi-flash or spi. ie what I'm maintaining from long. I'm always looking for persistent code to be IN. May be it can't be syn-cable but we can work it more maintainable in u-boot way like other opensource project. Well this is my experience with the U-Boot project development so-far, I never ever hold any features but if u-boot need the same features, better to add then like new code.

Quoted 3 lines

I think that for flash related SPI we should follow the lead of the rest of MTD/NAND and adapt the kernel code.

I have no hard preference, although I prefer MTD conventions wrt __UBOOT__ and file names as this code resides under drivers/mtd/.

Signature · 2 lines
Regards
Vignesh
author maintainer
#31 lore raw

PATCH 6/16 mtd: spi: Switch to new SPI NOR framework

In reply to Vignesh R

Switch spi_flash_* interfaces to call into new SPI NOR framework via MTD layer. Fix up sf_dataflash to work in legacy way. And update sandbox to use new interfaces/defintions

---
 common/spl/Kconfig             |  12 +-
 drivers/mtd/spi/Kconfig        |  15 ++-
 drivers/mtd/spi/Makefile       |   4 +-
 drivers/mtd/spi/sandbox.c      |  36 +++---
 drivers/mtd/spi/sf_dataflash.c |  11 +-
 drivers/mtd/spi/sf_internal.h  | 228 +++++++--------------------------
 drivers/mtd/spi/sf_probe.c     |  33 +++--
 drivers/mtd/spi/spi-nor-core.c |  59 +--------
 drivers/spi/stm32_qspi.c       |   4 +-
 include/spi_flash.h            | 105 ++++-----------
 10 files changed, 137 insertions(+), 370 deletions(-)
common/spl/Kconfig +11 -1
index 0ddbffc7d1c6..ba6d4d71fbc6 100644
@@ -727,13 +727,23 @@ config SPL_SPI_FLASH_SUPPORT
 	  lines). This enables the drivers in drivers/mtd/spi as part of an
 	  SPL build. This normally requires SPL_SPI_SUPPORT.
 
+if SPL_SPI_FLASH_SUPPORT
+
+config SPL_SPI_FLASH_SFDP_SUPPORT
+	bool "SFDP table parsing support for SPI NOR flashes"
+	help
+	 Enable support for parsing and auto discovery of parameters for
+	 SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP)
+	 tables as per JESD216 standard in SPL.
+
 config SPL_SPI_LOAD
 	bool "Support loading from SPI flash"
-	depends on SPL_SPI_FLASH_SUPPORT
 	help
 	  Enable support for loading next stage, U-Boot or otherwise, from
 	  SPI NOR in U-Boot SPL.
 
+endif # SPL_SPI_FLASH_SUPPORT
+
 config SPL_SPI_SUPPORT
 	bool "Support SPI drivers"
 	help
drivers/mtd/spi/Kconfig +11 -4
index 76d5a1d11527..8bd6db6ff4d3 100644
@@ -27,6 +27,8 @@ config SPI_FLASH_SANDBOX
 
 config SPI_FLASH
 	bool "Legacy SPI Flash Interface support"
+	depends on SPI
+	select SPI_MEM
 	help
 	  Enable the legacy SPI flash support. This will include basic
 	  standard support for things like probing, read / write, and
@@ -34,9 +36,17 @@ config SPI_FLASH
 
 	  If unsure, say N
 
+if SPI_FLASH
+
+config SPI_FLASH_SFDP_SUPPORT
+	bool "SFDP table parsing support for SPI NOR flashes"
+	help
+	 Enable support for parsing and auto discovery of parameters for
+	 SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP)
+	 tables as per JESD216 standard.
+
 config SPI_FLASH_BAR
 	bool "SPI flash Bank/Extended address register support"
-	depends on SPI_FLASH
 	help
 	  Enable the SPI flash Bank/Extended address register support.
 	  Bank/Extended address registers are used to access the flash
@@ -44,13 +54,10 @@ config SPI_FLASH_BAR
 
 config SF_DUAL_FLASH
 	bool "SPI DUAL flash memory support"
-	depends on SPI_FLASH
 	help
 	  Enable this option to support two flash memories connected to a single
 	  controller. Currently Xilinx Zynq qspi supports this.
 
-if SPI_FLASH
-
 config SPI_FLASH_ATMEL
 	bool "Atmel SPI flash support"
 	help
drivers/mtd/spi/Makefile +2 -2
index b4c7e1c98bd5..70058d3df2b9 100644
@@ -9,7 +9,7 @@ ifdef CONFIG_SPL_BUILD
 obj-$(CONFIG_SPL_SPI_BOOT)	+= fsl_espi_spl.o
 endif
 
-obj-$(CONFIG_SPI_FLASH) += sf_probe.o spi_flash.o spi_flash_ids.o sf.o
-obj-$(CONFIG_SPI_FLASH_DATAFLASH) += sf_dataflash.o
+obj-$(CONFIG_SPI_FLASH) += sf_probe.o spi-nor-core.o
+obj-$(CONFIG_SPI_FLASH_DATAFLASH) += sf_dataflash.o sf.o
 obj-$(CONFIG_SPI_FLASH_MTD) += sf_mtd.o
 obj-$(CONFIG_SPI_FLASH_SANDBOX) += sandbox.o
drivers/mtd/spi/sandbox.c +18 -18
index 7b9891cb981c..084c66e9840b 100644
@@ -92,7 +92,7 @@ struct sandbox_spi_flash {
 	/* The current flash status (see STAT_XXX defines above) */
 	u16 status;
 	/* Data describing the flash we're emulating */
-	const struct spi_flash_info *data;
+	const struct flash_info *data;
 	/* The file on disk to serv up data from */
 	int fd;
 };
@@ -122,7 +122,7 @@ static int sandbox_sf_probe(struct udevice *dev)
 	/* spec = idcode:file */
 	struct sandbox_spi_flash *sbsf = dev_get_priv(dev);
 	size_t len, idname_len;
-	const struct spi_flash_info *data;
+	const struct flash_info *data;
 	struct sandbox_spi_flash_plat_data *pdata = dev_get_platdata(dev);
 	struct sandbox_state *state = state_get_current();
 	struct dm_spi_slave_platdata *slave_plat;
@@ -155,7 +155,7 @@ static int sandbox_sf_probe(struct udevice *dev)
 	idname_len = strlen(spec);
 	debug("%s: device='%s'\n", __func__, spec);
 
-	for (data = spi_flash_ids; data->name; data++) {
+	for (data = spi_nor_ids; data->name; data++) {
 		len = strlen(data->name);
 		if (idname_len != len)
 			continue;
@@ -243,43 +243,43 @@ static int sandbox_sf_process_cmd(struct sandbox_spi_flash *sbsf, const u8 *rx,
 
 	sbsf->cmd = rx[0];
 	switch (sbsf->cmd) {
-	case CMD_READ_ID:
+	case SPINOR_OP_RDID:
 		sbsf->state = SF_ID;
 		sbsf->cmd = SF_ID;
 		break;
-	case CMD_READ_ARRAY_FAST:
+	case SPINOR_OP_READ_FAST:
 		sbsf->pad_addr_bytes = 1;
-	case CMD_READ_ARRAY_SLOW:
-	case CMD_PAGE_PROGRAM:
+	case SPINOR_OP_READ:
+	case SPINOR_OP_PP:
 		sbsf->state = SF_ADDR;
 		break;
-	case CMD_WRITE_DISABLE:
+	case SPINOR_OP_WRDI:
 		debug(" write disabled\n");
 		sbsf->status &= ~STAT_WEL;
 		break;
-	case CMD_READ_STATUS:
+	case SPINOR_OP_RDSR:
 		sbsf->state = SF_READ_STATUS;
 		break;
-	case CMD_READ_STATUS1:
+	case SPINOR_OP_RDSR2:
 		sbsf->state = SF_READ_STATUS1;
 		break;
-	case CMD_WRITE_ENABLE:
+	case SPINOR_OP_WREN:
 		debug(" write enabled\n");
 		sbsf->status |= STAT_WEL;
 		break;
-	case CMD_WRITE_STATUS:
+	case SPINOR_OP_WRSR:
 		sbsf->state = SF_WRITE_STATUS;
 		break;
 	default: {
 		int flags = sbsf->data->flags;
 
 		/* we only support erase here */
-		if (sbsf->cmd == CMD_ERASE_CHIP) {
+		if (sbsf->cmd == SPINOR_OP_CHIP_ERASE) {
 			sbsf->erase_size = sbsf->data->sector_size *
 				sbsf->data->n_sectors;
-		} else if (sbsf->cmd == CMD_ERASE_4K && (flags & SECT_4K)) {
+		} else if (sbsf->cmd == SPINOR_OP_BE_4K && (flags & SECT_4K)) {
 			sbsf->erase_size = 4 << 10;
-		} else if (sbsf->cmd == CMD_ERASE_64K && !(flags & SECT_4K)) {
+		} else if (sbsf->cmd == SPINOR_OP_SE && !(flags & SECT_4K)) {
 			sbsf->erase_size = 64 << 10;
 		} else {
 			debug(" cmd unknown: %#x\n", sbsf->cmd);
@@ -380,11 +380,11 @@ static int sandbox_sf_xfer(struct udevice *dev, unsigned int bitlen,
 				return -EIO;
 			}
 			switch (sbsf->cmd) {
-			case CMD_READ_ARRAY_FAST:
-			case CMD_READ_ARRAY_SLOW:
+			case SPINOR_OP_READ_FAST:
+			case SPINOR_OP_READ:
 				sbsf->state = SF_READ;
 				break;
-			case CMD_PAGE_PROGRAM:
+			case SPINOR_OP_PP:
 				sbsf->state = SF_WRITE;
 				break;
 			default:
drivers/mtd/spi/sf_dataflash.c +6 -5
index 4a60c1b2b43a..b6a2631747a9 100644
@@ -18,6 +18,7 @@
 
 #include "sf_internal.h"
 
+#define CMD_READ_ID		0x9f
 /* reads can bypass the buffers */
 #define OP_READ_CONTINUOUS	0xE8
 #define OP_READ_PAGE		0xD2
@@ -441,7 +442,7 @@ static int add_dataflash(struct udevice *dev, char *name, int nr_pages,
 	return 0;
 }
 
-struct flash_info {
+struct data_flash_info {
 	char		*name;
 
 	/*
@@ -460,7 +461,7 @@ struct flash_info {
 #define IS_POW2PS	0x0001		/* uses 2^N byte pages */
 };
 
-static struct flash_info dataflash_data[] = {
+static struct data_flash_info dataflash_data[] = {
 	/*
 	 * NOTE:  chips with SUP_POW2PS (rev D and up) need two entries,
 	 * one with IS_POW2PS and the other without.  The entry with the
@@ -501,12 +502,12 @@ static struct flash_info dataflash_data[] = {
 	{ "at45db642d",  0x1f2800, 8192, 1024, 10, SUP_POW2PS | IS_POW2PS},
 };
 
-static struct flash_info *jedec_probe(struct spi_slave *spi)
+static struct data_flash_info *jedec_probe(struct spi_slave *spi)
 {
 	int			tmp;
 	uint8_t			id[5];
 	uint32_t		jedec;
-	struct flash_info	*info;
+	struct data_flash_info	*info;
 	int status;
 
 	/*
@@ -583,7 +584,7 @@ static int spi_dataflash_probe(struct udevice *dev)
 {
 	struct spi_slave *spi = dev_get_parent_priv(dev);
 	struct spi_flash *spi_flash;
-	struct flash_info *info;
+	struct data_flash_info *info;
 	int status;
 
 	spi_flash = dev_get_uclass_priv(dev);
drivers/mtd/spi/sf_internal.h +43 -185

263 lines not on this page · raw message

drivers/mtd/spi/sf_probe.c +20 -13
index 00f8558e7019..7f1378f4946d 100644
@@ -40,7 +40,7 @@ static int spi_flash_probe_slave(struct spi_flash *flash)
 		return ret;
 	}
 
-	ret = spi_flash_scan(flash);
+	ret = spi_nor_scan(flash);
 	if (ret)
 		goto err_read_id;
 
@@ -96,32 +96,38 @@ static int spi_flash_std_read(struct udevice *dev, u32 offset, size_t len,
 			      void *buf)
 {
 	struct spi_flash *flash = dev_get_uclass_priv(dev);
+	struct mtd_info *mtd = &flash->mtd;
+	size_t retlen;
 
-	return log_ret(spi_flash_cmd_read_ops(flash, offset, len, buf));
+	return log_ret(mtd->_read(mtd, offset, len, &retlen, buf));
 }
 
 static int spi_flash_std_write(struct udevice *dev, u32 offset, size_t len,
 			       const void *buf)
 {
 	struct spi_flash *flash = dev_get_uclass_priv(dev);
+	struct mtd_info *mtd = &flash->mtd;
+	size_t retlen;
 
-#if defined(CONFIG_SPI_FLASH_SST)
-	if (flash->flags & SNOR_F_SST_WR) {
-		if (flash->spi->mode & SPI_TX_BYTE)
-			return sst_write_bp(flash, offset, len, buf);
-		else
-			return sst_write_wp(flash, offset, len, buf);
-	}
-#endif
-
-	return spi_flash_cmd_write_ops(flash, offset, len, buf);
+	return mtd->_write(mtd, offset, len, &retlen, buf);
 }
 
 static int spi_flash_std_erase(struct udevice *dev, u32 offset, size_t len)
 {
 	struct spi_flash *flash = dev_get_uclass_priv(dev);
+	struct mtd_info *mtd = &flash->mtd;
+	struct erase_info instr;
+
+	if (offset % mtd->erasesize || len % mtd->erasesize) {
+		printf("SF: Erase offset/length not multiple of erase size\n");
+		return -EINVAL;
+	}
+
+	memset(&instr, 0, sizeof(instr));
+	instr.addr = offset;
+	instr.len = len;
 
-	return spi_flash_cmd_erase_ops(flash, offset, len);
+	return mtd->_erase(mtd, &instr);
 }
 
 static int spi_flash_std_get_sw_write_prot(struct udevice *dev)
@@ -161,6 +167,7 @@ static const struct dm_spi_flash_ops spi_flash_std_ops = {
 
 static const struct udevice_id spi_flash_std_ids[] = {
 	{ .compatible = "spi-flash" },
+	{ .compatible = "jedec,spi-nor" },
 	{ }
 };
 
drivers/mtd/spi/spi-nor-core.c +2 -57

71 lines not on this page · raw message

drivers/spi/stm32_qspi.c +2 -2
index 3b92254a5ce1..8b60d7c3b224 100644
@@ -271,9 +271,9 @@ static void _stm32_qspi_enable_mmap(struct stm32_qspi_priv *priv,
 {
 	unsigned int ccr_reg;
 
-	priv->command = flash->read_cmd | CMD_HAS_ADR | CMD_HAS_DATA
+	priv->command = flash->read_opcode | CMD_HAS_ADR | CMD_HAS_DATA
 			| CMD_HAS_DUMMY;
-	priv->dummycycles = flash->dummy_byte * 8;
+	priv->dummycycles = flash->read_dummy;
 
 	ccr_reg = _stm32_qspi_gen_ccr(priv, STM32_QSPI_CCR_MEM_MAP);
 
include/spi_flash.h +22 -83

133 lines not on this page · raw message

Signature · 1 line
2.19.2
author maintainer
#32 lore raw

PATCH 7/16 mtd: spi: Remove unused files

In reply to Vignesh R

spi_flash and spi_flash_ids are no longer needed after SPI NOR migration. Remove them.

---
 drivers/mtd/spi/spi_flash.c     | 1337 -------------------------------
 drivers/mtd/spi/spi_flash_ids.c |  211 -----
 2 files changed, 1548 deletions(-)
 delete mode 100644 drivers/mtd/spi/spi_flash.c
 delete mode 100644 drivers/mtd/spi/spi_flash_ids.c
drivers/mtd/spi/spi_flash.c deleted +0 -1337
deleted file mode 100644
index 0c2392f28a43..000000000000
@@ -1,1337 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * SPI Flash Core
- *
- * Copyright (C) 2015 Jagan Teki <[email protected]>
- * Copyright (C) 2013 Jagannadha Sutradharudu Teki, Xilinx Inc.
- * Copyright (C) 2010 Reinhard Meyer, EMK Elektronik
- * Copyright (C) 2008 Atmel Corporation
- */
-
-#include <common.h>
-#include <errno.h>
-#include <malloc.h>
-#include <mapmem.h>
-#include <spi.h>
-#include <spi_flash.h>
-#include <linux/log2.h>
-#include <linux/sizes.h>
-#include <dma.h>
-
-#include "sf_internal.h"
-
-static void spi_flash_addr(u32 addr, u8 *cmd)
-{
-	/* cmd[0] is actual command */
-	cmd[1] = addr >> 16;
-	cmd[2] = addr >> 8;
-	cmd[3] = addr >> 0;
-}
-
-static int read_sr(struct spi_flash *flash, u8 *rs)
-{
-	int ret;
-	u8 cmd;
-
-	cmd = CMD_READ_STATUS;
-	ret = spi_flash_read_common(flash, &cmd, 1, rs, 1);
-	if (ret < 0) {
-		debug("SF: fail to read status register\n");
-		return ret;
-	}
-
-	return 0;
-}
-
-static int read_fsr(struct spi_flash *flash, u8 *fsr)
-{
-	int ret;
-	const u8 cmd = CMD_FLAG_STATUS;
-
-	ret = spi_flash_read_common(flash, &cmd, 1, fsr, 1);
-	if (ret < 0) {
-		debug("SF: fail to read flag status register\n");
-		return ret;
-	}
-
-	return 0;
-}
-
-static int write_sr(struct spi_flash *flash, u8 ws)
-{
-	u8 cmd;
-	int ret;
-
-	cmd = CMD_WRITE_STATUS;
-	ret = spi_flash_write_common(flash, &cmd, 1, &ws, 1);
-	if (ret < 0) {
-		debug("SF: fail to write status register\n");
-		return ret;
-	}
-
-	return 0;
-}
-
-#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
-static int read_cr(struct spi_flash *flash, u8 *rc)
-{
-	int ret;
-	u8 cmd;
-
-	cmd = CMD_READ_CONFIG;
-	ret = spi_flash_read_common(flash, &cmd, 1, rc, 1);
-	if (ret < 0) {
-		debug("SF: fail to read config register\n");
-		return ret;
-	}
-
-	return 0;
-}
-
-static int write_cr(struct spi_flash *flash, u8 wc)
-{
-	u8 data[2];
-	u8 cmd;
-	int ret;
-
-	ret = read_sr(flash, &data[0]);
-	if (ret < 0)
-		return ret;
-
-	cmd = CMD_WRITE_STATUS;
-	data[1] = wc;
-	ret = spi_flash_write_common(flash, &cmd, 1, &data, 2);
-	if (ret) {
-		debug("SF: fail to write config register\n");
-		return ret;
-	}
-
-	return 0;
-}
-#endif
-
-int spi_flash_cmd_get_sw_write_prot(struct spi_flash *flash)
-{
-	u8 status;
-	int ret;
-
-	ret = read_sr(flash, &status);
-	if (ret)
-		return ret;
-
-	return (status >> 2) & 7;
-}
-
-#ifdef CONFIG_SPI_FLASH_BAR
-/*
- * This "clean_bar" is necessary in a situation when one was accessing
- * spi flash memory > 16 MiB by using Bank Address Register's BA24 bit.
- *
- * After it the BA24 bit shall be cleared to allow access to correct
- * memory region after SW reset (by calling "reset" command).
- *
- * Otherwise, the BA24 bit may be left set and then after reset, the
- * ROM would read/write/erase SPL from 16 MiB * bank_sel address.
- */
-static int clean_bar(struct spi_flash *flash)
-{
-	u8 cmd, bank_sel = 0;
-
-	if (flash->bank_curr == 0)
-		return 0;
-	cmd = flash->bank_write_cmd;
-	flash->bank_curr = 0;
-
-	return spi_flash_write_common(flash, &cmd, 1, &bank_sel, 1);
-}
-
-static int write_bar(struct spi_flash *flash, u32 offset)
-{
-	u8 cmd, bank_sel;
-	int ret;
-
-	bank_sel = offset / (SPI_FLASH_16MB_BOUN << flash->shift);
-	if (bank_sel == flash->bank_curr)
-		goto bar_end;
-
-	cmd = flash->bank_write_cmd;
-	ret = spi_flash_write_common(flash, &cmd, 1, &bank_sel, 1);
-	if (ret < 0) {
-		debug("SF: fail to write bank register\n");
-		return ret;
-	}
-
-bar_end:
-	flash->bank_curr = bank_sel;
-	return flash->bank_curr;
-}
-
-static int read_bar(struct spi_flash *flash, const struct spi_flash_info *info)
-{
-	u8 curr_bank = 0;
-	int ret;
-
-	if (flash->size <= SPI_FLASH_16MB_BOUN)
-		goto bar_end;
-
-	switch (JEDEC_MFR(info)) {
-	case SPI_FLASH_CFI_MFR_SPANSION:
-		flash->bank_read_cmd = CMD_BANKADDR_BRRD;
-		flash->bank_write_cmd = CMD_BANKADDR_BRWR;
-		break;
-	default:
-		flash->bank_read_cmd = CMD_EXTNADDR_RDEAR;
-		flash->bank_write_cmd = CMD_EXTNADDR_WREAR;
-	}
-
-	ret = spi_flash_read_common(flash, &flash->bank_read_cmd, 1,
-				    &curr_bank, 1);
-	if (ret) {
-		debug("SF: fail to read bank addr register\n");
-		return ret;
-	}
-
-bar_end:
-	flash->bank_curr = curr_bank;
-	return 0;
-}
-#endif
-
-#ifdef CONFIG_SF_DUAL_FLASH
-static void spi_flash_dual(struct spi_flash *flash, u32 *addr)
-{
-	switch (flash->dual_flash) {
-	case SF_DUAL_STACKED_FLASH:
-		if (*addr >= (flash->size >> 1)) {
-			*addr -= flash->size >> 1;
-			flash->flags |= SNOR_F_USE_UPAGE;
-		} else {
-			flash->flags &= ~SNOR_F_USE_UPAGE;
-		}
-		break;
-	case SF_DUAL_PARALLEL_FLASH:
-		*addr >>= flash->shift;
-		break;
-	default:
-		debug("SF: Unsupported dual_flash=%d\n", flash->dual_flash);
-		break;
-	}
-}
-#endif
-
-static int spi_flash_sr_ready(struct spi_flash *flash)
-{
-	u8 sr;
-	int ret;
-
-	ret = read_sr(flash, &sr);
-	if (ret < 0)
-		return ret;
-
-	return !(sr & STATUS_WIP);
-}
-
-static int spi_flash_fsr_ready(struct spi_flash *flash)
-{
-	u8 fsr;
-	int ret;
-
-	ret = read_fsr(flash, &fsr);
-	if (ret < 0)
-		return ret;
-
-	return fsr & STATUS_PEC;
-}
-
-static int spi_flash_ready(struct spi_flash *flash)
-{
-	int sr, fsr;
-
-	sr = spi_flash_sr_ready(flash);
-	if (sr < 0)
-		return sr;
-
-	fsr = 1;
-	if (flash->flags & SNOR_F_USE_FSR) {
-		fsr = spi_flash_fsr_ready(flash);
-		if (fsr < 0)
-			return fsr;
-	}
-
-	return sr && fsr;
-}
-
-static int spi_flash_wait_till_ready(struct spi_flash *flash,
-				     unsigned long timeout)
-{
-	unsigned long timebase;
-	int ret;
-
-	timebase = get_timer(0);
-
-	while (get_timer(timebase) < timeout) {
-		ret = spi_flash_ready(flash);
-		if (ret < 0)
-			return ret;
-		if (ret)
-			return 0;
-	}
-
-	printf("SF: Timeout!\n");
-
-	return -ETIMEDOUT;
-}
-
-int spi_flash_write_common(struct spi_flash *flash, const u8 *cmd,
-		size_t cmd_len, const void *buf, size_t buf_len)
-{
-	struct spi_slave *spi = flash->spi;
-	unsigned long timeout = SPI_FLASH_PROG_TIMEOUT;
-	int ret;
-
-	if (buf == NULL)
-		timeout = SPI_FLASH_PAGE_ERASE_TIMEOUT;
-
-	ret = spi_claim_bus(spi);
-	if (ret) {
-		debug("SF: unable to claim SPI bus\n");
-		return ret;
-	}
-
-	ret = spi_flash_cmd_write_enable(flash);
-	if (ret < 0) {
-		debug("SF: enabling write failed\n");
-		return ret;
-	}
-
-	ret = spi_flash_cmd_write(spi, cmd, cmd_len, buf, buf_len);
-	if (ret < 0) {
-		debug("SF: write cmd failed\n");
-		return ret;
-	}
-
-	ret = spi_flash_wait_till_ready(flash, timeout);
-	if (ret < 0) {
-		debug("SF: write %s timed out\n",
-		      timeout == SPI_FLASH_PROG_TIMEOUT ?
-			"program" : "page erase");
-		return ret;
-	}
-
-	spi_release_bus(spi);
-
-	return ret;
-}
-
-int spi_flash_cmd_erase_ops(struct spi_flash *flash, u32 offset, size_t len)
-{
-	u32 erase_size, erase_addr;
-	u8 cmd[SPI_FLASH_CMD_LEN];
-	int ret = -1;
-
-	erase_size = flash->erase_size;
-	if (offset % erase_size || len % erase_size) {
-		printf("SF: Erase offset/length not multiple of erase size\n");
-		return -1;
-	}
-
-	if (flash->flash_is_locked) {
-		if (flash->flash_is_locked(flash, offset, len) > 0) {
-			printf("offset 0x%x is protected and cannot be erased\n",
-			       offset);
-			return -EINVAL;
-		}
-	}
-
-	cmd[0] = flash->erase_cmd;
-	while (len) {
-		erase_addr = offset;
-
-#ifdef CONFIG_SF_DUAL_FLASH
-		if (flash->dual_flash > SF_SINGLE_FLASH)
-			spi_flash_dual(flash, &erase_addr);
-#endif
-#ifdef CONFIG_SPI_FLASH_BAR
-		ret = write_bar(flash, erase_addr);
-		if (ret < 0)
-			return ret;
-#endif
-		spi_flash_addr(erase_addr, cmd);
-
-		debug("SF: erase %2x %2x %2x %2x (%x)\n", cmd[0], cmd[1],
-		      cmd[2], cmd[3], erase_addr);
-
-		ret = spi_flash_write_common(flash, cmd, sizeof(cmd), NULL, 0);
-		if (ret < 0) {
-			debug("SF: erase failed\n");
-			break;
-		}
-
-		offset += erase_size;
-		len -= erase_size;
-	}
-
-#ifdef CONFIG_SPI_FLASH_BAR
-	ret = clean_bar(flash);
-#endif
-
-	return ret;
-}
-
-int spi_flash_cmd_write_ops(struct spi_flash *flash, u32 offset,
-		size_t len, const void *buf)
-{
-	struct spi_slave *spi = flash->spi;
-	unsigned long byte_addr, page_size;
-	u32 write_addr;
-	size_t chunk_len, actual;
-	u8 cmd[SPI_FLASH_CMD_LEN];
-	int ret = -1;
-
-	page_size = flash->page_size;
-
-	if (flash->flash_is_locked) {
-		if (flash->flash_is_locked(flash, offset, len) > 0) {
-			printf("offset 0x%x is protected and cannot be written\n",
-			       offset);
-			return -EINVAL;
-		}
-	}
-
-	cmd[0] = flash->write_cmd;
-	for (actual = 0; actual < len; actual += chunk_len) {
-		write_addr = offset;
-
-#ifdef CONFIG_SF_DUAL_FLASH
-		if (flash->dual_flash > SF_SINGLE_FLASH)
-			spi_flash_dual(flash, &write_addr);
-#endif
-#ifdef CONFIG_SPI_FLASH_BAR
-		ret = write_bar(flash, write_addr);
-		if (ret < 0)
-			return ret;
-#endif
-		byte_addr = offset % page_size;
-		chunk_len = min(len - actual, (size_t)(page_size - byte_addr));
-
-		if (spi->max_write_size)
-			chunk_len = min(chunk_len,
-					spi->max_write_size - sizeof(cmd));
-
-		spi_flash_addr(write_addr, cmd);
-
-		debug("SF: 0x%p => cmd = { 0x%02x 0x%02x%02x%02x } chunk_len = %zu\n",
-		      buf + actual, cmd[0], cmd[1], cmd[2], cmd[3], chunk_len);
-
-		ret = spi_flash_write_common(flash, cmd, sizeof(cmd),
-					buf + actual, chunk_len);
-		if (ret < 0) {
-			debug("SF: write failed\n");
-			break;
-		}
-
-		offset += chunk_len;
-	}
-
-#ifdef CONFIG_SPI_FLASH_BAR
-	ret = clean_bar(flash);
-#endif
-
-	return ret;
-}
-
-int spi_flash_read_common(struct spi_flash *flash, const u8 *cmd,
-		size_t cmd_len, void *data, size_t data_len)
-{
-	struct spi_slave *spi = flash->spi;
-	int ret;
-
-	ret = spi_claim_bus(spi);
-	if (ret) {
-		debug("SF: unable to claim SPI bus\n");
-		return ret;
-	}
-
-	ret = spi_flash_cmd_read(spi, cmd, cmd_len, data, data_len);
-	if (ret < 0) {
-		debug("SF: read cmd failed\n");
-		return ret;
-	}
-
-	spi_release_bus(spi);
-
-	return ret;
-}
-
-/*
- * TODO: remove the weak after all the other spi_flash_copy_mmap
- * implementations removed from drivers
- */
-void __weak spi_flash_copy_mmap(void *data, void *offset, size_t len)
-{
-#ifdef CONFIG_DMA
-	if (!dma_memcpy(data, offset, len))
-		return;
-#endif
-	memcpy(data, offset, len);
-}
-
-int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 offset,
-		size_t len, void *data)
-{
-	struct spi_slave *spi = flash->spi;
-	u8 cmdsz;
-	u32 remain_len, read_len, read_addr;
-	int bank_sel = 0;
-	int ret = 0;
-
-	/* Handle memory-mapped SPI */
-	if (flash->memory_map) {
-		ret = spi_claim_bus(spi);
-		if (ret) {
-			debug("SF: unable to claim SPI bus\n");
-			return log_ret(ret);
-		}
-		spi_xfer(spi, 0, NULL, NULL, SPI_XFER_MMAP);
-		spi_flash_copy_mmap(data, flash->memory_map + offset, len);
-		spi_xfer(spi, 0, NULL, NULL, SPI_XFER_MMAP_END);
-		spi_release_bus(spi);
-		return 0;
-	}
-
-	cmdsz = SPI_FLASH_CMD_LEN + flash->dummy_byte;
-	u8 cmd[cmdsz];
-
-	cmd[0] = flash->read_cmd;
-	while (len) {
-		read_addr = offset;
-
-#ifdef CONFIG_SF_DUAL_FLASH
-		if (flash->dual_flash > SF_SINGLE_FLASH)
-			spi_flash_dual(flash, &read_addr);
-#endif
-#ifdef CONFIG_SPI_FLASH_BAR
-		ret = write_bar(flash, read_addr);
-		if (ret < 0)
-			return log_ret(ret);
-		bank_sel = flash->bank_curr;
-#endif
-		remain_len = ((SPI_FLASH_16MB_BOUN << flash->shift) *
-				(bank_sel + 1)) - offset;
-		if (len < remain_len)
-			read_len = len;
-		else
-			read_len = remain_len;
-
-		if (spi->max_read_size)
-			read_len = min(read_len, spi->max_read_size);
-
-		spi_flash_addr(read_addr, cmd);
-
-		ret = spi_flash_read_common(flash, cmd, cmdsz, data, read_len);
-		if (ret < 0) {
-			debug("SF: read failed\n");
-			break;
-		}
-
-		offset += read_len;
-		len -= read_len;
-		data += read_len;
-	}
-
-#ifdef CONFIG_SPI_FLASH_BAR
-	ret = clean_bar(flash);
-#endif
-
-	return log_ret(ret);
-}
-
-#ifdef CONFIG_SPI_FLASH_SST
-static bool sst26_process_bpr(u32 bpr_size, u8 *cmd, u32 bit, enum lock_ctl ctl)
-{
-	switch (ctl) {
-		case SST26_CTL_LOCK:
-			cmd[bpr_size - (bit / 8) - 1] |= BIT(bit % 8);
-			break;
-		case SST26_CTL_UNLOCK:
-			cmd[bpr_size - (bit / 8) - 1] &= ~BIT(bit % 8);
-			break;
-		case SST26_CTL_CHECK:
-			return !!(cmd[bpr_size - (bit / 8) - 1] & BIT(bit % 8));
-	}
-
-	return false;
-}
-
-/*
- * sst26wf016/sst26wf032/sst26wf064 have next block protection:
- * 4x   - 8  KByte blocks - read & write protection bits - upper addresses
- * 1x   - 32 KByte blocks - write protection bits
- * rest - 64 KByte blocks - write protection bits
- * 1x   - 32 KByte blocks - write protection bits
- * 4x   - 8  KByte blocks - read & write protection bits - lower addresses
- *
- * We'll support only per 64k lock/unlock so lower and upper 64 KByte region
- * will be treated as single block.
- */
-
-/*
- * Lock, unlock or check lock status of the flash region of the flash (depending
- * on the lock_ctl value)
- */
-static int sst26_lock_ctl(struct spi_flash *flash, u32 ofs, size_t len, enum lock_ctl ctl)
-{
-	u32 i, bpr_ptr, rptr_64k, lptr_64k, bpr_size;
-	bool lower_64k = false, upper_64k = false;
-	u8 cmd, bpr_buff[SST26_MAX_BPR_REG_LEN] = {};
-	int ret;
-
-	/* Check length and offset for 64k alignment */
-	if ((ofs & (SZ_64K - 1)) || (len & (SZ_64K - 1)))
-		return -EINVAL;
-
-	if (ofs + len > flash->size)
-		return -EINVAL;
-
-	/* SST26 family has only 16 Mbit, 32 Mbit and 64 Mbit IC */
-	if (flash->size != SZ_2M &&
-	    flash->size != SZ_4M &&
-	    flash->size != SZ_8M)
-		return -EINVAL;
-
-	bpr_size = 2 + (flash->size / SZ_64K / 8);
-
-	cmd = SST26_CMD_READ_BPR;
-	ret = spi_flash_read_common(flash, &cmd, 1, bpr_buff, bpr_size);
-	if (ret < 0) {
-		printf("SF: fail to read block-protection register\n");
-		return ret;
-	}
-
-	rptr_64k = min_t(u32, ofs + len , flash->size - SST26_BOUND_REG_SIZE);
-	lptr_64k = max_t(u32, ofs, SST26_BOUND_REG_SIZE);
-
-	upper_64k = ((ofs + len) > (flash->size - SST26_BOUND_REG_SIZE));
-	lower_64k = (ofs < SST26_BOUND_REG_SIZE);
-
-	/* Lower bits in block-protection register are about 64k region */
-	bpr_ptr = lptr_64k / SZ_64K - 1;
-
-	/* Process 64K blocks region */
-	while (lptr_64k < rptr_64k) {
-		if (sst26_process_bpr(bpr_size, bpr_buff, bpr_ptr, ctl))
-			return EACCES;
-
-		bpr_ptr++;
-		lptr_64k += SZ_64K;
-	}
-
-	/* 32K and 8K region bits in BPR are after 64k region bits */
-	bpr_ptr = (flash->size - 2 * SST26_BOUND_REG_SIZE) / SZ_64K;
-
-	/* Process lower 32K block region */
-	if (lower_64k)
-		if (sst26_process_bpr(bpr_size, bpr_buff, bpr_ptr, ctl))
-			return EACCES;
-
-	bpr_ptr++;
-
-	/* Process upper 32K block region */
-	if (upper_64k)
-		if (sst26_process_bpr(bpr_size, bpr_buff, bpr_ptr, ctl))
-			return EACCES;
-
-	bpr_ptr++;
-
-	/* Process lower 8K block regions */
-	for (i = 0; i < SST26_BPR_8K_NUM; i++) {
-		if (lower_64k)
-			if (sst26_process_bpr(bpr_size, bpr_buff, bpr_ptr, ctl))
-				return EACCES;
-
-		/* In 8K area BPR has both read and write protection bits */
-		bpr_ptr += 2;
-	}
-
-	/* Process upper 8K block regions */
-	for (i = 0; i < SST26_BPR_8K_NUM; i++) {
-		if (upper_64k)
-			if (sst26_process_bpr(bpr_size, bpr_buff, bpr_ptr, ctl))
-				return EACCES;
-
-		/* In 8K area BPR has both read and write protection bits */
-		bpr_ptr += 2;
-	}
-
-	/* If we check region status we don't need to write BPR back */
-	if (ctl == SST26_CTL_CHECK)
-		return 0;
-
-	cmd = SST26_CMD_WRITE_BPR;
-	ret = spi_flash_write_common(flash, &cmd, 1, bpr_buff, bpr_size);
-	if (ret < 0) {
-		printf("SF: fail to write block-protection register\n");
-		return ret;
-	}
-
-	return 0;
-}
-
-static int sst26_unlock(struct spi_flash *flash, u32 ofs, size_t len)
-{
-	return sst26_lock_ctl(flash, ofs, len, SST26_CTL_UNLOCK);
-}
-
-static int sst26_lock(struct spi_flash *flash, u32 ofs, size_t len)
-{
-	return sst26_lock_ctl(flash, ofs, len, SST26_CTL_LOCK);
-}
-
-/*
- * Returns EACCES (positive value) if region is locked, 0 if region is unlocked,
- * and negative on errors.
- */
-static int sst26_is_locked(struct spi_flash *flash, u32 ofs, size_t len)
-{
-	/*
-	 * is_locked function is used for check before reading or erasing flash
-	 * region, so offset and length might be not 64k allighned, so adjust
-	 * them to be 64k allighned as sst26_lock_ctl works only with 64k
-	 * allighned regions.
-	 */
-	ofs -= ofs & (SZ_64K - 1);
-	len = len & (SZ_64K - 1) ? (len & ~(SZ_64K - 1)) + SZ_64K : len;
-
-	return sst26_lock_ctl(flash, ofs, len, SST26_CTL_CHECK);
-}
-
-static int sst_byte_write(struct spi_flash *flash, u32 offset, const void *buf)
-{
-	struct spi_slave *spi = flash->spi;
-	int ret;
-	u8 cmd[4] = {
-		CMD_SST_BP,
-		offset >> 16,
-		offset >> 8,
-		offset,
-	};
-
-	debug("BP[%02x]: 0x%p => cmd = { 0x%02x 0x%06x }\n",
-	      spi_w8r8(spi, CMD_READ_STATUS), buf, cmd[0], offset);
-
-	ret = spi_flash_cmd_write_enable(flash);
-	if (ret)
-		return ret;
-
-	ret = spi_flash_cmd_write(spi, cmd, sizeof(cmd), buf, 1);
-	if (ret)
-		return ret;
-
-	return spi_flash_wait_till_ready(flash, SPI_FLASH_PROG_TIMEOUT);
-}
-
-int sst_write_wp(struct spi_flash *flash, u32 offset, size_t len,
-		const void *buf)
-{
-	struct spi_slave *spi = flash->spi;
-	size_t actual, cmd_len;
-	int ret;
-	u8 cmd[4];
-
-	ret = spi_claim_bus(spi);
-	if (ret) {
-		debug("SF: Unable to claim SPI bus\n");
-		return ret;
-	}
-
-	/* If the data is not word aligned, write out leading single byte */
-	actual = offset % 2;
-	if (actual) {
-		ret = sst_byte_write(flash, offset, buf);
-		if (ret)
-			goto done;
-	}
-	offset += actual;
-
-	ret = spi_flash_cmd_write_enable(flash);
-	if (ret)
-		goto done;
-
-	cmd_len = 4;
-	cmd[0] = CMD_SST_AAI_WP;
-	cmd[1] = offset >> 16;
-	cmd[2] = offset >> 8;
-	cmd[3] = offset;
-
-	for (; actual < len - 1; actual += 2) {
-		debug("WP[%02x]: 0x%p => cmd = { 0x%02x 0x%06x }\n",
-		      spi_w8r8(spi, CMD_READ_STATUS), buf + actual,
-		      cmd[0], offset);
-
-		ret = spi_flash_cmd_write(spi, cmd, cmd_len,
-					buf + actual, 2);
-		if (ret) {
-			debug("SF: sst word program failed\n");
-			break;
-		}
-
-		ret = spi_flash_wait_till_ready(flash, SPI_FLASH_PROG_TIMEOUT);
-		if (ret)
-			break;
-
-		cmd_len = 1;
-		offset += 2;
-	}
-
-	if (!ret)
-		ret = spi_flash_cmd_write_disable(flash);
-
-	/* If there is a single trailing byte, write it out */
-	if (!ret && actual != len)
-		ret = sst_byte_write(flash, offset, buf + actual);
-
- done:
-	debug("SF: sst: program %s %zu bytes @ 0x%zx\n",
-	      ret ? "failure" : "success", len, offset - actual);
-
-	spi_release_bus(spi);
-	return ret;
-}
-
-int sst_write_bp(struct spi_flash *flash, u32 offset, size_t len,
-		const void *buf)
-{
-	struct spi_slave *spi = flash->spi;
-	size_t actual;
-	int ret;
-
-	ret = spi_claim_bus(spi);
-	if (ret) {
-		debug("SF: Unable to claim SPI bus\n");
-		return ret;
-	}
-
-	for (actual = 0; actual < len; actual++) {
-		ret = sst_byte_write(flash, offset, buf + actual);
-		if (ret) {
-			debug("SF: sst byte program failed\n");
-			break;
-		}
-		offset++;
-	}
-
-	if (!ret)
-		ret = spi_flash_cmd_write_disable(flash);
-
-	debug("SF: sst: program %s %zu bytes @ 0x%zx\n",
-	      ret ? "failure" : "success", len, offset - actual);
-
-	spi_release_bus(spi);
-	return ret;
-}
-#endif
-
-#if defined(CONFIG_SPI_FLASH_STMICRO) || defined(CONFIG_SPI_FLASH_SST)
-static void stm_get_locked_range(struct spi_flash *flash, u8 sr, loff_t *ofs,
-				 u64 *len)
-{
-	u8 mask = SR_BP2 | SR_BP1 | SR_BP0;
-	int shift = ffs(mask) - 1;
-	int pow;
-
-	if (!(sr & mask)) {
-		/* No protection */
-		*ofs = 0;
-		*len = 0;
-	} else {
-		pow = ((sr & mask) ^ mask) >> shift;
-		*len = flash->size >> pow;
-		*ofs = flash->size - *len;
-	}
-}
-
-/*
- * Return 1 if the entire region is locked, 0 otherwise
- */
-static int stm_is_locked_sr(struct spi_flash *flash, loff_t ofs, u64 len,
-			    u8 sr)
-{
-	loff_t lock_offs;
-	u64 lock_len;
-
-	stm_get_locked_range(flash, sr, &lock_offs, &lock_len);
-
-	return (ofs + len <= lock_offs + lock_len) && (ofs >= lock_offs);
-}
-
-/*
- * Check if a region of the flash is (completely) locked. See stm_lock() for
- * more info.
- *
- * Returns 1 if entire region is locked, 0 if any portion is unlocked, and
- * negative on errors.
- */
-int stm_is_locked(struct spi_flash *flash, u32 ofs, size_t len)
-{
-	int status;
-	u8 sr;
-
-	status = read_sr(flash, &sr);
-	if (status < 0)
-		return status;
-
-	return stm_is_locked_sr(flash, ofs, len, sr);
-}
-
-/*
- * Lock a region of the flash. Compatible with ST Micro and similar flash.
- * Supports only the block protection bits BP{0,1,2} in the status register
- * (SR). Does not support these features found in newer SR bitfields:
- *   - TB: top/bottom protect - only handle TB=0 (top protect)
- *   - SEC: sector/block protect - only handle SEC=0 (block protect)
- *   - CMP: complement protect - only support CMP=0 (range is not complemented)
- *
- * Sample table portion for 8MB flash (Winbond w25q64fw):
- *
- *   SEC  |  TB   |  BP2  |  BP1  |  BP0  |  Prot Length  | Protected Portion
- *  --------------------------------------------------------------------------
- *    X   |   X   |   0   |   0   |   0   |  NONE         | NONE
- *    0   |   0   |   0   |   0   |   1   |  128 KB       | Upper 1/64
- *    0   |   0   |   0   |   1   |   0   |  256 KB       | Upper 1/32
- *    0   |   0   |   0   |   1   |   1   |  512 KB       | Upper 1/16
- *    0   |   0   |   1   |   0   |   0   |  1 MB         | Upper 1/8
- *    0   |   0   |   1   |   0   |   1   |  2 MB         | Upper 1/4
- *    0   |   0   |   1   |   1   |   0   |  4 MB         | Upper 1/2
- *    X   |   X   |   1   |   1   |   1   |  8 MB         | ALL
- *
- * Returns negative on errors, 0 on success.
- */
-int stm_lock(struct spi_flash *flash, u32 ofs, size_t len)
-{
-	u8 status_old, status_new;
-	u8 mask = SR_BP2 | SR_BP1 | SR_BP0;
-	u8 shift = ffs(mask) - 1, pow, val;
-	int ret;
-
-	ret = read_sr(flash, &status_old);
-	if (ret < 0)
-		return ret;
-
-	/* SPI NOR always locks to the end */
-	if (ofs + len != flash->size) {
-		/* Does combined region extend to end? */
-		if (!stm_is_locked_sr(flash, ofs + len, flash->size - ofs - len,
-				      status_old))
-			return -EINVAL;
-		len = flash->size - ofs;
-	}
-
-	/*
-	 * Need smallest pow such that:
-	 *
-	 *   1 / (2^pow) <= (len / size)
-	 *
-	 * so (assuming power-of-2 size) we do:
-	 *
-	 *   pow = ceil(log2(size / len)) = log2(size) - floor(log2(len))
-	 */
-	pow = ilog2(flash->size) - ilog2(len);
-	val = mask - (pow << shift);
-	if (val & ~mask)
-		return -EINVAL;
-
-	/* Don't "lock" with no region! */
-	if (!(val & mask))
-		return -EINVAL;
-
-	status_new = (status_old & ~mask) | val;
-
-	/* Only modify protection if it will not unlock other areas */
-	if ((status_new & mask) <= (status_old & mask))
-		return -EINVAL;
-
-	write_sr(flash, status_new);
-
-	return 0;
-}
-
-/*
- * Unlock a region of the flash. See stm_lock() for more info
- *
- * Returns negative on errors, 0 on success.
- */
-int stm_unlock(struct spi_flash *flash, u32 ofs, size_t len)
-{
-	uint8_t status_old, status_new;
-	u8 mask = SR_BP2 | SR_BP1 | SR_BP0;
-	u8 shift = ffs(mask) - 1, pow, val;
-	int ret;
-
-	ret = read_sr(flash, &status_old);
-	if (ret < 0)
-		return ret;
-
-	/* Cannot unlock; would unlock larger region than requested */
-	if (stm_is_locked_sr(flash, ofs - flash->erase_size, flash->erase_size,
-			     status_old))
-		return -EINVAL;
-	/*
-	 * Need largest pow such that:
-	 *
-	 *   1 / (2^pow) >= (len / size)
-	 *
-	 * so (assuming power-of-2 size) we do:
-	 *
-	 *   pow = floor(log2(size / len)) = log2(size) - ceil(log2(len))
-	 */
-	pow = ilog2(flash->size) - order_base_2(flash->size - (ofs + len));
-	if (ofs + len == flash->size) {
-		val = 0; /* fully unlocked */
-	} else {
-		val = mask - (pow << shift);
-		/* Some power-of-two sizes are not supported */
-		if (val & ~mask)
-			return -EINVAL;
-	}
-
-	status_new = (status_old & ~mask) | val;
-
-	/* Only modify protection if it will not lock other areas */
-	if ((status_new & mask) >= (status_old & mask))
-		return -EINVAL;
-
-	write_sr(flash, status_new);
-
-	return 0;
-}
-#endif
-
-
-#ifdef CONFIG_SPI_FLASH_MACRONIX
-static int macronix_quad_enable(struct spi_flash *flash)
-{
-	u8 qeb_status;
-	int ret;
-
-	ret = read_sr(flash, &qeb_status);
-	if (ret < 0)
-		return ret;
-
-	if (qeb_status & STATUS_QEB_MXIC)
-		return 0;
-
-	ret = write_sr(flash, qeb_status | STATUS_QEB_MXIC);
-	if (ret < 0)
-		return ret;
-
-	/* read SR and check it */
-	ret = read_sr(flash, &qeb_status);
-	if (!(ret >= 0 && (qeb_status & STATUS_QEB_MXIC))) {
-		printf("SF: Macronix SR Quad bit not clear\n");
-		return -EINVAL;
-	}
-
-	return ret;
-}
-#endif
-
-#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
-static int spansion_quad_enable(struct spi_flash *flash)
-{
-	u8 qeb_status;
-	int ret;
-
-	ret = read_cr(flash, &qeb_status);
-	if (ret < 0)
-		return ret;
-
-	if (qeb_status & STATUS_QEB_WINSPAN)
-		return 0;
-
-	ret = write_cr(flash, qeb_status | STATUS_QEB_WINSPAN);
-	if (ret < 0)
-		return ret;
-
-	/* read CR and check it */
-	ret = read_cr(flash, &qeb_status);
-	if (!(ret >= 0 && (qeb_status & STATUS_QEB_WINSPAN))) {
-		printf("SF: Spansion CR Quad bit not clear\n");
-		return -EINVAL;
-	}
-
-	return ret;
-}
-#endif
-
-static const struct spi_flash_info *spi_flash_read_id(struct spi_flash *flash)
-{
-	int				tmp;
-	u8				id[SPI_FLASH_MAX_ID_LEN];
-	const struct spi_flash_info	*info;
-
-	tmp = spi_flash_cmd(flash->spi, CMD_READ_ID, id, SPI_FLASH_MAX_ID_LEN);
-	if (tmp < 0) {
-		printf("SF: error %d reading JEDEC ID\n", tmp);
-		return ERR_PTR(tmp);
-	}
-
-	info = spi_flash_ids;
-	for (; info->name != NULL; info++) {
-		if (info->id_len) {
-			if (!memcmp(info->id, id, info->id_len))
-				return info;
-		}
-	}
-
-	printf("SF: unrecognized JEDEC id bytes: %02x, %02x, %02x\n",
-	       id[0], id[1], id[2]);
-	return ERR_PTR(-ENODEV);
-}
-
-static int set_quad_mode(struct spi_flash *flash,
-			 const struct spi_flash_info *info)
-{
-	switch (JEDEC_MFR(info)) {
-#ifdef CONFIG_SPI_FLASH_MACRONIX
-	case SPI_FLASH_CFI_MFR_MACRONIX:
-		return macronix_quad_enable(flash);
-#endif
-#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
-	case SPI_FLASH_CFI_MFR_SPANSION:
-	case SPI_FLASH_CFI_MFR_WINBOND:
-		return spansion_quad_enable(flash);
-#endif
-#ifdef CONFIG_SPI_FLASH_STMICRO
-	case SPI_FLASH_CFI_MFR_STMICRO:
-	case SPI_FLASH_CFI_MFR_MICRON:
-		debug("SF: QEB is volatile for %02x flash\n", JEDEC_MFR(info));
-		return 0;
-#endif
-	default:
-		printf("SF: Need set QEB func for %02x flash\n",
-		       JEDEC_MFR(info));
-		return -1;
-	}
-}
-
-#if CONFIG_IS_ENABLED(OF_CONTROL)
-int spi_flash_decode_fdt(struct spi_flash *flash)
-{
-#ifdef CONFIG_DM_SPI_FLASH
-	fdt_addr_t addr;
-	fdt_size_t size;
-
-	addr = dev_read_addr_size(flash->dev, "memory-map", &size);
-	if (addr == FDT_ADDR_T_NONE) {
-		debug("%s: Cannot decode address\n", __func__);
-		return 0;
-	}
-
-	if (flash->size > size) {
-		debug("%s: Memory map must cover entire device\n", __func__);
-		return -1;
-	}
-	flash->memory_map = map_sysmem(addr, size);
-#endif
-
-	return 0;
-}
-#endif /* CONFIG_IS_ENABLED(OF_CONTROL) */
-
-int spi_flash_scan(struct spi_flash *flash)
-{
-	struct spi_slave *spi = flash->spi;
-	const struct spi_flash_info *info = NULL;
-	int ret;
-
-	info = spi_flash_read_id(flash);
-	if (IS_ERR_OR_NULL(info))
-		return -ENOENT;
-
-	/*
-	 * Flash powers up read-only, so clear BP# bits.
-	 *
-	 * Note on some flash (like Macronix), QE (quad enable) bit is in the
-	 * same status register as BP# bits, and we need preserve its original
-	 * value during a reboot cycle as this is required by some platforms
-	 * (like Intel ICH SPI controller working under descriptor mode).
-	 */
-	if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_ATMEL ||
-	   (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_SST) ||
-	   (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_MACRONIX)) {
-		u8 sr = 0;
-
-		if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_MACRONIX) {
-			read_sr(flash, &sr);
-			sr &= STATUS_QEB_MXIC;
-		}
-		write_sr(flash, sr);
-	}
-
-	flash->name = info->name;
-	flash->memory_map = spi->memory_map;
-
-	if (info->flags & SST_WR)
-		flash->flags |= SNOR_F_SST_WR;
-
-#ifndef CONFIG_DM_SPI_FLASH
-	flash->write = spi_flash_cmd_write_ops;
-#if defined(CONFIG_SPI_FLASH_SST)
-	if (flash->flags & SNOR_F_SST_WR) {
-		if (spi->mode & SPI_TX_BYTE)
-			flash->write = sst_write_bp;
-		else
-			flash->write = sst_write_wp;
-	}
-#endif
-	flash->erase = spi_flash_cmd_erase_ops;
-	flash->read = spi_flash_cmd_read_ops;
-#endif
-
-#if defined(CONFIG_SPI_FLASH_STMICRO) || defined(CONFIG_SPI_FLASH_SST)
-	/* NOR protection support for STmicro/Micron chips and similar */
-	if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_STMICRO ||
-	    JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_MICRON ||
-	    JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_SST) {
-		flash->flash_lock = stm_lock;
-		flash->flash_unlock = stm_unlock;
-		flash->flash_is_locked = stm_is_locked;
-	}
-#endif
-
-/* sst26wf series block protection implementation differs from other series */
-#if defined(CONFIG_SPI_FLASH_SST)
-	if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_SST && info->id[1] == 0x26) {
-		flash->flash_lock = sst26_lock;
-		flash->flash_unlock = sst26_unlock;
-		flash->flash_is_locked = sst26_is_locked;
-	}
-#endif
-
-	/* Compute the flash size */
-	flash->shift = (flash->dual_flash & SF_DUAL_PARALLEL_FLASH) ? 1 : 0;
-	flash->page_size = info->page_size;
-	/*
-	 * The Spansion S25FS512S, S25FL032P and S25FL064P have 256b pages,
-	 * yet use the 0x4d00 Extended JEDEC code. The rest of the Spansion
-	 * flashes with the 0x4d00 Extended JEDEC code have 512b pages.
-	 * All of the others have 256b pages.
-	 */
-	if (JEDEC_EXT(info) == 0x4d00) {
-		if ((JEDEC_ID(info) != 0x0215) &&
-		    (JEDEC_ID(info) != 0x0216) &&
-		    (JEDEC_ID(info) != 0x0220))
-			flash->page_size = 512;
-	}
-	flash->page_size <<= flash->shift;
-	flash->sector_size = info->sector_size << flash->shift;
-	flash->size = flash->sector_size * info->n_sectors << flash->shift;
-#ifdef CONFIG_SF_DUAL_FLASH
-	if (flash->dual_flash & SF_DUAL_STACKED_FLASH)
-		flash->size <<= 1;
-#endif
-
-#ifdef CONFIG_SPI_FLASH_USE_4K_SECTORS
-	/* Compute erase sector and command */
-	if (info->flags & SECT_4K) {
-		flash->erase_cmd = CMD_ERASE_4K;
-		flash->erase_size = 4096 << flash->shift;
-	} else
-#endif
-	{
-		flash->erase_cmd = CMD_ERASE_64K;
-		flash->erase_size = flash->sector_size;
-	}
-
-	/* Now erase size becomes valid sector size */
-	flash->sector_size = flash->erase_size;
-
-	/* Look for read commands */
-	flash->read_cmd = CMD_READ_ARRAY_FAST;
-	if (spi->mode & SPI_RX_SLOW)
-		flash->read_cmd = CMD_READ_ARRAY_SLOW;
-	else if (spi->mode & SPI_RX_QUAD && info->flags & RD_QUAD)
-		flash->read_cmd = CMD_READ_QUAD_OUTPUT_FAST;
-	else if (spi->mode & SPI_RX_DUAL && info->flags & RD_DUAL)
-		flash->read_cmd = CMD_READ_DUAL_OUTPUT_FAST;
-
-	/* Look for write commands */
-	if (info->flags & WR_QPP && spi->mode & SPI_TX_QUAD)
-		flash->write_cmd = CMD_QUAD_PAGE_PROGRAM;
-	else
-		/* Go for default supported write cmd */
-		flash->write_cmd = CMD_PAGE_PROGRAM;
-
-	/* Set the quad enable bit - only for quad commands */
-	if ((flash->read_cmd == CMD_READ_QUAD_OUTPUT_FAST) ||
-	    (flash->read_cmd == CMD_READ_QUAD_IO_FAST) ||
-	    (flash->write_cmd == CMD_QUAD_PAGE_PROGRAM)) {
-		ret = set_quad_mode(flash, info);
-		if (ret) {
-			debug("SF: Fail to set QEB for %02x\n",
-			      JEDEC_MFR(info));
-			return -EINVAL;
-		}
-	}
-
-	/* Read dummy_byte: dummy byte is determined based on the
-	 * dummy cycles of a particular command.
-	 * Fast commands - dummy_byte = dummy_cycles/8
-	 * I/O commands- dummy_byte = (dummy_cycles * no.of lines)/8
-	 * For I/O commands except cmd[0] everything goes on no.of lines
-	 * based on particular command but incase of fast commands except
-	 * data all go on single line irrespective of command.
-	 */
-	switch (flash->read_cmd) {
-	case CMD_READ_QUAD_IO_FAST:
-		flash->dummy_byte = 2;
-		break;
-	case CMD_READ_ARRAY_SLOW:
-		flash->dummy_byte = 0;
-		break;
-	default:
-		flash->dummy_byte = 1;
-	}
-
-#ifdef CONFIG_SPI_FLASH_STMICRO
-	if (info->flags & E_FSR)
-		flash->flags |= SNOR_F_USE_FSR;
-#endif
-
-	/* Configure the BAR - discover bank cmds and read current bank */
-#ifdef CONFIG_SPI_FLASH_BAR
-	ret = read_bar(flash, info);
-	if (ret < 0)
-		return ret;
-#endif
-
-#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
-	ret = spi_flash_decode_fdt(flash);
-	if (ret) {
-		debug("SF: FDT decode error\n");
-		return -EINVAL;
-	}
-#endif
-
-#ifndef CONFIG_SPL_BUILD
-	printf("SF: Detected %s with page size ", flash->name);
-	print_size(flash->page_size, ", erase size ");
-	print_size(flash->erase_size, ", total ");
-	print_size(flash->size, "");
-	if (flash->memory_map)
-		printf(", mapped at %p", flash->memory_map);
-	puts("\n");
-#endif
-
-#ifndef CONFIG_SPI_FLASH_BAR
-	if (((flash->dual_flash == SF_SINGLE_FLASH) &&
-	     (flash->size > SPI_FLASH_16MB_BOUN)) ||
-	     ((flash->dual_flash > SF_SINGLE_FLASH) &&
-	     (flash->size > SPI_FLASH_16MB_BOUN << 1))) {
-		puts("SF: Warning - Only lower 16MiB accessible,");
-		puts(" Full access #define CONFIG_SPI_FLASH_BAR\n");
-	}
-#endif
-
-	return 0;
-}
drivers/mtd/spi/spi_flash_ids.c deleted +0 -211

211 lines not on this page · raw message

Signature · 1 line
2.19.2
#33 lore raw

PATCH 7/16 mtd: spi: Remove unused files

Quoted 8 lines · Vignesh R

spi_flash and spi_flash_ids are no longer needed after SPI NOR migration. Remove them.

---
 drivers/mtd/spi/spi_flash.c     | 1337 -------------------------------
 drivers/mtd/spi/spi_flash_ids.c |  211 -----

Better to keep this by renaming and other licesnes, ie what I did before. It's good for maintaining ids separately instead of having in one big spi-nor file.

author maintainer
#34 lore raw

PATCH 7/16 mtd: spi: Remove unused files

Quoted 5 lines · Jagan Teki
Quoted 4 lines · Vignesh R

spi_flash and spi_flash_ids are no longer needed after SPI NOR migration. Remove them.

Quoted 9 lines
Quoted 4 lines
---
 drivers/mtd/spi/spi_flash.c     | 1337 -------------------------------
 drivers/mtd/spi/spi_flash_ids.c |  211 -----

Better to keep this by renaming and other licesnes, ie what I did before. It's good for maintaining ids separately instead of having in one big spi-nor file.

Flash ID table is refactored to separate file spi-nor-ids.c as part of 8/16. Its daunting task to update spi_flash_ids.c file to work with Linux's spi-nor layer due to differences in flags and addition of new SPI_NOR_4B_OPCODES flag.
I can re-add copyright next time around as some of the information is borrowed from existing spi_flash_ids.c

Signature · 2 lines
Regards
Vignesh
author maintainer
#35 lore raw

PATCH 8/16 mtd: spi: Add lightweight SPI flash stack for SPL

In reply to Vignesh R

Add a tiny SPI flash stack that just supports reading data/images from SPI flash. This is useful for boards that have SPL size constraints and would need to use SPI flash framework just to read images/data from flash. There is approximately 1.5 to 2KB savings with this.

Based on prior work of reducing spi flash id table by Simon Goldschmidt <[email protected]>

---
 common/spl/Kconfig             |   9 +
 drivers/mtd/spi/Makefile       |  10 +-
 drivers/mtd/spi/sf_internal.h  |   2 +
 drivers/mtd/spi/spi-nor-core.c | 266 +----------
 drivers/mtd/spi/spi-nor-ids.c  | 294 ++++++++++++
 drivers/mtd/spi/spi-nor-tiny.c | 810 +++++++++++++++++++++++++++++++++
 6 files changed, 1128 insertions(+), 263 deletions(-)
 create mode 100644 drivers/mtd/spi/spi-nor-ids.c
 create mode 100644 drivers/mtd/spi/spi-nor-tiny.c
common/spl/Kconfig +9 -0
index ba6d4d71fbc6..7433c049332d 100644
@@ -729,8 +729,17 @@ config SPL_SPI_FLASH_SUPPORT
 
 if SPL_SPI_FLASH_SUPPORT
 
+config SPL_SPI_FLASH_TINY
+	bool "Enable low footprint SPL SPI Flash support"
+	help
+	 Enable lightweight SPL SPI Flash support that supports just reading
+	 data/images from flash. No support to write/erase flash. Enable
+	 this if you have SPL size limitations and don't need full
+	 fledged SPI flash support.
+
 config SPL_SPI_FLASH_SFDP_SUPPORT
 	bool "SFDP table parsing support for SPI NOR flashes"
+	depends on !SPL_SPI_FLASH_TINY
 	help
 	 Enable support for parsing and auto discovery of parameters for
 	 SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP)
drivers/mtd/spi/Makefile +9 -1
index 70058d3df2b9..f99f6cb16e29 100644
@@ -4,12 +4,20 @@
 # Wolfgang Denk, DENX Software Engineering, wd at denx.de.
 
 obj-$(CONFIG_DM_SPI_FLASH) += sf-uclass.o
+spi-nor-y := sf_probe.o spi-nor-ids.o
 
 ifdef CONFIG_SPL_BUILD
 obj-$(CONFIG_SPL_SPI_BOOT)	+= fsl_espi_spl.o
+ifeq ($(CONFIG_SPL_SPI_FLASH_TINY),y)
+spi-nor-y += spi-nor-tiny.o
+else
+spi-nor-y += spi-nor-core.o
+endif
+else
+spi-nor-y += spi-nor-core.o
 endif
 
-obj-$(CONFIG_SPI_FLASH) += sf_probe.o spi-nor-core.o
+obj-$(CONFIG_SPI_FLASH) += spi-nor.o
 obj-$(CONFIG_SPI_FLASH_DATAFLASH) += sf_dataflash.o sf.o
 obj-$(CONFIG_SPI_FLASH_MTD) += sf_mtd.o
 obj-$(CONFIG_SPI_FLASH_SANDBOX) += sandbox.o
drivers/mtd/spi/sf_internal.h +2 -0
index 55619f5aea5c..7e7d400cdbdf 100644
@@ -16,7 +16,9 @@
 #define SPI_NOR_MAX_ADDR_WIDTH	4
 
 struct flash_info {
+#if !CONFIG_IS_ENABLED(SPI_FLASH_TINY)
 	char		*name;
+#endif
 
 	/*
 	 * This array stores the ID bytes.
drivers/mtd/spi/spi-nor-core.c +4 -262

288 lines not on this page · raw message

drivers/mtd/spi/spi-nor-ids.c new file +294 -0

294 lines not on this page · raw message

drivers/mtd/spi/spi-nor-tiny.c new file +810 -0

810 lines not on this page · raw message

Signature · 1 line
2.19.2
author maintainer
#36 lore raw

PATCH 9/16 sf_mtd: Simply mtd operations

In reply to Vignesh R

Now that there is new SPI NOR framework, simplify mtd device registration and read/write/erase operations.

---
 drivers/mtd/spi/sf_internal.h |  2 +-
 drivers/mtd/spi/sf_mtd.c      | 52 ++++++++++++++---------------------
 drivers/mtd/spi/sf_probe.c    |  5 ++--
 3 files changed, 24 insertions(+), 35 deletions(-)
drivers/mtd/spi/sf_internal.h +1 -1
index 7e7d400cdbdf..8b445bb0b506 100644
@@ -99,6 +99,6 @@ int spi_flash_cmd_get_sw_write_prot(struct spi_flash *flash);
 
 #ifdef CONFIG_SPI_FLASH_MTD
 int spi_flash_mtd_register(struct spi_flash *flash);
-void spi_flash_mtd_unregister(void);
+void spi_flash_mtd_unregister(struct spi_flash *flash);
 #endif
 #endif /* _SF_INTERNAL_H_ */
drivers/mtd/spi/sf_mtd.c +20 -32

126 lines not on this page · raw message

drivers/mtd/spi/sf_probe.c +3 -2
index 7f1378f4946d..05a38dcb91c8 100644
@@ -84,7 +84,7 @@ struct spi_flash *spi_flash_probe(unsigned int busnum, unsigned int cs,
 void spi_flash_free(struct spi_flash *flash)
 {
 #ifdef CONFIG_SPI_FLASH_MTD
-	spi_flash_mtd_unregister();
+	spi_flash_mtd_unregister(flash);
 #endif
 	spi_free_slave(flash->spi);
 	free(flash);
@@ -153,7 +153,8 @@ static int spi_flash_std_probe(struct udevice *dev)
 static int spi_flash_std_remove(struct udevice *dev)
 {
 #ifdef CONFIG_SPI_FLASH_MTD
-	spi_flash_mtd_unregister();
+	struct spi_flash *flash = dev_get_uclass_priv(dev);
+	spi_flash_mtd_unregister(flash);
 #endif
 	return 0;
 }
Signature · 1 line
2.19.2
#37 lore raw

PATCH 9/16 sf_mtd: Simply mtd operations

drivers/mtd/spi/sf_mtd.c static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info *instr) · line 45

Quoted 13 lines · On Wed, 12 Dec 2018 23:02:21 +0530 Vignesh R <[email protected]> wrote:
drivers/mtd/spi/sf_mtd.c +2 -3
@@ -39,13 +37,12 @@ static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)
 static int spi_flash_mtd_read(struct mtd_info *mtd, loff_t from, size_t len,
 	size_t *retlen, u_char *buf)
 {
-	struct spi_flash *flash = mtd->priv;
 	int err;
 
-	if (!flash)
+	if (!mtd || !mtd->priv)
 		return -ENODEV;
 
-	err = spi_flash_read(flash, from, len, buf);
+	err = mtd->_read(mtd, from, len, retlen, buf);

Please use the wrappers instead of calling those hooks directly.

#38 lore raw

PATCH 9/16 sf_mtd: Simply mtd operations

In reply to Vignesh R

Am 12.12.18 um 18:32 schrieb Vignesh R:

Quoted 37 lines

Now that there is new SPI NOR framework, simplify mtd device registration and read/write/erase operations.

---
 drivers/mtd/spi/sf_internal.h |  2 +-
 drivers/mtd/spi/sf_mtd.c      | 52 ++++++++++++++---------------------
 drivers/mtd/spi/sf_probe.c    |  5 ++--
 3 files changed, 24 insertions(+), 35 deletions(-)
drivers/mtd/spi/sf_internal.h +1 -1
index 7e7d400cdbdf..8b445bb0b506 100644
@@ -99,6 +99,6 @@ int spi_flash_cmd_get_sw_write_prot(struct spi_flash *flash);
 
 #ifdef CONFIG_SPI_FLASH_MTD
 int spi_flash_mtd_register(struct spi_flash *flash);
-void spi_flash_mtd_unregister(void);
+void spi_flash_mtd_unregister(struct spi_flash *flash);
 #endif
 #endif /* _SF_INTERNAL_H_ */
drivers/mtd/spi/sf_mtd.c +0 -2
index 68c36002bee2..65185b7c57dc 100644
@@ -9,21 +9,19 @@
 #include <linux/mtd/mtd.h>
 #include <spi_flash.h>
 
-static struct mtd_info sf_mtd_info;
 static bool sf_mtd_registered;
 static char sf_mtd_name[8];
 
 static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)
 {
-	struct spi_flash *flash = mtd->priv;

drivers/mtd/spi/sf_mtd.c line 24

Quoted 10 lines
drivers/mtd/spi/sf_mtd.c +2 -2
 	int err;
 
-	if (!flash)
+	if (!mtd || !mtd->priv)
 		return -ENODEV;
 
 	instr->state = MTD_ERASING;
 
-	err = spi_flash_erase(flash, instr->addr, instr->len);
+	err = mtd->_erase(mtd, instr);

this looks strange. Now you're delegating from the MTD instance created in this driver to the one created by spi-nor. This driver was only meant as an adapter between MTD and legacy SPI flash API. After the switch to spi-nor this driver is obsolete and should be removed in patch 6/16. Or is there any reason why users like cmd_mtd can't directly use the spi-nor MTD instance?

Quoted 135 lines
drivers/mtd/spi/sf_mtd.c +18 -28
 	if (err) {
 		instr->state = MTD_ERASE_FAILED;
 		instr->fail_addr = MTD_FAIL_ADDR_UNKNOWN;
@@ -39,13 +37,12 @@ static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)
 static int spi_flash_mtd_read(struct mtd_info *mtd, loff_t from, size_t len,
 	size_t *retlen, u_char *buf)
 {
-	struct spi_flash *flash = mtd->priv;
 	int err;
 
-	if (!flash)
+	if (!mtd || !mtd->priv)
 		return -ENODEV;
 
-	err = spi_flash_read(flash, from, len, buf);
+	err = mtd->_read(mtd, from, len, retlen, buf);
 	if (!err)
 		*retlen = len;
 
@@ -55,13 +52,12 @@ static int spi_flash_mtd_read(struct mtd_info *mtd, loff_t from, size_t len,
 static int spi_flash_mtd_write(struct mtd_info *mtd, loff_t to, size_t len,
 	size_t *retlen, const u_char *buf)
 {
-	struct spi_flash *flash = mtd->priv;
 	int err;
 
-	if (!flash)
+	if (!mtd || !mtd->priv)
 		return -ENODEV;
 
-	err = spi_flash_write(flash, to, len, buf);
+	err = mtd->_write(mtd, to, len, retlen, buf);
 	if (!err)
 		*retlen = len;
 
@@ -83,10 +79,11 @@ static int spi_flash_mtd_number(void)
 
 int spi_flash_mtd_register(struct spi_flash *flash)
 {
+	struct mtd_info *mtd = &flash->mtd;
 	int ret;
 
 	if (sf_mtd_registered) {
-		ret = del_mtd_device(&sf_mtd_info);
+		ret = del_mtd_device(mtd);
 		if (ret)
 			return ret;
 
@@ -94,42 +91,33 @@ int spi_flash_mtd_register(struct spi_flash *flash)
 	}
 
 	sf_mtd_registered = false;
-	memset(&sf_mtd_info, 0, sizeof(sf_mtd_info));
 	sprintf(sf_mtd_name, "nor%d", spi_flash_mtd_number());
 
-	sf_mtd_info.name = sf_mtd_name;
-	sf_mtd_info.type = MTD_NORFLASH;
-	sf_mtd_info.flags = MTD_CAP_NORFLASH;
-	sf_mtd_info.writesize = 1;
-	sf_mtd_info.writebufsize = flash->page_size;
-
-	sf_mtd_info._erase = spi_flash_mtd_erase;
-	sf_mtd_info._read = spi_flash_mtd_read;
-	sf_mtd_info._write = spi_flash_mtd_write;
-	sf_mtd_info._sync = spi_flash_mtd_sync;
-
-	sf_mtd_info.size = flash->size;
-	sf_mtd_info.priv = flash;
+	mtd->name = sf_mtd_name;
+	mtd->_erase = spi_flash_mtd_erase;
+	mtd->_read = spi_flash_mtd_read;
+	mtd->_write = spi_flash_mtd_write;
+	mtd->_sync = spi_flash_mtd_sync;
 
 	/* Only uniform flash devices for now */
-	sf_mtd_info.numeraseregions = 0;
-	sf_mtd_info.erasesize = flash->sector_size;
+	mtd->numeraseregions = 0;
 
-	ret = add_mtd_device(&sf_mtd_info);
+	ret = add_mtd_device(mtd);
 	if (!ret)
 		sf_mtd_registered = true;
 
 	return ret;
 }
 
-void spi_flash_mtd_unregister(void)
+void spi_flash_mtd_unregister(struct spi_flash *flash)
 {
+	struct mtd_info *mtd = &flash->mtd;
 	int ret;
 
 	if (!sf_mtd_registered)
 		return;
 
-	ret = del_mtd_device(&sf_mtd_info);
+	ret = del_mtd_device(mtd);
 	if (!ret) {
 		sf_mtd_registered = false;
 		return;
@@ -141,7 +129,7 @@ void spi_flash_mtd_unregister(void)
 	 * use-after-free bug. Still, things should be fixed to prevent the
 	 * spi_flash object from being destroyed when del_mtd_device() fails.
 	 */
-	sf_mtd_info.priv = NULL;
+	mtd->priv = NULL;
 	printf("Failed to unregister MTD %s and the spi_flash object is going away: you're in deep trouble!",
-	       sf_mtd_info.name);
+	       sf_mtd_name);
 }
drivers/mtd/spi/sf_probe.c +3 -2
index 7f1378f4946d..05a38dcb91c8 100644
@@ -84,7 +84,7 @@ struct spi_flash *spi_flash_probe(unsigned int busnum, unsigned int cs,
 void spi_flash_free(struct spi_flash *flash)
 {
 #ifdef CONFIG_SPI_FLASH_MTD
-	spi_flash_mtd_unregister();
+	spi_flash_mtd_unregister(flash);
 #endif
 	spi_free_slave(flash->spi);
 	free(flash);
@@ -153,7 +153,8 @@ static int spi_flash_std_probe(struct udevice *dev)
 static int spi_flash_std_remove(struct udevice *dev)
 {
 #ifdef CONFIG_SPI_FLASH_MTD
-	spi_flash_mtd_unregister();
+	struct spi_flash *flash = dev_get_uclass_priv(dev);
+	spi_flash_mtd_unregister(flash);
 #endif
 	return 0;
 }
Signature · 1 line
- Daniel
#39 lore raw

PATCH 9/16 sf_mtd: Simply mtd operations

In reply to Vignesh R

Hi Vignesh,

Quoted 55 lines · Vignesh R

Now that there is new SPI NOR framework, simplify mtd device registration and read/write/erase operations.

---
  drivers/mtd/spi/sf_internal.h |  2 +-
  drivers/mtd/spi/sf_mtd.c      | 52 ++++++++++++++---------------------
  drivers/mtd/spi/sf_probe.c    |  5 ++--
  3 files changed, 24 insertions(+), 35 deletions(-)
drivers/mtd/spi/sf_internal.h +1 -1
index 7e7d400cdbdf..8b445bb0b506 100644
@@ -99,6 +99,6 @@ int spi_flash_cmd_get_sw_write_prot(struct spi_flash *flash);
 
  #ifdef CONFIG_SPI_FLASH_MTD
  int spi_flash_mtd_register(struct spi_flash *flash);
-void spi_flash_mtd_unregister(void);
+void spi_flash_mtd_unregister(struct spi_flash *flash);
  #endif
  #endif /* _SF_INTERNAL_H_ */
drivers/mtd/spi/sf_mtd.c +2 -5
index 68c36002bee2..65185b7c57dc 100644
@@ -9,21 +9,19 @@
  #include <linux/mtd/mtd.h>
  #include <spi_flash.h>
 
-static struct mtd_info sf_mtd_info;
  static bool sf_mtd_registered;
  static char sf_mtd_name[8];
 
  static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)
  {
-	struct spi_flash *flash = mtd->priv;
  	int err;
 
-	if (!flash)
+	if (!mtd || !mtd->priv)
  		return -ENODEV;
 
  	instr->state = MTD_ERASING;
 
-	err = spi_flash_erase(flash, instr->addr, instr->len);
+	err = mtd->_erase(mtd, instr);
  	if (err) {
  		instr->state = MTD_ERASE_FAILED;
  		instr->fail_addr = MTD_FAIL_ADDR_UNKNOWN;
@@ -39,13 +37,12 @@ static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)
  static int spi_flash_mtd_read(struct mtd_info *mtd, loff_t from, size_t len,
  	size_t *retlen, u_char *buf)
  {
-	struct spi_flash *flash = mtd->priv;

drivers/mtd/spi/sf_mtd.c static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info *instr) · line 47

Quoted 10 lines
drivers/mtd/spi/sf_mtd.c +2 -2
  	int err;
 
-	if (!flash)
+	if (!mtd || !mtd->priv)
  		return -ENODEV;
 
-	err = spi_flash_read(flash, from, len, buf);
+	err = mtd->_read(mtd, from, len, retlen, buf);
  	if (!err)
  		*retlen = len;

I just tested this patchset on my MIPS linkit smart platform and it hangs in an infinite loop here in this read function. The callstack is:

spi_flash_std_read -> spi_flash_mtd_read

spi_flash_mtd_read() now calls itself recursively.

Any ideas?

Thanks,
Stefan

author maintainer
#40 lore raw

PATCH 9/16 sf_mtd: Simply mtd operations

In reply to Vignesh R

Boris, Stefan, Daniel

Quoted 5 lines · Vignesh R

Now that there is new SPI NOR framework, simplify mtd device registration and read/write/erase operations.

---

Oops, sorry I messed up rebase-ing this patch onto latest mainline. At this time it looks like MTD kconfig changes [1] are needed before I can simplify sf_mtd.c. Things should work even w/o this patch. I think I will drop this patch for now.

[1] https://patchwork.ozlabs.org/cover/1010033/

Quoted 177 lines
 drivers/mtd/spi/sf_internal.h |  2 +-
 drivers/mtd/spi/sf_mtd.c      | 52 ++++++++++++++---------------------
 drivers/mtd/spi/sf_probe.c    |  5 ++--
 3 files changed, 24 insertions(+), 35 deletions(-)
drivers/mtd/spi/sf_internal.h +1 -1
index 7e7d400cdbdf..8b445bb0b506 100644
@@ -99,6 +99,6 @@ int spi_flash_cmd_get_sw_write_prot(struct spi_flash *flash);
 
 #ifdef CONFIG_SPI_FLASH_MTD
 int spi_flash_mtd_register(struct spi_flash *flash);
-void spi_flash_mtd_unregister(void);
+void spi_flash_mtd_unregister(struct spi_flash *flash);
 #endif
 #endif /* _SF_INTERNAL_H_ */
drivers/mtd/spi/sf_mtd.c +20 -32
index 68c36002bee2..65185b7c57dc 100644
@@ -9,21 +9,19 @@
 #include <linux/mtd/mtd.h>
 #include <spi_flash.h>
 
-static struct mtd_info sf_mtd_info;
 static bool sf_mtd_registered;
 static char sf_mtd_name[8];
 
 static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)
 {
-	struct spi_flash *flash = mtd->priv;
 	int err;
 
-	if (!flash)
+	if (!mtd || !mtd->priv)
 		return -ENODEV;
 
 	instr->state = MTD_ERASING;
 
-	err = spi_flash_erase(flash, instr->addr, instr->len);
+	err = mtd->_erase(mtd, instr);
 	if (err) {
 		instr->state = MTD_ERASE_FAILED;
 		instr->fail_addr = MTD_FAIL_ADDR_UNKNOWN;
@@ -39,13 +37,12 @@ static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)
 static int spi_flash_mtd_read(struct mtd_info *mtd, loff_t from, size_t len,
 	size_t *retlen, u_char *buf)
 {
-	struct spi_flash *flash = mtd->priv;
 	int err;
 
-	if (!flash)
+	if (!mtd || !mtd->priv)
 		return -ENODEV;
 
-	err = spi_flash_read(flash, from, len, buf);
+	err = mtd->_read(mtd, from, len, retlen, buf);
 	if (!err)
 		*retlen = len;
 
@@ -55,13 +52,12 @@ static int spi_flash_mtd_read(struct mtd_info *mtd, loff_t from, size_t len,
 static int spi_flash_mtd_write(struct mtd_info *mtd, loff_t to, size_t len,
 	size_t *retlen, const u_char *buf)
 {
-	struct spi_flash *flash = mtd->priv;
 	int err;
 
-	if (!flash)
+	if (!mtd || !mtd->priv)
 		return -ENODEV;
 
-	err = spi_flash_write(flash, to, len, buf);
+	err = mtd->_write(mtd, to, len, retlen, buf);
 	if (!err)
 		*retlen = len;
 
@@ -83,10 +79,11 @@ static int spi_flash_mtd_number(void)
 
 int spi_flash_mtd_register(struct spi_flash *flash)
 {
+	struct mtd_info *mtd = &flash->mtd;
 	int ret;
 
 	if (sf_mtd_registered) {
-		ret = del_mtd_device(&sf_mtd_info);
+		ret = del_mtd_device(mtd);
 		if (ret)
 			return ret;
 
@@ -94,42 +91,33 @@ int spi_flash_mtd_register(struct spi_flash *flash)
 	}
 
 	sf_mtd_registered = false;
-	memset(&sf_mtd_info, 0, sizeof(sf_mtd_info));
 	sprintf(sf_mtd_name, "nor%d", spi_flash_mtd_number());
 
-	sf_mtd_info.name = sf_mtd_name;
-	sf_mtd_info.type = MTD_NORFLASH;
-	sf_mtd_info.flags = MTD_CAP_NORFLASH;
-	sf_mtd_info.writesize = 1;
-	sf_mtd_info.writebufsize = flash->page_size;
-
-	sf_mtd_info._erase = spi_flash_mtd_erase;
-	sf_mtd_info._read = spi_flash_mtd_read;
-	sf_mtd_info._write = spi_flash_mtd_write;
-	sf_mtd_info._sync = spi_flash_mtd_sync;
-
-	sf_mtd_info.size = flash->size;
-	sf_mtd_info.priv = flash;
+	mtd->name = sf_mtd_name;
+	mtd->_erase = spi_flash_mtd_erase;
+	mtd->_read = spi_flash_mtd_read;
+	mtd->_write = spi_flash_mtd_write;
+	mtd->_sync = spi_flash_mtd_sync;
 
 	/* Only uniform flash devices for now */
-	sf_mtd_info.numeraseregions = 0;
-	sf_mtd_info.erasesize = flash->sector_size;
+	mtd->numeraseregions = 0;
 
-	ret = add_mtd_device(&sf_mtd_info);
+	ret = add_mtd_device(mtd);
 	if (!ret)
 		sf_mtd_registered = true;
 
 	return ret;
 }
 
-void spi_flash_mtd_unregister(void)
+void spi_flash_mtd_unregister(struct spi_flash *flash)
 {
+	struct mtd_info *mtd = &flash->mtd;
 	int ret;
 
 	if (!sf_mtd_registered)
 		return;
 
-	ret = del_mtd_device(&sf_mtd_info);
+	ret = del_mtd_device(mtd);
 	if (!ret) {
 		sf_mtd_registered = false;
 		return;
@@ -141,7 +129,7 @@ void spi_flash_mtd_unregister(void)
 	 * use-after-free bug. Still, things should be fixed to prevent the
 	 * spi_flash object from being destroyed when del_mtd_device() fails.
 	 */
-	sf_mtd_info.priv = NULL;
+	mtd->priv = NULL;
 	printf("Failed to unregister MTD %s and the spi_flash object is going away: you're in deep trouble!",
-	       sf_mtd_info.name);
+	       sf_mtd_name);
 }
drivers/mtd/spi/sf_probe.c +3 -2
index 7f1378f4946d..05a38dcb91c8 100644
@@ -84,7 +84,7 @@ struct spi_flash *spi_flash_probe(unsigned int busnum, unsigned int cs,
 void spi_flash_free(struct spi_flash *flash)
 {
 #ifdef CONFIG_SPI_FLASH_MTD
-	spi_flash_mtd_unregister();
+	spi_flash_mtd_unregister(flash);
 #endif
 	spi_free_slave(flash->spi);
 	free(flash);
@@ -153,7 +153,8 @@ static int spi_flash_std_probe(struct udevice *dev)
 static int spi_flash_std_remove(struct udevice *dev)
 {
 #ifdef CONFIG_SPI_FLASH_MTD
-	spi_flash_mtd_unregister();
+	struct spi_flash *flash = dev_get_uclass_priv(dev);
+	spi_flash_mtd_unregister(flash);
 #endif
 	return 0;
 }
Signature · 2 lines
Regards
Vignesh
#41 lore raw

PATCH 9/16 sf_mtd: Simply mtd operations

Quoted 6 lines · Vignesh R

Boris, Stefan, Daniel

Quoted 3 lines · Vignesh R

Now that there is new SPI NOR framework, simplify mtd device registration and read/write/erase operations.

Quoted 7 lines
Quoted 2 lines

---

Oops, sorry I messed up rebase-ing this patch onto latest mainline. At this time it looks like MTD kconfig changes [1] are needed before I can simplify sf_mtd.c. Things should work even w/o this patch. I think I will drop this patch for now.

With this patch removed from this series, all seems to work just fine on my board with the strapped to 4-byte mode SPI NOR chip. Feel free to add my:

Thanks,
Stefan

Quoted 171 lines

[1] https://patchwork.ozlabs.org/cover/1010033/

Quoted 169 lines
  drivers/mtd/spi/sf_internal.h |  2 +-
  drivers/mtd/spi/sf_mtd.c      | 52 ++++++++++++++---------------------
  drivers/mtd/spi/sf_probe.c    |  5 ++--
  3 files changed, 24 insertions(+), 35 deletions(-)
drivers/mtd/spi/sf_internal.h +1 -1
index 7e7d400cdbdf..8b445bb0b506 100644
@@ -99,6 +99,6 @@ int spi_flash_cmd_get_sw_write_prot(struct spi_flash *flash);
 
  #ifdef CONFIG_SPI_FLASH_MTD
  int spi_flash_mtd_register(struct spi_flash *flash);
-void spi_flash_mtd_unregister(void);
+void spi_flash_mtd_unregister(struct spi_flash *flash);
  #endif
  #endif /* _SF_INTERNAL_H_ */
drivers/mtd/spi/sf_mtd.c +20 -32
index 68c36002bee2..65185b7c57dc 100644
@@ -9,21 +9,19 @@
  #include <linux/mtd/mtd.h>
  #include <spi_flash.h>
 
-static struct mtd_info sf_mtd_info;
  static bool sf_mtd_registered;
  static char sf_mtd_name[8];
 
  static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)
  {
-	struct spi_flash *flash = mtd->priv;
  	int err;
 
-	if (!flash)
+	if (!mtd || !mtd->priv)
  		return -ENODEV;
 
  	instr->state = MTD_ERASING;
 
-	err = spi_flash_erase(flash, instr->addr, instr->len);
+	err = mtd->_erase(mtd, instr);
  	if (err) {
  		instr->state = MTD_ERASE_FAILED;
  		instr->fail_addr = MTD_FAIL_ADDR_UNKNOWN;
@@ -39,13 +37,12 @@ static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)
  static int spi_flash_mtd_read(struct mtd_info *mtd, loff_t from, size_t len,
  	size_t *retlen, u_char *buf)
  {
-	struct spi_flash *flash = mtd->priv;
  	int err;
 
-	if (!flash)
+	if (!mtd || !mtd->priv)
  		return -ENODEV;
 
-	err = spi_flash_read(flash, from, len, buf);
+	err = mtd->_read(mtd, from, len, retlen, buf);
  	if (!err)
  		*retlen = len;
 
@@ -55,13 +52,12 @@ static int spi_flash_mtd_read(struct mtd_info *mtd, loff_t from, size_t len,
  static int spi_flash_mtd_write(struct mtd_info *mtd, loff_t to, size_t len,
  	size_t *retlen, const u_char *buf)
  {
-	struct spi_flash *flash = mtd->priv;
  	int err;
 
-	if (!flash)
+	if (!mtd || !mtd->priv)
  		return -ENODEV;
 
-	err = spi_flash_write(flash, to, len, buf);
+	err = mtd->_write(mtd, to, len, retlen, buf);
  	if (!err)
  		*retlen = len;
 
@@ -83,10 +79,11 @@ static int spi_flash_mtd_number(void)
 
  int spi_flash_mtd_register(struct spi_flash *flash)
  {
+	struct mtd_info *mtd = &flash->mtd;
  	int ret;
 
  	if (sf_mtd_registered) {
-		ret = del_mtd_device(&sf_mtd_info);
+		ret = del_mtd_device(mtd);
  		if (ret)
  			return ret;
 
@@ -94,42 +91,33 @@ int spi_flash_mtd_register(struct spi_flash *flash)
  	}
 
  	sf_mtd_registered = false;
-	memset(&sf_mtd_info, 0, sizeof(sf_mtd_info));
  	sprintf(sf_mtd_name, "nor%d", spi_flash_mtd_number());
 
-	sf_mtd_info.name = sf_mtd_name;
-	sf_mtd_info.type = MTD_NORFLASH;
-	sf_mtd_info.flags = MTD_CAP_NORFLASH;
-	sf_mtd_info.writesize = 1;
-	sf_mtd_info.writebufsize = flash->page_size;
-
-	sf_mtd_info._erase = spi_flash_mtd_erase;
-	sf_mtd_info._read = spi_flash_mtd_read;
-	sf_mtd_info._write = spi_flash_mtd_write;
-	sf_mtd_info._sync = spi_flash_mtd_sync;
-
-	sf_mtd_info.size = flash->size;
-	sf_mtd_info.priv = flash;
+	mtd->name = sf_mtd_name;
+	mtd->_erase = spi_flash_mtd_erase;
+	mtd->_read = spi_flash_mtd_read;
+	mtd->_write = spi_flash_mtd_write;
+	mtd->_sync = spi_flash_mtd_sync;
 
  	/* Only uniform flash devices for now */
-	sf_mtd_info.numeraseregions = 0;
-	sf_mtd_info.erasesize = flash->sector_size;
+	mtd->numeraseregions = 0;
 
-	ret = add_mtd_device(&sf_mtd_info);
+	ret = add_mtd_device(mtd);
  	if (!ret)
  		sf_mtd_registered = true;
 
  	return ret;
  }
 
-void spi_flash_mtd_unregister(void)
+void spi_flash_mtd_unregister(struct spi_flash *flash)
  {
+	struct mtd_info *mtd = &flash->mtd;
  	int ret;
 
  	if (!sf_mtd_registered)
  		return;
 
-	ret = del_mtd_device(&sf_mtd_info);
+	ret = del_mtd_device(mtd);
  	if (!ret) {
  		sf_mtd_registered = false;
  		return;
@@ -141,7 +129,7 @@ void spi_flash_mtd_unregister(void)
  	 * use-after-free bug. Still, things should be fixed to prevent the
  	 * spi_flash object from being destroyed when del_mtd_device() fails.
  	 */
-	sf_mtd_info.priv = NULL;
+	mtd->priv = NULL;
  	printf("Failed to unregister MTD %s and the spi_flash object is going away: you're in deep trouble!",
-	       sf_mtd_info.name);
+	       sf_mtd_name);
  }
drivers/mtd/spi/sf_probe.c +1 -1
index 7f1378f4946d..05a38dcb91c8 100644
@@ -84,7 +84,7 @@ struct spi_flash *spi_flash_probe(unsigned int busnum, unsigned int cs,
  void spi_flash_free(struct spi_flash *flash)
  {
  #ifdef CONFIG_SPI_FLASH_MTD
-	spi_flash_mtd_unregister();
+	spi_flash_mtd_unregister(flash);
  #endif
  	spi_free_slave(flash->spi);
  	free(flash);
@@ -153,7 +153,8 @@ static int spi_flash_std_probe(struct udevice *dev)
  static int spi_flash_std_remove(struct udevice *dev)
  {
Quoted 9 lines

drivers/mtd/spi/sf_probe.c static int spi_flash_std_probe(struct udevice *dev) · line 160

Quoted 8 lines
drivers/mtd/spi/sf_probe.c +2 -1
  #ifdef CONFIG_SPI_FLASH_MTD
-	spi_flash_mtd_unregister();
+	struct spi_flash *flash = dev_get_uclass_priv(dev);
+	spi_flash_mtd_unregister(flash);
  #endif
  	return 0;
  }

Viele Grüße,
Stefan

Signature · 3 lines
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de
author maintainer
#42 lore raw

PATCH 10/16 configs: Get rid of SPI_FLASH_BAR

In reply to Vignesh R

Now that we have new SPI NOR framework in place that supports 4 byte addressing mode by default, get rid of CONFIG_SPI_FLASH_BAR

---
 arch/arm/mach-omap2/am33xx/Kconfig               | 1 -
 configs/alt_defconfig                            | 1 -
 configs/am57xx_evm_defconfig                     | 1 -
 configs/am57xx_hs_evm_defconfig                  | 1 -
 configs/ap121_defconfig                          | 1 -
 configs/ap143_defconfig                          | 1 -
 configs/avnet_ultra96_rev1_defconfig             | 1 -
 configs/axs101_defconfig                         | 1 -
 configs/axs103_defconfig                         | 1 -
 configs/bg0900_defconfig                         | 1 -
 configs/blanche_defconfig                        | 1 -
 configs/cl-som-am57x_defconfig                   | 1 -
 configs/clearfog_defconfig                       | 1 -
 configs/cm_t43_defconfig                         | 1 -
 configs/db-88f6820-amc_defconfig                 | 1 -
 configs/display5_defconfig                       | 1 -
 configs/display5_factory_defconfig               | 1 -
 configs/dra7xx_evm_defconfig                     | 1 -
 configs/dra7xx_hs_evm_defconfig                  | 1 -
 configs/ds109_defconfig                          | 1 -
 configs/ds414_defconfig                          | 1 -
 configs/evb-rv1108_defconfig                     | 1 -
 configs/gose_defconfig                           | 1 -
 configs/helios4_defconfig                        | 1 -
 configs/k2g_evm_defconfig                        | 1 -
 configs/k2g_hs_evm_defconfig                     | 1 -
 configs/koelsch_defconfig                        | 1 -
 configs/lager_defconfig                          | 1 -
 configs/maxbcm_defconfig                         | 1 -
 configs/mt7629_rfb_defconfig                     | 1 -
 configs/mx6sxsabreauto_defconfig                 | 1 -
 configs/mx6sxsabresd_defconfig                   | 1 -
 configs/mx6ul_14x14_evk_defconfig                | 1 -
 configs/mx6ul_9x9_evk_defconfig                  | 1 -
 configs/mx6ull_14x14_evk_defconfig               | 1 -
 configs/mx6ull_14x14_evk_plugin_defconfig        | 1 -
 configs/mx7dsabresd_qspi_defconfig               | 1 -
 configs/porter_defconfig                         | 1 -
 configs/r8a77970_eagle_defconfig                 | 1 -
 configs/silk_defconfig                           | 1 -
 configs/socfpga_arria5_defconfig                 | 1 -
 configs/socfpga_cyclone5_defconfig               | 1 -
 configs/socfpga_is1_defconfig                    | 1 -
 configs/socfpga_sockit_defconfig                 | 1 -
 configs/socfpga_socrates_defconfig               | 1 -
 configs/socfpga_sr1500_defconfig                 | 1 -
 configs/socfpga_stratix10_defconfig              | 1 -
 configs/stout_defconfig                          | 1 -
 configs/topic_miami_defconfig                    | 1 -
 configs/topic_miamilite_defconfig                | 1 -
 configs/topic_miamiplus_defconfig                | 1 -
 configs/xilinx_versal_virt_defconfig             | 1 -
 configs/xilinx_zynqmp_mini_qspi_defconfig        | 1 -
 configs/xilinx_zynqmp_zc1232_revA_defconfig      | 1 -
 configs/xilinx_zynqmp_zc1254_revA_defconfig      | 1 -
 configs/xilinx_zynqmp_zc1275_revA_defconfig      | 1 -
 configs/xilinx_zynqmp_zc1275_revB_defconfig      | 1 -
 configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 -
 configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 -
 configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 1 -
 configs/xilinx_zynqmp_zcu100_revC_defconfig      | 1 -
 configs/xilinx_zynqmp_zcu102_rev1_0_defconfig    | 1 -
 configs/xilinx_zynqmp_zcu102_revA_defconfig      | 1 -
 configs/xilinx_zynqmp_zcu102_revB_defconfig      | 1 -
 configs/xilinx_zynqmp_zcu104_revA_defconfig      | 1 -
 configs/xilinx_zynqmp_zcu104_revC_defconfig      | 1 -
 configs/xilinx_zynqmp_zcu106_revA_defconfig      | 1 -
 configs/xilinx_zynqmp_zcu111_revA_defconfig      | 1 -
 configs/zynq_cc108_defconfig                     | 1 -
 configs/zynq_cse_qspi_defconfig                  | 1 -
 configs/zynq_dlc20_rev1_0_defconfig              | 1 -
 configs/zynq_microzed_defconfig                  | 1 -
 configs/zynq_minized_defconfig                   | 1 -
 configs/zynq_z_turn_defconfig                    | 1 -
 configs/zynq_zc702_defconfig                     | 1 -
 configs/zynq_zc706_defconfig                     | 1 -
 configs/zynq_zc770_xm010_defconfig               | 1 -
 configs/zynq_zc770_xm013_defconfig               | 1 -
 configs/zynq_zed_defconfig                       | 1 -
 configs/zynq_zybo_defconfig                      | 1 -
 configs/zynq_zybo_z7_defconfig                   | 1 -
 doc/SPI/README.ti_qspi_dra_test                  | 1 -
 drivers/mtd/spi/Kconfig                          | 7 -------
 include/configs/T102xQDS.h                       | 1 -
 include/configs/T102xRDB.h                       | 1 -
 include/configs/T104xRDB.h                       | 1 -
 include/configs/T208xQDS.h                       | 1 -
 include/configs/T208xRDB.h                       | 1 -
 include/configs/gw_ventana.h                     | 1 -
 include/configs/km/kmp204x-common.h              | 1 -
 include/configs/ls1021aiot.h                     | 1 -
 91 files changed, 97 deletions(-)
arch/arm/mach-omap2/am33xx/Kconfig +0 -1
index 3529607479d2..7eb319a11979 100644
@@ -229,7 +229,6 @@ config TARGET_AM43XX_EVM
 	imply DM_I2C
 	imply DM_SPI
 	imply DM_SPI_FLASH
-	imply SPI_FLASH_BAR
 	imply SPL_ENV_SUPPORT
 	imply SPL_EXT_SUPPORT
 	imply SPL_FAT_SUPPORT
configs/alt_defconfig +0 -1
index 396ed5eaf287..44f1e1c51a4c 100644
@@ -65,7 +65,6 @@ CONFIG_RENESAS_SDHI=y
 CONFIG_MTD=y
 CONFIG_MTD_DEVICE=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_MTD=y
 CONFIG_PHY_MICREL=y
configs/am57xx_evm_defconfig +0 -1
index aa8283033e53..7e14ae0ccd97 100644
@@ -56,7 +56,6 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
configs/am57xx_hs_evm_defconfig +0 -1
index 09f3774b6d0e..ef8e7ced30fc 100644
@@ -59,7 +59,6 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
configs/ap121_defconfig +0 -1
index 5d54267cd345..c9dbe4d72174 100644
@@ -35,7 +35,6 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_ATMEL=y
 CONFIG_SPI_FLASH_EON=y
 CONFIG_SPI_FLASH_GIGADEVICE=y
configs/ap143_defconfig +0 -1
index 83eb583b563e..7c1a296e2775 100644
@@ -34,7 +34,6 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y
 # CONFIG_NET is not set
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_ATMEL=y
 CONFIG_SPI_FLASH_EON=y
 CONFIG_SPI_FLASH_GIGADEVICE=y
configs/avnet_ultra96_rev1_defconfig +0 -1
index 9ca884e4056a..542700a4ae43 100644
@@ -60,7 +60,6 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
configs/axs101_defconfig +0 -1
index b4621c359fc6..b77ecc178151 100644
@@ -38,7 +38,6 @@ CONFIG_MMC=y
 CONFIG_MMC_DW=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_MTD=y
 CONFIG_DM_ETH=y
configs/axs103_defconfig +0 -1
index e7894d297cda..f42b694ca78b 100644
@@ -38,7 +38,6 @@ CONFIG_MMC=y
 CONFIG_MMC_DW=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_MTD=y
 CONFIG_DM_ETH=y
configs/bg0900_defconfig +0 -1
index 6de81621cd45..2bafc793bc80 100644
@@ -32,7 +32,6 @@ CONFIG_DOS_PARTITION=y
 CONFIG_NAND=y
 CONFIG_NAND_MXS=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_MII=y
 CONFIG_CONS_INDEX=0
configs/blanche_defconfig +0 -1
index 244ab22f6fc1..c5042d885f4e 100644
@@ -49,7 +49,6 @@ CONFIG_MTD_NOR_FLASH=y
 CONFIG_FLASH_CFI_DRIVER=y
 CONFIG_SYS_FLASH_CFI=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SMC911X=y
 CONFIG_SMC911X_BASE=0x18000000
configs/cl-som-am57x_defconfig +0 -1
index c5337f909e95..6e174067e22a 100644
@@ -37,7 +37,6 @@ CONFIG_LED_STATUS_BIT=37
 CONFIG_LED_STATUS_STATE=2
 CONFIG_MMC_OMAP_HS=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_ATMEL=y
 CONFIG_SPI_FLASH_EON=y
 CONFIG_SPI_FLASH_GIGADEVICE=y
configs/clearfog_defconfig +0 -1
index 2e59686291b7..aba9ff06a32d 100644
@@ -48,7 +48,6 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_SDMA=y
 CONFIG_MMC_SDHCI_MV=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_SPI_FLASH_MTD=y
 CONFIG_PHY_MARVELL=y
configs/cm_t43_defconfig +0 -1
index eb4a8f5a3308..b77b1c2c3c03 100644
@@ -49,7 +49,6 @@ CONFIG_DM_GPIO=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_NAND=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_ATMEL=y
 CONFIG_SPI_FLASH_EON=y
 CONFIG_SPI_FLASH_GIGADEVICE=y
configs/db-88f6820-amc_defconfig +0 -1
index dd58198a5469..0f42935f394a 100644
@@ -49,7 +49,6 @@ CONFIG_SYS_I2C_MVTWSI=y
 CONFIG_NAND=y
 CONFIG_NAND_PXA3XX=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PHY_MARVELL=y
configs/display5_defconfig +0 -1
index e6162e3cfb7c..a07c5d812249 100644
@@ -64,7 +64,6 @@ CONFIG_SYS_BOOTCOUNT_ADDR=0x020CC068
 CONFIG_FSL_ESDHC=y
 CONFIG_MTD_DEVICE=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PHYLIB=y
configs/display5_factory_defconfig +0 -1
index 6ef85e246ccf..44980864798e 100644
@@ -65,7 +65,6 @@ CONFIG_DFU_SF=y
 CONFIG_FSL_ESDHC=y
 CONFIG_MTD_DEVICE=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PHYLIB=y
configs/dra7xx_evm_defconfig +0 -1
index 2b6606f9e205..338319e2df83 100644
@@ -67,7 +67,6 @@ CONFIG_SPL_MMC_HS200_SUPPORT=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_DM_ETH=y
 CONFIG_DRIVER_TI_CPSW=y
configs/dra7xx_hs_evm_defconfig +0 -1
index 725acb527942..4d71b1308bea 100644
@@ -65,7 +65,6 @@ CONFIG_MMC_HS200_SUPPORT=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_DM_ETH=y
 CONFIG_DRIVER_TI_CPSW=y
configs/ds109_defconfig +0 -1
index 352403e57385..3e4e71bcbf4e 100644
@@ -25,7 +25,6 @@ CONFIG_SYS_I2C_MVTWSI=y
 # CONFIG_MMC is not set
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_MVGBE=y
 CONFIG_MII=y
configs/ds414_defconfig +0 -1
index 5325bd9968a8..8e1272a3817e 100644
@@ -44,7 +44,6 @@ CONFIG_SPL_OF_TRANSLATE=y
 # CONFIG_MMC is not set
 CONFIG_MTD_DEVICE=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PHY_ADDR_ENABLE=y
 CONFIG_PHY_MARVELL=y
configs/evb-rv1108_defconfig +0 -1
index 2ef041f2c50e..c267213a9d97 100644
@@ -29,7 +29,6 @@ CONFIG_FASTBOOT_FLASH_MMC_DEV=1
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_GIGADEVICE=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_SPI_FLASH_MTD=y
configs/gose_defconfig +0 -1
index 0368c659633e..a5afb3c5699b 100644
@@ -64,7 +64,6 @@ CONFIG_RENESAS_SDHI=y
 CONFIG_MTD=y
 CONFIG_MTD_DEVICE=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_MTD=y
 CONFIG_PHY_MICREL=y
configs/helios4_defconfig +0 -1
index 3bb4622fbee0..3e2488e6371f 100644
@@ -48,7 +48,6 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_SDMA=y
 CONFIG_MMC_SDHCI_MV=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_PHY_GIGE=y
 CONFIG_MVNETA=y
configs/k2g_evm_defconfig +0 -1
index bc4b92b4915f..6babe93b50f8 100644
@@ -42,7 +42,6 @@ CONFIG_NAND=y
 CONFIG_NAND_DAVINCI=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PHYLIB=y
configs/k2g_hs_evm_defconfig +0 -1
index 66d8220aebb6..5e617e7b0ed5 100644
@@ -35,7 +35,6 @@ CONFIG_NAND=y
 CONFIG_NAND_DAVINCI=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PHYLIB=y
configs/koelsch_defconfig +0 -1
index dbacfd87ba5d..1ff14ac4abd0 100644
@@ -64,7 +64,6 @@ CONFIG_RENESAS_SDHI=y
 CONFIG_MTD=y
 CONFIG_MTD_DEVICE=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_MTD=y
 CONFIG_PHY_MICREL=y
configs/lager_defconfig +0 -1
index 242e104b6bd3..d924d76911de 100644
@@ -66,7 +66,6 @@ CONFIG_RENESAS_SDHI=y
 CONFIG_MTD=y
 CONFIG_MTD_DEVICE=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_MTD=y
 CONFIG_PHY_MICREL=y
configs/maxbcm_defconfig +0 -1
index a4d2fcd2596a..5c716cdec8b8 100644
@@ -33,7 +33,6 @@ CONFIG_DEFAULT_DEVICE_TREE="armada-xp-maxbcm"
 CONFIG_SPL_OF_TRANSLATE=y
 # CONFIG_MMC is not set
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
configs/mt7629_rfb_defconfig +0 -1
index 1729d13c3d38..e390d8cc0b22 100644
@@ -43,7 +43,6 @@ CONFIG_DM_GPIO=y
 # CONFIG_MMC is not set
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_EON=y
 CONFIG_SPI_FLASH_GIGADEVICE=y
 CONFIG_SPI_FLASH_ISSI=y
configs/mx6sxsabreauto_defconfig +0 -1
index 41fac12d0c91..1f3dc837890a 100644
@@ -38,7 +38,6 @@ CONFIG_NAND=y
 CONFIG_NAND_MXS=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PHYLIB=y
 CONFIG_MII=y
configs/mx6sxsabresd_defconfig +0 -1
index d04ec4f9a34a..6ad293907109 100644
@@ -40,7 +40,6 @@ CONFIG_DM_MMC=y
 CONFIG_FSL_ESDHC=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PHYLIB=y
configs/mx6ul_14x14_evk_defconfig +0 -1
index 607045f8570d..12b51c777d83 100644
@@ -45,7 +45,6 @@ CONFIG_DM_MMC=y
 CONFIG_FSL_ESDHC=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_MICREL=y
configs/mx6ul_9x9_evk_defconfig +0 -1
index 2c8be5fb31ef..dad9e5a1da14 100644
@@ -45,7 +45,6 @@ CONFIG_DM_MMC=y
 CONFIG_FSL_ESDHC=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_MICREL=y
configs/mx6ull_14x14_evk_defconfig +0 -1
index 0b7dcd63a944..e4076927c41e 100644
@@ -32,7 +32,6 @@ CONFIG_DM_MMC=y
 CONFIG_FSL_ESDHC=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y
configs/mx6ull_14x14_evk_plugin_defconfig +0 -1
index 6fee83d020d1..aae81e2772c4 100644
@@ -33,7 +33,6 @@ CONFIG_DM_MMC=y
 CONFIG_FSL_ESDHC=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y
configs/mx7dsabresd_qspi_defconfig +0 -1
index 48f4068e8cd0..3ef95851d761 100644
@@ -49,7 +49,6 @@ CONFIG_MMC_HS200_SUPPORT=y
 CONFIG_FSL_ESDHC=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_EON=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_PHYLIB=y
configs/porter_defconfig +0 -1
index d51db3d5cb28..7c54a5463869 100644
@@ -64,7 +64,6 @@ CONFIG_RENESAS_SDHI=y
 CONFIG_MTD=y
 CONFIG_MTD_DEVICE=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_MTD=y
 CONFIG_PHY_MICREL=y
configs/r8a77970_eagle_defconfig +0 -1
index 5af1bdb221f6..d269c62101e3 100644
@@ -43,7 +43,6 @@ CONFIG_SYS_I2C_RCAR_IIC=y
 # CONFIG_MMC is not set
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_PHY_MICREL=y
configs/silk_defconfig +0 -1
index 3350e6903960..3cb4f6e005ae 100644
@@ -66,7 +66,6 @@ CONFIG_RENESAS_SDHI=y
 CONFIG_MTD=y
 CONFIG_MTD_DEVICE=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_MTD=y
 CONFIG_PHY_MICREL=y
configs/socfpga_arria5_defconfig +0 -1
index e7e1121c5c42..02e329a70417 100644
@@ -51,7 +51,6 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_DW=y
 CONFIG_MTD_DEVICE=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
configs/socfpga_cyclone5_defconfig +0 -1
index 8989c4dc96ce..13dc508631e9 100644
@@ -51,7 +51,6 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_DW=y
 CONFIG_MTD_DEVICE=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
configs/socfpga_is1_defconfig +0 -1
index 682e58fdb8b8..cd7211d202ba 100644
@@ -48,7 +48,6 @@ CONFIG_SYS_I2C_DW=y
 # CONFIG_MMC is not set
 CONFIG_MTD_DEVICE=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
configs/socfpga_sockit_defconfig +0 -1
index 66f7733ee86a..c2c3c9eec4ab 100644
@@ -51,7 +51,6 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_DW=y
 CONFIG_MTD_DEVICE=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
configs/socfpga_socrates_defconfig +0 -1
index 05f38cbcd22f..0fc76152a315 100644
@@ -52,7 +52,6 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_DW=y
 CONFIG_MTD_DEVICE=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
configs/socfpga_sr1500_defconfig +0 -1
index 97366cdfff0c..d984047bfe63 100644
@@ -53,7 +53,6 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_DW=y
 CONFIG_MTD_DEVICE=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_STMICRO=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_PHY_MARVELL=y
configs/socfpga_stratix10_defconfig +0 -1
index 5f3d733a8bc2..8550acb9ba2b 100644
@@ -39,7 +39,6 @@ CONFIG_SYS_I2C_DW=y
 CONFIG_DM_MMC=y
 CONFIG_MMC_DW=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
configs/stout_defconfig +0 -1
index acd05564f327..1b1ed8d3acc4 100644
@@ -64,7 +64,6 @@ CONFIG_RENESAS_SDHI=y
 CONFIG_MTD=y
 CONFIG_MTD_DEVICE=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_MTD=y
 CONFIG_PHY_MICREL=y
configs/topic_miami_defconfig +0 -1
index 6bdfd63c8ee0..407c3bdaa3de 100644
@@ -40,7 +40,6 @@ CONFIG_ZYNQ_I2C1=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_STMICRO=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_DEBUG_UART_ZYNQ=y
configs/topic_miamilite_defconfig +0 -1
index 4486975f9503..fe27239c94bf 100644
@@ -40,7 +40,6 @@ CONFIG_ZYNQ_I2C1=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SF_DUAL_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
configs/topic_miamiplus_defconfig +0 -1
index ee83f0545bd5..4b7ff3ae1815 100644
@@ -39,7 +39,6 @@ CONFIG_ZYNQ_I2C1=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SF_DUAL_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
configs/xilinx_versal_virt_defconfig +0 -1
index 668c313a2914..c56b504bef7c 100644
@@ -47,7 +47,6 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_mini_qspi_defconfig +0 -1
index de7bf079551f..e6e024a8098e 100644
@@ -55,7 +55,6 @@ CONFIG_SPL_DM_SEQ_ALIAS=y
 # CONFIG_MMC is not set
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SF_DUAL_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
configs/xilinx_zynqmp_zc1232_revA_defconfig +0 -1
index 7521fc4e34e4..1e8529098f74 100644
@@ -37,7 +37,6 @@ CONFIG_FPGA_ZYNQMPPL=y
 CONFIG_MISC=y
 CONFIG_DM_MMC=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SF_DUAL_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
configs/xilinx_zynqmp_zc1254_revA_defconfig +0 -1
index e0822b931edb..f883f8ecc692 100644
@@ -37,7 +37,6 @@ CONFIG_FPGA_ZYNQMPPL=y
 CONFIG_MISC=y
 CONFIG_DM_MMC=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SF_DUAL_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
configs/xilinx_zynqmp_zc1275_revA_defconfig +0 -1
index 3afed6973709..2aa71b3fbc1c 100644
@@ -37,7 +37,6 @@ CONFIG_FPGA_ZYNQMPPL=y
 CONFIG_MISC=y
 CONFIG_DM_MMC=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SF_DUAL_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
configs/xilinx_zynqmp_zc1275_revB_defconfig +0 -1
index 7e31b1112f8f..debb23739bfd 100644
@@ -40,7 +40,6 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SF_DUAL_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig +0 -1
index ec26dd70fd57..536cfc98f115 100644
@@ -61,7 +61,6 @@ CONFIG_MMC_HS200_SUPPORT=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig +0 -1
index c2b3d189ec4d..213f4c9cbfe4 100644
@@ -58,7 +58,6 @@ CONFIG_MTD_DEVICE=y
 CONFIG_NAND=y
 CONFIG_NAND_ARASAN=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SST=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_NATSEMI=y
configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig +0 -1
index a0bbc0fbde8b..6e31550e601c 100644
@@ -47,7 +47,6 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zcu100_revC_defconfig +0 -1
index 429bfd4fd3dd..23d2ca58c1b7 100644
@@ -60,7 +60,6 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zcu102_rev1_0_defconfig +0 -1
index e41366ecf7d0..4a7ad87f4093 100644
@@ -75,7 +75,6 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zcu102_revA_defconfig +0 -1
index 41a03371d514..aa2adbd19313 100644
@@ -72,7 +72,6 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zcu102_revB_defconfig +0 -1
index 78deb6a967f2..17903a1e29d2 100644
@@ -72,7 +72,6 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zcu104_revA_defconfig +0 -1
index ff57ca8674e6..4a24d5d9cfe0 100644
@@ -57,7 +57,6 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SF_DUAL_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
configs/xilinx_zynqmp_zcu104_revC_defconfig +0 -1
index 0357b1744545..a3f4c7f36614 100644
@@ -58,7 +58,6 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SF_DUAL_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
configs/xilinx_zynqmp_zcu106_revA_defconfig +0 -1
index 210c9a347fb2..157bbce7fd2b 100644
@@ -66,7 +66,6 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SF_DUAL_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
configs/xilinx_zynqmp_zcu111_revA_defconfig +0 -1
index 8bace6d80883..f5dcceb6ae30 100644
@@ -60,7 +60,6 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
configs/zynq_cc108_defconfig +0 -1
index c06e546e0a2c..48bd2523e25f 100644
@@ -34,7 +34,6 @@ CONFIG_DM_GPIO=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_ISSI=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
configs/zynq_cse_qspi_defconfig +0 -1
index 2aee069bb188..d78a842e6a79 100644
@@ -57,7 +57,6 @@ CONFIG_DEFAULT_DEVICE_TREE="zynq-cse-qspi-single"
 CONFIG_SPL_DM_SEQ_ALIAS=y
 # CONFIG_MMC is not set
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_ISSI=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
configs/zynq_dlc20_rev1_0_defconfig +0 -1
index 4b9fdfe186c8..1acfad8486ac 100644
@@ -50,7 +50,6 @@ CONFIG_ZYNQ_I2C0=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_PHY_REALTEK=y
configs/zynq_microzed_defconfig +0 -1
index 29b8594d8bc1..d705be077e36 100644
@@ -40,7 +40,6 @@ CONFIG_DM_GPIO=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
configs/zynq_minized_defconfig +0 -1
index 8597c41ca03c..cdf31330a29d 100644
@@ -41,7 +41,6 @@ CONFIG_DM_GPIO=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
configs/zynq_z_turn_defconfig +0 -1
index e40afaacf865..830c9ef067b0 100644
@@ -40,7 +40,6 @@ CONFIG_LED_GPIO=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
configs/zynq_zc702_defconfig +0 -1
index 27e6bd1e0e8b..1ae867d72503 100644
@@ -52,7 +52,6 @@ CONFIG_LED_GPIO=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_ISSI=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
configs/zynq_zc706_defconfig +0 -1
index bcbfa65e41b1..5ac94326f718 100644
@@ -52,7 +52,6 @@ CONFIG_ZYNQ_I2C0=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_ISSI=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
configs/zynq_zc770_xm010_defconfig +0 -1
index fed1502d1b6b..22d5b847668c 100644
@@ -41,7 +41,6 @@ CONFIG_DM_GPIO=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_ISSI=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
configs/zynq_zc770_xm013_defconfig +0 -1
index a08bd2993385..dcadaf21316b 100644
@@ -35,7 +35,6 @@ CONFIG_FPGA_ZYNQPL=y
 CONFIG_DM_GPIO=y
 # CONFIG_MMC is not set
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_ISSI=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
configs/zynq_zed_defconfig +0 -1
index c583c5c83b92..eaaf0a09b912 100644
@@ -43,7 +43,6 @@ CONFIG_DM_GPIO=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
configs/zynq_zybo_defconfig +0 -1
index 82931713a2ce..300cf05456a6 100644
@@ -50,7 +50,6 @@ CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET=0xFA
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_REALTEK=y
configs/zynq_zybo_z7_defconfig +0 -1
index 190759fe8b0e..3670b1998dc7 100644
@@ -47,7 +47,6 @@ CONFIG_ZYNQ_I2C1=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_REALTEK=y
 CONFIG_MII=y
doc/SPI/README.ti_qspi_dra_test +0 -1
index fe378572369b..e89f53587fa7 100644
@@ -22,7 +22,6 @@ Commands to erase/write u-boot/mlo to flash device
 --------------------------------------------------
 U-Boot# sf probe 0
 SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB, mapped at 5c000000
-SF: Warning - Only lower 16MiB accessible, Full access #define CONFIG_SPI_FLASH_BAR
 U-Boot# sf erase 0 0x10000
 SF: 65536 bytes @ 0x0 Erased: OK
 U-Boot# sf erase 0x20000 0x10000
drivers/mtd/spi/Kconfig +0 -7
index 8bd6db6ff4d3..6afaaa8731cb 100644
@@ -45,13 +45,6 @@ config SPI_FLASH_SFDP_SUPPORT
 	 SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP)
 	 tables as per JESD216 standard.
 
-config SPI_FLASH_BAR
-	bool "SPI flash Bank/Extended address register support"
-	help
-	  Enable the SPI flash Bank/Extended address register support.
-	  Bank/Extended address registers are used to access the flash
-	  which has size > 16MiB in 3-byte addressing.
-
 config SF_DUAL_FLASH
 	bool "SPI DUAL flash memory support"
 	help
include/configs/T102xQDS.h +0 -1
index f3b0fe0144ff..c63dfd318680 100644
@@ -501,7 +501,6 @@ unsigned long get_board_ddr_clk(void);
 /*
  * eSPI - Enhanced SPI
  */
-#define CONFIG_SPI_FLASH_BAR
 #define CONFIG_SF_DEFAULT_SPEED	 10000000
 #define CONFIG_SF_DEFAULT_MODE	  0
 
include/configs/T102xRDB.h +0 -1
index 673d1112e22a..c72be9fb387a 100644
@@ -498,7 +498,6 @@ unsigned long get_board_ddr_clk(void);
 /*
  * eSPI - Enhanced SPI
  */
-#define CONFIG_SPI_FLASH_BAR
 #define CONFIG_SF_DEFAULT_SPEED	10000000
 #define CONFIG_SF_DEFAULT_MODE	0
 
include/configs/T104xRDB.h +0 -1
index 7375d6ff4607..4cecab3401e9 100644
@@ -521,7 +521,6 @@ $(SRCTREE)/board/freescale/t104xrdb/t1042d4_sd_rcw.cfg
 /*
  * eSPI - Enhanced SPI
  */
-#define CONFIG_SPI_FLASH_BAR
 #define CONFIG_SF_DEFAULT_SPEED         10000000
 #define CONFIG_SF_DEFAULT_MODE          0
 #define CONFIG_ENV_SPI_BUS              0
include/configs/T208xQDS.h +0 -1
index 1dcf2779d755..69ec109831a0 100644
@@ -497,7 +497,6 @@ unsigned long get_board_ddr_clk(void);
  */
 #ifdef CONFIG_SPI_FLASH
 
-#define CONFIG_SPI_FLASH_BAR
 #define CONFIG_SF_DEFAULT_SPEED	 10000000
 #define CONFIG_SF_DEFAULT_MODE	  0
 #endif
include/configs/T208xRDB.h +0 -1
index ddb60b3d6d94..1d6a390b72df 100644
@@ -437,7 +437,6 @@ unsigned long get_board_ddr_clk(void);
  * eSPI - Enhanced SPI
  */
 #ifdef CONFIG_SPI_FLASH
-#define CONFIG_SPI_FLASH_BAR
 #define CONFIG_SF_DEFAULT_SPEED	 10000000
 #define CONFIG_SF_DEFAULT_MODE	  0
 #endif
include/configs/gw_ventana.h +0 -1
index 6cafdc66859b..6e23fa29b33b 100644
@@ -52,7 +52,6 @@
 /* SPI */
 #ifdef CONFIG_CMD_SF
   #define CONFIG_SPI_FLASH_MTD
-  #define CONFIG_SPI_FLASH_BAR
   #define CONFIG_SF_DEFAULT_BUS              0
   #define CONFIG_SF_DEFAULT_CS               0
 					     /* GPIO 3-19 (21248) */
include/configs/km/kmp204x-common.h +0 -1
index a8f7300c1eb2..c762c93ac0aa 100644
@@ -253,7 +253,6 @@ int get_scl(void);
 /*
  * eSPI - Enhanced SPI
  */
-#define CONFIG_SPI_FLASH_BAR	/* 4 byte-addressing */
 #define CONFIG_SF_DEFAULT_SPEED         20000000
 #define CONFIG_SF_DEFAULT_MODE          0
 
include/configs/ls1021aiot.h +0 -1
index 10dc0c68435b..6be8df109bd6 100644
@@ -135,7 +135,6 @@
 #define QSPI0_AMBA_BASE			0x40000000
 #define FSL_QSPI_FLASH_SIZE		(1 << 24)
 #define FSL_QSPI_FLASH_NUM		2
-#define CONFIG_SPI_FLASH_BAR
 #define CONFIG_SPI_FLASH_SPANSION
 #endif
 
Signature · 1 line
2.19.2
#43 lore raw

PATCH 10/16 configs: Get rid of SPI_FLASH_BAR

Quoted 3 lines · Vignesh R

Now that we have new SPI NOR framework in place that supports 4 byte addressing mode by default, get rid of CONFIG_SPI_FLASH_BAR

I already mentioned in previous mail, BAR is not exact replacement for 4-byte. Some controllers do handle > 16MB flashes even-though controller support 3-byte addressing. we have these board since from 2014.

Better to make changes in accordance with that.

#44 lore raw

PATCH 10/16 configs: Get rid of SPI_FLASH_BAR

Quoted 9 lines · On Thu, 13 Dec 2018 02:11:48 +0530 Jagan Teki <[email protected]>…
Quoted 3 lines · Vignesh R

Now that we have new SPI NOR framework in place that supports 4 byte addressing mode by default, get rid of CONFIG_SPI_FLASH_BAR

I already mentioned in previous mail, BAR is not exact replacement for 4-byte. Some controllers do handle > 16MB flashes even-though controller support 3-byte addressing. we have these board since from 2014.

That's something you should be able to detect with spi_mem_supports_op(). If the controller does not support sending 4 byte addresses, it should return -ENOTSUPP and the framework should fallback to BAR setting (if the NOR supports it). Do we really need a config option for that?

#45 lore raw

PATCH 10/16 configs: Get rid of SPI_FLASH_BAR

In reply to Jagan Teki

Am Mi., 12. Dez. 2018, 21:42 hat Jagan Teki <[email protected]> geschrieben:

Quoted 11 lines · Vignesh R
Quoted 3 lines

Now that we have new SPI NOR framework in place that supports 4 byte addressing mode by default, get rid of CONFIG_SPI_FLASH_BAR

I already mentioned in previous mail, BAR is not exact replacement for 4-byte. Some controllers do handle > 16MB flashes even-though controller support 3-byte addressing. we have these board since from 2014.

Better to make changes in accordance with that.

While BAR is one possibility to address > 16 MiB, I think it's about the worst solution. So it's ok for boards that support no other methods, but how do we ensure it's only used for those and not the default?

Regards,
Simon

author maintainer
#46 lore raw

PATCH 10/16 configs: Get rid of SPI_FLASH_BAR

In reply to Jagan Teki
Quoted 5 lines · Jagan Teki
Quoted 3 lines · Vignesh R

Now that we have new SPI NOR framework in place that supports 4 byte addressing mode by default, get rid of CONFIG_SPI_FLASH_BAR

Quoted 7 lines

I already mentioned in previous mail, BAR is not exact replacement for 4-byte. Some controllers do handle > 16MB flashes even-though controller support 3-byte addressing. we have these board since from 2014.

Better to make changes in accordance with that.

Hmm, could you point to such SPI controller drivers?
I can work on adding a fallback and enable FLASH_BAR support only for such SoC/Board. We dont want to enable this support for all.

Signature · 2 lines
Regards
Vignesh
author maintainer
#47 lore raw

PATCH 11/16 configs: Remove SF_DUAL_FLASH

In reply to Vignesh R

SF_DUAL_FLASH claims to enable support for SF_DUAL_STACKED_FLASH and SF_DUAL_PARALLEL_FLASH. But, in current U-Boot code, grepping for above enums yield no user and therefore support seems to be incomplete. Remove these configs so as to avoid confusion.

---
 configs/topic_miamilite_defconfig           |  1 -
 configs/topic_miamiplus_defconfig           |  1 -
 configs/xilinx_zynqmp_mini_qspi_defconfig   |  1 -
 configs/xilinx_zynqmp_zc1232_revA_defconfig |  1 -
 configs/xilinx_zynqmp_zc1254_revA_defconfig |  1 -
 configs/xilinx_zynqmp_zc1275_revA_defconfig |  1 -
 configs/xilinx_zynqmp_zc1275_revB_defconfig |  1 -
 configs/xilinx_zynqmp_zcu104_revA_defconfig |  1 -
 configs/xilinx_zynqmp_zcu104_revC_defconfig |  1 -
 configs/xilinx_zynqmp_zcu106_revA_defconfig |  1 -
 doc/SPI/README.dual-flash                   | 92 ---------------------
 drivers/mtd/spi/Kconfig                     |  6 --
 include/configs/socfpga_stratix10_socdk.h   |  1 -
 13 files changed, 109 deletions(-)
 delete mode 100644 doc/SPI/README.dual-flash
configs/topic_miamilite_defconfig +0 -1
index fe27239c94bf..8e912d8586d2 100644
@@ -40,7 +40,6 @@ CONFIG_ZYNQ_I2C1=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SF_DUAL_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_DEBUG_UART_ZYNQ=y
configs/topic_miamiplus_defconfig +0 -1
index 4b7ff3ae1815..371b2ad91571 100644
@@ -39,7 +39,6 @@ CONFIG_ZYNQ_I2C1=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SF_DUAL_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 # CONFIG_NETDEVICES is not set
configs/xilinx_zynqmp_mini_qspi_defconfig +0 -1
index e6e024a8098e..9f2a2f59f6ea 100644
@@ -55,7 +55,6 @@ CONFIG_SPL_DM_SEQ_ALIAS=y
 # CONFIG_MMC is not set
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
-CONFIG_SF_DUAL_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zc1232_revA_defconfig +0 -1
index 1e8529098f74..06247a0628fb 100644
@@ -37,7 +37,6 @@ CONFIG_FPGA_ZYNQMPPL=y
 CONFIG_MISC=y
 CONFIG_DM_MMC=y
 CONFIG_SPI_FLASH=y
-CONFIG_SF_DUAL_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zc1254_revA_defconfig +0 -1
index f883f8ecc692..5bc1aaba696b 100644
@@ -37,7 +37,6 @@ CONFIG_FPGA_ZYNQMPPL=y
 CONFIG_MISC=y
 CONFIG_DM_MMC=y
 CONFIG_SPI_FLASH=y
-CONFIG_SF_DUAL_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zc1275_revA_defconfig +0 -1
index 2aa71b3fbc1c..d0b0a19caf93 100644
@@ -37,7 +37,6 @@ CONFIG_FPGA_ZYNQMPPL=y
 CONFIG_MISC=y
 CONFIG_DM_MMC=y
 CONFIG_SPI_FLASH=y
-CONFIG_SF_DUAL_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zc1275_revB_defconfig +0 -1
index debb23739bfd..6bc3b6af9a67 100644
@@ -40,7 +40,6 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SF_DUAL_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zcu104_revA_defconfig +0 -1
index 4a24d5d9cfe0..28e18ae1252e 100644
@@ -57,7 +57,6 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SF_DUAL_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zcu104_revC_defconfig +0 -1
index a3f4c7f36614..3ddd63181603 100644
@@ -58,7 +58,6 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SF_DUAL_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
configs/xilinx_zynqmp_zcu106_revA_defconfig +0 -1
index 157bbce7fd2b..a6da8976317c 100644
@@ -66,7 +66,6 @@ CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
 CONFIG_SPI_FLASH=y
-CONFIG_SF_DUAL_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
doc/SPI/README.dual-flash deleted +0 -92

92 lines not on this page · raw message

drivers/mtd/spi/Kconfig +0 -6
index 6afaaa8731cb..b552704ee285 100644
@@ -45,12 +45,6 @@ config SPI_FLASH_SFDP_SUPPORT
 	 SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP)
 	 tables as per JESD216 standard.
 
-config SF_DUAL_FLASH
-	bool "SPI DUAL flash memory support"
-	help
-	  Enable this option to support two flash memories connected to a single
-	  controller. Currently Xilinx Zynq qspi supports this.
-
 config SPI_FLASH_ATMEL
 	bool "Atmel SPI flash support"
 	help
include/configs/socfpga_stratix10_socdk.h +0 -1
index e190b3d9889d..0b705e6adb80 100644
@@ -57,7 +57,6 @@
  */
  #ifdef CONFIG_CADENCE_QSPI
 /* Enable it if you want to use dual-stacked mode */
-#undef CONFIG_SF_DUAL_FLASH
 /*#define CONFIG_QSPI_RBF_ADDR		0x720000*/
 
 /* Flash device info */
Signature · 1 line
2.19.2
#48 lore raw

PATCH 11/16 configs: Remove SF_DUAL_FLASH

Quoted 7 lines · Vignesh R

SF_DUAL_FLASH claims to enable support for SF_DUAL_STACKED_FLASH and SF_DUAL_PARALLEL_FLASH. But, in current U-Boot code, grepping for above enums yield no user and therefore support seems to be incomplete. Remove these configs so as to avoid confusion.

Quoted 16 lines
---
 configs/topic_miamilite_defconfig           |  1 -
 configs/topic_miamiplus_defconfig           |  1 -
 configs/xilinx_zynqmp_mini_qspi_defconfig   |  1 -
 configs/xilinx_zynqmp_zc1232_revA_defconfig |  1 -
 configs/xilinx_zynqmp_zc1254_revA_defconfig |  1 -
 configs/xilinx_zynqmp_zc1275_revA_defconfig |  1 -
 configs/xilinx_zynqmp_zc1275_revB_defconfig |  1 -
 configs/xilinx_zynqmp_zcu104_revA_defconfig |  1 -
 configs/xilinx_zynqmp_zcu104_revC_defconfig |  1 -
 configs/xilinx_zynqmp_zcu106_revA_defconfig |  1 -
 doc/SPI/README.dual-flash                   | 92 ---------------------
 drivers/mtd/spi/Kconfig                     |  6 --
 include/configs/socfpga_stratix10_socdk.h   |  1 -
 13 files changed, 109 deletions(-)
 delete mode 100644 doc/SPI/README.dual-flash

dual flash has used boards, even though spi driver can't enable it. I asked Siva, and(Michal) about the updates. we have some drivers and code in tree even-thought the relevant users out-of tree.

Siva., Michal any inputs?

author maintainer
#49 lore raw

PATCH 12/16 axm_defconfig: Enable simple malloc in SPL

In reply to Vignesh R

Enable CONFIG_SPL_SYS_MALLOC_SIMPLE in SPL to reduce SPL size

---
 configs/axm_defconfig | 1 +
 1 file changed, 1 insertion(+)
configs/axm_defconfig +1 -0
index 89d6b6f2012c..16c093b37b83 100644
@@ -44,3 +44,4 @@ CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PHYLIB=y
 CONFIG_USE_TINY_PRINTF=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
Signature · 1 line
2.19.2
author maintainer
#50 lore raw

PATCH 13/16 taurus_defconfig: Enable simple malloc in SPL

In reply to Vignesh R

Enable SPL simple malloc to reduce SPL size

---
 configs/taurus_defconfig | 1 +
 1 file changed, 1 insertion(+)
configs/taurus_defconfig +1 -0
index e53e075d4825..9c3a1276aa8f 100644
@@ -64,3 +64,4 @@ CONFIG_USE_TINY_PRINTF=y
 CONFIG_WDT=y
 CONFIG_WDT_AT91=y
 CONFIG_AT91_HW_WDT_TIMEOUT=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
Signature · 1 line
2.19.2
author maintainer
#51 lore raw

PATCH 14/16 da850_am18xxevm: Enable tiny printf

In reply to Vignesh R

Enable tiny printf to reduce SPL size

---
 configs/da850_am18xxevm_defconfig | 1 +
 1 file changed, 1 insertion(+)
configs/da850_am18xxevm_defconfig +1 -0
index 58745fec8267..5fecfccba50c 100644
@@ -57,3 +57,4 @@ CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_DAVINCI_SPI=y
 # CONFIG_FAT_WRITE is not set
+CONFIG_USE_TINY_PRINTF=y
Signature · 1 line
2.19.2
author maintainer
#52 lore raw

PATCH 15/16 turris_omnia_defconfig: Enable tiny printf

In reply to Vignesh R

Enable tiny printf to reduce SPL size

---
 configs/turris_omnia_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
configs/turris_omnia_defconfig +1 -1
index 38c5de18bb2d..4655d6561a13 100644
@@ -52,6 +52,6 @@ CONFIG_KIRKWOOD_SPI=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_STORAGE=y
 CONFIG_WDT=y
 CONFIG_WDT_ORION=y
+CONFIG_USE_TINY_PRINTF=y
Signature · 1 line
2.19.2
author maintainer
#53 lore raw

PATCH 16/16 MAINTAINERS: Add an entry for SPI NOR

In reply to Vignesh R

Add myself as co-maintainer for U-Boot SPI NOR subsystem

---
Jagan,

If you agree, I can help in co-maintaining SPI NOR part especially for the code that is added/sync'd from Linux.

 MAINTAINERS | 8 ++++++++
 1 file changed, 8 insertions(+)
MAINTAINERS +8 -0
index 0cec39c542db..d09e0a478f52 100644
@@ -634,6 +634,14 @@ F:	drivers/mtd/spi/
 F:	drivers/spi/
 F:	include/spi*
 
+SPI-NOR
+M:	Vignesh R <[email protected]>
+S:	Maintained
+F:	drivers/mtd/spi/
+F:	include/spi_flash.h
+F:	include/linux/mtd/cfi.h
+F:	include/linux/mtd/spi-nor.h
+
 SPMI
 M:	Mateusz Kulikowski <[email protected]>
 S:	Maintained
Signature · 1 line
2.19.2
#54 lore raw

PATCH 16/16 MAINTAINERS: Add an entry for SPI NOR

Quoted 9 lines · Vignesh R

Add myself as co-maintainer for U-Boot SPI NOR subsystem

---
Jagan,

If you agree, I can help in co-maintaining SPI NOR part especially for the code that is added/sync'd from Linux.

Thanks for the help and support.

MAINTAINERS F: drivers/mtd/spi/ · line 637

Quoted 13 lines
 MAINTAINERS | 8 ++++++++
 1 file changed, 8 insertions(+)
MAINTAINERS +1 -0
index 0cec39c542db..d09e0a478f52 100644
@@ -634,6 +634,14 @@ F: drivers/mtd/spi/
 F:     drivers/spi/
 F:     include/spi*
 
+SPI-NOR

You missed my name :)

Quoted 6 lines
MAINTAINERS +6 -0
+M:     Vignesh R <[email protected]>
+S:     Maintained
+F:     drivers/mtd/spi/
+F:     include/spi_flash.h
+F:     include/linux/mtd/cfi.h
+F:     include/linux/mtd/spi-nor.h
author maintainer
#55 lore raw

PATCH 16/16 MAINTAINERS: Add an entry for SPI NOR

Quoted 26 lines · Jagan Teki
Quoted 9 lines · On Wed, Dec 12, 2018 at 11:19 PM Vignesh R <[email protected]…

Add myself as co-maintainer for U-Boot SPI NOR subsystem

Signed-off-by Vignesh R <vigneshr at ti.com <mailto:[email protected]>>

---
Jagan,

If you agree, I can help in co-maintaining SPI NOR part especially for the code that is added/sync'd from Linux.

Thanks for the help and support.

Quoted 12 lines

  MAINTAINERS | 8 ++++++++

  1 file changed, 8 insertions(+)
MAINTAINERS +0 -0
index 0cec39c542db..d09e0a478f52 100644
@@ -634,6 +634,14 @@ F: drivers/mtd/spi/

  F:     drivers/spi/
  F:     include/spi*

Quoted 4 lines
Quoted 1 line

+SPI-NOR

You missed my name :)

Sorry, I thought regex under SPI entry would cover all. Anyways, will add your name here as well.

Quoted 6 lines
Quoted 6 lines
MAINTAINERS +6 -0
+M:     Vignesh R <vigneshr at ti.com <mailto:[email protected]>>
+S:     Maintained
+F:     drivers/mtd/spi/
+F:     include/spi_flash.h
+F:     include/linux/mtd/cfi.h
+F:     include/linux/mtd/spi-nor.h
Signature · 2 lines
Regards
Vignesh
#56 lore raw

cover SF: Migrate to Linux SPI NOR framework

In reply to Vignesh R
Quoted 19 lines · Vignesh R

U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
This patch series syncs SPI NOR framework from Linux v4.19. It also adds spi-mem support on top.
So, we gain 4byte addressing support and SFDP support. This makes migrating to U-Boot MTD framework easier.

Tested with few Spansion, micron and macronix flashes with TI's dra7xx, k2g, am43xx EVMs. I dont have access to flashes from other vendors. So, I would greatly appreciate testing on other platforms. Complete series with dependencies here[1]

Quoted 7 lines

For clean build on some platforms, depends on CONFIG_SPI_FLASH migration to defconfigs [2]

[1] https://github.com/r-vignesh/u-boot.git branch: spi-nor-mig-patch-v1
[2] https://patchwork.ozlabs.org/patch/1007485/

Patch 12-15 are compile tested.

Fist of all thanks for your time and work on this.

Since most of the discussion on the individual patches seems similar, repeat and never ended. I'm trying to summarize my comments here.
1) You can sync or add new features by grabbing the code from Linux, but I don't recommend __UBOOT macro or any Linux specific stuff in drivers/mtd/spi
2) For BAR support, lets place it as it is and support via spi-nor
3) For dual flash, wait for Xilinx developers if they really want to support it?
4) For non-dm code in spi-mem, no comments? (Tom is already commented, may be Simon can comment)

Jagan.

author maintainer
#57 lore raw

cover SF: Migrate to Linux SPI NOR framework

Quoted 28 lines · Jagan Teki
Quoted 19 lines · Vignesh R

U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
This patch series syncs SPI NOR framework from Linux v4.19. It also adds spi-mem support on top.
So, we gain 4byte addressing support and SFDP support. This makes migrating to U-Boot MTD framework easier.

Tested with few Spansion, micron and macronix flashes with TI's dra7xx, k2g, am43xx EVMs. I dont have access to flashes from other vendors. So, I would greatly appreciate testing on other platforms. Complete series with dependencies here[1]

Quoted 7 lines

For clean build on some platforms, depends on CONFIG_SPI_FLASH migration to defconfigs [2]

[1] https://github.com/r-vignesh/u-boot.git branch: spi-nor-mig-patch-v1
[2] https://patchwork.ozlabs.org/patch/1007485/

Patch 12-15 are compile tested.

Quoted 7 lines

Fist of all thanks for your time and work on this.

Since most of the discussion on the individual patches seems similar, repeat and never ended. I'm trying to summarize my comments here.
1) You can sync or add new features by grabbing the code from Linux, but I don't recommend __UBOOT macro or any Linux specific stuff in drivers/mtd/spi

I am fine either way.

Quoted 1 line

2) For BAR support, lets place it as it is and support via spi-nor

Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems like 4 byte addressing (stateless dedicated opcode or with enter/exit 4 byte mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintaining when it may not be needed.

But if you insist, I just have to add BAR support back.

Quoted 1 line

3) For dual flash, wait for Xilinx developers if they really want to support it?

Sorry, this feature was never supported properly *in mainline U-Boot*. If support is needed in the future, we can accept patches on top of new framework.

Quoted 3 lines

4) For non-dm code in spi-mem, no comments? (Tom is already commented, may be Simon can comment)

Signature · 2 lines
Regards
Vignesh
#58 lore raw

cover SF: Migrate to Linux SPI NOR framework

Am Fr., 14. Dez. 2018, 16:59 hat Vignesh R <[email protected]> geschrieben:

Quoted 51 lines · Jagan Teki
Quoted 4 lines · Vignesh R
Quoted 3 lines

U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different

types of

Quoted 16 lines
Quoted 16 lines

quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
This patch series syncs SPI NOR framework from Linux v4.19. It also adds spi-mem support on top.
So, we gain 4byte addressing support and SFDP support. This makes migrating to U-Boot MTD framework easier.

Tested with few Spansion, micron and macronix flashes with TI's dra7xx, k2g, am43xx EVMs. I dont have access to flashes from other vendors. So, I would greatly appreciate testing on other platforms. Complete series with dependencies here[1]

Quoted 4 lines
Quoted 4 lines

For clean build on some platforms, depends on CONFIG_SPI_FLASH migration to defconfigs [2]

[1] https://github.com/r-vignesh/u-boot.git branch:

spi-nor-mig-patch-v1

Quoted 11 lines
Quoted 3 lines

[2] https://patchwork.ozlabs.org/patch/1007485/

Patch 12-15 are compile tested.

Fist of all thanks for your time and work on this.

Since most of the discussion on the individual patches seems similar, repeat and never ended. I'm trying to summarize my comments here.
1) You can sync or add new features by grabbing the code from Linux, but I don't recommend __UBOOT macro or any Linux specific stuff in drivers/mtd/spi

I am fine either way.

Quoted 1 line

2) For BAR support, lets place it as it is and support via spi-nor

Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems like 4 byte addressing (stateless dedicated opcode or with enter/exit 4 byte mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintaining when it may not be needed.

Quoted 2 lines

But if you insist, I just have to add BAR support back.

But if we do that, could we please have a config option so that I can somehow ensure only 4 byte opcoses are used that don't change some state in the chip?

BTW, should I re-read this series or is it equal to the RFC I tested?

Simon

Quoted 20 lines
Quoted 1 line

3) For dual flash, wait for Xilinx developers if they really want to

support it?

Sorry, this feature was never supported properly *in mainline U-Boot*. If support is needed in the future, we can accept patches on top of new framework.

Quoted 3 lines

4) For non-dm code in spi-mem, no comments? (Tom is already commented, may be Simon can comment)

--
Regards
Vignesh
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot

author maintainer
#59 lore raw

cover SF: Migrate to Linux SPI NOR framework

Quoted 64 lines · Simon Goldschmidt

Am Fr., 14. Dez. 2018, 16:59 hat Vignesh R <[email protected] <mailto:[email protected]>> geschrieben:

On 14/12/18 3:43 PM, Jagan Teki wrote:
> On Wed, Dec 12, 2018 at 11:02 PM Vignesh R <[email protected] <mailto:[email protected]>> wrote:
>>
>> U-Boot SPI NOR support (sf layer) is quite outdated as it does not >> support 4 byte addressing opcodes, SFDP table parsing and different types of
>> quad mode enable sequences. Many newer flashes no longer support BANK >> registers used by sf layer to a access >16MB space.
>> Also, many SPI controllers have special MMIO interfaces which provide >> accelerated read/write access but require knowledge of flash parameters
>> to make use of it. Recent spi-mem layer provides a way to support such
>> flashes but sf layer isn't using that.
>> This patch series syncs SPI NOR framework from Linux v4.19. It also adds
>> spi-mem support on top.
>> So, we gain 4byte addressing support and SFDP support. This makes >> migrating to U-Boot MTD framework easier.
>>
>> Tested with few Spansion, micron and macronix flashes with TI's dra7xx,
>> k2g, am43xx EVMs. I dont have access to flashes from other vendors. So,
>> I would greatly appreciate testing on other platforms. Complete series
>> with dependencies here[1]
>>
>> For clean build on some platforms, depends on CONFIG_SPI_FLASH migration
>> to defconfigs [2]
>>
>> [1] https://github.com/r-vignesh/u-boot.git  branch:
spi-nor-mig-patch-v1
>> [2] https://patchwork.ozlabs.org/patch/1007485/
>>
>> Patch 12-15 are compile tested.
>
> Fist of all thanks for your time and work on this.
>
> Since most of the discussion on the individual patches seems similar, > repeat and never ended. I'm trying to summarize my comments here. > 1) You can sync or add new features by grabbing the code from Linux, > but I don't recommend __UBOOT macro or any Linux specific stuff  in > drivers/mtd/spi

I am fine either way.

> 2) For BAR support, lets place it as it is and support via spi-nor

Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems like 4 byte addressing (stateless dedicated opcode or with enter/exit 4 byte mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintaining when it may not be needed.

Quoted 7 lines

But if you insist, I just have to add BAR support back.

But if we do that, could we please have a config option so that I can somehow ensure only 4 byte opcoses are used that don't change some state in the chip?

I am afraid BAR support would be the default as Jagan suggests not to change existing behavior. You would have to disable SPI_FLASH_BAR to use 4 Byte addressing opcodes.

Quoted 2 lines

BTW, should I re-read this series or is it equal to the RFC I tested?

Nope, its same as that branch you gave Tested-by to(sorry forgot to carry the tag here). But I may have to do one more revision if above change is needed.

Regards
Vignesh

Quoted 23 lines

Simon

Quoted 1 line

3) For dual flash, wait for Xilinx developers if they really want

to support it?

Sorry, this feature was never supported properly *in mainline U-Boot*. If support is needed in the future, we can accept patches on top of new framework.

> 4) For non-dm code in spi-mem, no comments? (Tom is already commented, > may be Simon can comment)
>

--
Regards
Vignesh
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de <mailto:[email protected]>
https://lists.denx.de/listinfo/u-boot

#60 lore raw

cover SF: Migrate to Linux SPI NOR framework

Am Fr., 14. Dez. 2018, 17:28 hat Vignesh R <[email protected]> geschrieben:

Quoted 76 lines · Simon Goldschmidt
Quoted 5 lines

Am Fr., 14. Dez. 2018, 16:59 hat Vignesh R <[email protected] <mailto:[email protected]>> geschrieben:

Quoted 8 lines

On 14/12/18 3:43 PM, Jagan Teki wrote:
> On Wed, Dec 12, 2018 at 11:02 PM Vignesh R <[email protected] <mailto:[email protected]>> wrote:
>>
>> U-Boot SPI NOR support (sf layer) is quite outdated as it does not >> support 4 byte addressing opcodes, SFDP table parsing and different types of
>> quad mode enable sequences. Many newer flashes no longer support

BANK

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

registers used by sf layer to a access >16MB space. Also, many SPI controllers have special MMIO interfaces which

provide

Quoted 27 lines
Quoted 1 line
Quoted 1 line

accelerated read/write access but require knowledge of flash

parameters
>> to make use of it. Recent spi-mem layer provides a way to support such
>> flashes but sf layer isn't using that.
>> This patch series syncs SPI NOR framework from Linux v4.19. It also adds
>> spi-mem support on top.
>> So, we gain 4byte addressing support and SFDP support. This makes >> migrating to U-Boot MTD framework easier.
>>
>> Tested with few Spansion, micron and macronix flashes with TI's dra7xx,
>> k2g, am43xx EVMs. I dont have access to flashes from other vendors. So,
>> I would greatly appreciate testing on other platforms. Complete series
>> with dependencies here[1]
>>
>> For clean build on some platforms, depends on CONFIG_SPI_FLASH migration
>> to defconfigs [2]
>>
>> [1] https://github.com/r-vignesh/u-boot.git branch:
spi-nor-mig-patch-v1
>> [2] https://patchwork.ozlabs.org/patch/1007485/
>>

Quoted 5 lines

>> Patch 12-15 are compile tested.
>
> Fist of all thanks for your time and work on this. >
> Since most of the discussion on the individual patches seems

similar,

Quoted 2 lines
Quoted 2 lines

repeat and never ended. I'm trying to summarize my comments here.
1) You can sync or add new features by grabbing the code from

Linux,

Quoted 9 lines
Quoted 2 lines

but I don't recommend __UBOOT macro or any Linux specific stuff in drivers/mtd/spi

I am fine either way.

> 2) For BAR support, lets place it as it is and support via spi-nor

Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems

like 4

Quoted 4 lines

byte addressing (stateless dedicated opcode or with enter/exit 4 byte mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintaining

when

Quoted 5 lines

it may not be needed.

But if you insist, I just have to add BAR support back.

Quoted 9 lines
Quoted 4 lines

But if we do that, could we please have a config option so that I can somehow ensure only 4 byte opcoses are used that don't change some state in the chip?

I am afraid BAR support would be the default as Jagan suggests not to change existing behavior. You would have to disable SPI_FLASH_BAR to use 4 Byte addressing opcodes.

Honestly, I don't like the idea of making BAR the default. Why can't we go the Linux way and enable BAR (maybe then as default) for boards that need it only?

Quoted 7 lines
Quoted 2 lines

BTW, should I re-read this series or is it equal to the RFC I tested?

Nope, its same as that branch you gave Tested-by to(sorry forgot to carry the tag here). But I may have to do one more revision if above change is needed.

Ok, thanks.

Regards,
Simon

Quoted 30 lines

Regards
Vignesh

Quoted 7 lines

Simon

Quoted 1 line

3) For dual flash, wait for Xilinx developers if they really want

to support it?

Sorry, this feature was never supported properly *in mainline

U-Boot*.

Quoted 1 line

If support is needed in the future, we can accept patches on top of

new

Quoted 3 lines

framework.

> 4) For non-dm code in spi-mem, no comments? (Tom is already

commented,

Quoted 12 lines
Quoted 2 lines

may be Simon can comment)

--
Regards
Vignesh
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de <mailto:[email protected]>
https://lists.denx.de/listinfo/u-boot

author maintainer
#61 lore raw

cover SF: Migrate to Linux SPI NOR framework

Quoted 25 lines
Quoted 2 lines

     > 2) For BAR support, lets place it as it is and support via

spi-nor

Quoted 3 lines

     Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it

seems like 4
>     byte addressing (stateless dedicated opcode or with enter/exit 4 byte
>     mode) seems to be standard.
>     Also, Linux doesn't support BAR and haven't seen any request for BAR
>     support. Why support additional feature and burden of maintaining when
>     it may not be needed.
>
>     But if you insist, I just have to add BAR support back. >
>
> But if we do that, could we please have a config option so that I can > somehow ensure only 4 byte opcoses are used that don't change some state
> in the chip?
>

Quoted 9 lines

I am afraid BAR support would be the default as Jagan suggests not to change existing behavior. You would have to disable SPI_FLASH_BAR to use 4 Byte addressing opcodes.

Honestly, I don't like the idea of making BAR the default. Why can't we go the Linux way and enable BAR (maybe then as default) for boards that need it only?

Jagan, would that be acceptable?

Regards
Vignesh

#62 lore raw

cover SF: Migrate to Linux SPI NOR framework

Quoted 31 lines · Vignesh R
Quoted 31 lines
Quoted 3 lines
Quoted 3 lines

2) For BAR support, lets place it as it is and support via

spi-nor

Quoted 3 lines

Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it

seems like 4
> byte addressing (stateless dedicated opcode or with enter/exit
4 byte
> mode) seems to be standard.
> Also, Linux doesn't support BAR and haven't seen any request
for BAR
> support. Why support additional feature and burden of
maintaining when
> it may not be needed.
>
> But if you insist, I just have to add BAR support back.
>
>
> But if we do that, could we please have a config option so that I can > somehow ensure only 4 byte opcoses are used that don't change some state
> in the chip?
>

I am afraid BAR support would be the default as Jagan suggests not to change existing behavior. You would have to disable SPI_FLASH_BAR to use 4 Byte addressing opcodes.

Quoted 6 lines
Quoted 4 lines

Honestly, I don't like the idea of making BAR the default. Why can't we go the Linux way and enable BAR (maybe then as default) for boards that need it only?

Jagan, would that be acceptable?

Better way to have some controller flag to check we go with 3-byte or 4-byte addressing if flash > 16MiB. anyway let me give some time, will come back for the better to way to go this. ofcourse CONFIG would require if BAR handling code occupy more foot-print, but we have to enable based some controller indication.

#63 lore raw

cover SF: Migrate to Linux SPI NOR framework

Quoted 38 lines · Jagan Teki
Quoted 36 lines · Vignesh R
Quoted 35 lines
Quoted 3 lines
Quoted 3 lines

2) For BAR support, lets place it as it is and support via

spi-nor

Quoted 3 lines

Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it

seems like 4
> byte addressing (stateless dedicated opcode or with enter/exit
4 byte
> mode) seems to be standard.
> Also, Linux doesn't support BAR and haven't seen any request
for BAR
> support. Why support additional feature and burden of
maintaining when
> it may not be needed.
>
> But if you insist, I just have to add BAR support back.
>
>
> But if we do that, could we please have a config option so that I can > somehow ensure only 4 byte opcoses are used that don't change some state
> in the chip?
>

I am afraid BAR support would be the default as Jagan suggests not to change existing behavior. You would have to disable SPI_FLASH_BAR to use 4 Byte addressing opcodes.

Honestly, I don't like the idea of making BAR the default. Why can't we go the Linux way and enable BAR (maybe then as default) for boards that need it only?

Quoted 7 lines
Quoted 1 line

Jagan, would that be acceptable?

Better way to have some controller flag to check we go with 3-byte or 4-byte addressing if flash > 16MiB. anyway let me give some time, will come back for the better to way to go this. ofcourse CONFIG would require if BAR handling code occupy more foot-print, but we have to enable based some controller indication.

another approach can be do some sanity transfer if the flash > 16MiB with 4-byte addressing failure can lead to enable BAR.

#64 lore raw

cover SF: Migrate to Linux SPI NOR framework

In reply to Vignesh R
Quoted 70 lines · Vignesh R
Quoted 67 lines · Simon Goldschmidt

Am Fr., 14. Dez. 2018, 16:59 hat Vignesh R <[email protected] <mailto:[email protected]>> geschrieben:

On 14/12/18 3:43 PM, Jagan Teki wrote:
> On Wed, Dec 12, 2018 at 11:02 PM Vignesh R <[email protected] <mailto:[email protected]>> wrote:
>>
>> U-Boot SPI NOR support (sf layer) is quite outdated as it does not >> support 4 byte addressing opcodes, SFDP table parsing and different types of
>> quad mode enable sequences. Many newer flashes no longer support BANK >> registers used by sf layer to a access >16MB space.
>> Also, many SPI controllers have special MMIO interfaces which provide >> accelerated read/write access but require knowledge of flash parameters
>> to make use of it. Recent spi-mem layer provides a way to support such
>> flashes but sf layer isn't using that.
>> This patch series syncs SPI NOR framework from Linux v4.19. It also adds
>> spi-mem support on top.
>> So, we gain 4byte addressing support and SFDP support. This makes >> migrating to U-Boot MTD framework easier.
>>
>> Tested with few Spansion, micron and macronix flashes with TI's dra7xx,
>> k2g, am43xx EVMs. I dont have access to flashes from other vendors. So,
>> I would greatly appreciate testing on other platforms. Complete series
>> with dependencies here[1]
>>
>> For clean build on some platforms, depends on CONFIG_SPI_FLASH migration
>> to defconfigs [2]
>>
>> [1] https://github.com/r-vignesh/u-boot.git  branch:
spi-nor-mig-patch-v1
>> [2] https://patchwork.ozlabs.org/patch/1007485/
>>
>> Patch 12-15 are compile tested.
>
> Fist of all thanks for your time and work on this.
>
> Since most of the discussion on the individual patches seems similar, > repeat and never ended. I'm trying to summarize my comments here. > 1) You can sync or add new features by grabbing the code from Linux, > but I don't recommend __UBOOT macro or any Linux specific stuff  in > drivers/mtd/spi

I am fine either way.

> 2) For BAR support, lets place it as it is and support via spi-nor

Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems like 4 byte addressing (stateless dedicated opcode or with enter/exit 4 byte mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintaining when it may not be needed.

But if you insist, I just have to add BAR support back.

Quoted 8 lines
Quoted 4 lines

But if we do that, could we please have a config option so that I can somehow ensure only 4 byte opcoses are used that don't change some state in the chip?

I am afraid BAR support would be the default as Jagan suggests not to change existing behavior. You would have to disable SPI_FLASH_BAR to use 4 Byte addressing opcodes.

Please don't make SPI_FLASH_BAR support the default. It never was enabled per default until now IIRC.

Thanks,
Stefan

#65 lore raw

cover SF: Migrate to Linux SPI NOR framework

In reply to Vignesh R
Quoted 50 lines · Vignesh R
Quoted 28 lines · Jagan Teki
Quoted 19 lines · Vignesh R

U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
This patch series syncs SPI NOR framework from Linux v4.19. It also adds spi-mem support on top.
So, we gain 4byte addressing support and SFDP support. This makes migrating to U-Boot MTD framework easier.

Tested with few Spansion, micron and macronix flashes with TI's dra7xx, k2g, am43xx EVMs. I dont have access to flashes from other vendors. So, I would greatly appreciate testing on other platforms. Complete series with dependencies here[1]

Quoted 7 lines

For clean build on some platforms, depends on CONFIG_SPI_FLASH migration to defconfigs [2]

[1] https://github.com/r-vignesh/u-boot.git branch: spi-nor-mig-patch-v1
[2] https://patchwork.ozlabs.org/patch/1007485/

Patch 12-15 are compile tested.

Quoted 7 lines

Fist of all thanks for your time and work on this.

Since most of the discussion on the individual patches seems similar, repeat and never ended. I'm trying to summarize my comments here.
1) You can sync or add new features by grabbing the code from Linux, but I don't recommend __UBOOT macro or any Linux specific stuff in drivers/mtd/spi

I am fine either way.

Quoted 1 line

2) For BAR support, lets place it as it is and support via spi-nor

Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems like 4 byte addressing (stateless dedicated opcode or with enter/exit 4 byte mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintaining when it may not be needed.

Quoted 1 line

But if you insist, I just have to add BAR support back.

It's not about insistence, ie how we support since from long and u-boot bootloader project does in general. bootloader can be some certain boot difference functionalities unlike Linux, it's better not to compare u-boot with Linux in all cases.

Example we have SPI_TX_BYTE which usually not supported in Linux. Since it's ich controller specific and it require for bootloader to do byte tx on that specific controller, so we supported. Same for the case with the BAR, this specific controller(or supported boards) has been in U-Boot since from long and they do upstream well. So we need to support BAR in any case or we can find any alternative to work the same functionalities. (we tried before but ended-up adding BAR)

Quoted 6 lines
Quoted 2 lines

3) For dual flash, wait for Xilinx developers if they really want to support it?

Sorry, this feature was never supported properly *in mainline U-Boot*. If support is needed in the future, we can accept patches on top of new framework.

Siva, Michael any time-line to work on this topic?

author maintainer
#66 lore raw

cover SF: Migrate to Linux SPI NOR framework

Quoted 17 lines
Quoted 11 lines
Quoted 1 line

2) For BAR support, lets place it as it is and support via spi-nor

Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems like 4 byte addressing (stateless dedicated opcode or with enter/exit 4 byte mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintaining when it may not be needed.

But if you insist, I just have to add BAR support back.

It's not about insistence, ie how we support since from long and u-boot bootloader project does in general. bootloader can be some certain boot difference functionalities unlike Linux, it's better not to compare u-boot with Linux in all cases.

Quoted 8 lines

Example we have SPI_TX_BYTE which usually not supported in Linux. Since it's ich controller specific and it require for bootloader to do byte tx on that specific controller, so we supported. Same for the case with the BAR, this specific controller(or supported boards) has been in U-Boot since from long and they do upstream well. So we need to support BAR in any case or we can find any alternative to work the same functionalities. (we tried before but ended-up adding BAR)

How about this instead?

Lets use 4 byte addressing opcodes as default for >16MB flashes. But if CONFIG_SPI_FLASH_BAR is enabled then, spi-nor layer will use BAR registers for >16MB access instead of 4 byte addressing.
I will remove SPI_FLASH_BAR from defconfigs from all boards expect those controllers that really cannot handle 4 byte addressing. From a quick glance it looks following controllers support only 3 byte addresses:
stm32_qspi.c
ich.c
fsl_qspi.c
renesas_rpc_spi.c
mtk_qspi.c

So, except for boards with above controllers, I will remove SPI_FLASH_BAR for all other boards. If there is a regression, then such boards can go back to enabling CONFIG_SPI_FLASH_BAR.

AFAIU, above controller HWs(except ich perhaps) can support 4 byte addressing but would need to move to spi-mem.

Regards
Vignesh
ex

#67 lore raw

cover SF: Migrate to Linux SPI NOR framework

Quoted 26 lines · Vignesh R
Quoted 18 lines
Quoted 11 lines
Quoted 2 lines

2) For BAR support, lets place it as it is and support via spi-nor

Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems like 4 byte addressing (stateless dedicated opcode or with enter/exit 4 byte mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintaining when it may not be needed.

Quoted 1 line

But if you insist, I just have to add BAR support back.

It's not about insistence, ie how we support since from long and u-boot bootloader project does in general. bootloader can be some certain boot difference functionalities unlike Linux, it's better not to compare u-boot with Linux in all cases.

Quoted 8 lines

Example we have SPI_TX_BYTE which usually not supported in Linux. Since it's ich controller specific and it require for bootloader to do byte tx on that specific controller, so we supported. Same for the case with the BAR, this specific controller(or supported boards) has been in U-Boot since from long and they do upstream well. So we need to support BAR in any case or we can find any alternative to work the same functionalities. (we tried before but ended-up adding BAR)

Quoted 5 lines

How about this instead?

Lets use 4 byte addressing opcodes as default for >16MB flashes. But if CONFIG_SPI_FLASH_BAR is enabled then, spi-nor layer will use BAR registers for >16MB access instead of 4 byte addressing.

Yes, this can be normal approach. but what I'm trying to initiate here is if we have a generic kind of sanity check transfer for > 16MB flashes, then we can notify the controllers enable BAR to support > 16MiB.

This way we can reduce the ifdefs on code, and if we handle BAR in better way to minimize the code eventually we even drop the CONFIG option.

Quoted 8 lines

I will remove SPI_FLASH_BAR from defconfigs from all boards expect those controllers that really cannot handle 4 byte addressing. From a quick glance it looks following controllers support only 3 byte addresses:
stm32_qspi.c
ich.c
fsl_qspi.c
renesas_rpc_spi.c
mtk_qspi.c

I'm not sure whether all these support 4-byte addressing or not? since we don't have 4-byte on spi-flash they do use BAR for accessing > 16MiB, zynq_qspi is the key taker for this initially.

Quoted 4 lines

So, except for boards with above controllers, I will remove SPI_FLASH_BAR for all other boards. If there is a regression, then such boards can go back to enabling CONFIG_SPI_FLASH_BAR.

I think we can go the BAR code in flash as you mentioned with CONFIG option, and don't remove any CONFIG items from board configs then we can add sanity check patch on top of spi-nor changes and give warning to boards which never need BAR(ask them to drop CONFIG_BAR). This way transition look promising to move BAR to 4-byte addressing.

Quoted 3 lines

AFAIU, above controller HWs(except ich perhaps) can support 4 byte addressing but would need to move to spi-mem.

Even if we move to spi-mem, but BAR need to handle it flash side. isn't it?

author maintainer
#68 lore raw

cover SF: Migrate to Linux SPI NOR framework

Quoted 29 lines · Jagan Teki
Quoted 28 lines · Vignesh R
Quoted 18 lines
Quoted 11 lines
Quoted 2 lines

2) For BAR support, lets place it as it is and support via spi-nor

Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems like 4 byte addressing (stateless dedicated opcode or with enter/exit 4 byte mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintaining when it may not be needed.

Quoted 1 line

But if you insist, I just have to add BAR support back.

It's not about insistence, ie how we support since from long and u-boot bootloader project does in general. bootloader can be some certain boot difference functionalities unlike Linux, it's better not to compare u-boot with Linux in all cases.

Quoted 8 lines

Example we have SPI_TX_BYTE which usually not supported in Linux. Since it's ich controller specific and it require for bootloader to do byte tx on that specific controller, so we supported. Same for the case with the BAR, this specific controller(or supported boards) has been in U-Boot since from long and they do upstream well. So we need to support BAR in any case or we can find any alternative to work the same functionalities. (we tried before but ended-up adding BAR)

How about this instead?

Quoted 9 lines
Quoted 3 lines

Lets use 4 byte addressing opcodes as default for >16MB flashes. But if CONFIG_SPI_FLASH_BAR is enabled then, spi-nor layer will use BAR registers for >16MB access instead of 4 byte addressing.

Yes, this can be normal approach. but what I'm trying to initiate here is if we have a generic kind of sanity check transfer for > 16MB flashes, then we can notify the controllers enable BAR to support > 16MiB.

I guess you are saying to attempt 4 byte addressing transfers and if that fails then try using BAR? AFAIK, there is _no way_ to detect whether or not controller/flash supports 4 byte addressing and then do a fallback.

Quoted 13 lines

This way we can reduce the ifdefs on code, and if we handle BAR in better way to minimize the code eventually we even drop the CONFIG option.

Quoted 8 lines

I will remove SPI_FLASH_BAR from defconfigs from all boards expect those controllers that really cannot handle 4 byte addressing. From a quick glance it looks following controllers support only 3 byte addresses:
stm32_qspi.c
ich.c
fsl_qspi.c
renesas_rpc_spi.c
mtk_qspi.c

Quoted 1 line

I'm not sure whether all these support 4-byte addressing or not?

Just to be clear, all SPI drivers _except_ those in above list can support 4 byte addressing mode w/o any additional code change.

Quoted 3 lines

since we don't have 4-byte on spi-flash they do use BAR for accessing > 16MiB, zynq_qspi is the key taker for this initially.

I am confused here, let me put down more details:

Access >16MB of flash memory is possible by 3 ways:
1. using dedicated 4 byte addressing opcodes
2. Send "enter 4 byte" command and then use normal commands but with 4 bytes of address
3 Provide BA24 BA25 of address via BAR register

AFAIK, all flashes support 1 or 2. But only some flashes support 3. So, the idea is to use option 1 or 2 as default and use 3 only if SPI_FLASH_BAR is enabled.

Ideally, there is _nothing_ in SPI controllers that would stop us from using 4 byte addressing because a SPI controller would have no idea of slave connected (ie. it may or may not be a flash). SPI drivers should _blindly_ send/receive dout/din buffers passed as part of spi_xfer() and not interpret these buffers as cmd/addr/data separately
So, the decision on which of the above 3 options to use should be in the SPI NOR layer and has nothing to do with SPI controller drivers.

But since spi_flash.c was always used 3 byte addressing, _some_ of the SPI controller drivers are _hard-coded_ to expect 3 byte addresses (eg.:
above 4 drivers that I mentioned) See [1] on how these drivers convert dout buffer is back to flash offset. This is because there is no way to communicate cmd/addr/data separately using spi_xfer(), but _intelligent_ SPI HW do need this information. This is not a HW limitation but more of a framework limitation.

So, thus we can classify SPI controllers into roughly two types:
1. Controllers that need to know flash specific information like opcode, address length, dummy bytes etc (controllers that supports memory mapped access to flash(or such other acceleration interface).
Such controllers should move to spi-mem (but can optionally implement spi_xfer to support non flash devices)

2. Traditional SPI controllers that are usually FIFO/shift register based and provide direct access to SPI bus will continue to use traditional SPI framework.

Moving to 4 byte addressing mode will not affect second type of SPI controllers, but will break first type of controllers that do their own address conversion logic like[1].
So my suggestion is to enable CONFIG_SPI_FLASH_BAR only for controllers to do[1] until moved to spi-mem.

From my analysis:

Quoted 7 lines
Quoted 7 lines

stm32_qspi.c
ich.c
fsl_qspi.c
renesas_rpc_spi.c
mtk_qspi.c
ti_qspi.c
cadence_quadspi.c

are candidates to move to spi-mem layer. Rest seems to be traditional SPI controllers.

AFAIU, zynq_qspi seems to be FIFO based SPI controller. Why would zynq_qspi driverneed to know whether SPI NOR layer uses BAR or not? Or did I miss something?

Quoted 11 lines
Quoted 4 lines

So, except for boards with above controllers, I will remove SPI_FLASH_BAR for all other boards. If there is a regression, then such boards can go back to enabling CONFIG_SPI_FLASH_BAR.

I think we can go the BAR code in flash as you mentioned with CONFIG option, and don't remove any CONFIG items from board configs then we can add sanity check patch on top of spi-nor changes and give warning to boards which never need BAR(ask them to drop CONFIG_BAR). This way transition look promising to move BAR to 4-byte addressing.

Are you suggesting board users should individually remove CONFIG_SPI_FLASH_BAR from defconfigs based on their judgement? How do you propose to do sanity check?
Why not use 4 byte addressing as default and enable CONFIG_SPI_FLASH_BAR only for controllers that need them?

Quoted 6 lines
Quoted 3 lines

AFAIU, above controller HWs(except ich perhaps) can support 4 byte addressing but would need to move to spi-mem.

t
Even if we move to spi-mem, but BAR need to handle it flash side. isn't it?

Yes, presence/configuration of BAR registers is abstracted by SPI NOR and spi-mem drivers need not have any knowledge.

[1]
https://elixir.bootlin.com/u-boot/latest/source/drivers/spi/renesas_rpc_spi.c#L264
https://elixir.bootlin.com/u-boot/v2019.01-rc2/source/drivers/spi/mtk_qspi.c#L253

Regards
Vignesh

#69 lore raw

cover SF: Migrate to Linux SPI NOR framework

Quoted 73 lines

-----Original Message-----
From: U-Boot <[email protected]> On Behalf Of Vignesh R
Sent: Tuesday, December 18, 2018 10:49 PM
To: Jagan Teki <[email protected]>
Cc: Marek Vasut <[email protected]>; Tom Rini <[email protected]>; U-Boot- Denx <[email protected]>; Michal Simek <[email protected]>; Siva Durga Prasad Paladugu <[email protected]>; Boris Brezillon <[email protected]>; Miquel Raynal <[email protected]>; Stefan Roese <[email protected]>; Jagan Teki <[email protected]>
Subject: Re: [U-Boot] [PATCH 00/16] SF: Migrate to Linux SPI NOR framework

Quoted 31 lines · Jagan Teki
Quoted 30 lines · Vignesh R
Quoted 19 lines
Quoted 12 lines
Quoted 2 lines

2) For BAR support, lets place it as it is and support via spi-nor

Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems like 4 byte addressing (stateless dedicated opcode or with enter/exit 4 byte
mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintaining when it may not be needed.

Quoted 1 line

But if you insist, I just have to add BAR support back.

It's not about insistence, ie how we support since from long and u-boot bootloader project does in general. bootloader can be some certain boot difference functionalities unlike Linux, it's better not to compare u-boot with Linux in all cases.

Quoted 9 lines

Example we have SPI_TX_BYTE which usually not supported in Linux. Since it's ich controller specific and it require for bootloader to do byte tx on that specific controller, so we supported. Same for the case with the BAR, this specific controller(or supported boards) has been in U-Boot since from long and they do upstream well. So we need to support BAR in any case or we can find any alternative to work the same functionalities. (we tried before but ended-up adding BAR)

How about this instead?

Quoted 9 lines
Quoted 3 lines

Lets use 4 byte addressing opcodes as default for >16MB flashes. But if CONFIG_SPI_FLASH_BAR is enabled then, spi-nor layer will use BAR registers for >16MB access instead of 4 byte addressing.

Yes, this can be normal approach. but what I'm trying to initiate here is if we have a generic kind of sanity check transfer for > 16MB flashes, then we can notify the controllers enable BAR to support > 16MiB.

I guess you are saying to attempt 4 byte addressing transfers and if that fails then try using BAR? AFAIK, there is _no way_ to detect whether or not controller/flash supports 4 byte addressing and then do a fallback.

Quoted 13 lines

This way we can reduce the ifdefs on code, and if we handle BAR in better way to minimize the code eventually we even drop the CONFIG option.

Quoted 8 lines

I will remove SPI_FLASH_BAR from defconfigs from all boards expect those controllers that really cannot handle 4 byte addressing. From a quick glance it looks following controllers support only 3 byte addresses:
stm32_qspi.c
ich.c
fsl_qspi.c
renesas_rpc_spi.c
mtk_qspi.c

Quoted 4 lines
Quoted 1 line

I'm not sure whether all these support 4-byte addressing or not?

Just to be clear, all SPI drivers _except_ those in above list can support 4 byte addressing mode w/o any additional code change.

fsl_qspi.c: should support 4 byte as well, since the current frame work had limitation, u-boot.denx.de version of this driver was only supporting until 16MB

Regards
Ashish

Quoted 57 lines
Quoted 4 lines

since we don't have 4-byte on spi-flash they do use BAR for accessing

Quoted 1 line

16MiB, zynq_qspi is the key taker for this initially.

I am confused here, let me put down more details:

Access >16MB of flash memory is possible by 3 ways:
1. using dedicated 4 byte addressing opcodes 2. Send "enter 4 byte" command and then use normal commands but with
4 bytes of address
3 Provide BA24 BA25 of address via BAR register

AFAIK, all flashes support 1 or 2. But only some flashes support 3. So, the idea is to use option 1 or 2 as default and use 3 only if SPI_FLASH_BAR is enabled.

Ideally, there is _nothing_ in SPI controllers that would stop us from using 4 byte addressing because a SPI controller would have no idea of slave connected (ie. it may or may not be a flash). SPI drivers should _blindly_ send/receive dout/din buffers passed as part of spi_xfer() and not interpret these buffers as cmd/addr/data separately So, the decision on which of the above 3 options to use should be in the SPI NOR layer and has nothing to do with SPI controller drivers.

But since spi_flash.c was always used 3 byte addressing, _some_ of the SPI controller drivers are _hard-coded_ to expect 3 byte addresses (eg.:
above 4 drivers that I mentioned) See [1] on how these drivers convert dout buffer is back to flash offset. This is because there is no way to communicate cmd/addr/data separately using spi_xfer(), but _intelligent_ SPI HW do need this information. This is not a HW limitation but more of a framework limitation.

So, thus we can classify SPI controllers into roughly two types:
1. Controllers that need to know flash specific information like opcode, address length, dummy bytes etc (controllers that supports memory mapped access to flash(or such other acceleration interface).
Such controllers should move to spi-mem (but can optionally implement spi_xfer to support non flash devices)

2. Traditional SPI controllers that are usually FIFO/shift register based and provide direct access to SPI bus will continue to use traditional SPI framework.

Moving to 4 byte addressing mode will not affect second type of SPI controllers, but will break first type of controllers that do their own address conversion logic like[1].
So my suggestion is to enable CONFIG_SPI_FLASH_BAR only for controllers to do[1] until moved to spi-mem.

From my analysis:

Quoted 7 lines
Quoted 7 lines

stm32_qspi.c
ich.c
fsl_qspi.c
renesas_rpc_spi.c
mtk_qspi.c
ti_qspi.c
cadence_quadspi.c

Quoted 2 lines

are candidates to move to spi-mem layer. Rest seems to be traditional SPI controllers.

Yes fsl_qspi.c should be moved to spi-mem layer. Similar work in being done in Linux as well.

Regards
Ashish

Quoted 60 lines

AFAIU, zynq_qspi seems to be FIFO based SPI controller. Why would zynq_qspi driverneed to know whether SPI NOR layer uses BAR or not? Or did I miss something?

Quoted 11 lines
Quoted 4 lines

So, except for boards with above controllers, I will remove SPI_FLASH_BAR for all other boards. If there is a regression, then such boards can go back to enabling CONFIG_SPI_FLASH_BAR.

I think we can go the BAR code in flash as you mentioned with CONFIG option, and don't remove any CONFIG items from board configs then we can add sanity check patch on top of spi-nor changes and give warning to boards which never need BAR(ask them to drop CONFIG_BAR). This way transition look promising to move BAR to 4-byte addressing.

Are you suggesting board users should individually remove CONFIG_SPI_FLASH_BAR from defconfigs based on their judgement? How do you propose to do sanity check?
Why not use 4 byte addressing as default and enable CONFIG_SPI_FLASH_BAR only for controllers that need them?

Quoted 6 lines
Quoted 3 lines

AFAIU, above controller HWs(except ich perhaps) can support 4 byte addressing but would need to move to spi-mem.

t
Even if we move to spi-mem, but BAR need to handle it flash side. isn't it?

Yes, presence/configuration of BAR registers is abstracted by SPI NOR and spi- mem drivers need not have any knowledge.

[1]
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.b
ootlin.com%2Fu- boot%2Flatest%2Fsource%2Fdrivers%2Fspi%2Frenesas_rpc_spi.c%23L264&am p;data=02%7C01%7CAshish.Kumar%40nxp.com%7Cd535d3bc013949ad15230 8d6650d0bfa%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63680 7504073361903&amp;sdata=DpdMcJ%2F81jOOVE5MRNe6xSqgAlRGXVyvFb6C dm3ot8Q%3D&amp;reserved=0
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.b
ootlin.com%2Fu-boot%2Fv2019.01- rc2%2Fsource%2Fdrivers%2Fspi%2Fmtk_qspi.c%23L253&amp;data=02%7C01 %7CAshish.Kumar%40nxp.com%7Cd535d3bc013949ad152308d6650d0bfa%7 C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636807504073361903 &amp;sdata=JprAHMDaR4DY2vZocYIP0Wfu1l9yuxrl4zveN69hVA0%3D&amp;re served=0

Regards
Vignesh
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.de
nx.de%2Flistinfo%2Fu- boot&amp;data=02%7C01%7CAshish.Kumar%40nxp.com%7Cd535d3bc013949 ad152308d6650d0bfa%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0% 7C636807504073361903&amp;sdata=bJBeSCBf%2BtAcF3XyUr04jB1ba4UMTS ZC%2FRSlr6qKkcA%3D&amp;reserved=0

author maintainer
#70 lore raw

cover SF: Migrate to Linux SPI NOR framework

In reply to Jagan Teki
Quoted 17 lines
Quoted 11 lines
Quoted 1 line

2) For BAR support, lets place it as it is and support via spi-nor

Problem is, it not desirable to use BAR as default because its not stateless and does not work with all flash parts. OTOH, it seems like 4 byte addressing (stateless dedicated opcode or with enter/exit 4 byte mode) seems to be standard.
Also, Linux doesn't support BAR and haven't seen any request for BAR support. Why support additional feature and burden of maintaining when it may not be needed.

But if you insist, I just have to add BAR support back.

It's not about insistence, ie how we support since from long and u-boot bootloader project does in general. bootloader can be some certain boot difference functionalities unlike Linux, it's better not to compare u-boot with Linux in all cases.

Quoted 8 lines

Example we have SPI_TX_BYTE which usually not supported in Linux. Since it's ich controller specific and it require for bootloader to do byte tx on that specific controller, so we supported. Same for the case with the BAR, this specific controller(or supported boards) has been in U-Boot since from long and they do upstream well. So we need to support BAR in any case or we can find any alternative to work the same functionalities. (we tried before but ended-up adding BAR)

How about this instead?

Lets use 4 byte addressing opcodes as default for >16MB flashes. But if CONFIG_SPI_FLASH_BAR is enabled then, spi-nor layer will use BAR registers for >16MB access instead of 4 byte addressing.
I will remove SPI_FLASH_BAR from defconfigs from all boards expect those controllers that really cannot handle 4 byte addressing. From a quick glance it looks following controllers support only 3 byte addresses:
stm32_qspi.c
ich.c
fsl_qspi.c
renesas_rpc_spi.c
mtk_qspi.c

So, except for boards with above controllers, I will remove SPI_FLASH_BAR for all other boards. If there is a regression, then such boards can go back to enabling CONFIG_SPI_FLASH_BAR.

AFAIU, above controller HWs(except ich) can support 4 byte addressing but would need to move to spi-mem.

Regards
Vignesh
ex