RAW writes were broken by 782ce79a
which introduced a check of ops->ooboffs in nand_do_write_ops().

When writing in RAW mode this is called with an ops struct on the stack
of mtdchar.c:mtd_write() which does not initialise ops->ooboffs, so it
is garbage and fails this test.

This test does not make sense if ops->oobbuf is NULL, which it is in the
RAW write path, so include that in the test.
Signed-off-by: NJon Povey <jon.povey@racelogic.co.uk>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Not all the NAND devices have all the information in additional
id bytes.

So add a hook in the nand_chip{} is a good method to calculate the
right value of oobsize, erasesize and so on.

Without the hook,you will get the wrong value, and you have to hack
in the ->scan_bbt() to change the wrong value which make the code
mess.
Signed-off-by: NHuang Shijie <shijie8@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Currently MTD caches the last read NAND page, even if there was an uncorrectable ECC
error. This patch prevents caching in case of uncorrectable ECC errors. The reason
is that we want to allow the user to re-read the NAND page several times. In case of
unstable bits re-trying may help.

Moreover, current behavior is wrong because the first read returns -EBADMSG (correctly)
but the second read succeeds and incorrectly returns 0 (because we read from the cache).
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Only 3 warnings are left, one is off by one character, but splitting the line
would reduce the readability. One is for a for loop statement, which would also
not improve readability. The last one is a false positive on a test.

Artem: it is much easier to verify patches against nand_base.c with
       checkpatch.pl when nand_base.c itself does not have so many
       checkpatch.pl warnings.
Signed-off-by: NFlorian Fainelli <ffainelli@freebox.fr>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Artem: it is much easier to verify patches against nand_base.c with
       checkpatch.pl when nand_base.c itself does not have so many
       checkpatch.pl warnings.
Signed-off-by: NFlorian Fainelli <ffainelli@freebox.fr>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

In order to reduce the indentation and improve the readability of nand_get_
flash_type, split the ONFI detection logic to its own function. The detection
logic inside nand_flash_detect_onfi is also rewritten to allow for less
indentation.
Signed-off-by: NFlorian Fainelli <ffainelli@freebox.fr>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This patch adds support for reading NAND device ONFI parameters and use
the ONFI informations to define its geometry. In case the device supports
ONFI, the onfi_version field in struct nand_chip contains the version (BCD)
and the onfi_params structure can be used by drivers to set up timings and
such. We currently only support ONFI 1.0 parameters.
Signed-off-by: NBrian Norris <norris@broadcom.com>
Signed-off-by: NMatthieu Castet <matthieu.castet@parrot.com>
Signed-off-by: NMaxime Bizon <mbizon@freebox.fr>
Signed-off-by: NFlorian Fainelli <ffainelli@freebox.fr>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

There are some additions to the detection scheme used by Samsung
MLC NAND. These simple changes to support the 400- and 436-byte OOB
are found in the following data sheet:

Samsung K9GBG08U0M (p.40)
Signed-off-by: NBrian Norris <norris@broadcom.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Toshiba does not use ONFI for their NAND flash. So we have to continue
to add new IDs used by Toshiba devices as well as heuristic detection
for scanning the 2nd page for a BBM. This is a relatively harmless
start at supporting many of them.

These chips mostly follow the same ID fields of previous generations,
but there is a need for a tweak.

These chips introduce a strange 576 byte OOB (that's 36 bytes per
512 bytes of page). In the preliminary data, Toshiba has not
defined exactly how their ID strings should decode. In the future,
a new tweak must be added.

Data is taken from, among others, Toshiba TC58TxG4S2FBAxx
Signed-off-by: NBrian Norris <norris@broadcom.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Some Spansion chips have a method for determining eraseblock size that
is incompatible with similar ID chips of other sizes. This implements
some heuristic detection of these differences.

This patch checks for a 5-byte ID with trailing zeros as well as a
512-byte page size to ensure that chips are not misdetected as the
S30MLxxxP ORNAND series.

