Based on Cyrille Pitchen's patch https://lkml.org/lkml/2017/3/22/935.

This patch is a transitional patch in introducing  the support of
SFDP SPI memories with non-uniform erase sizes like Spansion s25fs512s.
Non-uniform erase maps will be used later when initialized based on the
SFDP data.

Introduce the memory erase map which splits the memory array into one
or many erase regions. Each erase region supports up to 4 erase types,
as defined by the JEDEC JESD216B (SFDP) specification.

To be backward compatible, the erase map of uniform SPI NOR flash memories
is initialized so it contains only one erase region and this erase region
supports only one erase command. Hence a single size is used to erase any
sector/block of the memory.

Besides, since the algorithm used to erase sectors on non-uniform SPI NOR
flash memories is quite expensive, when possible, the erase map is tuned
to come back to the uniform case.

The 'erase with the best command, move forward and repeat' approach was
suggested by Cristian Birsan in a brainstorm session, so:
Suggested-by: NCristian Birsan <cristian.birsan@microchip.com>
Signed-off-by: NTudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: NMarek Vasut <marek.vasut@gmail.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

Commit 59b356ff ("mtd: m25p80: restore the status of SPI flash when
exiting") is the latest from a long history of attempts to add reboot
handling to handle stateful addressing modes on SPI flash. Some prior
mostly-related discussions:

http://lists.infradead.org/pipermail/linux-mtd/2013-March/046343.html
[PATCH 1/3] mtd: m25p80: utilize dedicated 4-byte addressing commands

http://lists.infradead.org/pipermail/barebox/2014-September/020682.html
[RFC] MTD m25p80 3-byte addressing and boot problem

http://lists.infradead.org/pipermail/linux-mtd/2015-February/057683.html
[PATCH 2/2] m25p80: if supported put chip to deep power down if not used

Previously, attempts to add reboot-time software reset handling were
rejected, but the latest attempt was not.

Quick summary of the problem:
Some systems (e.g., boot ROM or bootloader) assume that they can read
initial boot code from their SPI flash using 3-byte addressing. If the
flash is left in 4-byte mode after reset, these systems won't boot. The
above patch provided a shutdown/remove hook to attempt to reset the
addressing mode before we reboot. Notably, this patch misses out on
huge classes of unexpected reboots (e.g., crashes, watchdog resets).

Unfortunately, it is essentially impossible to solve this problem 100%:
if your system doesn't know how to reset the SPI flash to power-on
defaults at initialization time, no amount of software can really rescue
you -- there will always be a chance of some unexpected reset that
leaves your flash in an addressing mode that your boot sequence didn't
expect.

While it is not directly harmful to perform hacks like the
aforementioned commit on all 4-byte addressing flash, a
properly-designed system should not need the hack -- and in fact,
providing this hack may mask the fact that a given system is indeed
broken. So this patch attempts to apply this unsound hack more narrowly,
providing a strong suggestion to developers and system designers that
this is truly a hack. With luck, system designers can catch their errors
early on in their development cycle, rather than applying this hack long
term. But apparently enough systems are out in the wild that we still
have to provide this hack.

Document a new device tree property to denote systems that do not have a
proper hardware (or software) reset mechanism, and apply the hack (with
a loud warning) only in this case.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

Winbond spi-nor flash 32MB and larger have an 'Extended Address
Register' as one option for addressing beyond 16MB (Macronix
has the same concept, Spansion has EXTADD bits in the Bank Address
Register).

According to section
   8.2.7 Write Extended Address Register (C5h)

of the Winbond W25Q256FV data sheet (256M-BIT SPI flash)

   The Extended Address Register is only effective when the device is
   in the 3-Byte Address Mode.  When the device operates in the 4-Byte
   Address Mode (ADS=1), any command with address input of A31-A24
   will replace the Extended Address Register values. It is
   recommended to check and update the Extended Address Register if
   necessary when the device is switched from 4-Byte to 3-Byte Address
   Mode.

So the documentation suggests clearing the EAR after switching to
3-byte mode.  Experimentation shows that the EAR is *always* one after
the switch to 3-byte mode, so clearing the EAR is mandatory at
shutdown for a subsequent 3-byte-addressed reboot to work.

