kernel/git/stable/linux.git/drivers/mtd/nand/omap2.c, branch master

mtd: nand: move raw NAND related code to the raw/ subdir

2018-02-16T09:09:34+00:00

As part of the process of sharing more code between different NAND based devices, we need to move all raw NAND related code to the raw/ subdirectory. Signed-off-by: Boris Brezillon

mtd: nand: squash struct nand_buffers into struct nand_chip

2017-12-14T12:34:19+00:00

struct nand_buffers is malloc'ed in nand_scan_tail() just for containing three pointers. Squash this struct into nand_chip. Move and rename as follows: chip->buffers->ecccalc -> chip->ecc.calc_buf chip->buffers->ecccode -> chip->ecc.code_buf chip->buffers->databuf -> chip->data_buf Signed-off-by: Masahiro Yamada Signed-off-by: Boris Brezillon

mtd: nand: force drivers to explicitly send READ/PROG commands

2017-12-14T12:34:17+00:00

The core currently send the READ0 and SEQIN+PAGEPROG commands in nand_do_read/write_ops(). This is inconsistent with ->read/write_oob[_raw]() hooks behavior which are expected to send these commands. There's already a flag (NAND_ECC_CUSTOM_PAGE_ACCESS) to inform the core that a specific controller wants to send the READ/SEQIN+PAGEPROG commands on its own, but it's an opt-in flag, and existing drivers are unlikely to be updated to pass it. Moreover, some controllers cannot dissociate the READ/PAGEPROG commands from the associated data transfer and ECC engine activation, and developers have to hack things in their ->cmdfunc() implementation to handle such complex cases, or have to accept the perf penalty of sending twice the same command. To address this problem we are planning on adding a new interface which is passed all information about a NAND operation (including the amount of data to transfer) and replacing all calls to ->cmdfunc() to calls to this new ->exec_op() hook. But, in order to do that, we need to have all ->cmdfunc() calls placed near their associated ->read/write_buf/byte() calls. Modify the core and relevant drivers to make NAND_ECC_CUSTOM_PAGE_ACCESS the default case, and remove this flag. Signed-off-by: Boris Brezillon [miquel.raynal@free-electrons.com: tested, fixed and rebased on nand/next] Signed-off-by: Miquel Raynal Acked-by: Masahiro Yamada

mtd: nand: provide several helpers to do common NAND operations

2017-12-14T12:34:12+00:00

This is part of the process of removing direct calls to ->cmdfunc() outside of the core in order to introduce a better interface to execute NAND operations. Here we provide several helpers and make use of them to remove all direct calls to ->cmdfunc(). This way, we can easily modify those helpers to make use of the new ->exec_op() interface when available. Signed-off-by: Boris Brezillon [miquel.raynal@free-electrons.com: rebased and fixed some conflicts] Signed-off-by: Miquel Raynal Acked-by: Masahiro Yamada

mtd: nand: omap2: Fix subpage write

2017-10-27T14:53:23+00:00

Since v4.12, NAND subpage writes were causing a NULL pointer dereference on OMAP platforms (omap2-nand) using OMAP_ECC_BCH4_CODE_HW, OMAP_ECC_BCH8_CODE_HW and OMAP_ECC_BCH16_CODE_HW. This is because for those ECC modes, omap_calculate_ecc_bch() generates ECC bytes for the entire (multi-sector) page and this can overflow the ECC buffer provided by nand_write_subpage_hwecc() as it expects ecc.calculate() to return ECC bytes for just one sector. However, the root cause of the problem is present since v3.9 but was not seen then as NAND buffers were being allocated as one big chunk prior to commit 3deb9979c731 ("mtd: nand: allocate aligned buffers if NAND_OWN_BUFFERS is unset"). Fix the issue by providing a OMAP optimized write_subpage() implementation. Fixes: 62116e5171e0 ("mtd: nand: omap2: Support for hardware BCH error correction.") Cc: Signed-off-by: Roger Quadros Signed-off-by: Boris Brezillon

mtd: nand: omap2: Do not assign omap_nand_info to platform drvdata

2017-10-14T13:21:05+00:00

commit 67ce04bf2746 ("mtd: nand: add OMAP2/OMAP3 NAND driver") assigned pointer to omap_nand_info to the platform drvdata in probe function just to be reasigned later to the pointer to mtd_info, which is what remove function expects it to be. Remove useless assignment. Signed-off-by: Ladislav Michl Acked-by: Roger Quadros Signed-off-by: Boris Brezillon

mtd: nand: omap2: Remove omap_nand_platform_data

2017-10-14T13:18:17+00:00

As driver is now configured using DT, omap_nand_platform_data structure is no longer needed. Signed-off-by: Ladislav Michl Acked-by: Roger Quadros Signed-off-by: Boris Brezillon

mtd: nand: Rename nand.h into rawnand.h

2017-08-13T08:11:49+00:00

We are planning to share more code between different NAND based devices (SPI NAND, OneNAND and raw NANDs), but before doing that we need to move the existing include/linux/mtd/nand.h file into include/linux/mtd/rawnand.h so we can later create a nand.h header containing all common structure and function prototypes. Signed-off-by: Boris Brezillon Signed-off-by: Peter Pan Acked-by: Vladimir Zapolskiy Acked-by: Alexander Sverdlin Acked-by: Wenyou Yang Acked-by: Krzysztof Kozlowski Acked-by: Han Xu Acked-by: H Hartley Sweeten Acked-by: Shawn Guo Acked-by: Gregory CLEMENT Acked-by: Neil Armstrong Acked-by: Masahiro Yamada Acked-By: Harvey Hunt Acked-by: Tony Lindgren Acked-by: Krzysztof Halasa

mtd: nand: omap2: Fix partition creation via cmdline mtdparts

2017-04-25T12:18:40+00:00

commit c9711ec5250b ("mtd: nand: omap: Clean up device tree support") caused the parent device name to be changed from "omap2-nand.0" to ".nand" (e.g. 30000000.nand on omap3 platforms). This caused mtd->name to be changed as well. This breaks partition creation via mtdparts passed by u-boot as it uses "omap2-nand.0" for the mtd-id. Fix this by explicitly setting the mtd->name to "omap2-nand." if it isn't already set by nand_set_flash_node(). CS number is the NAND controller instance ID. Fixes: c9711ec5250b ("mtd: nand: omap: Clean up device tree support") Cc: # 4.7+ Reported-by: Leto Enrico Reported-by: Adam Ford Suggested-by: Boris Brezillon Tested-by: Adam Ford Signed-off-by: Roger Quadros Signed-off-by: Boris Brezillon

mtd: nand: omap2: return error code of nand_scan_ident/tail() on error

2016-11-07T13:48:50+00:00

The nand_scan_ident/tail() returns an appropriate error value when it fails. Use it instead of the fixed error code -ENXIO. Signed-off-by: Masahiro Yamada Reviewed-by: Marek Vasut Signed-off-by: Boris Brezillon