The FIXME and NOTE have already been fixed (we have FAST_READ support).
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NSourav Poddar <sourav.poddar@ti.com>
Acked-by: NMarek Vasut <marex@denx.de>

This patch fixes two memory errors:

1. During a probe failure (in mtd_device_parse_register?) the command
   buffer would not be freed.

2. The command buffer's size is determined based on the 'fast_read'
   boolean, but the assignment of fast_read is made after this
   allocation. Thus, the buffer may be allocated "too small".

To fix the first, just switch to the devres version of kzalloc.

To fix the second, increase MAX_CMD_SIZE unconditionally. It's not worth
saving a byte to fiddle around with the conditions here.

This problem was reported by Yuhang Wang a while back.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reported-by: NYuhang Wang <wangyuhang2014@gmail.com>
Reviewed-by: NSourav Poddar <sourav.poddar@ti.com>
Cc: <stable@vger.kernel.org>

Micron N25Q512A is a spi flash memory with following features:
-64MB size, 1.8V, Mulitple I/O, 4KB Sector erase memory.
-Memory is organised as 1024(64KB) main sectors.
-Each sector is divided into 256 pages.
-Register set/Opcodes are similar to other N25Q family products.
Signed-off-by: NPriyanka Jain <Priyanka.Jain@freescale.com>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This flashchip is used in D-Link DIR-610 A1 router board
and maybe several others, yet is not kernel upstream.

So add support for it according to datasheet [0], making it easier
to support other boards using this flashchip in the future.

[0] http://www.esmt.com.tw/DB/manager/upload/F25L32PA.pdfSigned-off-by: NFlavio Silveira <fggs@terra.com.br>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

According to the datasheet for Micron n25q256a (N25Q256A13ESF40F) 4-byte
addressing mode should be entered as follows:

<quote>
To enter or exit the 4-byte address mode, the WRITE ENABLE command
must be executed to set the write enable latch bit to 1. (Note: The
WRITE ENABLE command must NOT be executed on the N25Q256A83ESF40x and
N25Q256A83E1240x devices.) S# must be driven LOW. The effect of the
command is immediate; after the command has been executed, the write
enable latch bit is cleared to 0.
</quote>

Micron's portable way to perform this for all types of Micron flash
is to first issue a write enable, then switch the addressing mode
followed by a write disable to avoid leaving the flash in a write-
able state.
Signed-off-by: NElie De Brauwer <eliedebrauwer@email.com>
[Brian: reworked a bit]
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Add support for PMC (now Chingis, part of ISSI) Pm25LV512 (512 Kib),
Pm25LV010 (1 Mib) and Pm25LQ032 (32 Mib) SPI Flash chips.

This patch addresses two generations of PMC SPI Flash chips:

 - Pm25LV512 and Pm25LV010: these have 4KiB sectors and 32KiB
   blocks. The 4KiB sector erase uses a non-standard opcode
   (0xd7). They do not support JEDEC RDID (0x9f), and so they can only
   be detected by matching their name string with pre-configured
   platform data. Because of the cascaded acquisitions, the datasheet
   is no longer available on the current manufacturer's website,
   although it is still commonly used in some recent wireless routers
   (<https://forum.openwrt.org/viewtopic.php?pid=186360#p186360>). The
   only public datasheet available seems to be on GeoCities:
   <http://www.geocities.jp/scottle556/pdf/Pm25LV512-010.pdf>

 - Pm25LQ032: a newer generation flash, with 4KiB sectors and 64KiB
   blocks. It uses the standard erase and JEDEC read-ID
   opcodes. Manufacturer's datasheet is here:
   <http://www.chingistek.com/img/Product_Files/Pm25LQ032C%20datasheet%20v1.6.1.pdf>

This patch is resent in order to take into account both Brian Norris
remarks and this upstream patch:

commit e534ee4f
Author: Krzysztof Mazur <krzysiek@podlesie.net>
Date:   Fri Feb 22 15:51:05 2013 +0100

    mtd: m25p80: introduce SST_WRITE flag for SST byte programming

    Not all SST devices implement the SST byte programming command.
    Some devices (like SST25VF064C) implement only standard m25p80 page
    write command.

    Now SPI flash devices that need sst_write() are explicitly marked
    with new SST_WRITE flag and the decision to use sst_write() is based
    on this flag instead of manufacturer id.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NMichel Stempin <michel.stempin@wanadoo.fr>
[Brian: fixed conflict]
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This adds support for the Everspin mr25h10 MRAM chip to the m25p80
driver.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This patch adds a flag to struct flash_info indicating that
fast_read is not supported. This now gives the following logic
when determing whether to enable fastread:

If the flash chip does not support fast_read, then disable it.
Otherwise:
1) enable fast_read if device node contains m25p,fast-read
2) enable fast_read if forced in Kconfig

