There is one theoretical case that could fall through to using an
uninitialized value as the return code. Let's give it a value of 0.

Untested.

Caught by Coverity.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

When checking the upper boundary (i.e., whether an address is higher
than the maximum size of the MTD), we should be doing an inclusive check
(greater or equal). For instance, an address of 16MB (0x1000000) on a
16MB device is invalid.

The strengthening of this bounds check is redundant for those which
already have a address+length check and ensure that the length is
non-zero, but let's just fix them all, for completeness.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The variable 'retries' is never modified, so if the reset operation
never is going to complete, we'll get stuck in an infinite loop.

It looks like the intention was to decrement 'retries' on every loop.
Untested.

Caught by Coverity.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Do nand reset before write protect check.

If we want to check the WP# low or high through STATUS READ and check bit 7,
we must reset the device, other operation (eg.erase/program a locked block) can
also clear the bit 7 of status register.

As we know the status register can be refreshed, if we do some operation to trigger it,
for example if we do erase/program operation to one block that is locked, then READ STATUS,
the bit 7 of READ STATUS will be 0 indicate the device in write protect, then if we do
erase/program operation to another block that is unlocked, the bit 7 of READ STATUS will
be 1 indicate the device is not write protect.
Suppose we checked the bit 7 of READ STATUS is 0 then judge the WP# is low (write protect),
but in this case the WP# maybe high if we do erase/program operation to a locked block,
so we must reset the device if we want to check the WP# low or high through STATUS READ and
check bit 7.
Signed-off-by: NWhite Ding <bpqw@micron.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Fixed checkpatch warnings: "WARNING: Prefer seq_puts to seq_printf"

This patch is created with reference to the ongoing lkml thread
https://lkml.org/lkml/2014/7/15/646
where Andrew Morton wrote:

"
- puts is presumably faster

- puts doesn't go rogue if you accidentally pass it a "%".

- this patch would actually make compiled object files few bytes smaller.
  Perhaps because seq_printf() is a varargs function, forcing the
  caller to pass args on the stack instead of in registers.
"
Signed-off-by: NSamarth Parikh <samarthp@ymail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

MAP10 command with '0x2000' data sets up a read-ahead/write access.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This commit adds the support in the spi-nor driver of the Micron
M25PX80 flash, a 8 Mbit SPI flash from Micron.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

PMECC can support 512, 1k, 2k, 4k, 8k page size.
The driver currently only support 2k page size nand flash. So this patch
add support to 512, 1k, 4k and 8k page size nand flash.
Signed-off-by: NJosh Wu <josh.wu@atmel.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Some nand with 8k page size like Micron MT29F32G08ABAAAWP need more than 20us.
Signed-off-by: NRaphaël Poggi <poggi.raph@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Use NULL instead of 0 when returning an address. This fixes a
sparse warning.
Signed-off-by: NMartin Kepplinger <martink@posteo.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

We check "cs" for array overflows but we don't check for underflows and
it upsets the static checkers.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

replace au_read/write/sync with __raw_read/write and wmb.
Signed-off-by: NManuel Lauss <manuel.lauss@gmail.com>
Cc: Linux-MIPS <linux-mips@linux-mips.org>
Patchwork: https://patchwork.linux-mips.org/patch/7465/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

This patch changes the static memory controller registers to offsets
from base, prefixes them with AU1000_ to avoid silent failures due to
changed addresses and introduces helpers to access them.

No functional changes, comparing assembly of a few select functions shows
no differences.
Signed-off-by: NManuel Lauss <manuel.lauss@gmail.com>
Cc: Linux-MIPS <linux-mips@linux-mips.org>
Patchwork: https://patchwork.linux-mips.org/patch/7463/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Use the _safe variant because we're iterating over a list where items get
deleted and freed.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

This patch fixes the issue that on very large UBI volumes
UBI block does not work correctly.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

There's no need to set the disk capacity with the mutex held, so this
commit takes the variable setting out of the mutex. This simplifies
the disk capacity fix for very large volumes in a follow up commit.
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Currently, ubiblock_resize() can fail if the device is not found
in the list. This commit changes the return type, so the function can
return something meaningful on error paths.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

