If ubi_update_fastmap() fails notify the user.
This is not a hard error as ubi_update_fastmap() makes sure that upon failure
the current on-flash fastmap will no be used upon next UBI attach.
Signed-off-by: NRichard Weinberger <richard@nod.at>

Add a ubi_fastmap_close() to free all resources used by fastmap
at WL shutdown.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Tested-by: NGuido Martínez <guido@vanguardiasur.com.ar>
Reviewed-by: NGuido Martínez <guido@vanguardiasur.com.ar>

There is no need to allocate new ones every time, we can reuse
the existing ones.
This makes the code cleaner and more easy to follow.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Reviewed-by: NTanya Brokhman <tlinder@codeaurora.org>
Reviewed-by: NGuido Martínez <guido@vanguardiasur.com.ar>

Currently ubi_refill_pools() first fills the first and then
the second one.
If only very few free PEBs are available the second pool can get
zero PEBs.
Change ubi_refill_pools() to distribute free PEBs fair between
all pools.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Reviewed-by: NGuido Martínez <guido@vanguardiasur.com.ar>

Make it two functions, wl_get_wle() and wl_get_peb().
wl_get_peb() works exactly like __wl_get_peb() but wl_get_wle()
does not call produce_free_peb().
While refilling the fastmap user pool we cannot release ubi->wl_lock
as produce_free_peb() does.
Hence the fastmap logic uses now wl_get_wle().
Signed-off-by: NRichard Weinberger <richard@nod.at>

ubi_wl_get_peb() has two problems, it reads the pool
size and usage counters without any protection.
While reading one value would be perfectly fine it reads multiple
values and compares them. This is racy and can lead to incorrect
pool handling.
Furthermore ubi_update_fastmap() is called without wl_lock held,
before incrementing the used counter it needs to be checked again.
It could happen that another thread consumed all PEBs from the
pool and the counter goes beyond ->size.
Signed-off-by: NRichard Weinberger <richard@nod.at>

...otherwise the deferred work might run after datastructures
got freed and corrupt memory.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Reviewed-by: NGuido Martínez <guido@vanguardiasur.com.ar>

If the WL pool runs out of PEBs we schedule a fastmap write
to refill it as soon as possible.
Ensure that only one at a time is scheduled otherwise we might end in
a fastmap write storm because writing the fastmap can schedule another
write if bitflips are detected.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Reviewed-by: NTanya Brokhman <tlinder@codeaurora.org>
Reviewed-by: NGuido Martínez <guido@vanguardiasur.com.ar>

The kerneldoc for @vid_hdr_aloffset continues onto a second line, but
this is not obvious, because the second line isn't indented, and it
begins with '@'.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

The comparison from the previous line seems to have been erroneously
(partially) copied-and-pasted onto the next. The second line should be
checking req.bytes, not req.lnum.

Coverity CID #139400

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
[rw: Fixed comparison]
Signed-off-by: NRichard Weinberger <richard@nod.at>

In some of the 'out_not_moved' error paths, lnum may be used
uninitialized. Don't ignore the warning; let's fix it.

This uninitialized variable doesn't have much visible effect in the end,
since we just schedule the PEB for erasure, and its LEB number doesn't
really matter (it just gets printed in debug messages). But let's get it
straight anyway.

Coverity CID #113449

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

If aeb->len >= vol->reserved_pebs, we should not be writing aeb into the
PEB->LEB mapping.

Caught by Coverity, CID #711212.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

We are completely discarding the earlier value of 'bitflips', which
could reflect a bitflip found in ubi_io_read_vid_hdr(). Let's use the
bitwise OR of header and data 'bitflip' statuses instead.

Coverity CID #1226856

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

If NO_DMA=y:

    drivers/built-in.o: In function `hisi_nfc_probe':
    hisi504_nand.c:(.text+0x23e646): undefined reference to `dmam_alloc_coherent'
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

