These are already-documented common bindings for NAND chips. Let's
handle them in nand_base.

If NAND controller drivers need to act on this data before bringing up
the NAND chip (e.g., fill out ECC callback functions, change HW modes,
etc.), then they can do so between calling nand_scan_ident() and
nand_scan_tail().
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

As all four bytes are written in any case the memset() is in vain.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

If a NAND device is not really present or pin muxes are not correctly
configured we can lock up the kernel waiting infinitely for NAND_STATUS
to be ready.

This can be easily reproduced on TI's DRA7-evm board by booting it
without NAND support in u-boot and disabling NAND pin muxes in the kernel.

Add timeout when waiting for NAND_CMD_RESET completion. As per ONFi v4.0
tRST can be upto 250ms for EZ-NAND and 5ms for raw NAND.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Tested-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

We're not initializing the ooblen field. Our users don't care, since
they check that oobbuf == NULL first, but it's good practice to zero
unused fields out.

We can drop the NULL initializations since we're memset()ing the whole
thing.

Noticed by Coverity, CID #200821, #200822
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Coverity noticed that these 'ret' assignments weren't being used. Let's
use them.

Note that nand_lock() and nand_unlock() are still not officially used by
any drivers.

Coverity CIDs #1227054 and #1227037
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Signed-off-by: NBaruch Siach <baruch@tkos.co.il>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Previously, we requested that drivers pass ecc.size and ecc.bytes when
using NAND_ECC_SOFT_BCH. However, a driver is likely to only know the ECC
strength required for its NAND, so each driver would need to perform a
strength-to-bytes calculation.

Avoid duplicating this calculation in each driver by asking drivers to
pass ecc.size and ecc.strength so that the strength-to-bytes calculation
need only be implemented once.

This reverts/generalizes this commit:
    mtd: nand: Base BCH ECC bytes on required strength
Signed-off-by: NAaron Sierra <asierra@xes-inc.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The MTD API reports -EUCLEAN only if the maximum number of bitflips
found in any ECC block exceeds a certain threshold. This is done to
avoid excessive -EUCLEAN reports to MTD users, which may induce
additional scrubbing of data, even when the ECC algorithm in use is
perfectly capable of handling the bitflips.

This threshold can be controlled by user-space (via sysfs), to allow
users to determine what they are willing to tolerate in their
application. But it still helps to have sane defaults.

In recent discussion [1], it was pointed out that our default threshold
is equal to the correction strength. That means that we won't actually
report any -EUCLEAN (i.e., "bitflips were corrected") errors until there
are almost too many to handle. It was determined that 3/4 of the
correction strength is probably a better default.

[1] http://lists.infradead.org/pipermail/linux-mtd/2015-January/057259.htmlSigned-off-by: NBrian Norris <computersforpeace@gmail.com>
Acked-by: NHuang Shijie <shijie.huang@intel.com>

Commit 7854d3f7 ("mtd: spelling, capitalization, uniformity") added
a correctly spelled line, but failed to remove the wrongly spelled one.
Commit 064a7694 ("mtd: Fix typo mtd/tests") then fixed the spelling
again, but left the duplication.

Fixes: 7854d3f7 ("mtd: spelling, capitalization, uniformity")
Signed-off-by: NBaruch Siach <baruch@tkos.co.il>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Add nand_shutdown to wait for current nand operations to finish and prevent
further operations by changing the nand flash state to FL_SHUTDOWN.

This is addressing a problem observed during reboot tests using UBIFS
root file system: NAND erase operations that are in progress during
system reboot/shutdown are causing partial erased blocks. Although UBI should
be able to detect and recover from this error, this change will avoid
the creation of partial erased blocks on reboot in the middle of a NAND erase
operation.
Signed-off-by: NScott Branden <sbranden@broadcom.com>
Tested-by: NScott Branden <sbranden@broadcom.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Signed-off-by: NGu Zheng <guz.fnst@cn.fujitsu.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

It may be useful info, e.g. if someone wants to use ubinize.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

