Linux kernel source tree https://git.amat.us/linux/atom/drivers/mtd?h=v3.4.4 2012-06-09T15:36:13Z 2012-06-09T15:36:13Z Sascha Hauer s.hauer@pengutronix.de 2012-05-25T14:22:42Z urn:sha1:1e98ce80a4493f32b44f227d6050318462ca9d5d commit 4a43faf54e9173b6acce37cf7f053fc9515a2cdf upstream. Since commit 6a918bade9dab40aaef80559bd1169c69e8d69cb, the mxc_nand driver fails with: Driver must set ecc.strength when using hardware ECC This is because nand_scan_tail checks for correct ecc strength settings, so we must set them up before nand_scan_tail. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2012-06-09T15:36:13Z Gabor Juhos juhosg@openwrt.org 2012-05-23T22:17:23Z urn:sha1:29924c0318327d0444e0317587faf4a0693527a8 commit 2e24e32e2759348c9290404abad4f729f791bfad upstream. The 'mtd_writev' interface calls the function assigned to the '_write' field of a given mtd device if that is not NULL. The block2mtd driver sets the '_writev' field to the 'mtd_writev' function itself and thus causes a endless loop. This is caused by 1dbebd32562b3c2caeca35960e5cb00bfcc12900 (mtd: harmonize mtd_writev usage). Remove the assignment from the block2mtd driver to fix the issue. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2012-06-09T15:36:13Z Frank Svendsboe frank.svendsboe@gmail.com 2012-05-17T20:43:09Z urn:sha1:bdcefb1987edb1c62828d6c79f93e4b7af8734e2 commit 2e929d001e85126d9267de373d4b76014789661d upstream. MTD_OF_PARTS and the default setting is not working due to using 'Y' instead of 'y', introduced in commit d6137badeff1ef64b4e0092ec249ebdeaeb3ff37. This made our board, and possibly other boards using DTS defined partitions and not having CONFIG_MTD_OF_PARTS=y defined in the defconfig, fail to mount root. Signed-off-by: Frank Svendsboe <frank.svendsboe@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2012-06-09T15:36:12Z Dmitry Maluka D.Maluka@adbglobal.com 2012-05-11T17:51:51Z urn:sha1:a5b57cd820528f863d519ac5a0f6a94e5e8b3a0e commit 34a5704d91d6f8376a4c0a0143a1dd3eb3ccb37e upstream. It seems there is a bug in scan_read_raw_oob() in nand_bbt.c which should cause wrong functioning of NAND_BBT_SCANALLPAGES option. Artem: the patch did not apply and I had to amend it a bit. Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2012-05-13T18:33:09Z Linus Torvalds torvalds@linux-foundation.org 2012-05-13T18:33:09Z urn:sha1:9ff00d58a915b6747ba2e843ab2d04c712b4dc32 Pull three MTD fixes from David Woodhouse: - Fix a lock ordering deadlock in JFFS2 - Fix an oops in the dataflash driver, triggered by a dummy call to test whether it has OTP functionality. - Fix request_mem_region() failure on amsdelta NAND driver. * tag 'for-linus-3.4-20120513' of git://git.infradead.org/linux-mtd: mtd: ams-delta: fix request_mem_region() failure jffs2: Fix lock acquisition order bug in gc path mtd: fix oops in dataflash driver 2012-05-08T21:24:33Z Janusz Krzysztofik jkrzyszt@tis.icnet.pl 2012-05-07T20:51:37Z urn:sha1:b027274d2e3a332683b73f15e5cea79c240bc9a3 A call to request_mem_region() has been introduced in the omap-gpio driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40, "gpio/omap: Use devm_ API and add request_mem_region"). This change prevented the Amstrad Delta NAND driver, which was doing the same in order to take control over OMAP MPU I/O lines that the NAND device hangs off, from loading successfully. The I/O lines and corresponding registers used by the NAND driver are a subset of those used for the GPIO function. Then, to avoid run time collisions, all MPUIO GPIO lines should be marked as requested while initializing the NAND driver, and vice versa, a single MPUIO GPIO line already requested before the NAND driver initialization is attempted should prevent the NAND device from being started successfully. There is another driver, omap-keypad, which also manipulates MPUIO registers, but has never been calling request_mem_region() on startup, so it's not affected by the change in the gpio-omap and works correctly. It uses the depreciated omap_read/write functions for accessing MPUIO registers. Unlike the NAND driver, these I/O lines and registers are separate from those used by the GPIO driver. However, both register sets are non-contiguous and overlapping, so it would be impractical to request the two sets separately, one from the gpio-omap, the other form the omap-keypad driver. In order to solve all these issues correctly, a solution first suggested by Artem Bityutskiy, then closer specified by Tony Lindgren while they commented the initial version of this fix, should be implemented. The gpio-omap driver should export a few functions which would allow the other two drivers to access MPUIO registers in a safe manner instead of trying to manage them in parallel to the GPIO driver. However, such a big change, affecting 3 drivers all together, is not suitable for the rc cycle, and should be prepared for the merge window. Then, an alternative solution is proposed as a regression fix. For the ams-delta NAND driver to initialize correctly in coexistence with the changed GPIO driver, drop the request_mem_region() call from the former, especially as this call is going to be removed while the long-term solution is implemented. Tested on Amstrad Delta. Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> 2012-05-07T19:29:50Z Will Newton will.newton@gmail.com 2012-03-30T10:51:02Z urn:sha1:7a84477c4acebf6299b6a8bd6a1d5894eb838ffa I'm seeing an oops in mtd_dataflash.c with Linux 3.3. What appears to be happening is that otp_select_filemode calls mtd_read_fact_prot_reg with -1 for offset and length and a NULL buffer to test if OTP operations are supported. This finds its way down to otp_read in mtd_dataflash.c and causes an oops when memcpying the returned data into the NULL buf. None of the checks in otp_read catches the negative length and offset. Changing the length of the dummy read to 0 prevents the oops. Cc: stable@kernel.org [3.3+] Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> 2012-04-26T22:33:36Z Linus Torvalds torvalds@linux-foundation.org 2012-04-26T22:33:36Z urn:sha1:acdf2fc860f785781bb304a7f178141541f85283 Pull [GIT PULL] slave-dmaengine fixes from Vinod Koul. * 'fixes' of git://git.infradead.org/users/vkoul/slave-dma: dmaengine/amba-pl08x : reset phychan_hold on terminate all dma: pl330: fix a couple of compilation warnings dma/ste_dma40: fix erroneous comparison dma/ste_dma40: explicitly include regulator consumer header dma40: Improve the logic of stopping logical chan dmaengine: at_hdmac: remove clear-on-read in atc_dostart() dma: mxs-dma: enable channel in device_issue_pending call dmaengine: imx-dma: dont complete descriptor for cyclic dma 2012-04-20T10:05:58Z Shawn Guo shawn.guo@linaro.org 2012-04-11T05:29:31Z urn:sha1:d04525ed0323709711277563a2c76e446a017423 Enable channel in device_issue_pending call, so that the order between cookie assignment and channel enabling can be ensured naturally. It fixes the mxs gpmi-nand breakage which is caused by the incorrect order of cookie assigning and channel enabling. Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Tested-by: Huang Shijie <b32955@freescale.com> Tested-by <samgandhi9@gmail.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com> 2012-04-09T05:38:55Z Al Viro viro@zeniv.linux.org.uk 2012-04-09T05:36:28Z urn:sha1:c65390f4dd49755863f6d772ec538ee4757c08d7 simple_release_fs() should be only done on failure there. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>