As the devicetree binding doesn't require num_cs to exist or be strictly
positive, and neither does the platform data case, a bug appear when
num_cs is set to 0 and panics the kernel.

The issue is that in alloc_nand_resource(), chip is dereferenced without
having a value assigned when num_cs == 0.

Fix this by returning ENODEV is num_cs == 0.

The panic seen is :
Unable to handle kernel NULL pointer dereference at virtual address 000002b8
pgd = c0004000
[000002b8] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT ARM
Modules linked in:
Hardware name: Marvell PXA3xx (Device Tree Support)
task: c3822aa0 ti: c3826000 task.ti: c3826000
PC is at alloc_nand_resource+0x180/0x4a8
LR is at alloc_nand_resource+0xa0/0x4a8
pc : [<c0275b90>]    lr : [<c0275ab0>]    psr: 68000013
sp : c3827d90  ip : 00000000  fp : 00000000
r10: c3862200  r9 : 0000005e  r8 : 00000000
r7 : c3865610  r6 : c3862210  r5 : c3924210  r4 : c3862200
r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : 00000000
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 0000397f  Table: 80004018  DAC: 00000035
Process swapper (pid: 1, stack limit = 0xc3826198)
Stack: (0xc3827d90 to 0xc3828000)
...zip...
[<c0275b90>] (alloc_nand_resource) from [<c0275ff8>] (pxa3xx_nand_probe+0x140/0x978)
[<c0275ff8>] (pxa3xx_nand_probe) from [<c0258c40>] (platform_drv_probe+0x48/0xa4)
[<c0258c40>] (platform_drv_probe) from [<c0257650>] (driver_probe_device+0x80/0x21c)
[<c0257650>] (driver_probe_device) from [<c0257878>] (__driver_attach+0x8c/0x90)
[<c0257878>] (__driver_attach) from [<c0255ec4>] (bus_for_each_dev+0x58/0x88)
[<c0255ec4>] (bus_for_each_dev) from [<c0256ec8>] (bus_add_driver+0xd8/0x1d4)
[<c0256ec8>] (bus_add_driver) from [<c0257f14>] (driver_register+0x78/0xf4)
[<c0257f14>] (driver_register) from [<c00088a8>] (do_one_initcall+0x80/0x1e4)
[<c00088a8>] (do_one_initcall) from [<c048ed08>] (kernel_init_freeable+0xec/0x1b4)
[<c048ed08>] (kernel_init_freeable) from [<c0377d8c>] (kernel_init+0x8/0xe4)
[<c0377d8c>] (kernel_init) from [<c00095f8>] (ret_from_fork+0x14/0x3c)
Code: e503b234 e5953008 e1530001 caffffd1 (e59002b8)
---[ end trace a5770060c8441895 ]---
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Acked-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The NDDB register holds the data that are needed by the read and write
commands.

However, during a read PIO access, the datasheet specifies that after each 32
bytes read in that register, when BCH is enabled, we have to make sure that the
RDDREQ bit is set in the NDSR register.

This fixes an issue that was seen on the Armada 385, and presumably other mvebu
SoCs, when a read on a newly erased page would end up in the driver reporting a
timeout from the NAND.

Cc: <stable@vger.kernel.org> # v3.14
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

commit 0e707ae7 ("UBI: do propagate positive error codes up") seems
to have produced an unintended change in the control flow here.

Completely untested, but it looks obvious.

Caught by Coverity, which didn't like the indentation. CID 1271184.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

The intent was to mask away some bits here, not to test true or false.

Fix: 54f531f6 ('mtd: hisilicon: add a new NAND controller driver for hisilicon hip04 Soc')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

We recently switched from allocating ->rq using blk_init_queue() to
use blk_mq_init_queue() so we need to update the error handling to
check for IS_ERR() instead of NULL.

Fixes: ff1f48ee ('UBI: Block: Add blk-mq support')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