update a comment in nand_command_lp() about specific requirements of
individual commands, the DEPLETE1 command was removed in the past and
the comment no longer applied
Signed-off-by: NGerhard Sittig <gsi@denx.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

NAND devices with page sizes over 4 KiB require more than 4-bits of ECC
coverage. This patch calculates the value of ecc_bytes based on a still
assumed 512-byte step size (13-bits) and the ecc_strength.

Example:
Micron M73A devices (8 KiB page) require 8-bit ECC per 512-byte
Signed-off-by: NJordan Friendshuh <jfriendshuh@xes-inc.com>
Signed-off-by: NAaron Sierra <asierra@xes-inc.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Add an onfi_timing_mode_default field to nand_chip and nand_flash_dev in
order to support NAND timings definition for non-ONFI NAND.

NAND that support better timings mode than the default one have to define
a new entry in the nand_ids table.

The default timing mode should be deduced from timings description from
the datasheet and the ONFI specification
(www.onfi.org/~/media/ONFI/specs/onfi_3_1_spec.pdf, chapter 4.15
"Timing Parameters").
You should choose the closest mode that fit the timings requirements of
your NAND chip.
Signed-off-by: NBoris BREZILLON <boris.brezillon@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This follows Chapter 2 of Linux's CodingStyle:
> However, never break user-visible strings such as printk messages,
> because that breaks the ability to grep for them.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

chip->pagebuf is a 32-bit type (int), so the shift will only be applied
as 32-bit. Fix this for 64-bit safety.

Caught by Coverity.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Do nand reset before write protect check.

If we want to check the WP# low or high through STATUS READ and check bit 7,
we must reset the device, other operation (eg.erase/program a locked block) can
also clear the bit 7 of status register.

As we know the status register can be refreshed, if we do some operation to trigger it,
for example if we do erase/program operation to one block that is locked, then READ STATUS,
the bit 7 of READ STATUS will be 0 indicate the device in write protect, then if we do
erase/program operation to another block that is unlocked, the bit 7 of READ STATUS will
be 1 indicate the device is not write protect.
Suppose we checked the bit 7 of READ STATUS is 0 then judge the WP# is low (write protect),
but in this case the WP# maybe high if we do erase/program operation to a locked block,
so we must reset the device if we want to check the WP# low or high through STATUS READ and
check bit 7.
Signed-off-by: NWhite Ding <bpqw@micron.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