With a flash-based BBT there is no reason to move the Factory Bad
Block Marker from the data area buffer (to where it is mapped by the
GPMI NAND controller) to the OOB buffer. Thus, make this feature
configurable via DT. This is required for the Ka-Ro electronics
platforms.

In the original code 'this->swap_block_mark' was synonymous with
'!GPMI_IS_MX23()', so use the latter at the relevant places.
Signed-off-by: NLothar Waßmann <LW@KARO-electronics.de>
Acked-by: NHuang Shijie <b32955@freescale.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Signed-off-by: NLothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Signed-off-by: NLothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Fix the following error, which sometimes happens during the NFC data
transfer:

  atmel_nand 80000000.nand: Time out to wait for interrupt: 0x00010000
  atmel_nand 80000000.nand: something wrong, No XFR_DONE interrupt comes.

The root cause is that in the interrupt handler, we read the ISR but
only handle one interrupt. If more than one interrupt arrive at the same
time, then the second one will be lost.

During the NFC data transfer. Two NFC interrupts (NFC_CMD_DONE and
NFC_XFR_DONE) may come at the same time.

NFC_CMD_DONE means NFC command is sent, and NFC_XFR_DONE means NFC data
is transferred.

This patch can handle multiple NFC interrupts at the same time. During
the NFC data transfer, we need to wait for two NFC interrupts:
NFC_CMD_DONE and NFC_XFR_DONE.

Also we separate the completion initialization code to a
nfc_prepare_interrupt(), which is paired with nfc_wait_interrupt().

We call nfc_prepare_interrupt() before sending out nfc commands, to make
sure no interrupt lost.
Reported-by: NMatthieu CRAPET <Matthieu.CRAPET@ingenico.com>
Tested-by: NMatthieu Crapet <Matthieu.Crapet@ingenico.com>
Signed-off-by: NJosh Wu <josh.wu@atmel.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

In nfc_device_ready(), it's more reasonable to check R/B bit in NFC_SR
than waiting for the R/B interrupt. It cost less time.
Signed-off-by: NJosh Wu <josh.wu@atmel.com>
Tested-by: NMatthieu Crapet <Matthieu.Crapet@ingenico.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Add a new function to read the NFC status. Meantime, this function will
check if there is any errors in NFC.
Signed-off-by: NJosh Wu <josh.wu@atmel.com>
Tested-by: NMatthieu Crapet <Matthieu.Crapet@ingenico.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

If the ecc parameter is not the same as definition, when the
mtd core check these parameters, it will give the error result.

Take the following as an example:

Calculate how many bits can be corrected in one page.
According to the ecc parameters definition,

one page correct bits = (mtd->writesize * ecc->strength) / ecc->size

take the following use case as an example:
mtd->writesize = 2048 bytes
ecc->strength = 4 bytes (for 512 bytes)

before this patch, the ecc->size = 2048, so the result is 4 bytes.
after this patch, the ecc->size = 512, so the result is 16 bytes.

So, align the ecc parameters the same as definition to correct
this kind of error.
Signed-off-by: NBo Shen <voice.shen@atmel.com>
Acked-by: NJosh Wu <josh.wu@atmel.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Add a converter to retrieve NAND timings from an ONFI NAND timing mode.
At the moment, only SDR NAND timings are supported.
Signed-off-by: NBoris BREZILLON <boris.brezillon@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

UBI assumes that ubi_attach_info will only contain ubi_ainf_volume
structures for volumes with at least one LEB.
In scanning mode this is true because UBI can nicely create a ubi_ainf_volume
on demand while creating the EBA table.

For fastmap this is not true, the fastmap on-flash structure has a list of
all volumes, the ubi_ainf_volume structures are created from this list.
So it can happen that an empty volume ends up in init_volumes().

We can easely deal with that by looking into ->leb_count too.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

For some NOR flashes, the size of the buffer program has been increased
from 256 bytes to 512 bytes, and so 2ms maximum timeout can may not be
sufficient for all different vendor's NOR flash. There is maximum
timeout information in the CFI area, so we instead of picking a fixed
value, we can calculate this according to the standard CFI parameters
parsed at probe time. If we haven't probed this information, or it is
smaller than 2000us, then specify a minimum value 2000us.

