leandrof/linux
1
0
Fork 0
forked from Minki/linux
Code Issues Pull Requests Packages Projects Releases Wiki Activity
4883a60c17
linux/drivers/mtd/spi-nor/Kconfig

74 lines
2.5 KiB
Plaintext
Raw Normal View History

treewide: Add SPDX license identifier - Makefile/Kconfig 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 <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-19 12:07:45 +00:00
# SPDX-License-Identifier: GPL-2.0-only
mtd: spi-nor: allow to be built as module There's no reason this can't be a module. Also, give SPI-NOR its own submenu. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Marek Vasut <marex@denx.de>
2014-04-10 18:05:34 +00:00
menuconfig MTD_SPI_NOR
mtd: spi-nor: Fix SPI NOR acronym 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 <tudor.ambarus@microchip.com> Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
2020-04-28 08:47:43 +00:00
tristate "SPI NOR device support"
mtd: spi-nor: add the framework for SPI NOR This patch cloned most of the m25p80.c. In theory, it adds a new spi-nor layer. Before this patch, the layer is like: MTD ------------------------ m25p80 ------------------------ spi bus driver ------------------------ SPI NOR chip After this patch, the layer is like: MTD ------------------------ spi-nor ------------------------ m25p80 ------------------------ spi bus driver ------------------------ SPI NOR chip With the spi-nor controller driver(Freescale Quadspi), it looks like: MTD ------------------------ spi-nor ------------------------ fsl-quadspi ------------------------ SPI NOR chip New APIs: spi_nor_scan: used to scan a spi-nor flash. Signed-off-by: Huang Shijie <b32955@freescale.com> Acked-by: Marek Vasut <marex@denx.de> [Brian: rebased to include additional m25p_ids[] entry] Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2014-02-24 10:37:37 +00:00
depends on MTD
mtd: spi-nor: Move m25p80 code in spi-nor.c 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 <boris.brezillon@bootlin.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
2019-08-06 05:10:40 +00:00
depends on MTD && SPI_MASTER
select SPI_MEM
mtd: spi-nor: add the framework for SPI NOR This patch cloned most of the m25p80.c. In theory, it adds a new spi-nor layer. Before this patch, the layer is like: MTD ------------------------ m25p80 ------------------------ spi bus driver ------------------------ SPI NOR chip After this patch, the layer is like: MTD ------------------------ spi-nor ------------------------ m25p80 ------------------------ spi bus driver ------------------------ SPI NOR chip With the spi-nor controller driver(Freescale Quadspi), it looks like: MTD ------------------------ spi-nor ------------------------ fsl-quadspi ------------------------ SPI NOR chip New APIs: spi_nor_scan: used to scan a spi-nor flash. Signed-off-by: Huang Shijie <b32955@freescale.com> Acked-by: Marek Vasut <marex@denx.de> [Brian: rebased to include additional m25p_ids[] entry] Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2014-02-24 10:37:37 +00:00
help
This is the framework for the SPI NOR which can be used by the SPI
mtd: spi-nor: Fix SPI NOR acronym 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 <tudor.ambarus@microchip.com> Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
2020-04-28 08:47:43 +00:00
device drivers and the SPI NOR device driver.
mtd: spi-nor: shorten Kconfig naming Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Marek Vasut <marex@denx.de> Acked-by: Huang Shijie <b32955@freescale.com>
2014-04-09 03:30:25 +00:00
if MTD_SPI_NOR
mtd: spi-nor: add Kconfig option to disable 4K sectors Current situation with 4K sectors is quite messy. First of all, some MTD "users" don't work with such small size. An example may be UBIFS which requires 15 KiB erase blocks as a minimum. In theory spi-nor should provide multiple erase regions and MTD "users" should use the one they need. Unforunately that is not implemented. In the result our flashes database in spi-nor is hackish. For some flashes we pretend they don't support 4K sectors just because some distribution uses UBIFS on it. This ofc leads to conflicts, like Samsung using w25q128 with 4K sectors vs. OpenWrt requiring it to pretend it's 64 KiB blocks only. My idea (plan?) for fixing this situation: 1) Use real hw info (this requires a way for disabling 4K for now) 2) Provide detailed info about erase regions 3) Make UBIFS work with devices that support 4K sectors Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2014-08-17 09:27:26 +00:00
config MTD_SPI_NOR_USE_4K_SECTORS
bool "Use small 4096 B erase sectors"
default y
help
Many flash memories support erasing small (4096 B) sectors. Depending
on the usage this feature may provide performance gain in comparison
to erasing whole blocks (32/64 KiB).
Changing a small part of the flash's contents is usually faster with
small sectors. On the other hand erasing should be faster when using
64 KiB block instead of 16 × 4 KiB sectors.
Please note that some tools/drivers/filesystems may not work with
4096 B erase size (e.g. UBIFS requires 15 KiB as a minimum).
mtd: spi-nor: keep lock bits if they are non-volatile 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 <michael@walle.cc> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201203162959.29589-8-michael@walle.cc
2020-12-03 16:29:59 +00:00
choice
prompt "Software write protection at boot"
default MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE
config MTD_SPI_NOR_SWP_DISABLE
bool "Disable SWP on any flashes (legacy behavior)"
help
This option disables the software write protection on any SPI
flashes at boot-up.
Depending on the flash chip this either clears the block protection
bits or does a "Global Unprotect" command.
Don't use this if you intent to use the software write protection
of your SPI flash. This is only to keep backwards compatibility.
config MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE
bool "Disable SWP on flashes w/ volatile protection bits"
help
Some SPI flashes have volatile block protection bits, ie. after a
power-up or a reset the flash is software write protected by
default.
This option disables the software write protection for these kind
of flashes while keeping it enabled for any other SPI flashes
which have non-volatile write protection bits.
If the software write protection will be disabled depending on
the flash either the block protection bits are cleared or a
"Global Unprotect" command is issued.
If you are unsure, select this option.
config MTD_SPI_NOR_SWP_KEEP
bool "Keep software write protection as is"
help
If you select this option the software write protection of any
SPI flashes will not be changed. If your flash is software write
protected or will be automatically software write protected after
power-up you have to manually unlock it before you are able to
write to it.
endchoice
mtd: spi-nor: Prepare core / manufacturer code split 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 <bbrezillon@kernel.org> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
2020-03-13 19:42:36 +00:00
source "drivers/mtd/spi-nor/controllers/Kconfig"
spi-nor: Add support for Intel SPI serial flash controller Add support for the SPI serial flash host controller found on many Intel CPUs including Baytrail and Braswell. The SPI serial flash controller is used to access BIOS and other platform specific information. By default the driver exposes a single read-only MTD device but with a module parameter "writeable=1" the MTD device can be made read-write which makes it possible to upgrade BIOS directly from Linux. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2016-11-28 12:06:24 +00:00
mtd: spi-nor: shorten Kconfig naming Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Marek Vasut <marex@denx.de> Acked-by: Huang Shijie <b32955@freescale.com>
2014-04-09 03:30:25 +00:00
endif # MTD_SPI_NOR
Reference in New Issue Copy Permalink