Add support for GD25Q256, a 32MiB SPI Nor flash
from GigaDevice.
Signed-off-by: NAndy Yan <andy.yan@rock-chips.com>
Signed-off-by: NCyrille 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: NAndy Yan <andy.yan@rock-chips.com>
Signed-off-by: NCyrille 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: NKamal Dasu <kdasu.kdev@gmail.com>
Signed-off-by: NCyrille 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: NKamal Dasu <kdasu.kdev@gmail.com>
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@wedev4u.fr>

header.minor is of type u8 and cannot be negative.

Detected by CoverityScan CID#1417858 ("Integer handling issues")

Fixes: f384b352 ("mtd: spi-nor: parse Serial Flash Discoverable
Parameters (SFDP) tables")
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NCyrille 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: f384b352 ("mtd: spi-nor: parse Serial Flash Discoverable Parameters (SFDP) tables")
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@wedev4u.fr>
Signed-off-by: NBoris 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: f384b352 ("mtd: spi-nor: parse Serial Flash Discoverable Parameters (SFDP) tables")
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NCyrille Pitchen <cyrille.pitchen@wedev4u.com>

Add support for Microchip sst26vf064b QSPI memory.
Signed-off-by: NClaudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@wedev4u.fr>

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: NAlexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: NCyrille 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: NCyrille Pitchen <cyrille.pitchen@microchip.com>
Reviewed-by: NMarek Vasut <marek.vasut@gmail.com>

It's an 8 MiB flash with 4 KiB erase sectors.
Signed-off-by: NHarry Chou <HarryYC.Chou@gmail.com>
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@wedev4u.fr>

This chip supports stateless 4-byte opcodes, dual and quad read and
uniform 4K-byte erase.
Signed-off-by: NAlexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@wedev4u.fr>

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: NCédric Le Goater <clg@kaod.org>
Reviewed-by: NMarek Vasut <marek.vasut@gmail.com>
Signed-off-by: NCyrille 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: NCédric Le Goater <clg@kaod.org>
Reviewed-by: NMarek Vasut <marek.vasut@gmail.com>
Signed-off-by: NCyrille 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.pdfSigned-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NJoel Stanley <joel@jms.id.au>
Signed-off-by: NCyrille 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: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NCyrille 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: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Reviewed-by: NMarek 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: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Reviewed-by: NMarek 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: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Reviewed-by: NMarek Vasut <marek.vasut@gmail.com>

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: NMathias Kresin <dev@kresin.me>
Acked-by: NMarek Vasut <marek.vasut@gmail.com>
Signed-off-by: NCyrille 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: NNobuhiro Iwamatsu <nobuhiro.iwamatsu.kw@hitachi.com>
Signed-off-by: NCyrille 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: NAlexander Kurz <akurz@blala.de>
Signed-off-by: NCyrille 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: NAlexander Kurz <akurz@blala.de>
Signed-off-by: NCyrille 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: NMarcin Krzeminski <mar.krzeminski@gmail.com>
Signed-off-by: NCyrille 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: NMarcin Krzeminski <mar.krzeminski@gmail.com>
Signed-off-by: NCyrille 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.comSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus 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: NL. D. Pinney <ldpinney@gmail.com>
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>

Add GigaDevice GD25Q16 (16M-bit) to supported list.
Signed-off-by: NKamal Dasu <kdasu.kdev@gmail.com>
Acked-by: NMarek Vasut <marek.vasut@gmail.com>
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>

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: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Acked-by: NMarek Vasut <marek.vasut@gmail.com>
Signed-off-by: NCyrille 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: NVictor Shyba <victor1984@riseup.net>
Acked-by: NMarek Vasut <marek.vasut@gmail.com>
Signed-off-by: NCyrille 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: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Tested-by: NVignesh R <vigneshr@ti.com>
Acked-by: NMarek 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: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: NMark Brown <broonie@kernel.org>
Acked-by: NMarek 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: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Suggested-by: NRichard Weinberger <richard@nod.at>
Suggested-by: NAndras Szemzo <szemzo.andras@gmail.com>
Acked-by: NBoris 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: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Reviewed-by: NJagan Teki <jagan@openedev.com>
Acked-by: NMarek 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: NRicardo 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: NMarek Vasut <marek.vasut@gmail.com>
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>

Trivial typo fix in comment.
Signed-off-by: NNobuhiro Iwamatsu <nobuhiro.iwamatsu.kw@hitachi.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Add Everspin mr25h40 512KB MRAM to the list of supported chips.
Signed-off-by: NMasahiko Iwamoto <iwamoto@allied-telesis.co.jp>
Reviewed-by: NJagan Teki <jagan@openedev.com>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NCyrille 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: NMoritz Fischer <moritz.fischer@ettus.com>
Reviewed-by: NJagan Teki <jteki@openedev.com>
Signed-off-by: NCyrille 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: NJagan Teki <jteki@openedev.com>
Acked-by: NWenyou Yang <wenyou.yang@atmel.com>
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>

Signed-off-by: NSean Nyekjaer <sean.nyekjaer@prevas.dk>
Reviewed-by: NJagan Teki <jagan@openedev.com>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>