The error code returned by the ecc.correct() are not consistent over the
all implementations.

Document the expected behavior in include/linux/mtd/nand.h and fix
offending implementations.

[Brian: this looks like a bugfix for the ECC reporting in the bf5xx_nand
driver, but we haven't seen any testing results for it]
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: NFranklin S Cooper Jr. <fcooper@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

mtd_to_nand() was recently introduced to avoid direct access to the
mtd->priv field. Update core code to use mtd_to_nand().
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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

Add the function name to the error message.

These messages are not very helpful:

[183356.176682] uncorrectable error :
[183356.180273] uncorrectable error :
[183356.184194] uncorrectable error :
[183356.187773] uncorrectable error :
[183356.191280] uncorrectable error :

Artem: amended the patch a bit
Signed-off-by: NTormod Volden <debian.tormod@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>

That is "success", "unknown", "through", "performance", "[re|un]mapping"
, "access", "default", "reasonable", "[con]currently", "temperature"
, "channel", "[un]used", "application", "example","hierarchy", "therefore"
, "[over|under]flow", "contiguous", "threshold", "enough" and others.
Signed-off-by: NAndré Goddard Rosa <andre.goddard@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add __nand_calculate_ecc() which does not take struct mtd_info.
The built-in 256/512 software ECC calculation and correction tester
will use it.
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Acked-by: NVimal Singh <vimalsingh@ti.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Split nand_correct_data() into two part, a pure calculation function
and a wrapper for mtd interface.

The tmio_nand driver can implement its ecc.correct function easily
using this __nand_correct_data helper.
Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Acked-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Acked-by: NVimal Singh <vimalsingh@ti.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Type of 'byte_addr' needes to be 'unsigned int' for 512 byte
ECC support.
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>

Support 512 byte ECC calculation

[FM: updated two comments]
Signed-off-by: NVimal Singh <vimalsingh@ti.com>
Signed-off-by: NFrans Meulenbroeks <fransmeulenbroeks@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

[Reported by Randy Dunlap]
Signed-off-by: NAlexey Korolev <akorolev@infradead.org>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This patch for nand_ecc.c fixes three issues

- fix code so it also works on big endian architectures
- added a printk in case of an uncorrectable ecc error
- strengthen the test for correctable errors (decreasing the chance
  that multiple bit faults by accident will be seen as correctable)

Note: the big endian code is only tested in a testbed (running on big endian
hardware) as I cannot rebuild and test a big endian kernel at the moment.
However the only thing that can go wrong is if <asm/byteorder.h> does not
give __BIG_ENDIAN in that case. In my eyes very unlikely.
Signed-off-by: NFrans Meulenbroeks <fransmeulenbroeks@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Make the standalone stuff a little cleaner, fix some checkpatch warnings.
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This patch improves the performance of the ecc generation code by a 
factor of 18 on an INTEL D920 CPU, a factor of 7 on MIPS and a factor of 5 
on ARM (NSLU2)
Signed-off-by: NFrans Meulenbroeks <fransmeulenbroeks@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Once upon a time, the MTD repository was using CVS.

This patch therefore removes all usages of the no longer updated CVS
keywords from the MTD code.

This also includes code that printed them to the user.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Magic numerical values are just bad style.  Particularly so when
undocumented.
Signed-off-by: NJörn Engel <joern@logfs.org>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Fix up the config option in the #ifdef statements in nand_ecc.c
Signed-off-by: NTimo Lindhorst <lindhors@linux.vnet.ibm.com>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Fix all kernel-doc warnings in MTD headers and source files:
- add some missing struct fields;
- correct some function parameter names;
- use kernel-doc format for function doc. headers;
- nand_ecc.c contains only exported interfaces, no internal ones;
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Unrolling the loops produces denser and much faster code.
Add a config switch which allows to select the byte order of the
resulting ecc code. The current Linux implementation has a byte
swap versus the SmartMedia specification
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

It was just too painful to deal with.
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!