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>

Use existing write_sr() call instead of decoding and
calling nor->write_reg separately.
Signed-off-by: NJagan Teki <jteki@openedev.com>
Cc: David Woodhouse <dwmw2@infradead.org>
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>

Commit 06bb6f5a ("mtd: spi-nor: stop (ab)using struct
spi_device_id") converted an array into a pointer, which means that
we should be checking if the pointer goes anywhere, not whether the C
string is empty. To do the latter means we dereference a NULL pointer
when we reach the terminating entry, for which 'name' is now NULL
instead of an array { 0, 0, ... }.

Sample crash:

[    1.101371] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[    1.109457] pgd = c0004000
[    1.112157] [00000000] *pgd=00000000
[    1.115736] Internal error: Oops: 5 [#1] SMP ARM
[    1.120345] Modules linked in:
[    1.123405] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.2.0-next-20150902+ #61
[    1.130611] Hardware name: Rockchip (Device Tree)
[    1.135306] task: ee0b8d40 ti: ee0ba000 task.ti: ee0ba000
[    1.140697] PC is at spi_nor_scan+0x90/0x8c4
[    1.144958] LR is at spi_nor_scan+0xa4/0x8c4
...
[    1.504112] [<c03cc2e0>] (spi_nor_scan) from [<c03cb188>] (m25p_probe+0xc8/0x11c)
[    1.511583] [<c03cb188>] (m25p_probe) from [<c03cd9d8>] (spi_drv_probe+0x60/0x7c)
[    1.519055] [<c03cd9d8>] (spi_drv_probe) from [<c037faa0>] (driver_probe_device+0x1a0/0x444)
[    1.527478] [<c037faa0>] (driver_probe_device) from [<c037fec8>] (__device_attach_driver+0x94/0xa0)
[    1.536507] [<c037fec8>] (__device_attach_driver) from [<c037db3c>] (bus_for_each_drv+0x94/0xa4)
[    1.545277] [<c037db3c>] (bus_for_each_drv) from [<c037f7e4>] (__device_attach+0xa4/0x144)
[    1.553526] [<c037f7e4>] (__device_attach) from [<c0380058>] (device_initial_probe+0x1c/0x20)
[    1.562035] [<c0380058>] (device_initial_probe) from [<c037ec88>] (bus_probe_device+0x38/0x94)
[    1.570631] [<c037ec88>] (bus_probe_device) from [<c037ccf4>] (device_add+0x430/0x558)
[    1.578534] [<c037ccf4>] (device_add) from [<c03d0240>] (spi_add_device+0xe4/0x174)
[    1.586178] [<c03d0240>] (spi_add_device) from [<c03d0a24>] (spi_register_master+0x698/0x7d4)
[    1.594688] [<c03d0a24>] (spi_register_master) from [<c03d0ba0>] (devm_spi_register_master+0x40/0x7c)
[    1.603892] [<c03d0ba0>] (devm_spi_register_master) from [<c03d2fb4>] (rockchip_spi_probe+0x360/0x3f4)
[    1.613182] [<c03d2fb4>] (rockchip_spi_probe) from [<c0381e34>] (platform_drv_probe+0x58/0xa8)
[    1.621779] [<c0381e34>] (platform_drv_probe) from [<c037faa0>] (driver_probe_device+0x1a0/0x444)
[    1.630635] [<c037faa0>] (driver_probe_device) from [<c037fdc4>] (__driver_attach+0x80/0xa4)
[    1.639058] [<c037fdc4>] (__driver_attach) from [<c037e850>] (bus_for_each_dev+0x98/0xac)
[    1.647221] [<c037e850>] (bus_for_each_dev) from [<c037f448>] (driver_attach+0x28/0x30)
[    1.655210] [<c037f448>] (driver_attach) from [<c037ef74>] (bus_add_driver+0x128/0x250)
[    1.663200] [<c037ef74>] (bus_add_driver) from [<c0380c40>] (driver_register+0xac/0xf0)
[    1.671191] [<c0380c40>] (driver_register) from [<c0381d50>] (__platform_driver_register+0x58/0x6c)
[    1.680221] [<c0381d50>] (__platform_driver_register) from [<c0a467c8>] (rockchip_spi_driver_init+0x18/0x20)
[    1.690033] [<c0a467c8>] (rockchip_spi_driver_init) from [<c00098a4>] (do_one_initcall+0x124/0x1dc)
[    1.699063] [<c00098a4>] (do_one_initcall) from [<c0a19f84>] (kernel_init_freeable+0x218/0x2ec)
[    1.707748] [<c0a19f84>] (kernel_init_freeable) from [<c0719ed8>] (kernel_init+0x1c/0xf4)
[    1.715912] [<c0719ed8>] (kernel_init) from [<c000fe50>] (ret_from_fork+0x14/0x24)
[    1.723460] Code: e3510000 159f67c0 0a00000c e5961000 (e5d13000)
[    1.729564] ---[ end trace 95baa6b3b861ce25 ]---

Fixes: 06bb6f5a ("mtd: spi-nor: stop (ab)using struct spi_device_id")
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Cc: Rafał Miłecki <zajec5@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>

Layering suggests that the SPI NOR layer (not the hardware driver)
should be initializing the MTD layer.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Tested-by: NJoachim Eastwood <manabian@gmail.com>

This chip can be found on Hitex LPC4350 Evaluation Board.
Signed-off-by: NJoachim Eastwood <manabian@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

According to the datasheet[1], both S25FL129P0 (256kB sectors) and
S25FL129P1 (64kB sectors) support dual read, quad read, dual i/o read
and quad i/o read.

I have verified dual read to be working for S25FL129P1 on a dual
capable spi controller. Quad as well as S25FL129P0 is untested, lacking
hardware to verify.

[1] http://www.spansion.com/Support/Datasheets/S25FL129P_00.pdfSigned-off-by: NJonas Gorski <jogo@openwrt.org>
Reviewed-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

It is a 256KiB flash with 4 KiB erase sectors
and 64KiB overlay blocks.

This is the one available on Hardkernel's Odroid U3 shield.
Signed-off-by: NAlexis Ballier <aballier@gentoo.org>
[Brian: seems like this does NOT require the usual SST_WRITE hacks]
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Add Micron (n25q064a) 8MB flash to the list of supported chips.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NJagan Teki <jteki@openedev.com>
[Brian: fixup context]
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Using struct spi_device_id for storing list of flash devices comes from
early SPI NOR framework days. Thanks to the commit 70f3ce05 ("mtd:
spi-nor: make spi_nor_scan() take a chip type name, not spi_device_id")
we can stop using spi_device_id and just switch to our own struct.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Spansion S25FL204K is a 4-Mbit 3.0V Serial Flash Memory
with Uniform 4 kB Sectors.
Signed-off-by: NAntony Pavlov <antonynpavlov@gmail.com>
Acked-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

When we added the "jedec,spi-nor" compatible string for use in this
driver, we added it as a modalias option. The modalias can be derived in
different ways for platform devices vs. device tree (of_*) matching. But
for device tree matching (the primary target of this identifier string),
the modalias is determined from the first entry in the 'compatible'
property. IOW, the following properties would bind to this driver:

	// Option (a), modalias = "spi-nor"
	compatible = "jedec,spi-nor";

	// Option (b), modalias = "spi-nor"
	compatible = "idontknowwhatimdoing,spi-nor";

But the following would not:

	// Option (c), modalias = "shinynewdevice"
	compatible = "myvendor,shinynewdevice", "jedec,spi-nor";

So, we'd like to match (a) and (c) (even when we don't have an explicit
entry for "shinynewdevice"), and we'd rather not allow (b).

To do this, we
  (1) always (for devices without specific platform data) pass the
      modalias to the spi-nor library;
  (2) rework the spi-nor library to not reject "bad" names, and
      instead just fall back to autodetection; and
  (3) add the .of_match_table to properly catch all "jedec,spi-nor".

This allows (a) and (c) without warnings, and rejects (b).
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Micron n25q064 flash supports 4 KiB erase sectors.
Signed-off-by: NAlexey Firago <alexey_firago@mentor.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Few recently added entries are missing SECT_4K flag despite of these
flashes supporting 4 KiB erase sectors and 0x20 erase command.
Also add a comment to help avoiding such mistakes in the future.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Cc: Knut Wohlrab <knut.wohlrab@de.bosch.com>
Cc: Huang Shijie <shijie.huang@intel.com>
Cc: Shengzhou Liu <shengzhou.liu@freescale.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

It's an 8 MiB flash with 4 KiB erase sectors.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Add Macronix (mx25u6435f) 8MB flash to the list of supported chips.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Add Winbond (w25q64dw) 8MB flash to the list of supported chips.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NLuka Perkov <luka@openwrt.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Add support for EON en25s64 SPI flash.
Signed-off-by: NShengzhou Liu <Shengzhou.Liu@freescale.com>
Signed-off-by: NBrian Norris <computersforpeace@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>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.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>

This will allow spi-nor users to plainly use JEDEC to detect flash chip.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

write_enable() was being duplicated to both m25p80.c and fsl-quadspi.c.
But this should be handled within the spi-nor abstraction layer.

At the same time, let's add write_disable() after erasing, so we don't
leave the flash in a write-enabled state afterward.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Acked-by: NHuang Shijie <shijie.huang@intel.com>

We need to store the six bytes ID for s25fl128s, since it shares the same
five bytes with s25fl129p1.

This patch adds a macro INFO6 which is used for the six bytes ID flash, and adds
a new item for the s25fl128s.
Signed-off-by: NHuang Shijie <shijie.huang@intel.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The "id" array contains all the information about the JEDEC and the
manufacturer ID info. This patch removes the jedec_id/ext_id from
flash_info.
Signed-off-by: NHuang Shijie <shijie.huang@intel.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This patch adds the id/id_len fields for flash_info{}, and rewrite the
INFO to fill them. And at last, we read out 6 bytes in the spi_nor_read_id(),
and we use these new fields to parse out the correct flash_info.
Signed-off-by: NHuang Shijie <shijie.huang@intel.com>
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Signed-off-by: NKnut Wohlrab <knut.wohlrab@de.bosch.com>
Signed-off-by: NAlison Chaiken <alison_chaiken@mentor.com>
Reviewed-by: NJagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

There are a few small issues with the timeout loop in
spi_nor_wait_till_ready():

 * The first operation should not be a reschedule; we should check the
   status register at least once to see if we're complete!

 * We should check the status register one last time after declaring the
   deadline has passed, to prevent a premature timeout error (this is
   theoretically possible if we sleep for a long time after the previous
   status register check).

 * Add an error message, so it's obvious if we ever hit a timeout.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Acked-by: NHuang Shijie <shijie.huang@intel.com>
Reviewed-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>

Add sst25wf080 to the spi-nor device id table.
Signed-off-by: NHarini Katakam <harinik@xilinx.com>
Reviewed-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Tested with this particular FRAM chip
Signed-off-by: NRostislav Lisovy <lisovy@merica.cz>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Because n25q032 is the Micron SPI chip, move it to Micron
devices list group. In order that know which Micron SPI
chips have been support at a glance.
Signed-off-by: NChunhe Lan <Chunhe.Lan@freescale.com>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Huang Shijie <shijie8@gmail.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>

We shouldn't have *every* function checking if a previous write is
complete; this should be done synchronously after each write/erase.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NMarek Vasut <marex@denx.de>

The error label was unused here. It looks like we're missing at least
one case that should be doing 'goto write_err'.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NMarek Vasut <marex@denx.de>
Acked-by: NHuang Shijie <shijie8@gmail.com>

These functions were near-carbon-copies due to a small per-flash quirk.
Let's add a new spi_nor::flags bitfield to support these types of
quirks.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NMarek Vasut <marex@denx.de>
Cc: Graham Moore <grmoore@altera.com>
Cc: Huang Shijie <shijie8@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

For the DDR Quad read, the dummy cycles maybe 3 or 6 which is less then 8.
The dummy cycles is actually 8 for SPI fast/dual/quad read.

This patch makes preparations for the DDR quad read, it fixes the wrong dummy
value for both the spi-nor.c and m25p80.c.
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>