Note that some SOCs (e.g. MT7621) do not assert a reset line at normal
reboot, so we cannot rely on hardware reset.  The MT7621 does assert a
reset line at watchdog-reset.
Acked-by: NMarek Vasut <marek.vasut@gmail.com>
Signed-off-by: NNeilBrown <neil@brown.name>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NHou Zhiqiang <Zhiqiang.Hou@nxp.com>
Signed-off-by: NCyrille 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: Nbeanhuo <beanhuo@micron.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>

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>

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>

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>

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>

Do not pass retlen to hardware driver read/write functions. Update it in
spi-nor generic driver instead.
Signed-off-by: NMichal Suchanek <hramrach@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Tested-by Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: NMichal Suchanek <hramrach@gmail.com>
Tested-by: NMichal 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: NMichal Suchanek <hramrach@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Tested-by Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: NMichal Suchanek <hramrach@gmail.com>
Tested-by: NMichal 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: NBrian Norris <computersforpeace@gmail.com>
Acked-by: NMarek Vasut <marex@denx.de>

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: NBrian Norris <computersforpeace@gmail.com>
Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>

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: 357ca38d ("mtd: spi-nor: support lock/unlock/is_locked for Winbond")
Fixes: c6fc2171 ("mtd: spi-nor: disable protection for Winbond flash at startup")
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reported-by: NFelix Fietkau <nbd@openwrt.org>
Cc: Felix Fietkau <nbd@openwrt.org>

So far struct spi_nor was using just a pointer to struct mtd_info so it
wasn't needed to have it fully defined there. After recent change we
embed whole struct so we need to include a proper header.

Fixes: 19763671 ("mtd: spi-nor: embed struct mtd_info within struct spi_nor")
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NBrian 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: NBrian Norris <computersforpeace@gmail.com>

We can just alias to the MTD of_node.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

We are going to begin using the mtd->dev.of_node field for MTD device
nodes, so let's add helpers for it. Also, we'll be making some
conversions on spi_nor (and nand_chip eventually) too, so get that ready
with their own helpers.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

This enables ioctl(MEMISLOCKED). Status can now be reported in the
mtdinfo or flash_lock utilities found in mtd-utils.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

I got the names of these fields wrong.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

These are often similar for CFI (parallel NOR) and for SPI NOR, but they
aren't always the same, for various reasons (different namespaces,
company acquisitions and renames, etc.). And some don't have CFI_MFR_*
entries at all.

So let's make a proper place to list the SPI NOR IDs, with all the SPI
NOR specific assumptions and comments.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

These status bits use different ways of representing similar integer
constants -- some are decimal, some are hex. Make them more consistent.

At the same time, impose my own preference, since IMO it's clearer what
these are when using the BIT() macro.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

We use BIT() in the header. No real problem for now, but it's better to
be accurate.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

struct spi_nor_xfer_cfg and read_xfer/write_xfer hooks were never used by
any driver. Do some cleanup by removing them.
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Reviewed-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The 'write_enable' argument is unused and unneeded, so remove it from
the API.
Signed-off-by: NJagan Teki <jteki@openedev.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Han Xu <han.xu@freescale.com>
[Brian: fixed for nxp-spifi.c]
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The problem this patch is trying to address is such, that SPI NOR flash
devices attached to a dedicated SPI NOR controller cannot read their
properties from the associated struct device_node.

A couple of facts first:
1) Each SPI NOR flash has a struct spi_nor associated with it.
2) Each SPI NOR flash has certain device properties associated
   with it, for example the OF property 'm25p,fast-read' is a
   good pick. These properties are used by the SPI NOR core to
   select which opcodes are sent to such SPI NOR flash. These
   properties are coming from spi_nor .dev->of_node .

The problem is, that for SPI NOR controllers, the struct spi_nor .dev
element points to the struct device of the SPI NOR controller, not the
SPI NOR flash. Therefore, the associated dev->of_node also is the
one of the controller and therefore the SPI NOR core code is trying to
parse the SPI NOR controller's properties, not the properties of the
SPI NOR flash.

