The driver call nand_scan_ident in 8 bit mode, then
readid or onfi detection are done (and detect bus width).
The driver should update its bus width before calling nand_scan_tail.

This work because readid and onfi are read work 8 byte mode.

Note that nand_scan_ident send command (NAND_CMD_RESET, NAND_CMD_READID, NAND_CMD_PARAM), address and read data
The ONFI specificication is not very clear for x16 device if high byte of address should be driven to 0,
but according to [1] it should be ok to not drive it during autodetection.

[1]
3.3.2. Target Initialization

[...]
The Read ID and Read Parameter Page commands only use the lower 8-bits of the data bus.
The host shall not issue commands that use a word data width on x16 devices until the host
determines the device supports a 16-bit data bus width in the parameter page.
Signed-off-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Add missing colons to fix kernel-doc generation warnings.
Signed-off-by: NRobert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Some Hynix and Samsung MLC NAND have 640B OOB size. Sooner or later, we should
dynamically allocate the buffers that use these macros.
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>

add onfi_get_async_timing_mode() to get the supportted asynchronous
timing mode.

add onfi_get_sync_timing_mode() to get the supportted synchronous
timing mode.

Also add the neccessary macros : the timing modes.
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Add the set-features(0xef)/get-features(0xee) helpers for ONFI nand.
Also add the necessary macros.
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

In the absence of any formal documentation of the nand interface, I thought this
patch to the header file might be helpful.
Signed-off-by: NMike Dunn <mikedunn@newsguy.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Added a NAND device flag for subpage read support. Previously this was
hard coded based on large page and soft ECC.
Updated base NAND driver to use the new subpage read flag if the NAND is
large page and soft ECC.
Signed-off-by: NJeff Westfahl <jeff.westfahl@ni.com>
Reviewed-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>

Fix kernel-doc warning in <linux/mtd/nand.h>:

Warning(include/linux/mtd/nand.h:659): No description found for parameter 'read_byte'
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Acked-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>

Just as Artem suggested:

"Both UBI and JFFS2 are able to read verify what they wrote already.
There are also MTD tests which do this verification. So I think there
is no reason to keep this in the NAND layer, let alone wasting RAM in
the driver to support this feature. Besides, it does not work for sub-pages
and many drivers have it broken. It hurts more than it provides benefits."

So kill MTD_NAND_VERIFY_WRITE entirely.
Signed-off-by: NHuang Shijie <shijie8@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

The NAND_CHIPOPTIONS_MSK has limited utility and is causing real bugs. It
silently masks off at least one flag that might be set by the driver
(NAND_NO_SUBPAGE_WRITE). This breaks the GPMI NAND driver and possibly
others.

Really, as long as driver writers exercise a small amount of care with
NAND_* options, this mask is not necessary at all; it was only here to
prevent certain options from accidentally being set by the driver. But the
original thought turns out to be a bad idea occasionally. Thus, kill it.

Note, this patch fixes some major gpmi-nand breakage.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Tested-by: NHuang Shijie <shijie8@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

There is an implemention of hardware ECC write page function which may return an
error indication.
For instance, using Atmel HW PMECC to write one page into a nand flash, the hardware
engine will compute the BCH ecc code for this page. so we need read a the
status register to theck whether the ecc code is generated.
But we cannot assume the status register always can be ready, for example,
incorrect hardware configuration or hardware issue, in such case we need
write_page() to return a error code.

Since the definition of 'write_page' function in struct nand_ecc_ctrl is 'void'.
So this patch will:
  1. add return 'int' value for 'write_page' function.
  2. to be consitent, add return 'int' value for 'write_page_raw' fuctions too.
  3. add code to test the return value, and if negative, indicate an
  error happend when write page with ECC.
  4. fix the compile warning in all impacted nand flash driver.

Note: I couldn't compile-test all of these easily, as some had ARCH dependencies.
Signed-off-by: NJosh Wu <josh.wu@atmel.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