This makes enabling CONFIG_M25PXX_USE_FAST_READ a safe option
since we no longer enable the fast_read option unconditionally.

For now fast_read is disabled for the everspin mr25h256 and the
catalyst devices. Others may need the flag aswell.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

The flags may have to be overwritten, so add them to the CAT25_INFO
macro.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

of_property_read_bool properly compiles away, no need to ifdef this
for non DT builds.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

For SPI NOR flash that are larger than 128Mbit (16MiB), we need 4 bytes
of address space to reach the entire flash; however, the original SPI
flash protocol used only 3 bytes for the address. So far, the practice
for handling this has been either to use new command opcodes that are
defined to use 4 bytes for their address, or to use special
mode-switching command to configure all traditionally-3-byte-address
commands to take 4 bytes instead.

Macronix and Spansion developed two incompatible methods for
entering/exiting "4-byte address mode." Micron flash uses the Macronix
method (OPCODE_{EN4B,EX4B}), not the Spansion method.

This patch solves addressing issues on Micron n25q256a and provides the
ability to support other future Micron SPI flash >16MiB.

Quoting a Micron representative:

  "Majority of our NOR that needs 4-byte addressing (256Mb or 32MB and
   higher) enter and exit 4byte through B7h and E9h commands. The
   N25Q256A7xxx and N25Q512A7xxx parts do not support 4-byte addressing
   mode via B7h or E9h command."

They further clarified that those that don't support the enter/exit
opcodes (B7h/E9h) are manufactured specifically to come up by default in
4-byte mode. We don't need to treat those parts any diffently, as they
will discard the EN4B opcode as a no-op.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Added a 16MiB winbond devce to the device list
erase size = 64KiB and number of blocks = 256.
Signed-off-by: NGirish K S <ks.giri@samsung.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Traditionally, the command set used by SPI flash only supported a 3-byte
address. However, large SPI flash (>= 32MiB, or 256Mib) require 4 bytes
to address the entire flash. Most manufacturers have supplied a mode
switch (via a "bank register writer", or a "enable 4-byte mode"
command), which tells the flash to expect 4 address cycles from now on,
instead of 3. This mode remains until power is cut, the reset line is
triggered (on packages where present), or a command is sent to reset the
flash or to reset the 3-byte addressing mode.

As an alternative, some flash manufacturers have developed a new command
set that accept a full 4-byte address. They can be used orthogonally to
any of the modes; that is, they can be used when the flash is in either
3-byte or 4-byte address mode.

Now, there are a number of reasons why the "stateful" 4-byte address
mode switch may not be acceptable. For instance, some SoC's perform a
dumb boot sequence in which they only send 3-byte read commands to the
flash. However, if an unexpected reset occurs, the flash chip cannot be
guaranteed to return to its 3-byte mode. Thus, the SoC controller and
flash will not understand each other. (One might consider hooking up the
aforementioned reset pin to the system reset line so that any system
reset will reset the flash to 3-byte mode, but some packages do not
provide this pin. And in some other packages, one must choose between
having a reset pin and having enough pins for 4-output QSPI support.
It is an error prone process choosing a flash that will support a
hardware reset pin!)

This patch provides support for the new stateless command set, so that
we can avoid the problems that come with a stateful addressing mode
change. The flash can be left in "3-byte mode" while still accessing the
entire flash.

