BMC/Intel-BMC/linux.git/drivers/mtd/nand, branch dev-4.4

mtd: nand: davinci: Reinitialize the HW ECC engine in 4bit hwctl

2016-10-07T13:23:40+00:00

commit f6d7c1b5598b6407c3f1da795dd54acf99c1990c upstream. This fixes subpage writes when using 4-bit HW ECC. There has been numerous reports about ECC errors with devices using this driver for a while. Also the 4-bit ECC has been reported as broken with subpages in [1] and with 16 bits NANDs in the driver and in mach* board files both in mainline and in the vendor BSPs. What I saw with 4-bit ECC on a 16bits NAND (on an LCDK) which got me to try reinitializing the ECC engine: - R/W on whole pages properly generates/checks RS code - try writing the 1st subpage only of a blank page, the subpage is well written and the RS code properly generated, re-reading the same page the HW detects some ECC error, reading the same page again no ECC error is detected Note that the ECC engine is already reinitialized in the 1-bit case. Tested on my LCDK with UBI+UBIFS using subpages. This could potentially get rid of the issue workarounded in [1]. [1] 28c015a9daab ("mtd: davinci-nand: disable subpage write for keystone-nand") Fixes: 6a4123e581b3 ("mtd: nand: davinci_nand, 4-bit ECC for smallpage") Signed-off-by: Karl Beldan Acked-by: Boris Brezillon Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman

mtd: nand: fix bug writing 1 byte less than page size

2016-08-20T16:09:24+00:00

commit 144f4c98399e2c0ca60eb414c15a2c68125c18b8 upstream. nand_do_write_ops() determines if it is writing a partial page with the formula: part_pagewr = (column || writelen < (mtd->writesize - 1)) When 'writelen' is exactly 1 byte less than the NAND page size the formula equates to zero, so the code doesn't process it as a partial write, although it should. As a consequence the function remains in the while(1) loop with 'writelen' becoming 0xffffffff and iterating endlessly. The bug may not be easy to reproduce in Linux since user space tools usually force the padding or round-up the write size to a page-size multiple. This was discovered in U-Boot where the issue can be reproduced by writing any size that is 1 byte less than a page-size multiple. For example, on a NAND with 2K page (0x800): => nand erase.part => nand write $loadaddr 7ff [Editor's note: the bug was added in commit 29072b96078f, but moved around in commit 66507c7bc8895 ("mtd: nand: Add support to use nand_base poi databuf as bounce buffer")] Fixes: 29072b96078f ("[MTD] NAND: add subpage write support") Signed-off-by: Hector Palacios Acked-by: Boris Brezillon Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman

mtd: nand: Drop mtd.owner requirement in nand_scan

2016-05-04T21:48:52+00:00

commit 20c07a5bf094198ff2382aa5e7c930b3c9807792 upstream. Since commit 807f16d4db95 ("mtd: core: set some defaults when dev.parent is set"), it's now legal for drivers to call nand_scan and nand_scan_ident without setting mtd.owner. Drop the check and while at it remove the BUG() abuse. Fixes: 807f16d4db95 ("mtd: core: set some defaults when dev.parent is set") Signed-off-by: Ezequiel Garcia Acked-by: Boris Brezillon [Brian: editorial note - while commit 807f16d4db95 wasn't explicitly broken, some follow-up commits in the v4.4 release broke a few drivers, since they would hit this BUG() if they used nand_scan() and were built as modules] Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman

mtd: brcmnand: Fix v7.1 register offsets

2016-05-04T21:48:52+00:00

commit d267aefc54a28efc5bda7f009598dc83b5f98734 upstream. The BRCMNAND controller revision 7.1 is almost 100% compatible with the previous v6.0 register offset layout, except for the Correctable Error Reporting Threshold registers. Fix this by adding another table with the correct offsets for CORR_THRESHOLD and CORR_THRESHOLD_EXT. Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller") Signed-off-by: Florian Fainelli Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman

mtd: nand: assign reasonable default name for NAND drivers

2016-02-17T20:30:56+00:00

commit f7a8e38f07a17be90758559fe66fe7337096053f upstream. Commits such as commit 853f1c58c4b2 ("mtd: nand: omap2: show parent device structure in sysfs") attempt to rely on the core MTD code to set the MTD name based on the parent device. However, nand_base tries to set a different default name according to the flash name (e.g., extracted from the ONFI parameter page), which means NAND drivers will never make use of the MTD defaults. This is not the intention of commit 853f1c58c4b2. This results in problems when trying to use the cmdline partition parser, since the MTD name is different than expected. Let's fix this by providing a default NAND name, where possible. Note that this is not really a great default name in the long run, since this means that if there are multiple MTDs attached to the same controller device, they will have the same name. But that is an existing issue and requires future work on a better controller vs. flash chip abstraction to fix properly. Fixes: 853f1c58c4b2 ("mtd: nand: omap2: show parent device structure in sysfs") Reported-by: Heiko Schocher Signed-off-by: Brian Norris Reviewed-by: Boris Brezillon Tested-by: Heiko Schocher Cc: Heiko Schocher Cc: Frans Klaver Signed-off-by: Greg Kroah-Hartman