According to its documentation, the NAND_NO_READRDY option is always used
when autoincrement is not supported. Autoincrement support was recently
dropped, so we can drop this options as well (defaulting to "no read ready
check").
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>

Eon's new NAND flash: EN27LN1G08.
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>

As of [mtd: nand: remove autoincrement 'sndcmd' code], the
NAND_CMD_READ0 command is issued unconditionally.

Thus, read_oob/read_oob_raw's 'sndcmd' argument is no longer needed, as
well as their return code.

Remove the 'sndcmd' parameter, and set the return code to 0.
Signed-off-by: NShmulik Ladkani <shmulik.ladkani@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

New NAND controllers can perform read/write via HW engines which don't expose
OOB data in their DMA mode. To reflect this, we should rework the nand_chip /
nand_ecc_ctrl interfaces that assume that drivers will always read/write OOB
data in the nand_chip.oob_poi buffer. A better interface includes a boolean
argument that explicitly tells the callee when OOB data is requested by the
calling layer (for reading/writing to/from nand_chip.oob_poi).

This patch adds the 'oob_required' parameter to each relevant {read,write}_page
interface; all 'oob_required' parameters are left unused for now. The next
patch will set the parameter properly in the nand_base.c callers, and follow-up
patches will make use of 'oob_required' in some of the callee functions.

Note that currently, there is no harm in ignoring the 'oob_required' parameter
and *always* utilizing nand_chip.oob_poi, but there can be
performance/complexity/design benefits from avoiding filling oob_poi in the
common case. I will try to implement this for some drivers which can be ported
easily.

Note: I couldn't compile-test all of these easily, as some had ARCH
dependencies.

[dwmw2: Merge later 1/0 vs. true/false cleanup]
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NShmulik Ladkani <shmulik.ladkani@gmail.com>
Acked-by: NJiandong Zheng <jdzheng@broadcom.com>
Acked-by: NMike Dunn <mikedunn@newsguy.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Lantiq SoCs have a External Bus Unit (EBU) that is used to attach MTD media.
As we need to co-exist with PCI on the same bus, certain swapping settings must
be applied. Similar to the NOR map driver we need to apply a fix to make NAND
work. The easiest way is to use byte reads.
Signed-off-by: NJohn Crispin <blogic@openwrt.org>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

No drivers use auto-increment NAND, so kill the NO_AUTOINCR option entirely.
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>

The drivers' _read() method, absent an error, returns a non-negative integer
indicating the maximum number of bit errors that were corrected in any one
region comprising an ecc step.  MTD returns -EUCLEAN if this is >=
bitflip_threshold, 0 otherwise.  If bitflip_threshold is zero, the comparison is
not made since these devices lack ECC and always return zero in the non-error
case (thanks Brian)¹.  Note that this is a subtle change to the driver
interface.

This and the preceding patches in this set were tested with ubi on top of the
nandsim and docg4 devices, running the ubi test io_basic from mtd-utils.

¹ http://lists.infradead.org/pipermail/linux-mtd/2012-March/040468.htmlSigned-off-by: NMike Dunn <mikedunn@newsguy.com>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Acked-by: NBrian Norris <computersforpeace@gmail.com>
Ivan Djelic <ivan.djelic@parrot.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This adds 'ecc_strength' to struct mtd_info.  This stores the maximum number of
bit errors that can be corrected in one writesize region.

For consistency with the nand code, 'strength' is similiarly added to struct
nand_ecc_ctrl.  This stores the maximum number of bit errors that can be
corrected in one ecc step.
Signed-off-by: NMike Dunn <mikedunn@newsguy.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

The description for badblockbits is incorrect. I think someone just made
up a false description on the spot to satisfy some kerneldoc warning.
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>

Macronix is produing SLC NAND MX30LF1208AA, so add their manufacturer
code to the manufacturer lists.
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>

The nand_chip.ops field is a struct that is passed around globally with
no particular reason. Every time it is used, it could just as easily be
replaced with a local struct that is updated on each operation. So make
it local.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@intel.com>

This fixes issues with `nanddump -n' and the MEMREADOOB[64] ioctls on
hardware that performs error correction when reading only OOB data. A
driver for such hardware needs to know when we're doing a RAW vs. a
normal write, but mtd_do_read_oob does not pass such information to the
lower layers (e.g., NAND). We should pass MTD_OOB_RAW or MTD_OOB_PLACE
based on the MTD file mode.

For now, most drivers can get away with just setting:

  chip->ecc.read_oob_raw = chip->ecc.read_oob

This is done by default; but for systems that behave as described above,
you must supply your own replacement function.

This was tested with nandsim as well as on actual SLC NAND.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Cc: Jim Quinlan <jim2101024@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@intel.com>

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

This fixes issues with `nandwrite -n -o' and the MEMWRITEOOB[64] ioctls
on hardware that writes ECC when writing OOB. The problem arises as
follows: `nandwrite -n' can write page data to flash without applying
ECC, but when used with the `-o' option, ECC is applied (incorrectly),
contrary to the `--noecc' option.

I found that this is the case because my hardware computes and writes
ECC data to flash upon either OOB write or page write. Thus, to support
a proper "no ECC" write, my driver must know when we're performing a raw
OOB write vs. a normal ECC OOB write. However, MTD does not pass any raw
mode information to the write_oob functions.  This patch addresses the
problems by:

1) Passing MTD_OOB_RAW down to lower layers, instead of just defaulting
   to MTD_OOB_PLACE
2) Handling MTD_OOB_RAW within the NAND layer's `nand_do_write_oob'
3) Adding a new (replaceable) function pointer in struct ecc_ctrl; this
   function should support writing OOB without ECC data. Current
   hardware often can use the same OOB write function when writing
   either with or without ECC

This was tested with nandsim as well as on actual SLC NAND.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Cc: Jim Quinlan <jim2101024@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@intel.com>

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