If one ubi volume is corrupted but another is not, it should be
possible to initialize that ubiblock from a kernel commandline which
includes both of them. This patch changes the error handling behavior
in initializing ubiblock to ensure that all parameters are attempted
even if one fails. If there is a failure, it is logged on dmesg.
It also makes error messages more descriptive by including the
name of the UBI volume that failed.

Tested: Formatted ubi volume /dev/ubi5_0 in a corrupt way and
dev/ubi3_0 properly and included "ubi.block=5,0 ubi.block=3,0" on
the kernel command line. At boot, I see the following in the console:
[   21.082420] UBI error: ubiblock_create_from_param: block: can't open volume on ubi5_0, err=-19
[   21.084268] UBI: ubiblock3_0 created from ubi3:0(rootfs)
Signed-off-by: NDan Ehrenberg <dehrenberg@chromium.org>
Reviewed-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: NRichard Weinberger <richard@nod.at>

This patch adds the support for hisilicon 504 NAND controller which is now used
by Hisilicon Soc Hip04.
Signed-off-by: NZhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Calling mtd_device_parse_register with the same mtd_info
(e.g. registering several partitions on a single device)
would add the same reboot notifier twice, causing an
infinte loop in notifier_chain_register during boot up.
Signed-off-by: NNiklas Cassel <nks@flawful.org>
[Brian: add FIXME comments]
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

In concat_read_oob both retlen and oobretlen should be updated.
concat_write_oob previously only (improperly) updated retlen.
Signed-off-by: NNiklas Cassel <niklass@axis.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The PPC_OF is a ppc specific option which is used to mean that the
firmware device tree access functions are available. Since all the
ppc platforms have a device tree, it is aways set to 'y' for ppc.
So it makes no sense to keep a such option in the current kernel.
Replace it with PPC.
Signed-off-by: NKevin Hao <haokexin@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This driver uses NAND_ECC_HW_SYNDROME mode.  The nand_scan_tail()
function would not complain about missing ecc->calculate,
ecc->correct, ecc->hwctl handlers.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Signed-off-by: NBaruch Siach <baruch@tkos.co.il>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Set AHB transfer size to 1K which improved the read performance.

Add ahb_buf_size field in fsl_qspi_devtype_data to denote the size for
different SoC.

Before:

root@imx6qdlsolo:~# dd if=/dev/mtd1 of=/dev/null bs=1M count=16
16+0 records in
16+0 records out
16777216 bytes (17 MB) copied, 0.472183 s, 25.1 MB/s

After:

root@imx6qdlsolo:~# dd if=/dev/mtd1 of=/dev/null bs=1M count=16
16+0 records in
16+0 records out
16777216 bytes (17 MB) copied, 0.369439 s, 29.5 MB/s
Signed-off-by: NAllen Xu <b45815@freescale.com>
Signed-off-by: NHuang Shijie <shijie8@gmail.com>
Signed-off-by: NFrank Li <Frank.Li@freescale.com>
Acked-by: NHuang Shijie <shijie.huang@intel.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

There is no need to keep the 'map_failed' label. We can simply return the error
code directly and let the code shorter and cleaner.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Acked-by: NHan Xu <han.xu@freescale.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

When the driver successfully probe we already have messages like:

[    1.140989] fsl-quadspi 21e4000.qspi: s25fl128s (16384 Kbytes)
[    1.150902] fsl-quadspi 21e4000.qspi: s25fl128s (16384 Kbytes)

Or in case of error:

[    1.175920] fsl-quadspi: probe of 21e4000.qspi failed with error -12

, so remove the unneeded success/error messages.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Acked-by: NHan Xu <han.xu@freescale.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Jumping to 'map_failed' label is not correct at these points, as it misses to
disable the clocks that were previously enabled.

