When the read operation fails, UBI tries to re-read several times in
a hope that one of the subsequent reads may succeed. However, currently
UBI re-reads only if MTD failed to read all data, but does not re-reads
if all the data were read, but with an integrity error (-EBADMSB). This
patch makes UBI to always re-try reading.

This should be useful for reading NAND pages with unstable bits -
re-reading may help to get correct data.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Just make them a bit more readable and explanatory.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

During scanning UBI allocates one struct ubi_scan_leb object for each PEB,
so it can end up allocating thousands of them. Use slab cache to reduce
memory consumption for these 48-byte objects, because currently used
'kmalloc()' ends up allocating 64 bytes per object, instead of 48.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

This change affects only the debugging code. Namely, use mtd->read()
function instead of ubi_io_read() to avoid bit-flips injection
(ubi_dbg_is_bitflip()) which we do not want on the debugging path.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

When reading data from the flash, corrupt the buffer we are about to
read to. The idea is to fix the following possible situation:

1. The buffer contains data from previous operation, e.g., read from
   another PEB previously. The data looks like expected, e.g., if we
   just do not read anything and return - the caller would not
   notice this. E.g., if we are reading a VID header, the buffer may
   contain a valid VID header from another PEB.
2. The driver is buggy and returns use success or -EBADMSG or
   -EUCLEAN, but it does not actually put any data to the buffer.

This may confuse UBI or upper layers - they may think the buffer
contains valid data while in fact it is just old data.

Thus, try to reveal such buggy MTD drivers with simple debugging
code which fills the read buffer with 0x12 constant.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Wrong macro was used in calculating the data offset: UBI_EC_HDR_SIZE instead of
UBI_VID_HDR_SIZE. The data offset should be VID header offset + VID header size
(aligned to the minimum I/O unit).

This was not a bug only because currently UBI_EC_HDR_SIZE and UBI_VID_HDR_SIZE
have the same value of 64 bytes.

Commit message was amended by Artem.
Signed-off-by: NJohn Ogness <john.ogness@linutronix.de>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

In 'nor_erase_prepare()' we want to make sure the UBI headers are
corrupted. But it is possible that one of the headers just contains
all 0xFFs, which is also OK, because UBI will erase it in case of
a power cut.
Signed-off-by: NHolger Brunck <holger.brunck@keymile.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Commit 2c01946c (omap3 nand: cleanup
virtual address usages) wrongly enabled CONFIG_MTD_NAND_OMAP_HWECC
which breaks boards like beagle and pandora that use software ECC
for write.

Boards like beagle and pandora uses sw ecc for write (e.g. binary flushed
from u-boot) and read from kernel.
Signed-off-by: NSukumar Ghorai <s-ghorai@ti.com>
Acked-by: NDavid Woodhouse <David.Woodhouse@intel.com>
[tony@atomide.com: updated comments]
Signed-off-by: NTony Lindgren <tony@atomide.com>

My new shiny code for corrupted PEB detection has NOR specific bug.
We tread PEB as corrupted and preserve it, if

1. EC header is OK.
2. VID header is corrupted.
3. data area is not "all 0xFFs"

In case of NOR we have 'nor_erase_prepare()' quirk, which invalidates
the headers before erasing the PEB. And we invalidate first the VID
header, and then the EC header. So if a power cut happens after we have
invalidated the VID header, but before we have invalidated the EC
header, we end up with a PEB which satisfies the above 3 conditions,
and the scanning code will treat it as corrupted, and will print
scary warnings, wrongly.

This patch fixes the issue by firt invalidating the EC header, then
invalidating the VID header. In case of power cut inbetween, we still
just lose the EC header, and UBI can deal with this situation gracefully.

Thanks to Anatolij Gustschin <agust@denx.de> for tracking this down.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Reported-by: NAnatolij Gustschin <agust@denx.de>
Tested-by: NAnatolij Gustschin <agust@denx.de>

Signed-off-by: NMarek Vasut <marek.vasut@gmail.com>
Acked-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Commit 45aafd32 "UBI: tighten the corrupted PEB criteria"
introduced some return paths that didn't release the ubi->buf_mutex
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

While building an x86 distro kernel, I hit the following:

Kernel: arch/x86/boot/bzImage is ready  (#7)
ERROR: "of_mtd_parse_partitions" [drivers/mtd/devices/m25p80.ko]
undefined!

of_mtd_parse_partitions is defined with MTD_OF_PARTS, and that's only
built on PPC and microblaze.  The code in question should be wrapped w/
a stricter #ifdef.
Signed-off-by: NAndres Salomon <dilinger@queued.net>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

In commit 2a48fc0a ('block: autoconvert
trivial BKL users to private mutex'), Arnd replaced the BKL usage with a
mutex. However, Maxim has already provided a better fix in commit
480792b7 ('mtd: blktrans: kill BKL'),
which was simply to remove the BKL without replacing it — since he'd
already made it do all necessary locking for itself.
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

register_blkdev return 1..255 when major = 0.

if (ret ) {
	printk(KERN_WARNING "Unable to register %s block device on major %d: %d\n",
		tr->name, tr->major, ret);
	      mutex_unlock(&mtd_table_mutex);
	return ret;
}

Above code will return fail when register_blkdev return allocated major number.
Signed-off-by: NFrank Li <Frank.Li@freescale.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

This reverts commit 432dc821.

The individual CFI geometry options were carefully set up to get sane
default values if the CFI_ADV_OPTIONS wasn't set, and it wasn't
appropriate to move them into an if/endif block.
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Some old SST chips use 0x50 as sector erase command, instead
of 0x30. Make this value variable to handle such chips.
Signed-off-by: NGuillaume LECERF <glecerf@gmail.com>
Acked-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Add support for SST38VF640x chips in CFI mode.
Signed-off-by: NGuillaume LECERF <glecerf@gmail.com>
Signed-off-by: Nyidong zhang <zhangyd6@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NGuillaume LECERF <glecerf@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NGuillaume LECERF <glecerf@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

When block2mtd_erase fails, a duplicated assignment instantly
changes instr->state from MTD_ERASE_FAILED to MTD_ERASE_DONE.

It looks to me like this might not be intended, or is it?
Signed-off-by: NNicolas Kaiser <nikai@nikai.net>
Acked-By: NJoern Engel <joern@logfs.org>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

When system uses 36bit physical address, res.start is 36bit
physical address. But the function of in_be32 returns 32bit
physical address. Then both of them compared each other is
wrong. So by converting the address of res.start into
the right format fixes this issue.
Signed-off-by: NLan Chunhe-B25806 <b25806@freescale.com>
Signed-off-by: NRoy Zang <tie-fei.zang@freescale.com>
Reviewed-by: NAnton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Move Freescale elbc interrupt from nand driver to elbc driver.
Then all elbc devices can use the interrupt instead of ONLY nand.

For former nand driver, it had the two functions:

1. detecting nand flash partitions;
2. registering elbc interrupt.

Now, second function is removed to fsl_lbc.c.
Signed-off-by: NLan Chunhe-B25806 <b25806@freescale.com>
Signed-off-by: NRoy Zang <tie-fei.zang@freescale.com>
Reviewed-by: NAnton Vorontsov <cbouatmailru@gmail.com>
Cc: Wood Scott-B07421 <B07421@freescale.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Use the more standard #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
No change in output strings.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

The suspend & resume called from mtd core. So no need to call at driver.
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

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>

I didn't know that kernel allows use of that typedef.
Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

It turns out that pci core now handles these, so this code is redundant
and can even cause bugs
Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

There is small race window that could make kthread_stop hang forever.
I found that while hacking the IR subsystem.
Signed-off-by: NMaxim Levitsky <maximlevisky@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

It not needed, because I already added locking for all fops
methods.
Signed-off-by: NMaxim Levitsky <maximlevisky@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Now it once again possible to remove mtdtrans module.
You still need to ensure that block devices of that module aren't mounted.
This is due to the fact that as long as a block device is open, it still exists,
therefore if we were to allow module removal, this block device might became used again.

This time in addition to code review, I also made the code
pass some torture tests like module reload in  a loop + read in a loop +
card insert/removal all at same time.

The blktrans_open/blktrans_release don't take the mtd table lock because:

While device is added (that includes execution of add_mtd_blktrans_dev)
the lock is already taken

Now suppose the device will never be removed. In this case even if we have changes
in mtd table, the entry that we need will stay exactly the same. (Note that we don't
look at table at all, just following private pointer of block device).

Now suppose that someone tries to remove the mtd device.
This will be propagated to trans driver which _ought_ to call del_mtd_blktrans_dev
which will take the per device lock, release the mtd device and set trans->mtd = NULL.
>From this point on, following opens won't even be able to know anything about that mtd device
(which at that point is likely not to exist)
Also the same care is taken not to trip over NULL mtd pointer in blktrans_dev_release.
Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Tested-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

As reported on lkml, building this module for HIMEM systems spews warnings
about mismatch in pointer types.  Further, we need to use ioremap() in order
to properly access the flash memory on most systems rather than just doing
it directly.
Reported-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

The bbt structure isn't actually used, just the badblockpos.  This lets
the driver correctly handle badblocks with the different OOB layout with
certain sized flashes.  Previously, the blocks would all be reported as
bad and be completely unusable.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

- remove disabled code (hasn't been touched since the beginning of git
  and should be reimplemented if really needed)
- convert remaining c++-comments to plain c-style
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Acked-by: NGuillaume LECERF <glecerf@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

For 4Gib non-DDP chip it does not follow that it is always 4KiB page chip.
The number of data buffers is checked and if it is equal to 1
we suppose that it is 4KiB page onenand chip.
Signed-off-by: NRoman Tereshonkov <roman.tereshonkov@nokia.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This patch changes the loop over the "reg" tuples to not exit
directly upon of_address_to_resource() failure but to continue
with the next "reg" tuple instead. This failure could be due to
size = 0, which might be passed via the device-tree.

This is needed for boards, where a "reg" tuple might have size 0
(of_address_to_resource() returns with EINVAL when size = 0).

Example:

Fully equipped board:

	reg = <0 0x00000000 0x00400000
	       0 0x00400000 0x00400000>;

Partially equipped board:

	reg = <0 0x00000000 0x00400000
	       0 0x00400000 0x00000000>;

This could be the case on boards with runtime detection of
multiple NOR flash configurations where the detected flash size
is inserted into the dtb in U-Boot.
Signed-off-by: NStefan Roese <sr@denx.de>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This patch fixes sparse warning for static declaration of variable "use_dma"

drivers/mtd/nand/omap2.c:114:11: warning: symbol 'use_dma' was not declared. Should it be static?
Signed-off-by: NG, Manjunath Kondaiah <manjugk@ti.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This patch adds the appropriate conversions to correct the endianness
issues in the MTD driver whenever it accesses the device tree (which is
always big endian).
Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>