The set_parts and priv members of struct platform_nand_chip where
removed in commit c36a6ef3845262ade529afb9f458738b1f196f83 but the
kerneldoc wasn't updated.
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NArtem Bityutskiy <dedekind1@gmail.com>

Therefor -> Therefore
[Intern], [Internal] -> [INTERN]
[REPLACABLE] -> [REPLACEABLE]
syndrom, syndom -> syndrome
ecc -> ECC
buswith -> buswidth
endianess -> endianness
dont -> don't
occures -> occurs
independend -> independent
wihin -> within
erease -> erase
blockes -> blocks
...
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Drop now unused set_parts from struct platform_nand_data. Also, while we are
at it, drop long unused priv field from platform_nand_data.
Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

After several steps of rearrangement and consolidation, it is probably
worth re-sequencing the numbers on some of our affected flags in nand.h
and bbm.h.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

The NAND_CREATE_EMPTY_BBT flag was added by commit:
  453281a9
  mtd: nand: introduce NAND_CREATE_EMPTY_BBT
This flag is not used within the kernel and not explained well, so I
took the liberty to edit its comments.

Also, this is a BBT-related flag (and closely tied with NAND_BBT_CREATE)
so I'm moving it to bbm.h next to NAND_BBT_CREATE, thus requiring that
we use the flag in nand_chip.bbt_options, *not* in nand_chip.options.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

This patch works with the following three flags from two headers (nand.h
and bbm.h):
  (1) NAND_USE_FLASH_BBT (nand.h)
  (2) NAND_USE_FLASH_BBT_NO_OOB (nand.h)
  (3) NAND_BBT_NO_OOB (bbm.h)

These flags are all related and interdependent, yet they were in
different headers. Flag (2) is simply the combination of (1) and (3) and
can be eliminated.

This patch accomplishes the following:
  * eliminate NAND_USE_FLASH_BBT_NO_OOB (i.e., flag (2))
  * move NAND_USE_FLASH_BBT (i.e., flag (1)) to bbm.h

It's important to note that because (1) and (3) are now both found in
bbm.h, they should NOT be used in the "nand_chip.options" field.

I removed a small section from the mtdnand DocBook because it referes to
NAND_USE_FLASH_BBT in nand.h, which has been moved to bbm.h.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

This patch handles the problems we've been having with using conflicting
flags from nand.h and bbm.h in the same nand_chip.options field. We
should try to separate these two spaces a little more clearly, and so I
have added a bbt_options field to nand_chip.

Important notes about nand_chip fields:
* bbt_options field should contain ONLY flags from bbm.h. They should be
  able to pass safely to a nand_bbt_descr data structure.
    - BBT option flags start with the "NAND_BBT_" prefix.
* options field should contian ONLY flags from nand.h. Ideally, they
  should not be involved in any BBT related options.
    - NAND chip option flags start with the "NAND_" prefix.
* Every flag should have a nice comment explaining what the flag is. While
  this is not yet the case on all existing flags, please be sure to write
  one for new flags. Even better, you can help document the code better
  yourself!

Please try to follow these conventions to make everyone's lives easier.

Among the flags that are being moved to the new bbt_options field
throughout various drivers, etc. are:
 * NAND_BBT_SCANLASTPAGE
 * NAND_BBT_SCAN2NDPAGE
and there will be more to come.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

The NAND_USE_FLASH_BBT_NO_OOB and NAND_CREATE_EMPTY_BBT flags conflict
with the NAND_BBT_SCANBYTE1AND6 and NAND_BBT_DYNAMICSTRUCT flags,
respectively. This change will allow us to utilize these options
independently.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>

This patch adds software BCH ECC support to mtd, in order to handle recent
NAND device ecc requirements (4 bits or more).

It does so by adding a new ecc mode (NAND_ECC_SOFT_BCH) for use by board
drivers, and a new Kconfig option to enable BCH support. It relies on the
generic BCH library introduced in a previous patch.

When a board driver uses mode NAND_ECC_SOFT_BCH, it should also set fields
chip->ecc.size and chip->ecc.bytes to select BCH ecc data size and required
error correction capability. See nand_bch_init() documentation for details.

It has been tested on the following platforms using mtd-utils, UBI and
UBIFS: x86 (with nandsim), arm926ejs.
Signed-off-by: NIvan Djelic <ivan.djelic@parrot.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Warning(include/linux/mtd/nand.h:543): No description found for parameter 'badblockbits'
Warning(drivers/mtd/nand/nand_bbt.c:1101): No description found for parameter 'mtd'
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc:	David Woodhouse <dwmw2@infradead.org>
Cc:	linux-mtd@lists.infradead.org
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Remove tabs between type and name.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

- *var instead of * var
- proper multiline comment
- func(args) instead of func (args)
- 80 lines

So from
|total: 2 errors, 37 warnings, 654 lines checked
we got to one warning.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

it will create an empty BBT table without considering vendor's BBT
information. Vendor's information may be unavailable if the NAND
controller has a different DATA & OOB layout or this information may be
allready purged.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>