In commit 67a9ad9b ("mtd: nand: Warn the user if the selected ECC
strength is too weak"), a check was added to inform the user when the
ECC used for a NAND device is weaker than the recommended ECC
advertised by the NAND chip. However, the warning uses WARN_ON(),
which has two undesirable side-effects:

 - It just prints to the kernel log the fact that there is a warning
   in this file, at this line, but it doesn't explain anything about
   the warning itself.

 - It dumps a stack trace which is very noisy, for something that the
   user is most likely not able to fix. If a certain ECC used by the
   kernel is weaker than the advertised one, it's most likely to make
   sure the kernel uses an ECC that is compatible with the one used by
   the bootloader, and changing the bootloader may not necessarily be
   easy. Therefore, normal users would not be able to do anything to
   fix this very noisy warning, and will have to suffer from it at
   every kernel boot. At least every time I see this stack trace in my
   kernel boot log, I wonder what new thing is broken, just to realize
   that it's once again this NAND ECC warning.

Therefore, this commit turns:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at /home/thomas/projets/linux-2.6/drivers/mtd/nand/nand_base.c:4051 nand_scan_tail+0x538/0x780()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 3.16.0-rc3-dirty #4
[<c000e3dc>] (unwind_backtrace) from [<c000bee4>] (show_stack+0x10/0x14)
[<c000bee4>] (show_stack) from [<c0018180>] (warn_slowpath_common+0x6c/0x8c)
[<c0018180>] (warn_slowpath_common) from [<c001823c>] (warn_slowpath_null+0x1c/0x24)
[<c001823c>] (warn_slowpath_null) from [<c02c50cc>] (nand_scan_tail+0x538/0x780)
[<c02c50cc>] (nand_scan_tail) from [<c0639f78>] (orion_nand_probe+0x224/0x2e4)
[<c0639f78>] (orion_nand_probe) from [<c026da00>] (platform_drv_probe+0x18/0x4c)
[<c026da00>] (platform_drv_probe) from [<c026c1f4>] (really_probe+0x80/0x218)
[<c026c1f4>] (really_probe) from [<c026c47c>] (__driver_attach+0x98/0x9c)
[<c026c47c>] (__driver_attach) from [<c026a8f0>] (bus_for_each_dev+0x64/0x94)
[<c026a8f0>] (bus_for_each_dev) from [<c026bae4>] (bus_add_driver+0x144/0x1ec)
[<c026bae4>] (bus_add_driver) from [<c026cb00>] (driver_register+0x78/0xf8)
[<c026cb00>] (driver_register) from [<c026da5c>] (platform_driver_probe+0x20/0xb8)
[<c026da5c>] (platform_driver_probe) from [<c00088b8>] (do_one_initcall+0x80/0x1d8)
[<c00088b8>] (do_one_initcall) from [<c0620c9c>] (kernel_init_freeable+0xf4/0x1b4)
[<c0620c9c>] (kernel_init_freeable) from [<c049a098>] (kernel_init+0x8/0xec)
[<c049a098>] (kernel_init) from [<c00095f0>] (ret_from_fork+0x14/0x24)
---[ end trace 62f87d875aceccb4 ]---

Into the much shorter, and much more useful:

nand: WARNING: MT29F2G08ABAEAWP: the ECC used on your system is too weak compared to the one required by the NAND chip
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

In addition to mtd_block_isbad(), which checks if a block is bad or
reserved, it's needed to check if a block is reserved only (but not
bad). This commit adds an MTD interface for it, in a similar fashion to
mtd_block_isbad().

While here, fix mtd_block_isbad() so the out-of-bounds checking is done
before the callback check.
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Tested-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This commit makes use of the chip->ecc_strength_ds and chip->ecc_step_ds which
contain the datasheet minimum requested ECC strength to produce a noisy warning
if the configured ECC strength is weaker.
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Signed-off-by: NRon Lee <ron@debian.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

nand_base can be passed a kmap()'d buffers from highmem by
filesystems like jffs2. This results in failure to map the
physical address of the DMA buffer on various contoller
driver on different platforms. This change adds a chip option
to use preallocated databuf as bounce buffers used in
nand_do_read_ops() and nand_do_write_ops().
This allows for specific nand controller driver to set this
option as needed.
Signed-off-by: NKamal Dasu <kdasu.kdev@gmail.com>
Signed-off-by: NBrian 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: NBrian Norris <computersforpeace@gmail.com>
Tested-by: NLee Jones <lee.jones@linaro.org>

Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: NBrian 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: NRon Lee <ron@debian.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Commit 7351d3a5 added an index variable
as part of fixing checkpatch warnings, presumably as a tool to make some
long lines shorter, however it only set that index in the case of there
being no gaps in eccpos for the fragment being read.  Which means the
later step of filling ecccode from oob_poi will use the wrong indexing
into eccpos in that case.

This patch restores the behaviour that existed prior to that change.
Signed-off-by: NRon Lee <ron@debian.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Mention to CONFIG_MTD_ECC_BCH in the warning message can be confusing as this
doesn't match the exact name of the configuration option.
This warning showed up once to me when I was starting to set up BCH. After
checking my .config file, it took a moment before realizing it is
CONFIG_MTD_NAND_ECC_BCH instead of CONFIG_MTD_ECC_BCH.
Signed-off-by: NErico Nunes <nunes.erico@gmail.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Add the "page" argument for the read_subpage hook. With this argument,
the implementation of this hook could prints out more accurate information
for debugging.
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The nand_get_flash_type parameter "busw" input value is not used by any
branch, and it is updated before use it in the function, so remove it,
define the "busw" as an internal variable.
Signed-off-by: NCai Zhiyong <caizhiyong@huawei.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Check the chip->jedec_version, and print out the right information
for JEDEC compliant NAND.
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This patch adds the parsing code for the JEDEC compliant NAND.

