Commit 90833fdab8 ("[ARM] 4554/1: replace
consistent_sync() with flush_ioremap_region()") introduced a new
"flush_ioremap_region()" function to be used by the MTD mainstone-flash
and lubbock-flash drivers to fix a regression from around 2.6.18.
Those drivers were independently merged into a single driver by Todd
Poynor in commit e644f7d628 ("[MTD] MAPS:
Merge Lubbock and Mainstone drivers into common PXA2xx driver")
Later, those two commits were merged into the main MTD tree by commit
b160292cc2 ("Merge Linux 2.6.23") by David
Woodhouse, but in that merge, the fix to use flush_iomap_region() got
lost (as it was to files that now no longer existed).
This reinstates the fix in the new driver.
Noticed-by: Russell King <rmk@arm.linux.org.uk>
Tested-and-acked-by: Nicolas Pitre <nico@cam.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Jared Hulbert <jaredeh@gmail.com>
Cc: Todd Poynor <tpoynor@mvista.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This allows the mtdconcat driver to work with NAND flash devices that
support sub-page writes.
Signed-off-by: Chris Paulson-Ellis <chris@edesix.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
When the erase callback performs some other action on the flash, it's
highly likely to deadlock unless we actually release the chip lock
before calling it.
This patch mirrors that same change already done for NAND.
Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Fix the following warning:
drivers/mtd/ubi/eba.c: In function 'ubi_eba_init_scan':
drivers/mtd/ubi/eba.c:1116: warning: 'err' may be used uninitialized in this function
Pointed-to-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
When the UBI device is nearly full, i.e. all LEBs are mapped, we have
only one spare LEB left - the one we reserved for WL purposes. Well,
I do not count the LEBs which were reserved for bad PEB handling -
suppose NOR flash for simplicity. If an "atomic LEB change operation"
is run, and the WL unit is moving a LEB, we have no spare LEBs to
finish the operation and fail, which is not good. Moreover, if there
are 2 or more simultanious "atomic LEB change" requests, only one of
them has chances to succeed, the other will fail with -ENOSPC. Not
good either.
This patch does 2 things:
1. Reserves one PEB for the "atomic LEB change" operation.
2. Serealize the operations so that only on of them may run
at a time (by means of a mutex).
Pointed-to-by: Brijesh Singh <brijesh.s.singh@gmail.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Similar reason as in case of the previous patch: it causes
deadlocks if a filesystem with writeback support works on top
of UBI. So pre-allocate needed buffers when attaching MTD device.
We also need mutexes to protect the buffers, but they do not
cause much contantion because they are used in recovery, torture,
and WL copy routines, which are called seldom.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Use GFP_NOFS flag when allocating memory on I/O path, because otherwise
we may deadlock the filesystem which works on top of us. We observed
the deadlocks with UBIFS. Example:
VFS->FS lock a lock->UBI->kmalloc()->VFS writeback->FS locks the same
lock again.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
I can't find anything guaranteeing that 'ubi_num' cannot be <0 in
drivers/mtd/ubi/kapi.c::ubi_open_volume(), and in fact the code
even tests for that and errors out if so. Unfortunately the test
for "ubi_num < 0" happens after we've already used 'ubi_num' as
an array index - bad thing to do if it is negative.
This patch moves the test earlier in the function and then moves
the indexing using that variable after the check. A bit safer :-)
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
I hit those situations and found out lack of print messages. Add more prints
when erase problems occur.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Fix "symbol shadows an earlier one" warnings. Although they are harmless
but it does not hurt to fix them and make sparse happy.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Coverity (1769) found the following problem: if the erase counter
overflow check triggers, ec_hdr is leaked.
Moving the allocation after the overflow check should take care of it.
Signed-off-by: Florin Malita <fmalita@gmail.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
This is the driver for latest Blackfin on-chip nand flash controller
- use nand_chip and mtd_info common nand driver interface
- provide both PIO and dma operation
- compiled with ezkit bf548 configuration
- use hardware 1-bit ECC
- tested with YAFFS2 and can mount YAFFS2 filesystem as rootfs
ChangeLog from try#1
- use hweight32() instead of count_bits()
- replace bf54x with bf5xx and BF54X with BF5XX
- compare against plat->page_size in 2 cases when enable hardware ECC
ChangeLog from try#2
- passed nand_test suites
- use cpu_relax() instead of busy wait loop
- some coding style issue pointed out by Andrew
Signed-off-by: Bryan Wu <bryan.wu@analog.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
When we press ctrl-alt-del,kernel_restart_prepare will invoke
cfi_intelext_reboot which will set flash to read array mode, but later
when device_shutdown is invoked which may put current work queue to
sleep and other process may be scheduled to running and programming
flash in not FL_READY mode again. So we can't boot up if this flash is
used for bootloader.
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
drivers/mtd/nand/alauda.c: In function 'alauda_bounce_read':
drivers/mtd/nand/alauda.c:412: warning: comparison of distinct pointer types lacks a cast
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
When the erase callback performs some other action on the flash, it's
highly likely to deadlock unless we actually release the chip lock
before calling it.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