Note that Spansion supports this command set on all its large flash
(e.g, S25FL512S), and Macronix has begun supporting this command set on
some new flash (e.g., MX25L25635F). For the moment, I don't know how to
differentiate the Macronix that don't support this command set (e.g.,
MX25L25635E) from those that do, so this patch only supports Spansion.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Use the wrapper functions for getting and setting the driver data using
spi_device instead of using dev_{get|set}_drvdata with &spi->dev, so we
can directly pass a struct spi_device.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This device was reported over a year ago on OpenWrt mailing list in the
thread [OpenWrt-Devel] RedBoot partition table with winbond m25q128vb
(unfortunately, I can't find message id). Macpaul seemed to have
problems with partition driver, but it seems the device was working OK.
Reported-by: NMacpaul Lin <macpaul@gmail.com>
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NKrzysztof Mazur <krzysiek@podlesie.net>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Not all SST devices implement the SST byte programming command.
Some devices (like SST25VF064C) implement only standard m25p80 page
write command.

Now SPI flash devices that need sst_write() are explicitly marked
with new SST_WRITE flag and the decision to use sst_write() is based
on this flag instead of manufacturer id.
Signed-off-by: NKrzysztof Mazur <krzysiek@podlesie.net>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Acked-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Add support for GigaDevice GD25Q32 32 Mbit (4 MB) SPI Flash (see datasheet:
http://www.gigadevice.com/UserFiles/GD25Q32_Rev0.2(1).pdf) used in Hame MPR-A1
and clones, and for GigaDevice GD25Q64 64 Mbit (8 MB) SPI Flash used in
Hame MPR-A2 devices (datasheet: http://www.gigadevice.com/UserFiles/GD25Q64.pdf).
Signed-off-by: NMichel Stempin <michel.stempin@wanadoo.fr>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

This patch adds generic support for flash protection on STmicro chips.
On chips with less than 3 protection bits, the unused bits are don't cares
and so can be written anyway. The lock function will only change the
protection bits if it would not unlock other areas. Similarly, the unlock
function will not lock currently unlocked areas. Tested on the m25p64.
Signed-off-by: NAustin Boyle <Austin.Boyle@aviatnet.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Micron N25Q128 has two types of flash:

 - One is for 1.8v supply voltage, prefixed with "n25q128a11" and the jedec
   code is 0x20bb18.

 - Another is for 3v supply voltage, prefixed with "n25q128a13" and the jedec
   code is 0x20ba18.

So modify the original type info and add another type for Micron N25Q128.
Signed-off-by: NLiming Wang <walimisdev@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Signed-off-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Add DT property "m25p,fast-read" that signalises the particular
chip supports "fast read" opcode.
Signed-off-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Quoting from the datasheet for S25FL064P, rev. 05, Nov 18 2011, § 9.17:

"A 64 kB[sic] sector erase (D8h) command issued on 4 kB or 8 kB erase
sectors will erase all sectors in the specified 64 kB region. However,
please note that a 4 kB sector erase (20h) or 8 kB sector erase (40h)
command will not work on a 64 kB sector."

Referring further to Table 8.1 and Table 8.2, it is clearly seen
that most of the sectors are 64KiB; therefore disable this 4KiB
erase support since it's valid only on first/last sectors.
Signed-off-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NJan Luebbe <jlu@pengutronix.de>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

The manufacturer datasheet can be found on the Micron website,
under the name n25q_256mb_3v_65nm.pdf:

http://www.micron.com/search?source=ps&q=n25q_256mb_3v_65nmSigned-off-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Due to the implementation of the following loop at the end
of jedec_probe():

776         for (tmp = 0; tmp < ARRAY_SIZE(m25p_ids) - 1; tmp++) {
777                 info = (void *)m25p_ids[tmp].driver_data;
778                 if (info->jedec_id == jedec) {
779                         if (info->ext_id != 0 && info->ext_id != ext_jedec)
780                                 continue;
781                         return &m25p_ids[tmp];
782                 }
783         }

In particular line 779 in the above numbering, the chips with ext_id != 0 must
be ordered first in the list of chips (m25p_ids[]).
Signed-off-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NKnut Wohlrab <knut.wohlrab@de.bosch.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NChunhe Lan <Chunhe.Lan@freescale.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NAlexandre Pereira da Silva <aletes.xgr@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>