mtd: nand: fix shutdown/reboot for multi-chip systems

2015-11-16T18:51:39+00:00

If multiple NAND chips are registered to the same controller, then when rebooting the system, the first one will grab the controller lock, while the second will wait forever for the first one to release it. i.e., a classic deadlock. This problem was solved for a similar case (suspend/resume) back in commit 6b0d9a841249 ("mtd: nand: fix multi-chip suspend problem"), and the shutdown state really isn't much different for us, so rather than adding a new special case to nand_get_device(), we can just overload the FL_PM_SUSPENDED state. Now, multiple chips can "get" the same controller lock (preventing further I/O), while we still allow other chips to pass through nand_shutdown(). Original report: http://thread.gmane.org/gmane.linux.drivers.mtd/59726 http://lists.infradead.org/pipermail/linux-mtd/2015-July/059992.html Fixes: 72ea403669c7 ("mtd: nand: added nand_shutdown") Reported-by: Andrew E. Mileski Signed-off-by: Brian Norris Cc: Scott Branden Cc: Andrew E. Mileski Acked-by: Scott Branden Reviewed-by: Boris Brezillon

mtd: jz4740_nand: fix build on jz4740 after removing gpio.h

2015-11-16T18:48:15+00:00

Fallout from commit 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h") We see errors like this: drivers/mtd/nand/jz4740_nand.c: In function 'jz_nand_detect_bank': drivers/mtd/nand/jz4740_nand.c:340:9: error: 'JZ_GPIO_MEM_CS0' undeclared (first use in this function) drivers/mtd/nand/jz4740_nand.c:340:9: note: each undeclared identifier is reported only once for each function it appears in drivers/mtd/nand/jz4740_nand.c:359:2: error: implicit declaration of function 'jz_gpio_set_function' [-Werror=implicit-function-declaration] drivers/mtd/nand/jz4740_nand.c:359:29: error: 'JZ_GPIO_FUNC_MEM_CS0' undeclared (first use in this function) drivers/mtd/nand/jz4740_nand.c:399:29: error: 'JZ_GPIO_FUNC_NONE' undeclared (first use in this function) drivers/mtd/nand/jz4740_nand.c: In function 'jz_nand_probe': drivers/mtd/nand/jz4740_nand.c:528:13: error: 'JZ_GPIO_MEM_CS0' undeclared (first use in this function) drivers/mtd/nand/jz4740_nand.c: In function 'jz_nand_remove': drivers/mtd/nand/jz4740_nand.c:555:14: error: 'JZ_GPIO_MEM_CS0' undeclared (first use in this function) Patched similarly to: https://patchwork.linux-mips.org/patch/11089/ Fixes: 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h") Signed-off-by: Brian Norris

mtd: nand: sunxi: avoid retrieving data before ECC pass

2015-11-02T20:54:37+00:00

The in-band data are copied twice: before ECC correction and after the ECC engine has fixed all the fixable bitflips. Drop the useless memcpy_fromio operation by passing a NULL pointer when calling sunxi_nfc_read_buf(). Signed-off-by: Boris Brezillon Signed-off-by: Brian Norris

mtd: nand: sunxi: fix sunxi_nfc_hw_ecc_read/write_chunk()

2015-11-02T20:54:25+00:00

The sunxi_nfc_hw_ecc_read/write_chunk() functions try to avoid changing the column address if unnecessary, but the logic to determine whether it's necessary or not is currently wrong: it adds the ecc->bytes value to the current offset where it should actually add ecc->size. Fixes: 913821bdd211 ("mtd: nand: sunxi: introduce sunxi_nfc_hw_ecc_read/write_chunk()") Signed-off-by: Boris Brezillon Signed-off-by: Brian Norris

mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()

2015-10-30T18:50:38+00:00

Just like other NAND controllers, the NAND READID command only works in 8bit mode for all versions of BRCMNAND controller. This patch forces 8bit mode for each NAND CS in brcmnand_init_cs() before doing nand_scan_ident() to ensure that BRCMNAND controller is in 8bit mode when NAND READID command is issued. Signed-off-by: Anup Patel Reviewed-by: Ray Jui Reviewed-by: Scott Branden Signed-off-by: Brian Norris