Jump to 'irq_failed' label instead that will correctly disable the clocks.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Acked-by: NHan Xu <han.xu@freescale.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The if and the else branch code are identical - so the condition has no
effect on the effective code. This patch removes the condition and the
duplicated code and updates the documentation as suggested by
Roger Quadros <rogerq@ti.com>.
Acked-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NNicholas Mc Guire <hofrat@osadl.org>
Reviewed-by: NPekon Gupta <pekon@pek-sem.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Use the GPIO descriptor API instead of the deprecated legacy GPIO API to
manage the busy GPIO.

The patch updates both the jz4740 nand driver and the only user of the driver
the qi-lb60 board driver.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NRalf Baechle <ralf@linux-mips.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Previously, we requested that drivers pass ecc.size and ecc.bytes when
using NAND_ECC_SOFT_BCH. However, a driver is likely to only know the ECC
strength required for its NAND, so each driver would need to perform a
strength-to-bytes calculation.

Avoid duplicating this calculation in each driver by asking drivers to
pass ecc.size and ecc.strength so that the strength-to-bytes calculation
need only be implemented once.

This reverts/generalizes this commit:
    mtd: nand: Base BCH ECC bytes on required strength
Signed-off-by: NAaron Sierra <asierra@xes-inc.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The recently added mtd_mmap_capabilities can be used from loadable
modules, in particular romfs, but is not exported, so we get

ERROR: "mtd_mmap_capabilities" [fs/romfs/romfs.ko] undefined!

This adds the missing export.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: b4caecd4 ("fs: introduce f_op->mmap_capabilities for nommu mmap support")
Acked-by: NChristoph Hellwig <hch@lst.de>
Acked-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NJens Axboe <axboe@fb.com>

Signed-off-by: NRichard Weinberger <richard@nod.at>

Running mtd-utils/tests/ubi-tests/io_basic.c could cause
soft lockup or watchdog reset. It is because *updatevol*
will perform ubi_check_volume() after updating finish
and this function will full scan the updated lebs if the
volume is initialized as STATIC_VOLUME.

This patch adds *cond_resched()* in the loop of lebs scan
to avoid soft lockup.

Helped by Richard Weinberger <richard@nod.at>

[ 2158.067096] INFO: rcu_sched self-detected stall on CPU { 1}  (t=2101 jiffies g=1606 c=1605 q=56)
[ 2158.172867] CPU: 1 PID: 2073 Comm: io_basic Tainted: G           O 3.10.53 #21
[ 2158.172898] [<c000f624>] (unwind_backtrace+0x0/0x120) from [<c000c294>] (show_stack+0x10/0x14)
[ 2158.172918] [<c000c294>] (show_stack+0x10/0x14) from [<c008ac3c>] (rcu_check_callbacks+0x1c0/0x660)
[ 2158.172936] [<c008ac3c>] (rcu_check_callbacks+0x1c0/0x660) from [<c002b480>] (update_process_times+0x38/0x64)
[ 2158.172953] [<c002b480>] (update_process_times+0x38/0x64) from [<c005ff38>] (tick_sched_handle+0x54/0x60)
[ 2158.172966] [<c005ff38>] (tick_sched_handle+0x54/0x60) from [<c00601ac>] (tick_sched_timer+0x44/0x74)
[ 2158.172978] [<c00601ac>] (tick_sched_timer+0x44/0x74) from [<c003f348>] (__run_hrtimer+0xc8/0x1b8)
[ 2158.172992] [<c003f348>] (__run_hrtimer+0xc8/0x1b8) from [<c003fd9c>] (hrtimer_interrupt+0x128/0x2a4)
[ 2158.173007] [<c003fd9c>] (hrtimer_interrupt+0x128/0x2a4) from [<c0246f1c>] (arch_timer_handler_virt+0x28/0x30)
[ 2158.173022] [<c0246f1c>] (arch_timer_handler_virt+0x28/0x30) from [<c0086214>] (handle_percpu_devid_irq+0x9c/0x124)
[ 2158.173036] [<c0086214>] (handle_percpu_devid_irq+0x9c/0x124) from [<c0082bd8>] (generic_handle_irq+0x20/0x30)
[ 2158.173049] [<c0082bd8>] (generic_handle_irq+0x20/0x30) from [<c000969c>] (handle_IRQ+0x64/0x8c)
[ 2158.173060] [<c000969c>] (handle_IRQ+0x64/0x8c) from [<c0008544>] (gic_handle_irq+0x3c/0x60)
[ 2158.173074] [<c0008544>] (gic_handle_irq+0x3c/0x60) from [<c02f0f80>] (__irq_svc+0x40/0x50)
[ 2158.173083] Exception stack(0xc4043c98 to 0xc4043ce0)
[ 2158.173092] 3c80:                                                       c4043ce4 00000019
[ 2158.173102] 3ca0: 1f8a865f c050ad10 1f8a864c 00000031 c04b5970 0003ebce 00000000 f3550000
[ 2158.173113] 3cc0: bf00bc68 00000800 0003ebce c4043ce0 c0186d14 c0186cb8 80000013 ffffffff
[ 2158.173130] [<c02f0f80>] (__irq_svc+0x40/0x50) from [<c0186cb8>] (read_current_timer+0x4/0x38)
[ 2158.173145] [<c0186cb8>] (read_current_timer+0x4/0x38) from [<1f8a865f>] (0x1f8a865f)
[ 2183.927097] BUG: soft lockup - CPU#1 stuck for 22s! [io_basic:2073]
[ 2184.002229] Modules linked in: nandflash(O) [last unloaded: nandflash]
Signed-off-by: NWang Kai <morgan.wang@huawei.com>
Signed-off-by: Nhujianyang <hujianyang@huawei.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