Since we need the 0x40 as the column address, this patch also
makes the NAND_CMD_PARAM to use the 8-bit address only.
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

read_buf is called in place of write_buf in the
nand_write_page_raw_syndrome function.
Signed-off-by: NBoris BREZILLON <b.brezillon.dev@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Use a repeated read_byte() instead of read_buf(), since for x16 buswidth
devices, we need to avoid the upper I/O[16:9] bits. See the following
commit for reference:

commit 05f78359
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Thu Dec 5 22:22:04 2013 +0100

    mtd: nand: don't use {read,write}_buf for 8-bit transfers

Now, I think that all barriers to probing ONFI on x16 devices are
removed, so remove the check from nand_flash_detect_onfi().

Tested on 8-bit ONFI NAND (Micron MT29F32G08CBADAWP).
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Tested-By: NPekon Gupta <pekon@ti.com>

The NAND command helpers tend to automatically shift the column address
for x16 bus devices, since most commands expect a word address, not a
byte address. The Read ID command, however, expects an 8-bit address
(i.e., 0x00, 0x20, or 0x40 should not be translated to 0x00, 0x10, or
0x20).

This fixes the column address for a few drivers which imitate the
nand_base defaults. Note that I don't touch sh_flctl.c, since it already
handles this problem slightly differently (note its comment "READID is
always performed using an 8-bit bus").

I have not tested this patch, as I only have x8 parts up for testing at
this point. Hopefully that can change soon...
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Tested-By: NPekon Gupta <pekon@ti.com>

The patch converts the arrays to buffer pointers for nand_buffers{}.

The cafe_nand.c is the only NAND_OWN_BUFFERS user which allocates
nand_buffers{} itself.

This patch disables the DMA for nand_scan_ident, and restores the DMA
status after we finish the nand_scan_ident. This way, we can get page
size and OOB size and use them to allocate cafe->dmabuf.

Since the cafe_nand.c uses the NAND_ECC_HW_SYNDROME ECC mode, we do not
allocate the buffers for @ecccalc and @ecccode.
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

A flash may support N read retry voltage threshold modes, numbered 0
through N-1 (where mode 0 represents the initial state). However,
nand_do_read_ops() tries to use mode 0 through N.

This off-by-one error shows up, for instance, when using nanddump, and
we have cycled through available modes:

    nand: setting READ RETRY mode 0
    nand: setting READ RETRY mode 1
    nand: setting READ RETRY mode 2
    nand: setting READ RETRY mode 3
    nand: setting READ RETRY mode 4
    nand: setting READ RETRY mode 5
    nand: setting READ RETRY mode 6
    nand: setting READ RETRY mode 7
    nand: setting READ RETRY mode 8
    libmtd: error!: cannot read 8192 bytes from mtd0 (eraseblock 20, offset 0)
            error 22 (Invalid argument)
    nanddump: error!: mtd_read

Tested on Micron MT29F64G08CBCBBH1, with 8 retry modes.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Acked-by: NHuang Shijie <b32955@freescale.com>

Assume that:
          tmp = ((extid >> 2) & 0x04) | (extid & 0x03));

From the K9LCG08U0B's datasheet, we know that:
  the oob size is 640 when tmp is 6;
  the oob size is 1024 when tmp is 7;
Signed-off-by: NHuang Shijie <b32955@freescale.com>
[Brian: fixed compile issue]
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

According to the Open NAND Flash Interface Specification (ONFI) Revision
3.1 "Parameters are always transferred on the lower 8-bits of the data
bus." for the Get Features and Set Features commands.

So using read_buf and write_buf is wrong for 16-bit wide nand chips as
they use I/O[15:0]. The Get Features command is easily fixed using 4
times the read_byte callback. For Set Features implement a new
overwritable callback "write_byte". Still I expect the default to work
just fine for all controllers and making it overwriteable was just done
for symmetry.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
[Brian: fixed warning]
Tested-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>