[Tweaked by Artem a bit]
Signed-off-by: NBrian Norris <norris@broadcom.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Drivers may (and do) return negative errno values other than -1 from the
ecc.correct callback.
Signed-off-by: NBaruch Siach <baruch@tkos.co.il>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Apparently, the check for a 6-byte ID string introduced by commit
426c457a ("mtd: nand: extend NAND flash
detection to new MLC chips") is NOT sufficient to determine whether or
not a Samsung chip uses their new MLC detection scheme or the old,
standard scheme. This adds a condition to check cell type.
Signed-off-by: NTilman Sauerbeck <tilman@code-monkey.de>
Signed-off-by: NBrian Norris <norris@broadcom.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
Cc: stable@kernel.org

Commit c7b28e25 ("mtd: nand: refactor BB 
marker detection") caused a regression in detection of factory-set bad 
block markers, especially for certain small-page NAND. This fix removes 
some unneeded constraints on using NAND_SMALL_BADBLOCK_POS, making the 
detection code more correct.

This regression can be seen, for example, in Hynix HY27US081G1M and
similar.
Signed-off-by: NBrian Norris <norris@broadcom.com>
Tested-by: NMichael Guntsche <mike@it-loops.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Fix mtd/nand_base.c kernel-doc warnings and typos.

Warning(drivers/mtd/nand/nand_base.c:893): No description found for parameter 'mtd'
Warning(drivers/mtd/nand/nand_base.c:893): No description found for parameter 'ofs'
Warning(drivers/mtd/nand/nand_base.c:893): No description found for parameter 'len'
Warning(drivers/mtd/nand/nand_base.c:893): No description found for parameter 'invert'
Warning(drivers/mtd/nand/nand_base.c:930): No description found for parameter 'mtd'
Warning(drivers/mtd/nand/nand_base.c:930): No description found for parameter 'ofs'
Warning(drivers/mtd/nand/nand_base.c:930): No description found for parameter 'len'
Warning(drivers/mtd/nand/nand_base.c:987): No description found for parameter 'mtd'
Warning(drivers/mtd/nand/nand_base.c:987): No description found for parameter 'ofs'
Warning(drivers/mtd/nand/nand_base.c:987): No description found for parameter 'len'
Warning(drivers/mtd/nand/nand_base.c:2087): No description found for parameter 'len'
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix mtd/nand_base.c kernel-doc warnings and typos.

Warning(drivers/mtd/nand/nand_base.c:893): No description found for parameter 'mtd'
Warning(drivers/mtd/nand/nand_base.c:893): No description found for parameter 'ofs'
Warning(drivers/mtd/nand/nand_base.c:893): No description found for parameter 'len'
Warning(drivers/mtd/nand/nand_base.c:893): No description found for parameter 'invert'
Warning(drivers/mtd/nand/nand_base.c:930): No description found for parameter 'mtd'
Warning(drivers/mtd/nand/nand_base.c:930): No description found for parameter 'ofs'
Warning(drivers/mtd/nand/nand_base.c:930): No description found for parameter 'len'
Warning(drivers/mtd/nand/nand_base.c:987): No description found for parameter 'mtd'
Warning(drivers/mtd/nand/nand_base.c:987): No description found for parameter 'ofs'
Warning(drivers/mtd/nand/nand_base.c:987): No description found for parameter 'len'
Warning(drivers/mtd/nand/nand_base.c:2087): No description found for parameter 'len'
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This is an update that depends on the previous patches I sent.

We can now write to all the appropriate BB marker locations (i.e.
pages 1 AND 2, bytes 1 AND 6) with nand_default_block_markbad() if
necessary, according to the flags marked in chip->options.

Note that I removed the line:
	ofs += mtd->oobsize;
Unless I am wrong, this line was completely unnecessary in the
first place.
Signed-off-by: NBrian Norris <norris@broadcom.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This is a revision to PATCH 2/2 that I sent. Link:
http://lists.infradead.org/pipermail/linux-mtd/2010-July/030911.html

Added new flag for scanning of both bytes 1 and 6 of the OOB for
a BB marker (instead of simply one or the other).

The "check_pattern" and "check_short_pattern" functions were updated
to include support for scanning the two different locations in the OOB.

In order to handle increases in variety of necessary scanning patterns,
I implemented dynamic memory allocation of nand_bbt_descr structs
in new function 'nand_create_default_bbt_descr()'. This replaces
some increasingly-unwieldy, statically-declared descriptors. It can
replace several more (e.g. "flashbased" structs). However, I do not
test the flashbased options personally.

How this was tested:

I referenced 30+ data sheets (covering 100+ parts), and I tested a
selection of 10 different chips to varying degrees. Particularly, I
tested the creation of bad-block descriptors and basic BB scanning on
three parts:

ST NAND04GW3B2D, 2K page
ST NAND128W3A, 512B page
Samsung K9F1G08U0A, 2K page

To test these, I wrote some fake bad block markers to the flash (in OOB
bytes 1, 6, and elsewhere) to see if the scanning routine would detect
them properly. However, this method was somewhat limited because the
driver I am using has some bugs in its OOB write functionality.
Signed-off-by: NBrian Norris <norris@broadcom.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Some level of support for various scanning locations was already built in,
but this required clean-up. First, BB marker location cannot be determined
_only_ by the page size. Instead, I implemented some heuristic detection
based on data sheets from various manufacturers (all found in
nand_base.c:nand_get_flash_type()).

Second, once these options were identified, they were not handled properly
by nand_bbt.c:nand_default_bbt(). I updated the static nand_bbt_desc structs
to reflect the need for more combinations of detection. The memory allocation
here probably needs to be done dynamically in the very near future (see next
patches).
Signed-off-by: NBrian Norris <norris@broadcom.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

NAND_BB_LAST_PAGE used to be in nand.h, but it pertained to bad block
management and so belongs next to NAND_BBT_SCAN2NDPAGE in bbm.h. Also,
its previous flag value (0x00000400) conflicted with NAND_BBT_SCANALLPAGES
so I changed its value to 0x00008000. All uses of the name were modified to
provide consistency with other "NAND_BBT_*" flags.
Signed-off-by: NBrian Norris <norris@broadcom.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This is a slightly modified version of a patch submitted last year by
Reuben Dowle <reuben.dowle@navico.com>.  His original comments follow:

This patch adds support for some MLC NAND flashes that place the BB
marker in the LAST page of the bad block rather than the FIRST page used
for SLC NAND and other types of MLC nand.

Lifted from Samsung datasheet for K9LG8G08U0A (1Gbyte MLC NAND):
"
Identifying Initial Invalid Block(s)
All device locations are erased(FFh) except locations where the initial
invalid block(s) information is written prior to shipping. The initial
invalid block(s) status is defined by the 1st byte in the spare area.
Samsung makes sure that the last page of every initial invalid block has
non-FFh data at the column address of 2,048.
...
"

As far as I can tell, this is the same for all Samsung MLC nand, and in
fact the samsung bsp for the processor used in our project (s3c6410)
actually contained a hack similar to this patch but less portable to
enable use of their NAND parts. I discovered this problem when trying to
use a Micron NAND which does not used this layout - I wish samsung would
put their stuff in main-line to avoid this type of problem.

Currently this patch causes all MLC nand with manufacturer codes from
Samsung and ST(Numonyx) to use this alternative location, since these
are the manufactures that I know of that use this layout.
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Some of the newer MLC devices have a 6-byte ID sequence in which
several field definitions differ from older chips in a manner that is
not backward compatible.  For instance:

Samsung K9GAG08U0M (5-byte sequence): ec d5 14 b6 74
4th byte, bits 1:0 encode the page size: 0=1KiB, 1=2KiB, 2=4KiB, 3=8KiB
4th byte, bits 5:4 encode the block size: 0=64KiB, 1=128KiB, ...
4th byte, bit 6 encodes the OOB size: 0=8B/512B, 1=16B/512B

Samsung K9GAG08U0D (6-byte sequence): ec d5 94 29 34 41
4th byte, bits 1:0 encode the page size: 0=2KiB, 1=4KiB, 3=8KiB, 4=rsvd
4th byte, bits 7;5:4 encode the block size: 0=128KiB, 1=256KiB, ...
4th byte, bits 6;3:2 encode the OOB size: 1=128B/page, 2=218B/page

This patch uses the new 6-byte scheme if the following conditions are
all true:

1) The ID code wraps around after exactly 6 bytes

2) Manufacturer is Samsung

