As subpage write is enabled by default for all drivers, nand_write_subpage_hwecc
causes a crash if the driver did not register ecc->hwctl or ecc->calculate.
This behavior was introduced in
   commit 837a6ba4
   "mtd: nand: subpage write support for hardware based ECC schemes".

This fixes a crash by emulating subpage write support by padding sub-page data
with 0xff on either sides to make it full page compatible.
Reported-by: Helmut Schaa <helmut.schaa@googlemail.com>
Tested-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Scott Wood <scottwood@freescale.com>
Cc: <stable@vger.kernel.org> # 3.10.x+
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

The samsung onenand driver passes around a dma address token
through a void pointer, which is incorrect and leads to
warnings like this one:

onenand/samsung.c:548:2: warning: passing argument 1 of '__fswab32' makes integer from pointer without a cast [enabled by default]
  writel(src, base + S5PC110_DMA_SRC_ADDR);
  ^

This patch makes it use dma_addr_t here, which is more appropriate.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: linux-mtd@lists.infradead.org
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

Make of_device_id array const, because all OF functions
handle it as const.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

Make of_device_id array const, because all OF functions
handle it as const.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

Make of_device_id array const, because all OF functions
handle it as const.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

On m68k, where access_ok() doesn't cast the address parameter:

drivers/mtd/mtdchar.c: In function 'mtdchar_write_ioctl':
drivers/mtd/mtdchar.c:575:4: warning: passing argument 2 of 'access_ok' makes pointer from integer without a cast [enabled by default]
arch/m68k/include/asm/uaccess_mm.h:17:90: note: expected 'const void *' but argument is of type '__u64'
drivers/mtd/mtdchar.c:576:4: warning: passing argument 2 of 'access_ok' makes pointer from integer without a cast [enabled by default]
arch/m68k/include/asm/uaccess_mm.h:17:90: note: expected 'const void *' but argument is of type '__u64'

The address parameter of access_ok() is really a userspace pointer.
On most architectures, access_ok() is a macro that casts the address
parameter, hiding issues in its users.

Move around and use the existing usr_data and usr_oob temporary variables
to kill the warnings. Add a few "consts", and make more use of the
temporaries while we're at it.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

fixes: commit 62116e51
       mtd: nand: omap2: Support for hardware BCH error correction.

In omap_elm_correct_data(), if bitflip_count in an erased-page is within the
correctable limit (< ecc.strength), then it is not indicated back to the caller
ecc->read_page().

This mis-guides upper layers like MTD and UBIFS layer to assume erased-page as
perfectly clean and use it for writing even if actual bitflip_count was
dangerously high (bitflip_count > mtd->bitflip_threshold).

This patch fixes this above issue, by returning 'stats' to caller
ecc->read_page() under all scenarios.
Reported-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Pekon Gupta <pekon@ti.com>
Cc: <stable@vger.kernel.org> # 3.9.x+
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

Spansion s25sl032p supports Dual and Quad SPI transfers, hence set the
SPI_NOR_DUAL_READ and SPI_NOR_QUAD_READ flags.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