Note: The m25p80 driver is not affected, because the controller and
      the flash are the same device, so the associated device_node
      of the controller and the flash are the same.

This patch adjusts the SPI NOR core such that the device_node is not
picked from spi_nor .dev directly, but from a new separate spi_nor
.flash_node element. This let's the SPI NOR controller drivers set up
a different spi_nor .flash_node element for each SPI NOR flash.

This patch also fixes the controller drivers to be compatible with
this modification and correctly set the spi_nor .flash_node element.

This patch is inspired by 5844feea
mtd: nand: add common DT init code
Signed-off-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This reflects the proper layering, so let's do it.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Tested-by: NJoachim Eastwood <manabian@gmail.com>

This header can't actually stand alone, as it relies on the declaration
(but not definition) of struct mtd_info. Let's fix that.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Tested-by: NJoachim Eastwood <manabian@gmail.com>

Flash lock/unlock is a flash-specific operations. Factor out a callback
for it to more readily support other vendors.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Tested-by: NVIET NGA DAO <vndao@altera.com>

This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes.

For Micron SPI NOR flash, enabling or disabling quad I/O protocol can be
done By two methods, which are to use EVCR (Enhanced Volatile
Configuration Register) and the ENTER QUAD I/O MODE command. There is no
difference between these two methods. Unfortunately, for some Micron SPI
NOR flashes, there no ENTER Quad I/O command (35h), such as n25q064. But
for all current Micron SPI NOR, if it support quad I/O mode, using EVCR
definitely be supported. It is a recommended method to enable Quad I/O
mode by EVCR, Quad I/O protocol bit 7. When EVCR bit 7 is reset to 0,
the SPI NOR flash will operate in quad I/O mode.

This patch has been tested on N25Q512A and MT25TL256BAA1ESF. Micron SPI
NOR of spi_nor_ids[] table all support this method.
Signed-off-by: NBean Huo <beanhuo@micron.com>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

We don't need to expose a 'wait-till-ready' interface to drivers. Status
register polling should be handled by the core spi-nor.c library, and as
of now, I see no need to provide a special driver-specific hook for it.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NMarek Vasut <marex@denx.de>

spi-nor.c should be taking care of these now.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NMarek Vasut <marex@denx.de>

There is currently no useful way to override the default
implementation of this operation.  The returned struct spi_device_id
must have a pointer to struct flash_info in its private data, but this
structure is defined inside spi-nor.
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

m25p80's device ID table is now spi_nor_ids, defined in spi-nor.  The
MODULE_DEVICE_TABLE() macro doesn't work with extern definitions, but
its use was also removed at the same time.  Now if m25p80 is built as
a module it doesn't get the necessary aliases to be loaded
automatically.

A clean solution to this will involve defining the list of device
IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
API, but this is quite a large change.

As a quick fix suitable for stable, copy the device IDs back into
m25p80.

Fixes: 03e296f6 ("mtd: m25p80: use the SPI nor framework")
Cc: <stable@vger.kernel.org> # 3.16.x: 32f1b7c8: mtd: move support for struct flash_platform_data into m25p80
Cc: <stable@vger.kernel.org> # 3.16.x: 90e55b38: mtd: m25p80: get rid of spi_get_device_id
Cc: <stable@vger.kernel.org> # 3.16.x: 70f3ce05: mtd: spi-nor: make spi_nor_scan() take a chip type name, not spi_device_id
Cc: <stable@vger.kernel.org> # 3.16.x
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Drivers currently call spi_nor_match_id() and then spi_nor_scan().
This adds a dependency on struct spi_device_id which we want to
avoid.  Make spi_nor_scan() do it for them.
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Some new Micron flash chips require reading the flag status register to
determine when operations have completed.

Furthermore, chips with multi-die stacks of the 65nm 256Mb QSPI also
require reading the status register before reading the flag status
register.

This patch adds support for the flag status register in the n25q512ax3
and n25q00 Micron QSPI flash chips.
Signed-off-by: NGraham Moore <grmoore@altera.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>