3) 6th byte is zero

The patch also extends the maximum OOB size from 128B to 256B.
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This can be used to protect against bitflips in that field, but now mostly
for smartmedia.
Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This changes the behavier of MTD_OOB_RAW. It used to read both OOB and 
data to the data buffer, however you would still need to specify the 
dummy oob buffer.

This is only used in one place, but makes it hard to read data+oob 
without ECC test, thus I removed that behavier, and fixed the user.

Now MTD_OOB_RAW behaves just like MTD_OOB_PLACE, but doesn't do ECC 
validation
Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

nand_do_write_ops was broken in regard to writing several pages, each 
with its own oob.

Although nand_do_write_ops intends to allow such mode, it fails do do so
Probably this was never tested.

Also add missing checks for attempts to write at illegal offsets.
Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

MTD_OOB_PLACE is supposed to read/write the raw oob data similiar to the 
MTD_OOB_RAW however due to a bug, currently it is not possible to read 
more data that is specified by the oob 'free' regions.
Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Since all userspace threads are frozen at the time the nand_suspend is called,
they aren't inside any nand function.

We don't call try_to_freeze in nand ether. Thus the only user that can 
be inside the nand functions is an non freezeable kernel thread. Thus we 
can safely wait for it to finish.
Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Add nand lock / unlock routines. At least 'micron' parts
support this.
Signed-off-by: NVimal Singh <vimalsingh@ti.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

