linux-toradex.git/drivers/mtd/spi-nor/Kconfig, branch master

mtd: spi-nor: Drop duplicate Kconfig dependency

2026-05-26T15:21:03+00:00

I do not think the MTD dependency is needed twice. This is likely a
duplicate coming from a former rebase when the spi-nor core got cleaned
up a while ago. Remove the extra line.

Fixes: b35b9a10362d ("mtd: spi-nor: Move m25p80 code in spi-nor.c")
Signed-off-by: Miquel Raynal 
Reviewed-by: Michael Walle 
Signed-off-by: Pratyush Yadav

mtd: spi-nor: keep lock bits if they are non-volatile

2020-12-07T17:31:15+00:00

Traditionally, Linux unlocks the whole flash because there are legacy
devices which has the write protection bits set by default at startup.
If you actually want to use the flash protection bits, eg. because there
is a read-only part for a bootloader, this automatic unlocking is
harmful. If there is no hardware write protection in place (usually
called WP#), a startup of the kernel just discards this protection.

I've gone through the datasheets of all the flashes (except the Intel
ones where I could not find any datasheet nor reference) which supports
the unlocking feature and looked how the sector protection was
implemented. The currently supported flashes can be divided into the
following two categories:
(1) block protection bits are non-volatile. Thus they keep their values
at reset and power-cycle
(2) flashes where these bits are volatile. After reset or power-cycle,
the whole memory array is protected.
(a) some devices needs a special "Global Unprotect" command, eg.
the Atmel AT25DF041A.
(b) some devices require to clear the BPn bits in the status
register.

Due to the reasons above, we do not want to clear the bits for flashes
which belong to category (1). Fortunately for us, only Atmel flashes
fall into category (2a). Implement the "Global Protect" and "Global
Unprotect" commands for these. For (2b) we can use normal block
protection locking scheme.

This patch adds a new flag to indicate the case (2). Only if we have
such a flash we unlock the whole flash array. To be backwards compatible
it also introduces a kernel configuration option which restores the
complete legacy behavior ("Disable write protection on any flashes").
Hopefully, this will clean up "unlock the entire flash for legacy
devices" once and for all.

For reference here are the actually commits which introduced the legacy
behavior (and extended the behavior to other chip manufacturers):

commit f80e521c916cb ("mtd: m25p80: add support for the Intel/Numonyx {16,32,64}0S33B SPI flash chips")
commit ea60658a08f8f ("mtd: m25p80: disable SST software protection bits by default")
commit 7228982442365 ("[MTD] m25p80: fix bug - ATmel spi flash fails to be copied to")

Actually, this might also fix handling of the Atmel AT25DF flashes,
because the original commit 7228982442365 ("[MTD] m25p80: fix bug -
ATmel spi flash fails to be copied to") was writing a 0 to the status
register, which is a "Global Unprotect". This might not be the case in
the current code which only handles the block protection bits BP2, BP1
and BP0. Thus, it depends on the current contents of the status register
if this unlock actually corresponds to a "Global Unprotect" command. In
the worst case, the current code might leave the AT25DF flashes in a
write protected state.

The commit 191f5c2ed4b6f ("mtd: spi-nor: use 16-bit WRR command when QE
is set on spansion flashes") changed that behavior by just clearing BP2
to BP0 instead of writing a 0 to the status register.

Further, the commit 3e0930f109e76 ("mtd: spi-nor: Rework the disabling
of block write protection") expanded the unlock_all() feature to ANY
flash which supports locking.

Signed-off-by: Michael Walle
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Tudor Ambarus
Link: https://lore.kernel.org/r/20201203162959.29589-8-michael@walle.cc

mtd: spi-nor: Fix SPI NOR acronym

2020-05-28T07:46:23+00:00

The correct terminology is serial NOR flash or SPI NOR.
s/SPI-NOR/SPI NOR and s/spi-nor/SPI NOR across the subsystem.

Signed-off-by: Tudor Ambarus 
Reviewed-by: Sergei Shtylyov

mtd: spi-nor: Prepare core / manufacturer code split

2020-03-16T16:28:53+00:00

Move all SPI NOR controller drivers to a controllers/ sub-directory
so that we only have SPI NOR related source files under
drivers/mtd/spi-nor/.

Rename spi-nor.c into core.c, we are about to split this file in multiple
source files (one per manufacturer, plus one for the SFDP parsing logic).

Signed-off-by: Boris Brezillon 
Signed-off-by: Tudor Ambarus 
Reviewed-by: Vignesh Raghavendra

mtd: spi-nor: remove mtk-quadspi driver

2020-03-11T19:56:08+00:00

This driver is superseded by the new spi-mtk-nor driver.

Signed-off-by: Chuanhong Guo 
Acked-by: Tudor Ambarus 
Link: https://lore.kernel.org/r/20200306085052.28258-5-gch981213@gmail.com
Signed-off-by: Mark Brown

mtd: spi-nor: hisi-sfc: Try to provide some clarity on which SFC we are

2020-01-10T17:04:30+00:00

The driver is for the HiSilicon FMC (Flash Memory Controller), which
supports SPI NOR in addition other memory technologies, like SPI NAND.

Indeed, the naming in the driver is a little inappropriate, especially
considering that there is already another HiSilicon SPI NOR flash
controller (which I believe the FMC is derived from).

Since we now want to provide software support for this other HiSilicon
controller, update code comments to at least try to make it clear that
this driver is for the FMC.

Signed-off-by: John Garry 
Signed-off-by: Tudor Ambarus

mtd: spi-nor: Move m25p80 code in spi-nor.c

2019-08-12T07:54:12+00:00

The m25p80 driver is actually a generic wrapper around the spi-mem
layer. Not only the driver name is misleading, but we'd expect such a
common logic to be directly available in the core. Another reason for
moving this code is that SPI NOR controller drivers should
progressively be replaced by SPI controller drivers implementing the
spi_mem_ops interface, and when the conversion is done, we should have
a single spi-nor driver directly interfacing with the spi-mem layer.

While moving the code we also fix a longstanding issue when
non-DMA-able buffers are passed by the MTD layer.

Signed-off-by: Boris Brezillon 
Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Tudor Ambarus

Merge tag 'spi-nor/for-5.3-v2' of gitolite.kernel.org:pub/scm/linux/kernel/git/mtd/linux into mtd/next

2019-07-07T20:53:15+00:00

SPI-NOR core changes:
- add support for the mt25ql02g and w25q16jv flashes
- print error in case of jedec read id fails
- is25lp256: add post BFPT fix to correct the addr_width

SPI NOR controller drivers changes:
- intel-spi: Add support for Intel Elkhart Lake SPI serial flash
- smt32: remove the driver as the driver was replaced by spi-stm32-qspi.c
- cadence-quadspi: add reset control

mtd: spi-nor: stm32: remove the driver as it was replaced by spi-stm32-qspi.c

2019-06-07T04:10:38+00:00

There's a new driver using the SPI memory interface of the
SPI framework at spi/spi-stm32-qspi.c, which can be used
together with m25p80.c to replace the functionality of
this SPI NOR driver.

The "new" driver uses the same dt properties and not affects
the legacy compatibility.

Signed-off-by: Ludovic Barre 
Signed-off-by: Tudor Ambarus

treewide: Add SPDX license identifier - Makefile/Kconfig

2019-05-21T08:50:46+00:00

Add SPDX license identifiers to all Make/Kconfig files which:

 - Have no license information of any form

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

  GPL-2.0-only

Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman