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

mtd: spi-nor: aspeed-smc: Use io string accessors to fifo

2016-02-22T05:27:33+00:00

Make and use new routines to access the fifo when in user mode. Instead of using memcpy_fromio, base the new routines on the io port string accessors. When the smc controllers are configured to transfer in user mode, the exact address within the chip select region is ignored and all valid data bytes are sent to the device fifo. It has been determined the reason _memcpy_fromio, an arm specific byte-by-byte variant of memcpy_fromio was required in read_reg, is that the later will stutter when coping from memory, discarding some bytes read, when switching from words to bytes for the final unaligned length. This change includes a hack to make inw/outw work. The default generic IO_SPACE_LIMIT is 0, and twenty bits when PCI is selected. While there is a PCMCIA SOC config to select the full 4GB space it would bring in the PCMCIA core for no use to the ast2400. We want to be part of the generic multi-platform arm kernel and therefore mach/io.h is not going to work. However, the limit is under an ifndef, so define it in this file an check it was not redefine at probe time. To avoid redefinition errors or warnings, guard the setting with CONFIG_ARM for cross-arch compile testing and with a Kconfig dependency for arm cross-compile tests. While some other architecture may not accept unsigned long addresses as ioport cookies, that can be addressed when, if ever, the hardware appears on another arch. While the change to use the designed-for-memory optimised copy template, even reusing the bytes of memcpy, was a recent change and only for little endian arm, designing and proposing a patch will take some time and there could be debate if the routine needs to work on changing memory. Signed-off-by: Milton Miller Reviewed-by: Andrew Jeffery Signed-off-by: Joel Stanley

Merge tag 'v4.3.6' into dev-4.3

2016-02-22T05:13:27+00:00

This is the 4.3.6 stable release Signed-off-by: Joel Stanley

mtd: ubi: don't leak e if schedule_erase() fails

2016-02-19T22:28:26+00:00

commit 6b238de189f69dc77d660d4cce62eed15547f4c3 upstream. If __erase_worker() fails to erase the EB and schedule_erase() fails as well to do anything about it then we go RO. But that is not a reason to leak the e argument here. Therefore clean up e. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman

mtd: ubi: fixup error correction in do_sync_erase()

2016-02-19T22:28:26+00:00

commit 1a31b20cd81d5cbc7ec6e24cb08066009a1ca32d upstream. Since fastmap we gained do_sync_erase(). This function can return an error and its error handling isn't obvious. First the memory allocation for struct ubi_work can fail and as such struct ubi_wl_entry is leaked. However if the memory allocation succeeds then the tail function takes care of the struct ubi_wl_entry. A free here could result in a double free. To make the error handling simpler, I split the tail function into one piece which does the work and another which frees the struct ubi_work which is passed as argument. As result do_sync_erase() can keep the struct on stack and we get rid of one error source. Fixes: 8199b901a ("UBI: Add fastmap support to the WL sub-system") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman

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

2016-02-19T22:28:26+00:00

commit 96dd922c198286681fbbc15100e196e0f629e2fb upstream. 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 Signed-off-by: Greg Kroah-Hartman

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

2016-02-19T22:28:26+00:00

commit 9ca641b0f02a3a1eedbc8c296e695326da9bbaf9 upstream. 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 Signed-off-by: Greg Kroah-Hartman

mtd: blkdevs: fix potential deadlock + lockdep warnings

2016-02-19T22:28:26+00:00

commit f3c63795e90f0c6238306883b6c72f14d5355721 upstream. Commit 073db4a51ee4 ("mtd: fix: avoid race condition when accessing mtd->usecount") fixed a race condition but due to poor ordering of the mutex acquisition, introduced a potential deadlock. The deadlock can occur, for example, when rmmod'ing the m25p80 module, which will delete one or more MTDs, along with any corresponding mtdblock devices. This could potentially race with an acquisition of the block device as follows. -> blktrans_open() -> mutex_lock(&dev->lock); -> mutex_lock(&mtd_table_mutex); -> del_mtd_device() -> mutex_lock(&mtd_table_mutex); -> blktrans_notify_remove() -> del_mtd_blktrans_dev() -> mutex_lock(&dev->lock); This is a classic (potential) ABBA deadlock, which can be fixed by making the A->B ordering consistent everywhere. There was no real purpose to the ordering in the original patch, AFAIR, so this shouldn't be a problem. This ordering was actually already present in del_mtd_blktrans_dev(), for one, where the function tried to ensure that its caller already held mtd_table_mutex before it acquired &dev->lock: if (mutex_trylock(&mtd_table_mutex)) { mutex_unlock(&mtd_table_mutex); BUG(); } So, reverse the ordering of acquisition of &dev->lock and &mtd_table_mutex so we always acquire mtd_table_mutex first. Snippets of the lockdep output follow: # modprobe -r m25p80 [ 53.419251] [ 53.420838] ====================================================== [ 53.427300] [ INFO: possible circular locking dependency detected ] [ 53.433865] 4.3.0-rc6 #96 Not tainted [ 53.437686] ------------------------------------------------------- [ 53.444220] modprobe/372 is trying to acquire lock: [ 53.449320] (&new->lock){+.+...}, at: [] del_mtd_blktrans_dev+0x80/0xdc [ 53.457271] [ 53.457271] but task is already holding lock: [ 53.463372] (mtd_table_mutex){+.+.+.}, at: [] del_mtd_device+0x18/0x100 [ 53.471321] [ 53.471321] which lock already depends on the new lock. [ 53.471321] [ 53.479856] [ 53.479856] the existing dependency chain (in reverse order) is: [ 53.487660] -> #1 (mtd_table_mutex){+.+.+.}: [ 53.492331] [] blktrans_open+0x34/0x1a4 [ 53.497879] [] __blkdev_get+0xc4/0x3b0 [ 53.503364] [] blkdev_get+0x108/0x320 [ 53.508743] [] do_dentry_open+0x218/0x314 [ 53.514496] [] path_openat+0x4c0/0xf9c [ 53.519959] [] do_filp_open+0x5c/0xc0 [ 53.525336] [] do_sys_open+0xfc/0x1cc [ 53.530716] [] ret_fast_syscall+0x0/0x1c [ 53.536375] -> #0 (&new->lock){+.+...}: [ 53.540587] [] mutex_lock_nested+0x38/0x3cc [ 53.546504] [] del_mtd_blktrans_dev+0x80/0xdc [ 53.552606] [] blktrans_notify_remove+0x7c/0x84 [ 53.558891] [] del_mtd_device+0x74/0x100 [ 53.564544] [] del_mtd_partitions+0x80/0xc8 [ 53.570451] [] mtd_device_unregister+0x24/0x48 [ 53.576637] [] spi_drv_remove+0x1c/0x34 [ 53.582207] [] __device_release_driver+0x88/0x114 [ 53.588663] [] device_release_driver+0x20/0x2c [ 53.594843] [] bus_remove_device+0xd8/0x108 [ 53.600748] [] device_del+0x10c/0x210 [ 53.606127] [] device_unregister+0xc/0x20 [ 53.611849] [] __unregister+0x10/0x20 [ 53.617211] [] device_for_each_child+0x50/0x7c [ 53.623387] [] spi_unregister_master+0x58/0x8c [ 53.629578] [] release_nodes+0x15c/0x1c8 [ 53.635223] [] __device_release_driver+0x90/0x114 [ 53.641689] [] driver_detach+0xb4/0xb8 [ 53.647147] [] bus_remove_driver+0x4c/0xa0 [ 53.652970] [] SyS_delete_module+0x11c/0x1e4 [ 53.658976] [] ret_fast_syscall+0x0/0x1c [ 53.664621] [ 53.664621] other info that might help us debug this: [ 53.664621] [ 53.672979] Possible unsafe locking scenario: [ 53.672979] [ 53.679169] CPU0 CPU1 [ 53.683900] ---- ---- [ 53.688633] lock(mtd_table_mutex); [ 53.692383] lock(&new->lock); [ 53.698306] lock(mtd_table_mutex); [ 53.704658] lock(&new->lock); [ 53.707946] [ 53.707946] *** DEADLOCK *** Fixes: 073db4a51ee4 ("mtd: fix: avoid race condition when accessing mtd->usecount") Reported-by: Felipe Balbi Tested-by: Felipe Balbi Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman

mtd: mtdpart: fix add_mtd_partitions error path

2016-02-19T22:28:26+00:00

commit e5bae86797141e4a95e42d825f737cb36d7b8c37 upstream. If we fail to allocate a partition structure in the middle of the partition creation process, the already allocated partitions are never removed, which means they are still present in the partition list and their resources are never freed. Signed-off-by: Boris Brezillon Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman

mtd/spi-nor: Add SPI memory controllers for ASPEED AST2400

2016-01-27T03:13:52+00:00

This driver adds mtd support for spi-nor attached to either or both of the Static Memory Controller (new registers) or the SPI Memory Controller. The Static Memory Controller is the boot soruce for the SOC. The controller supports up to 5 chip selects in any combination of NAND, NOR, and SPI. The memory controller registers were updated in the AST2300 and this fmc binding is for the registers in the new mode. This driver currently supports only SPI-NOR attached memory, but has some considerations to support the others later (including choice of the Kconfig symbol). There is also a similar register set to support the Static Memory Controller in a legacy address mode. That mode is not currently supported because it is expected that the system will run with the fmc binding supporting multiple chip selects. The normal application of the SPI Memory Controller is designated for use by the host system either for video bios or system bios and can be accessed over either an LPC bus and/or a PCIe bus or via a SPI passthough. The SOC can also access this chip for firmware updates when not in passthrough mode. It is expected the passthru mode and the alternate chip select will be controlled by a future pinmux driver. This driver has only been tested with the ast2400 SOC. Signed-off-by: Milton Miller

Merge tag 'for-linus-20151006' of git://git.infradead.org/linux-mtd

2015-10-07T08:35:15+00:00

Pull MTD fixes from Brian Norris: "A few MTD fixes: - mxc_nand: a "refactoring only" change in 4.3-rc1 had some bad pointer (array) arithmetic. Fix that - sunxi_nand: - Fix an old list manipulation / memory management bug in the device release() code path - Correct a few mistakes in OOB write support" * tag 'for-linus-20151006' of git://git.infradead.org/linux-mtd: mxc_nand: fix copy_spare mtd: nand: sunxi: fix sunxi_nand_chips_cleanup() mtd: nand: sunxi: fix OOB handling in ->write_xxx() functions