Tested with Micron JS28F512M29EWx and Micron MT28EW512ABA flash devices.
Signed-off-by: NBean Huo <beanhuo@outlook.com>
[Brian: fix up comments, use 'max()']
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The return value from 'ubi_io_read_ec_hdr()' was stored in 'err', not in 'ret'.
This fix makes sure Fastmap-enabled UBI does not miss bit-flip while reading EC
headers, events and scrubs the affected PEBs.

This issue was reported by Coverity Scan.

Artem: improved the commit message.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Acked-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

The Denali NAND driver reads only 5 bytes of ID, but some Hynix and Samsung
have size parameters in the 6th byte.  As a result, the page and oob size
for a Hynix H27UAG8T2B were calculated incorrectly and the driver failed to
load.

The solution is to read 8 bytes of ID, as expected by the NAND framework.
Signed-off-by: NGraham Moore <grmoore@altera.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

I got the following panic on my fsl p5020ds board.

  Unable to handle kernel paging request for data at address 0x7375627379737465
  Faulting instruction address: 0xc000000000100778
  Oops: Kernel access of bad area, sig: 11 [#1]
  SMP NR_CPUS=24 CoreNet Generic
  Modules linked in:
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-next-20140613 #145
  task: c0000000fe080000 ti: c0000000fe088000 task.ti: c0000000fe088000
  NIP: c000000000100778 LR: c00000000010073c CTR: 0000000000000000
  REGS: c0000000fe08aa00 TRAP: 0300   Not tainted  (3.15.0-next-20140613)
  MSR: 0000000080029000 <CE,EE,ME>  CR: 24ad2e24  XER: 00000000
  DEAR: 7375627379737465 ESR: 0000000000000000 SOFTE: 1
  GPR00: c0000000000c99b0 c0000000fe08ac80 c0000000009598e0 c0000000fe001d80
  GPR04: 00000000000000d0 0000000000000913 c000000007902b20 0000000000000000
  GPR08: c0000000feaae888 0000000000000000 0000000007091000 0000000000200200
  GPR12: 0000000028ad2e28 c00000000fff4000 c0000000007abe08 0000000000000000
  GPR16: c0000000007ab160 c0000000007aaf98 c00000000060ba68 c0000000007abda8
  GPR20: c0000000007abde8 c0000000feaea6f8 c0000000feaea708 c0000000007abd10
  GPR24: c000000000989370 c0000000008c6228 00000000000041ed c0000000fe00a400
  GPR28: c00000000017c1cc 00000000000000d0 7375627379737465 c0000000fe001d80
  NIP [c000000000100778] .__kmalloc_track_caller+0x70/0x168
  LR [c00000000010073c] .__kmalloc_track_caller+0x34/0x168
  Call Trace:
  [c0000000fe08ac80] [c00000000087e6b8] uevent_sock_list+0x0/0x10 (unreliable)
  [c0000000fe08ad20] [c0000000000c99b0] .kstrdup+0x44/0x90
  [c0000000fe08adc0] [c00000000017c1cc] .__kernfs_new_node+0x4c/0x130
  [c0000000fe08ae70] [c00000000017d7e4] .kernfs_new_node+0x2c/0x64
  [c0000000fe08aef0] [c00000000017db00] .kernfs_create_dir_ns+0x34/0xc8
  [c0000000fe08af80] [c00000000018067c] .sysfs_create_dir_ns+0x58/0xcc
  [c0000000fe08b010] [c0000000002c711c] .kobject_add_internal+0xc8/0x384
  [c0000000fe08b0b0] [c0000000002c7644] .kobject_add+0x64/0xc8
  [c0000000fe08b140] [c000000000355ebc] .device_add+0x11c/0x654
  [c0000000fe08b200] [c0000000002b5988] .add_disk+0x20c/0x4b4
  [c0000000fe08b2c0] [c0000000003a21d4] .add_mtd_blktrans_dev+0x340/0x514
  [c0000000fe08b350] [c0000000003a3410] .mtdblock_add_mtd+0x74/0xb4
  [c0000000fe08b3e0] [c0000000003a32cc] .blktrans_notify_add+0x64/0x94
  [c0000000fe08b470] [c00000000039b5b4] .add_mtd_device+0x1d4/0x368
  [c0000000fe08b520] [c00000000039b830] .mtd_device_parse_register+0xe8/0x104
  [c0000000fe08b5c0] [c0000000003b8408] .of_flash_probe+0x72c/0x734
  [c0000000fe08b750] [c00000000035ba40] .platform_drv_probe+0x38/0x84
  [c0000000fe08b7d0] [c0000000003599a4] .really_probe+0xa4/0x29c
  [c0000000fe08b870] [c000000000359d3c] .__driver_attach+0x100/0x104
  [c0000000fe08b900] [c00000000035746c] .bus_for_each_dev+0x84/0xe4
  [c0000000fe08b9a0] [c0000000003593c0] .driver_attach+0x24/0x38
  [c0000000fe08ba10] [c000000000358f24] .bus_add_driver+0x1c8/0x2ac
  [c0000000fe08bab0] [c00000000035a3a4] .driver_register+0x8c/0x158
  [c0000000fe08bb30] [c00000000035b9f4] .__platform_driver_register+0x6c/0x80
  [c0000000fe08bba0] [c00000000084e080] .of_flash_driver_init+0x1c/0x30
  [c0000000fe08bc10] [c000000000001864] .do_one_initcall+0xbc/0x238
  [c0000000fe08bd00] [c00000000082cdc0] .kernel_init_freeable+0x188/0x268
  [c0000000fe08bdb0] [c0000000000020a0] .kernel_init+0x1c/0xf7c
  [c0000000fe08be30] [c000000000000884] .ret_from_kernel_thread+0x58/0xd4
  Instruction dump:
  41bd0010 480000c8 4bf04eb5 60000000 e94d0028 e93f0000 7cc95214 e8a60008
  7fc9502a 2fbe0000 419e00c8 e93f0022 <7f7e482a> 39200000 88ed06b2 992d06b2
  ---[ end trace b4c9a94804a42d40 ]---

It seems that the corrupted partition header on my mtd device triggers
a bug in the ftl. In function build_maps() it will allocate the buffers
needed by the mtd partition, but if something goes wrong such as kmalloc
failure, mtd read error or invalid partition header parameter, it will
free all allocated buffers and then return non-zero. In my case, it
seems that partition header parameter 'NumTransferUnits' is invalid.

And the ftl_freepart() is a function which free all the partition
buffers allocated by build_maps(). Given the build_maps() is a self
cleaning function, so there is no need to invoke this function even
if build_maps() return with error. Otherwise it will causes the
buffers to be freed twice and then weird things would happen.

Cc: stable@vger.kernel.org
Signed-off-by: NKevin Hao <haokexin@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Fix various whitespace issues.

No functional changes.
Signed-off-by: NRob Ward <robert.ward114@googlemail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Signed-off-by: NSergey Ryazanov <ryazanov.s.a@gmail.com>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This family of chips was long ago supported by the pre-cfi driver.
CFI code tested on several Zaurus SL-5500 (Collie) 2x16 on 32 bit bus.

Function is_LH28F640BF() mimics is_m29ew() from cmdset_0002.c

Buffer write fixes as seen in 2007 patch c/o
Anti Sullin <anti.sullin <at> artecdesign.ee>
http://comments.gmane.org/gmane.linux.ports.arm.kernel/36733

[Brian: this patch is semi-urgent, because the following patch switches
  to using CFI detection for a chip which (until now) is unsupported by
  the CFI driver

  92183103  ARM: 8084/1: sa1100: collie: revert back to cfi_probe
]
Signed-off-by: NAndrea Adami <andrea.adami@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

In commit 67a9ad9b ("mtd: nand: Warn the user if the selected ECC
strength is too weak"), a check was added to inform the user when the
ECC used for a NAND device is weaker than the recommended ECC
advertised by the NAND chip. However, the warning uses WARN_ON(),
which has two undesirable side-effects:

 - It just prints to the kernel log the fact that there is a warning
   in this file, at this line, but it doesn't explain anything about
   the warning itself.

 - It dumps a stack trace which is very noisy, for something that the
   user is most likely not able to fix. If a certain ECC used by the
   kernel is weaker than the advertised one, it's most likely to make
   sure the kernel uses an ECC that is compatible with the one used by
   the bootloader, and changing the bootloader may not necessarily be
   easy. Therefore, normal users would not be able to do anything to
   fix this very noisy warning, and will have to suffer from it at
   every kernel boot. At least every time I see this stack trace in my
   kernel boot log, I wonder what new thing is broken, just to realize
   that it's once again this NAND ECC warning.

Therefore, this commit turns:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at /home/thomas/projets/linux-2.6/drivers/mtd/nand/nand_base.c:4051 nand_scan_tail+0x538/0x780()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 3.16.0-rc3-dirty #4
[<c000e3dc>] (unwind_backtrace) from [<c000bee4>] (show_stack+0x10/0x14)
[<c000bee4>] (show_stack) from [<c0018180>] (warn_slowpath_common+0x6c/0x8c)
[<c0018180>] (warn_slowpath_common) from [<c001823c>] (warn_slowpath_null+0x1c/0x24)
[<c001823c>] (warn_slowpath_null) from [<c02c50cc>] (nand_scan_tail+0x538/0x780)
[<c02c50cc>] (nand_scan_tail) from [<c0639f78>] (orion_nand_probe+0x224/0x2e4)
[<c0639f78>] (orion_nand_probe) from [<c026da00>] (platform_drv_probe+0x18/0x4c)
[<c026da00>] (platform_drv_probe) from [<c026c1f4>] (really_probe+0x80/0x218)
[<c026c1f4>] (really_probe) from [<c026c47c>] (__driver_attach+0x98/0x9c)
[<c026c47c>] (__driver_attach) from [<c026a8f0>] (bus_for_each_dev+0x64/0x94)
[<c026a8f0>] (bus_for_each_dev) from [<c026bae4>] (bus_add_driver+0x144/0x1ec)
[<c026bae4>] (bus_add_driver) from [<c026cb00>] (driver_register+0x78/0xf8)
[<c026cb00>] (driver_register) from [<c026da5c>] (platform_driver_probe+0x20/0xb8)
[<c026da5c>] (platform_driver_probe) from [<c00088b8>] (do_one_initcall+0x80/0x1d8)
[<c00088b8>] (do_one_initcall) from [<c0620c9c>] (kernel_init_freeable+0xf4/0x1b4)
[<c0620c9c>] (kernel_init_freeable) from [<c049a098>] (kernel_init+0x8/0xec)
[<c049a098>] (kernel_init) from [<c00095f0>] (ret_from_fork+0x14/0x24)
---[ end trace 62f87d875aceccb4 ]---

Into the much shorter, and much more useful:

nand: WARNING: MT29F2G08ABAEAWP: the ECC used on your system is too weak compared to the one required by the NAND chip
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This patch removes s5pc100 related onenand codes because of no more
support for S5PC100 SoC in mainline.

Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

This patch adds support for the locking of the one time
programmable (OTP) memory of Micron M29EW devices.
Signed-off-by: NChristian Riesch <christian.riesch@omicron.at>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This patch adds support for writing the one time programmable (OTP)
memory of Micron M29EW devices.
Signed-off-by: NChristian Riesch <christian.riesch@omicron.at>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

When the one time programmable (OTP) memory region is entered by
issuing the 0xaa/0x55/0x88 command, the OTP memory occupies the
addresses which are normally used by the first sector of the regular
flash memory. This patch therefore invalidates cache for this
addresses after entering/exiting OTP memory.

This patch also moves the code into separate functions.
Signed-off-by: NChristian Riesch <christian.riesch@omicron.at>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The Micron M29EW has a 256 byte one time programmable (OTP) memory.
This patch adds support for reading this memory. This support will be
extended for locking and writing in subsequent patches.
Signed-off-by: NChristian Riesch <christian.riesch@omicron.at>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>