Commit 03e296f6 ("mtd: m25p80: use the SPI
nor framework") accidentally removed support for Dual SPI read transfers.
Add it back.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Huang Shijie <shijie8@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

Fixes:
drivers/mtd/devices/elm.c:480:12: warning: 'elm_suspend' defined but not used [-Wunused-function]
drivers/mtd/devices/elm.c:488:12: warning: 'elm_resume' defined but not used [-Wunused-function]
Signed-off-by: Wolfram Sang <wsa@sang-engineering.com>
Acked-by: Pekon Gupta <pekon@ti.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

Anyone working with an AMD Elan SC520 development or evaluation board
would be building a dedicated kernel for it, so we can make the
sc520cdp and netsc520 maps depend on MELAN. SC520_CPUFREQ already
depends on MELAN so it makes things more consistent. It also makes
kernel configuration for every other x86 user easier.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

The nand_chip::erase_cmd callback previously served a dual purpose; for
one, it allowed a per-flash-chip override, so that AG-AND devices could
use a different erase command than other NAND. These AND devices were
dropped in commit 14c65786 (mtd: nand:
remove AG-AND support). On the other hand, some drivers (denali and
doc-g4) need to use this sort of callback to implement
controller-specific erase operations.

To make the latter operation easier for some drivers (e.g., ST's new BCH
NAND driver), it helps if the command dispatch and wait functions can be
lumped together, rather than called separately.

This patch does two things:
 1. Pull the call to chip->waitfunc() into chip->erase_cmd(), and return
    the status from this callback
 2. Rename erase_cmd() to just erase(), since this callback does a
    little more than just send a command
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by: Lee Jones <lee.jones@linaro.org>

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

mtd_oobtest writes OOB, read it back and verify.  The verification is
not correctly done if oobsize is not multiple of 4.  Although the data
to be written and the data to be compared are generated by several
prandom_byte_state() calls starting with the same seed, these two are
generated with the different size and different number of calls.

Due to the implementation of prandom_byte_state() if the size on each
call is not multiple of 4, the resulting data is not always same.

This fixes it by just calling prandom_byte_state() once and using
correct range instead of calling it multiple times for each.
Reported-by: George Cherian <george.cherian@ti.com>
Reported-by: Lothar Waßmann <LW@KARO-electronics.de>
Tested-by: Lothar Waßmann <LW@KARO-electronics.de>
Cc: George Cherian <george.cherian@ti.com>
Cc: Lothar Waßmann <LW@KARO-electronics.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: linux-mtd@lists.infradead.org
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

Addition of the spi-nor framework, plus updates to the ST SPI FSM
driver.

COMPILE_TEST allows us to build this driver on other arch'es. But not
all arch'es have the right I/O accessors -- particularly, x86 is missing
readsl() and writesl().

So just restrict this driver to ARCH_STI. It's still buildable for a
multiplatform ARM kernel, so it can get decent compile coverage.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Lee Jones <lee.jones@linaro.org>

Compile-testing for a 64-bit arch uncovers several bad casts:

    In file included from include/linux/linkage.h:4:0,
                     from include/linux/kernel.h:6,
                     from drivers/mtd/devices/st_spi_fsm.c:15:
    drivers/mtd/devices/st_spi_fsm.c: In function ‘stfsm_read_fifo’:
    drivers/mtd/devices/st_spi_fsm.c:758:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
      BUG_ON((((uint32_t)buf) & 0x3) || (size & 0x3));
    ...

Use uintptr_t instead of uint32_t, since it's guaranteed to be
pointer-sized.

We also see this warning, if size_t is not 32 bits wide:

    In file included from drivers/mtd/devices/st_spi_fsm.c:15:0:
    drivers/mtd/devices/st_spi_fsm.c: In function ‘stfsm_mtd_write’:
    include/linux/kernel.h:712:17: warning: comparison of distinct pointer types lacks a cast [enabled by default]
      (void) (&_min1 == &_min2);  \
                     ^
    drivers/mtd/devices/st_spi_fsm.c:1704:11: note: in expansion of macro ‘min’
       bytes = min(FLASH_PAGESIZE - page_offs, len);
               ^

Just use min_t() to force the type conversion, since we don't really
want to upgrade 'page_offs' and 'bytes' to size_t; they only should be
handling <= 256 byte offsets.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Lee Jones <lee.jones@linaro.org>

This corrects some sparse warnings:

   drivers/mtd/spi-nor/fsl-quadspi.c:281:31: warning: incorrect type in initializer (different address spaces) [sparse]
   drivers/mtd/spi-nor/fsl-quadspi.c:281:31:    expected void *[noderef] <asn:2>base [sparse]
   drivers/mtd/spi-nor/fsl-quadspi.c:281:31:    got void [noderef] <asn:2>*iobase [sparse]
   (etc.)
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Huang Shijie <b32955@freescale.com>

More and more chips use the GPMI controller, but these chips may use different
version of the IPs for GPMI and BCH. Different IPs have
 different features, such as the BCH's maximum ECC strength:

     imx23/imx28 -- the BCH's maximum ECC strength is 20
     imx6q       -- the BCH's maximum ECC strength is 40
     imx6sx      -- the BCH's maximum ECC strength is 62

This patch does the following things:

  [1] add a new data structure, gpmi_devdata{}, to store the information for
      each IP. Besides the IP version, we store the following information:
         <1> BCH's maximum ECC strength.
         <2> the maximum chain delay in ns used by the EDO mode.

      but we may add more information in future.

  [2] add the gpmi_devdata_imx{23|28|6q} to replace the gpmi_ids.

  [3] simplify the code by using the ECC strength from gpmi_devdata, such as
      gpmi_check_ecc() and legacy_set_geometry();

  [4] use the maximum chain delay to initialize the EDO mode,
      see gpmi_compute_edo_timing().

  [5] rewrite the macros, such GPMI_IS_MX{23|28|6Q}.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

Add line feed to pr_err.
Signed-off-by: Raphaël Poggi <poggi.raph@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

Sub page write doesn't work because of hw issue in controller found on
Keystone SOCs. AEMIF controller is also used on DaVinci SOCs which
don't seems to have any issue. So add "ti,keysone-nand" compatible
to nand driver in order to set NAND_NO_SUBPAGE_WRITE option.

Cc: Warner Losh <imp@bsdimp.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

mtd_blkdevs is device with volatile cache (writeback buffer), so it should support
REQ_FLUSH to do explicit flush.

Without this patch 'sync' does not guarantee that writeback buffer will be flushed
on disk in case of power off, e.g.:

  $ cp some_file /mnt
  $ sync

  ### POWER OFF

In case of this sequence writeback buffer will not be flushed on disk.

This patch fixes this behaviour and explicitly reports to block layer that flush
requests are being supported.
Signed-off-by: Roman Peniaev <r.peniaev@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: linux-mtd@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

Now that the index variable is correctly set earlier in this function
we can use it in other places that compute the same thing too.
Signed-off-by: Ron Lee <ron@debian.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

Commit 2c9f2365 (mtd: nand: omap: ecc.calculate: merge omap3_calculate_ecc_bch4
in omap_calculate_ecc_bch) introduced minor compile warning
"‘erased_sector_bitflips’ defined but not used [-Wunused-function]" when
compiling without CONFIG_MTD_NAND_OMAP_BCH. Move function
erased_sector_bitflips() into the same ifdef section as the only caller.
Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Pekon Gupta <pekon@ti.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

There's no reason this can't be a module. Also, give SPI-NOR its own
submenu.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>

Many of the serial_flash_cmds.h opcodes are duplicated with spi-nor.h.
Let's begin to unify them.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Marek Vasut <marex@denx.de>

Begin to unify the differences between serial_flash_cmds.h and
spi-nor.h.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Marek Vasut <marex@denx.de>

These are also in serial_flash_cmds.h. (FWIW, I didn't know the C
preprocessor allowed redefinitions without warning like this.)
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Marek Vasut <marex@denx.de>

I hear that this driver should depend on ARCH_STI, and that "SH" is not
actually a real symbol. At the same time, let's allow compile-testing on
other ARCH'es.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Marek Vasut <marex@denx.de>

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Huang Shijie <b32955@freescale.com>

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>

serial_flash_cmds.h defines our opcodes a little differently. Let's
borrow its naming, since it's borrowed from the SFDP standard, and it's
more extensible.

This prepares us for merging serial_flash_cmds.h and spi-nor.h opcode
listing.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Huang Shijie <b32955@freescale.com>

Qualify these with a better namespace, and prepare them for use in more
drivers.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Huang Shijie <b32955@freescale.com>

Spacing is a little non-standard here. Fix up tabs vs. spaces.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Huang Shijie <b32955@freescale.com>
Reviewed-by: Marek Vasut <marex@denx.de>

Add the copyright information for spi-nor.c and spi-nor.h.
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

This patch adds support for the Macronix MX25L3255E device.  Unlike the other
Macronix devices we have seen, this device supports WRITE_1_4_4 at reasonable
frequencies.  Rather than masking out WRITE_1_4_4 support altogether, we now
rely on the table parameters to indicate whether or not WRITE_1_4_4 should be
used.
Signed-off-by: Angus Clark <angus.clark@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

Add Spansion S25FL032P to the list of known devices.
Signed-off-by: Angus Clark <angus.clark@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

This patch refactors the fsm_read_status() and fsm_write_status() code to
support 1 or 2 byte operations, with a specified command.  This allows us to
remove device/register specific code, such as the N25Q fsm_wrvcr() function.

The 'QE' configuration code is updated accordingly, with minor tweaks to ensure
the register values are only written if actually required.  One notable change
in this area is that the 'W25Q_STATUS_QE' bit-field is now defined with respect
to the 'SR2' register, rather than the combined 'SR1+SR2' register which is only
used for write operations.
Signed-off-by: Angus Clark <angus.clark@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

Update the configuration of the Macronix 'QE' bit, such that
we only set or clear the bit if required.
Signed-off-by: Angus Clark <angus.clark@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

Support for the Macronix 32-bit addressing scheme was originally developed using
the MX25L25635E device.  As is often the case, it was found that the presence of
a "WAIT" instruction was required for the "EN4B/EX4B" FSM Sequence to complete.
(It is known that the SPI FSM Controller makes certain undocumented assumptions
regarding what constitutes a valid sequence.)  However, further testing
suggested that a small delay was required after issuing the "EX4B" command;
without this delay, data corruptions were observed, consistent with the device
not being ready to retrieve data.  Although the issue was not fully understood,
the workaround of adding a small delay was implemented, while awaiting
clarification from Macronix.

The same behaviour has now been found with a second Macronix device, the
MX25L25655E.  However, with this device, it seems that the delay is also
required after the 'EN4B' commands.  This discovery has prompted us to revisit
the issue.

Although still not conclusive, further tests have suggested that the issue is
down to the SPI FSM Controller, rather than the Macronix devices.  Furthermore,
an alternative workaround has emerged which is to set the WAIT time to
0x00000001, rather then 0x00000000.  (Note, the WAIT instruction is used purely
for the purpose of achieving "sequence validity", rather than actually
implementing a delay!)

The issue is now being investigated by the Design and Validation teams.  In the
meantime, we implement the alternative workaround, which reduces the effective
delay from 1us to 1ns.
Signed-off-by: Angus Clark <angus.clark@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>