... verification for 'nand_erase_nand'

These checks are expected to be used by 'nand_lock' and 'nand_unlock'
routines too. As all these three are block aligned operations.
So, creating a helper function for this makes sense.
Signed-off-by: NVimal Singh <vimalsingh@ti.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Symptom:
device_suspend(): mtd_cls_suspend+0x0/0x58 returns -11
PM: Device mtd14 failed to suspend: error -11
PM: Some devices failed to suspend

This patch enables other chips to be suspended if the active chip of
the controller has been suspended.
Signed-off-by: NJin Qing <b24347@freescale.com>
Signed-off-by: NLi Yang <leoli@freescale.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Add NAND_SCAN_SILENT_NODEV to chip->options to the user-worrying messages
'No NAND device found!!!'. This message often worries users (was three
exclamation marks really necessary?) and especially in systems such as the
Simtec Osiris where there may be optional NAND devices which are not
known until probe time.

Revised version of the original NAND_PROBE_SPECULATIVE patch after comments
by Artem Bityutskiy about adding a whole new call.
Signed-off-by: NBen Dooks <ben@simtec.co.uk>
Signed-off-by: NSimtec Linux Team <linux@simtec.co.uk>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This is a quick and dirty patch to add panic_write for NAND flashes. The
patch seems to work OK on my CRIS board running a 2.6.26 kernel with a
ID: 0x20, Chip ID: 0xf1 (ST Micro NAND 128MiB 3,3V 8-bit), and also on a
OpenRD base (Marvell Kirkwood) board with a Toshiba NAND 512MiB 3,3V
8-bit flash with 2.6.32-pre1.
Signed-off-by: NEdgar E. Iglesias <edgar@axis.com>
Signed-off-by: NSimon Kagstrom <simon.kagstrom@netinsight.net>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Fixed following htmldocs warnings:

  DOCPROC Documentation/DocBook/mtdnand.xml
  Warning(drivers/mtd/nand/nand_base.c:769): No description found for parameter 'page'
  Warning(drivers/mtd/nand/nand_base.c:785): No description found for parameter 'page'
  Warning(drivers/mtd/nand/nand_base.c:824): No description found for parameter 'page'
  Warning(drivers/mtd/nand/nand_base.c:947): No description found for parameter 'page'
  Warning(drivers/mtd/nand/nand_base.c:996): No description found for parameter 'page'
  Warning(drivers/mtd/nand/nand_base.c:1040): No description found for parameter 'page'
Signed-off-by: NJaswinder Singh Rajput <jaswinderrajput@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This patch adds the new mode NAND_ECC_HW_OOB_FIRST in the nand code to
support 4-bit ECC on TI DaVinci devices with large page (up to 2KiB) NAND
chips.  This ECC mode is similar to NAND_ECC_HW, with the exception of
read_page API that first reads the OOB area, reads the data in chunks,
feeds the ECC from OOB area to the ECC hw engine and perform any
correction on the data as per the ECC status reported by the engine.

"ECC_HW_OOB_FIRST" name suggested by Thomas Gleixner
Reviewed-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NSneha Narnakaje <nsnehaprabha@ti.com>
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This patch adds a new "page" parameter to all NAND read_page/read_page_raw
APIs.  The read_page API for the new mode ECC_HW_OOB_FIRST requires the
page information to send the READOOB command and read the OOB area before
the data area.
Reviewed-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NSneha Narnakaje <nsnehaprabha@ti.com>
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This patch allows core driver to choose ECC block size in
sw ecc case.
Signed-off-by: NVimal Singh <vimalsingh@ti.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Correcting debug prints by removing function names from print messages
and using '__func__' macro instead.

Function names were wrong in few places.
Signed-off-by: NVimal Singh <vimalsingh@ti.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Singed-off-by: NVimal Singh <vimalsingh@ti.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>