Fastmap can miss a PEB if it is in the protection queue
and not jet in the used tree.
Treat every protected PEB as used.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

UBI uses positive function return codes internally, and should not propagate
them up, except in the place this path fixes. Here is the original bug report
from Dan Carpenter:

The problem is really in ubi_eba_read_leb().

drivers/mtd/ubi/eba.c
   412                  err = ubi_io_read_vid_hdr(ubi, pnum, vid_hdr, 1);
   413                  if (err && err != UBI_IO_BITFLIPS) {
   414                          if (err > 0) {
   415                                  /*
   416                                   * The header is either absent or corrupted.
   417                                   * The former case means there is a bug -
   418                                   * switch to read-only mode just in case.
   419                                   * The latter case means a real corruption - we
   420                                   * may try to recover data. FIXME: but this is
   421                                   * not implemented.
   422                                   */
   423                                  if (err == UBI_IO_BAD_HDR_EBADMSG ||
   424                                      err == UBI_IO_BAD_HDR) {
   425                                          ubi_warn("corrupted VID header at PEB %d, LEB %d:%d",
   426                                                   pnum, vol_id, lnum);
   427                                          err = -EBADMSG;
   428                                  } else
   429                                          ubi_ro_mode(ubi);

On this path we return UBI_IO_FF and UBI_IO_FF_BITFLIPS and it
eventually gets passed to ERR_PTR().  We probably dereference the bad
pointer and oops.  At that point we've gone read only so it was already
a bad situation...

   430                          }
   431                          goto out_free;
   432                  } else if (err == UBI_IO_BITFLIPS)
   433                          scrub = 1;
   434
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Let's prefix UBI messages with 'ubiX' instead of 'UBI-X' - this is more
consistent with the way we name UBI devices.

Also, commit "32608703 UBI: Extend UBI layer debug/messaging capabilities"
added the function name print to 'ubi_msg()' - lets revert this change, since
these messages are supposed to be just informative messages, and not debugging
messages.
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Some cosmetic fixes to the patch "UBI: Extend UBI layer debug/messaging
capabilities".
Signed-off-by: NTanya Brokhman <tlinder@codeaurora.org>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>