Add this API to restore the status of SPI flash chip to the default
such as addressing mode, whenever detach the driver from device or
reboot the system.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
Previously, the lock and unlock functions returned success even if the
BP bits were not actually updated in the status register due to
hardware write protection. Introduce write_sr_and_check() to write and
read back the status register to ensure the desired BP bits are
actually set as requested.
Signed-off-by: Joe Schultz <jschultz@xes-inc.com>
Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
For Micron spi nor device, when erase/program operation
fails, especially the failure results from intending to
modify protected space, spi-nor upper layers still get
the return which shows the operation succeeds. This is
because current spi_nor_fsr_ready() only uses FSR bit.7
(flag status register) to check device whether ready.
This patch fixes this issue by checking relevant error
bits in FSR.
The FSR is a powerful tool to investigate the status of
device, checking information regarding what the memory is
actually doing and detecting possible error conditions.
Signed-off-by: beanhuo <beanhuo@micron.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
Add Everspin mr25h128 16KB MRAM to the list of supported chips.
Signed-off-by: Philipp Puschmann <pp@emlix.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
Add JEDEC entry for the Winbond w25q16fw/w25q16dw with similar
flags and format than the Winbond w25q32dw entry.
Tested on a Khadas VIM2 SBC board with an Amlogic S912 SoC.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
Tested against GD25LQ32D but the GD25LQ32C datasheet seems to be
identically feature-wise. Therefore dropping the suffix as it's
probably only indicating the die revision.
Signed-off-by: Klaus Goger <klaus.goger@theobroma-systems.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
Add support for GD25Q256, a 32MiB SPI Nor flash
from GigaDevice.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
Some manufacturers may use different bit to set QE on different
memories.
The GD25Q256 from GigaDevice is an example, which uses S6(bit 6
of the Status Register-1) to set QE, which is different with
other supported memories from GigaDevice that use S9(bit 1 of
the Status Register-2). This makes it is impossible to select
the quad enable method by distinguishing the MFR. This patch
introduce a quad_enable function which can be set per memory
in the flash_info list table.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
Implemented and populated spi-nor mtd PM handlers for resume ops.
spi-nor resume op re-initializes spi-nor flash to its probed
state by calling the newly implemented spi_nor_init() function.
Signed-off-by: Kamal Dasu <kdasu.kdev@gmail.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
This patch extracts some chunks from spi_nor_init_params and spi_nor_scan()
and moves them into a new spi_nor_init() function.
Indeed, spi_nor_init() regroups all the required SPI flash commands to be
sent to the SPI flash memory before performing any runtime operations
(Fast Read, Page Program, Sector Erase, ...). Hence spi_nor_init():
1) removes the flash protection if applicable for certain vendors.
2) sets the Quad Enable bit, if needed, before using Quad SPI protocols.
3) makes the memory enter its (stateful) 4-byte address mode, if needed,
for SPI flash memory > 128Mbits not supporting the 4-byte address
instruction set.
spi_nor_scan() now ends by calling spi_nor_init() once the probe phase has
completed. Further patches could also use spi_nor_init() to implement the
mtd->_resume() handler for the spi-nor framework.
Signed-off-by: Kamal Dasu <kdasu.kdev@gmail.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
header.minor is of type u8 and cannot be negative.
Detected by CoverityScan CID#1417858 ("Integer handling issues")
Fixes: f384b352cb ("mtd: spi-nor: parse Serial Flash Discoverable
Parameters (SFDP) tables")
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
spi_nor_read_sfdp() calls nor->read() to read the SFDP data.
When the m25p80 driver is used (pretty common case), nor->read() is then
implemented by the m25p80_read() function, which is likely to initialize a
'struct spi_transfer' from its buf argument before appending this
structure inside the 'struct spi_message' argument of spi_sync().
Besides the SPI sub-system states that both .tx_buf and .rx_buf members of
'struct spi_transfer' must point into dma-safe memory. However, two of the
three calls of spi_nor_read_sfdp() were given pointers to stack allocated
memory as buf argument, hence not in a dma-safe area.
Hopefully, the third and last call of spi_nor_read_sfdp() was already
given a kmalloc'ed buffer argument, hence dma-safe.
So this patch fixes this issue by introducing a
spi_nor_read_sfdp_dma_unsafe() function which simply wraps the existing
spi_nor_read_sfdp() function and uses some kmalloc'ed memory as a bounce
buffer.
Fixes: f384b352cb ("mtd: spi-nor: parse Serial Flash Discoverable Parameters (SFDP) tables")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
One field of the flash parameter table contains information about the
flash device size.
Most of the time the data extracted from this field is valid, but
sometimes the BFPT section of the SFDP table is corrupted or invalid and
this field is set to 0xffffffff, thus resulting in an integer overflow
when setting params->size.
Since NOR devices are anayway always smaller than 2^64 bytes, we can
easily stop the BFPT parsing if the size reported in this table is
invalid.
Fixes: f384b352cb ("mtd: spi-nor: parse Serial Flash Discoverable Parameters (SFDP) tables")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.com>
S25FL{128|256|512}S datasheets say:
"When P_ERR or E_ERR bits are set to one, the WIP bit will remain set to
one indicating the device remains busy and unable to receive new operation
commands. A Clear Status Register (CLSR) command must be received to return
the device to standby mode."
Current spi-nor code works until first error occurs, but write/erase errors
are not just rare hardware failures, they also occur if user tries to flash
write-protected areas. After such attempt no SPI command can be executed
any more and even read fails. This patch adds support for P_ERR and E_ERR
bits in Status Register 1 (so that operation fails immediately and not
after a long timeout) and proper recovery from the error condition.
Tested on Spansion S25FS128S, which is supported by S25FL129P entry.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
This patch adds support to the JESD216 rev B standard and parses the SFDP
tables to dynamically initialize the 'struct spi_nor_flash_parameter'.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@microchip.com>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
These devices are used on OpenPOWER systems. The SPI_NOR_DUAL_READ
flags is added for the Aspeed SoCs which do not support QUAD reads.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
These modules are used on the OpenPOWER Witherspoon systems to hold
the POWER9 host firmware image. The SPI_NOR_DUAL_READ flags is added
for the Aspeed SoCs which do not support QUAD reads.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
Similar to the other ones, different size. The "JV" suffix is in
the datasheet, I haven't seen mentions of a different one.
The datasheet indicates DUAL and QUAD are supported.
http://www.winbond.com/resource-files/w25m512jv%20revc%2001062017.pdf
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
Before commit cff959958832 ("mtd: spi-nor: introduce SPI 1-2-2 and SPI
1-4-4 protocols") then we treated 1 as -EINVAL in the caller but after
that commit we changed to propagate the return. My static checker
complains that it's eventually passed to an ERR_PTR() and later
dereferenced, but I'm not totally certain if that's true. Regardless,
returning 1 is wrong.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
This patch starts adding support to Octo SPI protocols (SPI x-y-8).
Op codes for Fast Read and/or Page Program operations using Octo SPI
protocols are not known yet (no JEDEC specification has defined them yet)
but we'd rather introduce the Octo SPI protocols now so it's done as it
should be.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
This patch introduces support to Double Transfer Rate (DTR) SPI protocols.
DTR is used only for Fast Read operations.
According to manufacturer datasheets, whatever the number of I/O lines
used during instruction (x) and address/mode/dummy (y) clock cycles, DTR
is used only during data (z) clock cycles of SPI x-y-z protocols.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
This patch changes the prototype of spi_nor_scan(): its 3rd parameter
is replaced by a 'struct spi_nor_hwcaps' pointer, which tells the spi-nor
framework about the actual hardware capabilities supported by the SPI
controller and its driver.
Besides, this patch also introduces a new 'struct spi_nor_flash_parameter'
telling the spi-nor framework about the hardware capabilities supported by
the SPI flash memory and the associated settings required to use those
hardware caps.
Then, to improve the readability of spi_nor_scan(), the discovery of the
memory settings and the memory initialization are now split into two
dedicated functions.
1 - spi_nor_init_params()
The spi_nor_init_params() function is responsible for initializing the
'struct spi_nor_flash_parameter'. Currently this structure is filled with
legacy values but further patches will allow to override some parameter
values dynamically, for instance by reading the JESD216 Serial Flash
Discoverable Parameter (SFDP) tables from the SPI memory.
The spi_nor_init_params() function only deals with the hardware
capabilities of the SPI flash memory: especially it doesn't care about
the hardware capabilities supported by the SPI controller.
2 - spi_nor_setup()
The second function is called once the 'struct spi_nor_flash_parameter'
has been initialized by spi_nor_init_params().
With both 'struct spi_nor_flash_parameter' and 'struct spi_nor_hwcaps',
the new argument of spi_nor_scan(), spi_nor_setup() computes the best
match between hardware caps supported by both the (Q)SPI memory and
controller hence selecting the relevant settings for (Fast) Read and Page
Program operations.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
NAND, from Boris:
"""
- some minor fixes/improvements on existing drivers (fsmc, gpio, ifc,
davinci, brcmnand, omap)
- a huge cleanup/rework of the denali driver accompanied with core
fixes/improvements to simplify the driver code
- a complete rewrite of the atmel driver to support new DT bindings
make future evolution easier
- the addition of per-vendor detection/initialization steps to avoid
extending the nand_ids table with more extended-id entries
"""
SPI NOR, from Cyrille:
"""
- fixes in the hisi SPI controller driver.
- fixes in the intel SPI controller driver.
- fixes in the Mediatek SPI controller driver.
- fixes to some SPI flash memories not supported the Chip Erase command.
- add support to some new memory parts (Winbond, Macronix, Micron, ESMT).
- add new driver for the STM32 QSPI controller.
"""
And a few fixes for Gemini and Versatile platforms on physmap-of
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJZE86yAAoJEFySrpd9RFgtlOoP/1o1s8dlKdd4TazdoxBTL2wy
C4wPkqPWyfREcD5ZUYJgr6ENI2OnEwcAxAt2CXnqegx+ZIPToBW4/WK9gj/TNLRx
AfSOz+EPPzo5uZwJPnfocgIFYuhsspymvmISwv66kPbjfkrSjo1l/K9nem3gh7an
IkQdVVq8brvxNeDZOAzbsT2Y5DZNfs00g1jLXkcQrpfM0sWKcbHIUa0BTWy4WKGV
ElTr+xh7QHh/Pd9/A5znd3xX54w5+YR/xe38jSBfTb0vEgw/RIfhIcnvxQ8G/7Se
jE0+8GR5ZJGKwA9Xk5nFzS2G3uECMFNS75KfxkZ0LlEE6ivUvpDbokCbIU4bDOCt
/8bWQf9AGA3gLHGgNUQTSt5HrkBXTGp917jtAZbI/y2MzTkLw3aAZ/m/j37vv9ON
ezeGRO6VWK3bcimLFrt6KO5emYstmm4Tp4rRe3jakH7eyTlINDsecKtuMo2xVzyZ
kK3tnDMdEntECAiKh3ndRdAUL3fs+/IdzWTAxnF9VQFQs1YxiZ1K8kY/zcN+rzbn
CVkEhdm+tdDBx8XgOdfnOTGRAJ07dGOoDhLPR4/egC/ta6GIRkHQjFSwsW7bD9p9
phHH6nQX9Bpza1JV/xvljezoHjvZkny4UhRpLgYMowb41DXv7os7ZV+g7kf5sd0i
mGzCH46j0DmWQ1u5/Q6j
=dxj5
-----END PGP SIGNATURE-----
Merge tag 'for-linus-20170510' of git://git.infradead.org/linux-mtd
Pull MTD updates from Brian Norris:
"NAND, from Boris:
- some minor fixes/improvements on existing drivers (fsmc, gpio, ifc,
davinci, brcmnand, omap)
- a huge cleanup/rework of the denali driver accompanied with core
fixes/improvements to simplify the driver code
- a complete rewrite of the atmel driver to support new DT bindings
make future evolution easier
- the addition of per-vendor detection/initialization steps to avoid
extending the nand_ids table with more extended-id entries
SPI NOR, from Cyrille:
- fixes in the hisi, intel and Mediatek SPI controller drivers
- fixes to some SPI flash memories not supporting the Chip Erase
command.
- add support to some new memory parts (Winbond, Macronix, Micron,
ESMT).
- add new driver for the STM32 QSPI controller
And a few fixes for Gemini and Versatile platforms on physmap-of"
* tag 'for-linus-20170510' of git://git.infradead.org/linux-mtd: (100 commits)
MAINTAINERS: Update NAND subsystem git repositories
mtd: nand: gpio: update binding
mtd: nand: add ooblayout for old hamming layout
mtd: oxnas_nand: Allocating more than necessary in probe()
dt-bindings: mtd: Document the STM32 QSPI bindings
mtd: mtk-nor: set controller's address width according to nor flash
mtd: spi-nor: add driver for STM32 quad spi flash controller
mtd: nand: brcmnand: Check flash #WP pin status before nand erase/program
mtd: nand: davinci: add comment on NAND subpage write status on keystone
mtd: nand: omap2: Fix partition creation via cmdline mtdparts
mtd: nand: NULL terminate a of_device_id table
mtd: nand: Fix a couple error codes
mtd: nand: allow drivers to request minimum alignment for passed buffer
mtd: nand: allocate aligned buffers if NAND_OWN_BUFFERS is unset
mtd: nand: denali: allow to override revision number
mtd: nand: denali_dt: use pdev instead of ofdev for platform_device
mtd: nand: denali_dt: remove dma-mask DT property
mtd: nand: denali: support 64bit capable DMA engine
mtd: nand: denali_dt: enable HW_ECC_FIXUP for Altera SOCFPGA variant
mtd: nand: denali: support HW_ECC_FIXUP capability
...
All required stateless 4-byte op codes are supported by this flash
chip. The stateless 4-byte support can't be autodetected due to a
missing 4-byte Address Instruction Table in SFDP.
Fixes hangs on reboot for SoCs expecting the flash chip in 3byte mode.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Acked-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Add new Micron N25Q256A (N25Q256A11) 256Mbit NOR Flash in the list
of supported devices. This chip has the same structure as the N25Q256A
but ID and voltage (1V8) to use is different. Therefore, this adds
N25Q256A11 as n25q256ax1.
In the future, for new Micron memories we could use the patterns
"n25q*ax1" for 1V8 and "n25q*ax3" for 3V3 memories.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.kw@hitachi.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Macronix MX25U2033E, MX25U4033E and MX25U4035 devices are used in 4/5/6th
generation Kindle ebook readers. Both MX25U403x variants share the same
JEDEC id. Add those spi-nor variants and the similar MX25U8035 mentioned
in the same set of datasheets.
Signed-off-by: Alexander Kurz <akurz@blala.de>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Winbond W25Q20BW devices are used in 4/5th generation Kindle ebook readers.
Add this spi-nor device and the similar W25Q20 devices to the list of known
devices.
Signed-off-by: Alexander Kurz <akurz@blala.de>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Micron n25q00 are stacked chips, thus do not support chip erase.
>From now spi-nor framework will not send chip erase command,
instead will use sector at time erase procedure.
Signed-off-by: Marcin Krzeminski <mar.krzeminski@gmail.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Currently it is possible to disable chip erase for spi-nor driver.
Some modern stacked (multi die) flash chips do not support chip
erase opcode at all but spi-nor framework needs to cope with them too.
This commit extends existing functionality to allow disable
chip erase for a single flash chip.
Signed-off-by: Marcin Krzeminski <mar.krzeminski@gmail.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Fix typos and add the following to the scripts/spelling.txt:
disble||disable
disbled||disabled
I kept the TSL2563_INT_DISBLED in /drivers/iio/light/tsl2563.c
untouched. The macro is not referenced at all, but this commit is
touching only comment blocks just in case.
Link: http://lkml.kernel.org/r/1481573103-11329-20-git-send-email-yamada.masahiro@socionext.com
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add support for the ESMT F25L32QA and F25L64QA.
These are 4MB and 8MB SPI-NOR Chips from Elite Semiconductor Memory
Technology.
Signed-off-by: L. D. Pinney <ldpinney@gmail.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
- add support to the 4-byte address instruction set.
- add support to new memory parts.
- add support to S3AN memories.
- add support to the Intel SPI controller.
- add support to the Aspeed AST2400 and AST2550 controllers.
- fix max SPI transfer and message sizes in m25p80_read().
- fix the Candence QSPI driver.
- fix the Freescale QSPI driver.
-----BEGIN PGP SIGNATURE-----
iQI4BAABCAAiBQJYncJ7GxxjeXJpbGxlLnBpdGNoZW5Ad2VkZXY0dS5mcgAKCRDn
4OgLHRpJcswfD/0dvIvhI9R9ne/kHUsXbW2tIAIc2vrl/jiEA0O90rinRRjxLyIi
3EacSYpL8PXAh5diNannIw/DrjK0FiHB34jJ1NwMP7CQbYMbfb1SGwp5nmIP676W
4iEaSOJDQu76Vbe5L2O4xHUIJoO1l9cr/bZDPXRachBD8H48ZRZUTx0ujff4LbiG
lEwv1Bk35doTRHgmPErPIB/WOlYdvLaoiCUVe9ME0mEEzCmEjoZorTDwaSBpBAMB
4Z04Lz06iP1aPFUm2VYvK5xMvkFN4tS+6xzWpUOUYj8Tty1YptYI7mQINa69J2NA
O8A/elH39Yv1FYvWgrC2SIS/kbHTR/Bxz6napJ0hK3HasLFCwt7Eq2w/XBxr/Wn9
+02buij0PWKywJfuj7tOiAId5IJW0hhEit2BcBFihwsiDDxix679beQoCZ/WRuW/
kJmR+NLRNByVyKCOP239VobiYWjy8DhDTpH5XGwI7bPTiJuS6G6MCVH3f0tYnFTo
8J3gXp4SH2mw6YzWrL8YtKzFKcLEfXTOGc/GFGQX2URV5Es1/Lw4Nh5lrkbEbVoy
dc/S57Ftdde/56L4lDDbydn7pAU8FbuX2gSewvJRuFyhCBKSyw2JEoy27T7t50pd
hN1JvuNYGQ5HP0Vqa/oe1g1GHnBfxiIOm5THX+Iv+3Y0jM1iUDeVeO4DTQ==
=/fPM
-----END PGP SIGNATURE-----
Merge tag 'spi-nor/for-4.11-v2' of git://github.com/spi-nor/linux
From Cyrille:
"""
This pull request contains the following notable changes:
- add support to the 4-byte address instruction set.
- add support to new memory parts.
- add support to S3AN memories.
- add support to the Intel SPI controller.
- add support to the Aspeed AST2400 and AST2550 controllers.
- fix max SPI transfer and message sizes in m25p80_read().
- fix the Candence QSPI driver.
- fix the Freescale QSPI driver.
"""
The page calculation under spi_nor_s3an_addr_convert() was wrong. On
Default Address Mode we need to perform a divide by page_size.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Acked-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
This chip has write protection enabled on power-up,
so this flag is necessary to support write operations.
Signed-off-by: Victor Shyba <victor1984@riseup.net>
Acked-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
This patch provides an alternative mean to support memory above 16MiB
(128Mib) by replacing 3byte address op codes by their associated 4byte
address versions.
Using the dedicated 4byte address op codes doesn't change the internal
state of the SPI NOR memory as opposed to using other means such as
updating a Base Address Register (BAR) and sending command to enter/leave
the 4byte mode.
Hence when a CPU reset occurs, early bootloaders don't need to be aware
of BAR value or 4byte mode being enabled: they can still access the first
16MiB of the SPI NOR memory using the regular 3byte address op codes.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Tested-by: Vignesh R <vigneshr@ti.com>
Acked-by: Marek Vasut <marek.vasut@gmail.com>
This patch renames the SPINOR_OP_* macros of the 4-byte address
instruction set so the new names all share a common pattern: the 4-byte
address name is built from the 3-byte address name appending the "_4B"
suffix.
The patch also introduces new op codes to support other SPI protocols such
as SPI 1-4-4 and SPI 1-2-2.
This is a transitional patch and will help a later patch of spi-nor.c
to automate the translation from the 3-byte address op codes into their
4-byte address version.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Marek Vasut <marek.vasut@gmail.com>
This patch removes the WARN_ONCE() test in spi_nor_write().
This macro triggers the display of a warning message almost every time we
use a UBI file-system because a write operation is performed at offset 64,
which is in the middle of the SPI NOR memory page. This is a valid
operation for ubifs.
Hence this warning is pretty annoying and useless so we just remove it.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Suggested-by: Richard Weinberger <richard@nod.at>
Suggested-by: Andras Szemzo <szemzo.andras@gmail.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
The patch checks whether the Quad Enable bit is already set in the Status
Register. If so, the function exits immediately with a successful return
code.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Acked-by: Marek Vasut <marek.vasut@gmail.com>
Xilinx Spartan-3AN FPGAs contain an In-System Flash where they keep
their configuration data and (optionally) some user data.
The protocol of this flash follows most of the spi-nor standard. With
the following differences:
- Page size might not be a power of two.
- The address calculation (default addressing mode).
- The spi nor commands used.
Protocol is described on Xilinx User Guide UG333
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Marek Vasut <marek.vasut@gmail.com>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Add Everspin mr25h40 512KB MRAM to the list of supported chips.
Signed-off-by: Masahiko Iwamoto <iwamoto@allied-telesis.co.jp>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Acked-by: Marek Vasut <marex@denx.de>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
This commit adds support in the spi-nor driver for the
N25Q016A, a 16Mbit SPI NOR flash from Micron.
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Jagan Teki <jteki@openedev.com>
Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Add Atmel at25df321 spi-nor flash to the list of spi_nor_ids.
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Wenyou Yang <wenyou.yang@atmel.com>
Signed-off-by: Jagan Teki <jteki@openedev.com>
Acked-by: Wenyou Yang <wenyou.yang@atmel.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
The Spansion S25FL128S also supports dual read mode.
In addition remove flag SECT_4K. 4K erases are supported,
but not uniformly.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>
Acked-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
With the S25FL127S nor flash part, each writing to the configuration
register takes hundreds of ms. During that time, no more accesses to
the flash should be done (even reads).
This commit adds a wait loop after the register writing until the flash
finishes its work.
This issue could make rootfs mounting fail when the latter was done too
much closely to this quad enable bit setting step. And in this case, a
driver as UBIFS may try to recover the filesystem and may broke it
completely.
Signed-off-by: Joël Esponde <joel.esponde@honeywell.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Gigadevice flash support BP{0,1,2,3,4} bits, where BP3 means the same as
the existing supported TB (Top/Bottom), and BP4 means the same as the
not-yet-supported 4K bit used on other flash (e.g., Winbond). Let's
support lock/unlock with the same feature flags as w25q32dw/w25q64dw.
Tested on gd25lq64c, but I checked datasheets for the other 3, to make
sure.
While I was at it, I noticed that these all support dual and quad as
well. I noted them, but can't test them at the moment, since my test
system only supports standard 1x SPI.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Add Micron (n25q00a) 1Gbit NOR Flash in the list of supported
devices.
This part is different from n25q00 in Memory Type.
Memory Type for n25q00 - BAh
Memory Type for n25q00a - BBh
Signed-off-by: P L Sai Krishna <lakshmis@xilinx.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
In stm_unlock(), the test to determine whether we've fully unlocked the
flash checks for the lock length to be equal to the flash size. That is
a typo/think-o -- the condition actually means the flash is completely
*locked.* We should be using the inverse condition -- that the lock
length is 0 (i.e., no protection).
The result of this bug is that we never actually turn off the Status
Register Write Disable bit, even if the flash is completely unlocked.
Now we can.
Fixes: 47b8edbf0d ("mtd: spi-nor: disallow further writes to SR if WP# is low")
Reported-by: Giorgio <giorgio.nicole@arcor.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
mtdblock and ubi do not handle the situation when read returns less data
than requested. Loop in spi-nor until buffer is filled or an error is
returned.
Signed-off-by: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Michal Suchanek <hramrach@gmail.com>
Tested-by: Michal Suchanek <hramrach@gmail.com>
The spi-nor write loop assumes that what is passed to the hardware
driver write() is what gets written.
When write() writes less than page size at once data is dropped on the
floor. Check the amount of data writen and exit if it does not match
requested amount.
Signed-off-by: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Michal Suchanek <hramrach@gmail.com>
Tested-by: Michal Suchanek <hramrach@gmail.com>
Do not pass retlen to hardware driver read/write functions. Update it in
spi-nor generic driver instead.
Signed-off-by: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Michal Suchanek <hramrach@gmail.com>
Tested-by: Michal Suchanek <hramrach@gmail.com>
SPI NOR hardware drivers now return useful value from their write
functions so check them.
Signed-off-by: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Michal Suchanek <hramrach@gmail.com>
Tested-by: Michal Suchanek <hramrach@gmail.com>
Change the return value of spi-nor device read and write methods to
allow returning amount of data transferred and errors as
read(2)/write(2) does.
Also, start handling positive returns in spi_nor_read(), since we want
to convert drivers to start returning the read-length both via *retlen
and the return code. (We don't need to do the same transition process
for spi_nor_write(), since ->write() didn't used to have a return code
at all.)
Signed-off-by: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Michal Suchanek <hramrach@gmail.com>
Tested-by: Michal Suchanek <hramrach@gmail.com>
Also note the GigaDevice JEDEC ID.
No write-protect support yet, since this flash uses a different status
register layout.
Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Marek Vasut <marex@denx.de>
These are recent Winbond models that are known to have lock/unlock
support via writing the Status Register, and that also support the TB
(Top/Bottom) protection bit.
Tested on w25q32dw.
[Note on style: these entries are getting pretty long lines, so I picked
a style that seems reasonable for splitting up the flags separate from
the other mostly-similar fields.]
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Some flash support a bit in the status register that inverts protection
so that it applies to the bottom of the flash, not the top. This yields
additions to the protection range table, as noted in the comments.
Because this feature is not universal to all flash that support
lock/unlock, control it via a new flag.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
We can't determine this purely by manufacturer type (see commit
67b9bcd369 ("mtd: spi-nor: fix Spansion regressions (aliased with
Winbond)")), and it's not autodetectable by anything like SFDP. So make
a new flag for it.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
It's a little easier to read and make sure there are no collisions
(IMO).
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Locking the flash is most useful if it provides real hardware security.
Otherwise, it's little more than a software permission bit.
A reasonable use case that provides real HW security might be like
follows:
(1) hardware WP# is deasserted
(2) program flash
(3) flash range is protected via status register
(4) hardware WP# is asserted
(5) flash protection range can no longer be changed, until WP# is
deasserted
In this way, flash protection is co-owned by hardware and software.
Now, one would expect to be able to perform step (3) with
ioctl(MEMLOCK), except that the spi-nor driver does not set the Status
Register Protect bit (a.k.a. Status Register Write Disable (SRWD)), so
even though the range is now locked, it does not satisfy step (5) -- it
can still be changed by a call to ioctl(MEMUNLOCK).
So, let's enable status register protection after the first lock
command, and disable protection only when the flash is fully unlocked.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
There are a few different corner cases to the current logic that seem
undesirable:
* mtd_lock() with offs==0 trips a bounds issue on
ofs - mtd->erasesize < 0
* mtd_unlock() on the middle of a flash that is already unlocked will
return -EINVAL
* probably other corner cases
So, let's stop doing "smart" checks like "check the block below us",
let's just do the following:
(a) pass only non-negative offsets/lengths to stm_is_locked_sr()
(b) add a similar stm_is_unlocked_sr() function, so we can check if the
*entire* range is unlocked (and not just whether some part of it is
unlocked)
Then armed with (b), we can make lock() and unlock() much more
symmetric:
(c) short-circuit the procedure if there is no work to be done, and
(d) check the entire range above/below
This also aligns well with the structure needed for proper TB
(Top/Bottom) support.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
If, for instance, the entire flash is already unlocked and I try to
mtd_unlock() the entire device, I don't expect to see an EINVAL error.
It should just silently succeed. Ditto for mtd_lock().
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Fixup a piece leftover by commit 32321e950d ("mtd: spi-nor: wait until
lock/unlock operations are ready"). That commit made us wait for the WIP
bit to settle after lock/unlock operations, but it missed the open-coded
"unlock" that happens at probe() time.
We should probably have this code utilize the unlock() routines in the
future, to avoid duplication, but unfortunately, flash which need to be
unlocked don't all have a proper ->flash_unlock() callback.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Stas Sergeev <stsp@users.sourceforge.net>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Micron n25q128axx support subsector (4K) erase so let's update the flags.
Tested on n25q128a13.
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
This patch remove the micron_quad_enable() function which force the Quad
SPI mode. However, once this mode is enabled, the Micron memory expect ALL
commands to use the SPI 4-4-4 protocol. Hence a failure does occur when
calling spi_nor_wait_till_ready() right after the update of the Enhanced
Volatile Configuration Register (EVCR) in the micron_quad_enable() as
the SPI controller driver is not aware about the protocol change.
Since there is almost no performance increase using Fast Read 4-4-4
commands instead of Fast Read 1-1-4 commands, we rather keep on using the
Extended SPI mode than enabling the Quad SPI mode.
Let's take the example of the pretty standard use of 8 dummy cycles during
Fast Read operations on 64KB erase sectors:
Fast Read 1-1-4 requires 8 cycles for the command, then 24 cycles for the
3byte address followed by 8 dummy clock cycles and finally 65536*2 cycles
for the read data; so 131112 clock cycles.
On the other hand the Fast Read 4-4-4 would require 2 cycles for the
command, then 6 cycles for the 3byte address followed by 8 dummy clock
cycles and finally 65536*2 cycles for the read data. So 131088 clock
cycles. The theorical bandwidth increase is 0.0%.
Now using Fast Read operations on 512byte pages:
Fast Read 1-1-4 needs 8+24+8+(512*2) = 1064 clock cycles whereas Fast
Read 4-4-4 would requires 2+6+8+(512*2) = 1040 clock cycles. Hence the
theorical bandwidth increase is 2.3%.
Consecutive reads for non sequential pages is not a relevant use case so
The Quad SPI mode is not worth it.
mtd_speedtest seems to confirm these figures.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Fixes: 548cd3ab54 ("mtd: spi-nor: Add quad I/O support for Micron SPI NOR")
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
The Spansion s25fl116k is a 16MBit NOR Flash supporting dual and
quad read operations.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
On Micron and Numonyx devices, the status register write command
(WRSR), raises a work-in-progress bit (WIP) on the status register.
The datasheets for these devices specify that while the status
register write is in progress, the status register WIP bit can still
be read to check the end of the operation.
This commit adds a wait_till_ready call on lock/unlock operations,
which is required for Micron and Numonyx but should be harmless for
others. This is needed to prevent applications from issuing erase or
program operations before the unlock operation is completed.
Reported-by: Stas Sergeev <stsp@list.ru>
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
stm_is_locked_sr() takes the status register (SR) value as the last
parameter, not the second.
Reported-by: Bayi Cheng <bayi.cheng@mediatek.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Bayi Cheng <bayi.cheng@mediatek.com>
Spansion and Winbond have occasionally used the same manufacturer ID,
and they don't support the same features. Particularly, writing SR=0
seems to break read access for Spansion's s25fl064k. Unfortunately, we
don't currently have a way to differentiate these Spansion and Winbond
parts, so rather than regressing support for these Spansion flash, let's
drop the new Winbond lock/unlock support for now. We can try to address
Winbond support during the next release cycle.
Original discussion:
http://patchwork.ozlabs.org/patch/549173/http://patchwork.ozlabs.org/patch/553683/
Fixes: 357ca38d47 ("mtd: spi-nor: support lock/unlock/is_locked for Winbond")
Fixes: c6fc2171b2 ("mtd: spi-nor: disable protection for Winbond flash at startup")
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reported-by: Felix Fietkau <nbd@openwrt.org>
Cc: Felix Fietkau <nbd@openwrt.org>
We should better check the return value from read_sr() and
propagate it in the case of error.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
The documenting comment of mtd_erase in mtdcore.c states:
Device drivers are supposed to call instr->callback() whenever
the operation completes, even if it completes with a failure.
Currently the callback isn't called in case of failure. Fix this.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
according datasheet both chips can erase 4kByte sectors individually
Signed-off-by: Andreas Fenkart <andreas.fenkart@dev.digitalstrom.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Some spi-nor drivers perform sector erase by duplicating their
write_reg() command. Let's not require that the driver fill this out,
and provide a default instead.
Tested on m25p80.c and Medatek's MT8173 SPI NOR flash driver.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
We can just alias to the MTD of_node.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Used semantic patch with 'make coccicheck MODE=patch COCCI=script.cocci':
---8<----
virtual patch
@@
struct spi_nor b;
struct spi_nor *c;
expression d;
@@
(
-(b).flash_node = (d)
+spi_nor_set_flash_node(&b, d)
|
-(c)->flash_node = (d)
+spi_nor_set_flash_node(c, d)
)
---8<----
And a manual conversion for the one use of spi_nor_get_flash_node().
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
We should pass along our flash DT node to the MTD layer, so it can set
up ofpart for us.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Many other flash share the same features as ST Micro. I've tested some
Winbond flash, so add them.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
This enables ioctl(MEMISLOCKED). Status can now be reported in the
mtdinfo or flash_lock utilities found in mtd-utils.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
This code was a bit sloppy, would produce a lot of copy-and-paste, and
did not always provide a sensible interface:
* It didn't validate the length for LOCK and the offset for UNLOCK, so
we were essentially discarding half of the user-supplied data and
assuming what they wanted to lock/unlock
* It didn't do very good error checking
* It didn't make use of the fact that this operation works on
power-of-two dimensions
So, rewrite this to do proper bit arithmetic rather than a bunch of
hard-coded condition tables. Now we have:
* More comments on how this was derived
* Notes on what is (and isn't) supported
* A more exendible function, so we could add support for other
protection ranges
* More accurate locking - e.g., suppose the top quadrant is locked (75%
to 100%); then in the following cases, case (a) will succeed but (b)
will not (return -EINVAL):
(a) user requests lock 3rd quadrant (50% to 75%)
(b) user requests lock 3rd quadrant, minus a few blocks (e.g., 50%
to 73%)
Case (b) *should* fail, since we'd have to lock blocks that weren't
requested. But the old implementation didn't know the difference and
would lock the entire second half (50% to 100%)
This refactoring work will also help enable the addition of
mtd_is_locked() support and potentially the support of bottom boot
protection (TB=1).
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
The N25Q032A is identical to the N25Q032 except it has a different
supply voltage range. Therefore, it has a new JEDEC ID.
Signed-off-by: Aurelien Chanot <chanot.a@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
This patch fixes timeout issues seen on large NOR flash (e.g., 16MB
w25q128fw) when using ioctl(MEMERASE) with offset=0 and length=16M. The
input parameters matter because spi_nor_erase() uses a different code
path for full-chip erase, where we use the SPINOR_OP_CHIP_ERASE (0xc7)
opcode.
Fix: use a different timeout for full-chip erase than for other
commands.
While most operations can be expected to perform relatively similarly
across a variety of NOR flash types and sizes (and therefore might as
well use a similar timeout to keep things simple), full-chip erase is
unique, because the time it typically takes to complete:
(1) is much larger than most operations and
(2) scales with the size of the flash.
Let's base our timeout on the original comments stuck here -- that a 2MB
flash requires max 40s to erase.
Small survey of a few flash datasheets I have lying around:
Chip Size (MB) Max chip erase (seconds)
---- -------- ------------------------
w25q32fw 4 50
w25q64cv 8 30
w25q64fw 8 100
w25q128fw 16 200
s25fl128s 16 ~256
s25fl256s 32 ~512
From this data, it seems plenty sufficient to say we need to wait for
40 seconds for each 2MB of flash.
After this change, it might make some sense to decrease the timeout for
everything else, as even the most extreme operations (single block
erase?) shouldn't take more than a handful of seconds. But for safety,
let's leave it as-is. It's only an error case, after all, so we don't
exactly need to optimize it.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
It is a 512KiB flash with 4 KiB erase sectors.
Signed-off-by: Yuan Yao <yao.yuan@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
s25fl016k can be found on Embedded Artists' LPC4357 Developer's Kit
where is used in quad mode by the LPC4357 SPIFI controller.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Sean Nyekjaer