- 29 Sep, 2012 40 commits
-
-
Iwo Mergler authored
This tests ECC biterror recovery on a single NAND page. Mostly intended to test ECC hardware and low-level NAND driver. There are two test modes: 0 - artificially inserting bit errors until the ECC fails This is the default method and fairly quick. It should be independent of the quality of the FLASH. 1 - re-writing the same pattern repeatedly until the ECC fails. This method relies on the physics of NAND FLASH to eventually generate '0' bits if '1' has been written sufficient times. Depending on the NAND, the first bit errors will appear after 1000 or more writes and then will usually snowball, reaching the limits of the ECC quickly. The test stops after 10000 cycles, should your FLASH be exceptionally good and not generate bit errors before that. Try a different page offset in that case. Please note that neither of these tests will significantly 'use up' any FLASH endurance. Only a maximum of two erase operations will be performed. Signed-off-by:Iwo Mergler <Iwo.Mergler@netcommwireless.com.au> Signed-off-by:
Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com>
-
Shmulik Ladkani authored
Huang Shijie <shijie8@gmail.com> explains: Assume we have a 1GiB(8Gib) NAND chip, and we set the partitions in the command line like this: #gpmi-nand:100m(boot),100m(kernel),1g(rootfs) In this case, the partition truncating occurs. The current code will get the following result: ---------------------------------- root@freescale ~$ cat /proc/mtd dev: size erasesize name mtd0: 06400000 00040000 "boot" mtd1: 06400000 00040000 "kernel" ---------------------------------- It is obvious that we lost the truncated partition `rootfs` which should be 824MiB in this case. Also, forbid 0-sized partitions. Signed-off-by:Shmulik Ladkani <shmulik.ladkani@gmail.com> Signed-off-by:
-
Sachin Kamat authored
module_platform_driver simplifies the code by eliminating module_init and module_exit calls. Signed-off-by:
Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by:
-
Fabio Estevam authored
With the new i.mx clock framework the mxc_nand clock is registered as: clk_register_clkdev(clk[nfc_gate], NULL, "mxc_nand");0") So we do not need to pass "nfc" string and can use NULL instead. Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
-
Fabio Estevam authored
Using module_platform_driver() makes the code smaller and cleaner. Signed-off-by:
-
Fabio Estevam authored
Using module_platform_driver() makes the code smaller and cleaner. Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
Fabio Estevam authored
Improve logging style by prefixing the pr_ messages with "gpmi_nand". Signed-off-by:
Huang Shijie <b32955@freescale.com> Signed-off-by:
-
Marek Vasut authored
Quoting from the datasheet for S25FL064P, rev. 05, Nov 18 2011, § 9.17: "A 64 kB[sic] sector erase (D8h) command issued on 4 kB or 8 kB erase sectors will erase all sectors in the specified 64 kB region. However, please note that a 4 kB sector erase (20h) or 8 kB sector erase (40h) command will not work on a 64 kB sector." Referring further to Table 8.1 and Table 8.2, it is clearly seen that most of the sectors are 64KiB; therefore disable this 4KiB erase support since it's valid only on first/last sectors. Signed-off-by:
-
Rafał Miłecki authored
This registers MTD driver for serial flash platform device. Right now it supports reading only, writing still has to be implemented. Artem: minor amendments. Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
David Woodhouse authored
Merge commit '371a0044' of 'git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git' We need the following 2 patches from the 'net-next' tree for the BCMA flash driver: 371a0044 bcma: detect and register NAND flash device d57ef3a6 bcma: detect and register serial flash device and this is why we are merging the net-next tree (presumably persistent) up to commit '371a0044'. Signed-off-by:
-
Akinobu Mita authored
Currently the data blocks which is used to test single bit error correction is allocated statically and injecting single bit error is implemented by using __change_bit() which must operate on the memory aligned to the size of an "unsigned long". But there is no such guarantee for statically allocated array. This fix the issue by allocating the data block dynamically by kmalloc(). It also allocate the ecc code dynamically instead of allocating statically on stack. The reason to allocate the ecc code dynamically is that later change will add tests which inject bit errors into the ecc code by bitops. Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by:
-
Akinobu Mita authored
This includes the message related changes: - Use pr_* instead of printk - Print hexdump of ECC code if test fails - Change log level for hexdump of data from KERN_DEBUG to KERN_INFO - Factor out the hexdump code into a separate function Signed-off-by:
-
Akinobu Mita authored
Return -EINVAL instead of -1 (-EPERM) when test fails. Signed-off-by:
-
Akinobu Mita authored
Including linux/jiffies.h was required for calling srandom32(jiffies) that has already been removed. Signed-off-by:
-
Brian Norris authored
JFFS2 was designed without thought for OOB bitflips, it seems, but they can occur and will be reported to JFFS2 via mtd_read_oob()[1]. We don't want to fail on these transactions, since the data was corrected. [1] Few drivers report bitflips for OOB-only transactions. With such drivers, this patch should have no effect. Signed-off-by:Brian Norris <computersforpeace@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Julia Lawall authored
devm free functions should not have to be explicitly used. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
-
Artem Bityutskiy authored
Clean-up the driver a bit to make it easier to read and amend the coding style. Mostly these are changes like: if (a) { } => if (a) { } Some extra blank lines were added. Indentation was changed to use tabs instead of spaces. Signed-off-by: -
Artem Bityutskiy authored
This patch revises and fixes error handling in the command line mtd partitions parser. Namely: 1. we ignored return code of 'mtdpart_setup_real()'. 2. instead of returning 0 for failure and 1 for success, teach 'mtdpart_setup_real()' to return real error codes. Signed-off-by:
-
Rafał Miłecki authored
This driver provides parser detecting partitions on BCM47XX flash memories. It has many differences in comparison to BCM63XX, like: 1) Different CFE with no more trivial MAGICs 2) More partitions types (board_data, ML, POT) 3) Supporting more than 1 flash on a device which resulted in decision of writing new parser. It uses generic mtd interface and was successfully tested with Netgear WNDR4500 router which has 2 flash memories: serial one and NAND one. Signed-off-by:
-
Artem Bityutskiy authored
We do not have to initialize variables for .bss to 0 in Linux. Signed-off-by:
-
Andreas Bießmann authored
Unloading the omap2 nand driver missed to release the memory region which will result in not being able to request it again if one want to load the driver later on. This patch fixes following error when loading omap2 module after unloading: ---8<--- ~ $ rmmod omap2 ~ $ modprobe omap2 [ 37.420928] omap2-nand: probe of omap2-nand.0 failed with error -16 ~ $ --->8--- This error was introduced in 67ce04bf which was the first commit of this driver. Signed-off-by:
Andreas Bießmann <andreas@biessmann.de> Cc: stable@vger.kernel.org Signed-off-by:
-
Andreas Bießmann authored
Do not kfree() the mtd_info; it is handled in the mtd subsystem and already freed by nand_release(). Instead kfree() the struct omap_nand_info allocated in omap_nand_probe which was not freed before. This patch fixes following error when unloading the omap2 module: ---8<--- ~ $ rmmod omap2 ------------[ cut here ]------------ kernel BUG at mm/slab.c:3126! Internal error: Oops - BUG: 0 [#1] PREEMPT ARM Modules linked in: omap2(-) CPU: 0 Not tainted (3.6.0-rc3-00230-g155e36d4-dirty #3) PC is at cache_free_debugcheck+0x2d4/0x36c LR is at kfree+0xc8/0x2ac pc : [<c01125a0>] lr : [<c0112efc>] psr: 200d0193 sp : c521fe08 ip : c0e8ef90 fp : c521fe5c r10: bf0001fc r9 : c521e000 r8 : c0d99c8c r7 : c661ebc0 r6 : c065d5a4 r5 : c65c4060 r4 : c78005c0 r3 : 00000000 r2 : 00001000 r1 : c65c4000 r0 : 00000001 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 86694019 DAC: 00000015 Process rmmod (pid: 549, stack limit = 0xc521e2f0) Stack: (0xc521fe08 to 0xc5220000) fe00: c008a874 c00bf44c c515c6d0 200d0193 c65c4860 c515c240 fe20: c521fe3c c521fe30 c008a9c0 c008a854 c521fe5c c65c4860 c78005c0 bf0001fc fe40: c780ff40 a00d0113 c521e000 00000000 c521fe84 c521fe60 c0112efc c01122d8 fe60: c65c4860 c0673778 c06737ac 00000000 00070013 00000000 c521fe9c c521fe88 fe80: bf0001fc c0112e40 c0673778 bf001ca8 c521feac c521fea0 c02ca11c bf0001ac fea0: c521fec4 c521feb0 c02c82c4 c02ca100 c0673778 bf001ca8 c521fee4 c521fec8 fec0: c02c8dd8 c02c8250 00000000 bf001ca8 bf001ca8 c0804ee0 c521ff04 c521fee8 fee0: c02c804c c02c8d20 bf001924 00000000 bf001ca8 c521e000 c521ff1c c521ff08 ff00: c02c950c c02c7fbc bf001d48 00000000 c521ff2c c521ff20 c02ca3a4 c02c94b8 ff20: c521ff3c c521ff30 bf001938 c02ca394 c521ffa4 c521ff40 c009beb4 bf001930 ff40: c521ff6c 70616d6f b6fe0032 c0014f84 70616d6f b6fe0032 00000081 60070010 ff60: c521ff84 c521ff70 c008e1f4 c00bf328 0001a004 70616d6f c521ff94 0021ff88 ff80: c008e368 0001a004 70616d6f b6fe0032 00000081 c0015028 00000000 c521ffa8 ffa0: c0014dc0 c009bcd0 0001a004 70616d6f bec2ab38 00000880 bec2ab38 00000880 ffc0: 0001a004 70616d6f b6fe0032 00000081 00000319 00000000 b6fe1000 00000000 ffe0: bec2ab30 bec2ab20 00019f00 b6f539c0 60070010 bec2ab38 aaaaaaaa aaaaaaaa Backtrace: [<c01122cc>] (cache_free_debugcheck+0x0/0x36c) from [<c0112efc>] (kfree+0xc8/0x2ac) [<c0112e34>] (kfree+0x0/0x2ac) from [<bf0001fc>] (omap_nand_remove+0x5c/0x64 [omap2]) [<bf0001a0>] (omap_nand_remove+0x0/0x64 [omap2]) from [<c02ca11c>] (platform_drv_remove+0x28/0x2c) r5:bf001ca8 r4:c0673778 [<c02ca0f4>] (platform_drv_remove+0x0/0x2c) from [<c02c82c4>] (__device_release_driver+0x80/0xdc) [<c02c8244>] (__device_release_driver+0x0/0xdc) from [<c02c8dd8>] (driver_detach+0xc4/0xc8) r5:bf001ca8 r4:c0673778 [<c02c8d14>] (driver_detach+0x0/0xc8) from [<c02c804c>] (bus_remove_driver+0x9c/0x104) r6:c0804ee0 r5:bf001ca8 r4:bf001ca8 r3:00000000 [<c02c7fb0>] (bus_remove_driver+0x0/0x104) from [<c02c950c>] (driver_unregister+0x60/0x80) r6:c521e000 r5:bf001ca8 r4:00000000 r3:bf001924 [<c02c94ac>] (driver_unregister+0x0/0x80) from [<c02ca3a4>] (platform_driver_unregister+0x1c/0x20) r5:00000000 r4:bf001d48 [<c02ca388>] (platform_driver_unregister+0x0/0x20) from [<bf001938>] (omap_nand_driver_exit+0x14/0x1c [omap2]) [<bf001924>] (omap_nand_driver_exit+0x0/0x1c [omap2]) from [<c009beb4>] (sys_delete_module+0x1f0/0x2ec) [<c009bcc4>] (sys_delete_module+0x0/0x2ec) from [<c0014dc0>] (ret_fast_syscall+0x0/0x48) r8:c0015028 r7:00000081 r6:b6fe0032 r5:70616d6f r4:0001a004 Code: e1a00005 eb0d9172 e7f001f2 e7f001f2 (e7f001f2) ---[ end trace 6a30b24d8c0cc2ee ]--- Segmentation fault --->8--- This error was introduced in 67ce04bf which was the first commit of this driver. Signed-off-by:
-
Stefan Roese authored
Unlocking may take up to 1.4 seconds on some Intel flashes. So lets use a max. of 1.5 seconds (1500ms) as timeout. See "Clear Block Lock-Bits Time" on page 40 in "3 Volt Intel StrataFlash Memory" 28F128J3,28F640J3,28F320J3 manual from February 2003 This patch also fixes some other problems with this timeout: - Don't use HZ in timeout "calculation"! While testing we noticed that an unlocking timeout occured with HZ=1000 and didn't occur with HZ=300. This was because the timeout parameter was calculated differently depending on the HZ value. Now a fixed value of 1500ms is used. - The last parameter of WAIT_TIMEOUT (defined to inval_cache_and_wait_for_operation) has to be passed in micro-seconds. So multiply the ms value with 1000 and not 100 to calculate this value. - Use variable name "mdelay" instead of misleading "udelay". Signed-off-by:
Stefan Roese <sr@denx.de> Tested-by:
Stephan Gatzka <stephan@gatzka.org> Signed-off-by:
-
Jeff Westfahl authored
Added a NAND device flag for subpage read support. Previously this was hard coded based on large page and soft ECC. Updated base NAND driver to use the new subpage read flag if the NAND is large page and soft ECC. Signed-off-by:
Jeff Westfahl <jeff.westfahl@ni.com> Reviewed-by:
-
Thomas Petazzoni authored
Commit abcda1dc ('arm: plat-orion: introduce PLAT_ORION_LEGACY hidden config option') currently pending in linux-next will make the ARCH_MVEBU platform select PLAT_ORION, which means that now all Orion drivers can be enabled on ARCH_MVEBU. This works fine for most drivers, except for orion_nand, because it includes <mach/hardware.h>, but mach-mvebu does not have a mach/hardware.h header (it is considered as a deprecated practice). It turns out that the <mach/hardware.h> include in orion_nand is not necessary: the driver builds perfectly fine without it, so we simply get rid of it. Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Akinobu Mita authored
Return an error code if test fails in order to detect a test case failure by invoking tests repeatedly like this: while sudo modprobe mtd_nandecctest; do sudo modprobe -r mtd_nandecctest done Signed-off-by:
-
Akinobu Mita authored
It is unnecessary for this driver to call srandom32() in module_init. Signed-off-by:
-
Gabor Juhos authored
Signed-off-by:
Gabor Juhos <juhosg@openwrt.org> Signed-off-by:
-
Jan Luebbe authored
Signed-off-by:
Jan Luebbe <jlu@pengutronix.de> Signed-off-by:
-
Roland Stigge authored
The LPC32xx's DT-only conversion of the MLC NAND driver makes NAND config via platform_data obsolete. Dropped by this patch. Further, the driver really needs CONFIG_OF, which is already reflected by the dependency on ARCH_LPC32XX which depends on CONFIG_OF. So also dropping CONFIG_OF ifdefs. There is still platform_data necessary to supply the dma_filter callback for the dma engine. This is a completely different data structure than the old platform_data for NAND config, so renaming some old "pdata" variable to "ncfg" to prevent confusion with the new platform data. Signed-off-by:
Roland Stigge <stigge@antcom.de> Signed-off-by:
-
Roland Stigge authored
The LPC32xx's DT-only conversion of the SLC NAND driver makes NAND config via platform_data obsolete. Dropped by this patch. Further, the driver really needs CONFIG_OF, which is already reflected by the dependency on ARCH_LPC32XX which depends on CONFIG_OF. So also dropping CONFIG_OF ifdefs. There is still platform_data necessary to supply the dma_filter callback for the dma engine. This is a completely different data structure than the old platform_data for NAND config, so renaming some old "pdata" variable to "ncfg" to prevent confusion with the new platform data. Signed-off-by:
-
Fabio Estevam authored
Allow MTD_NAND_GPMI_NAND to be built as module. Signed-off-by:
-
Fabio Estevam authored
When building MTD_NAND_GPMI_NAND as module, the following error shows up: ERROR: "nand_update_bbt" [drivers/mtd/nand/gpmi-nand/gpmi_nand.ko] undefined! Export nand_update_bbt to fix it. Signed-off-by:
-
Shmulik Ladkani authored
Rename 'len' variable of create_bbt/scan_block_fast/scan_block_full to 'numpages', since it really means number of pages to scan when searching for the BBM (and not the byte length of the scan). Signed-off-by:
-
Sachin Kamat authored
Fixes the following warnings: ‘s3c2410_nand_correct_data’ defined but not used [-Wunused-function] ‘s3c2410_nand_enable_hwecc’ defined but not used [-Wunused-function] ‘s3c2412_nand_enable_hwecc’ defined but not used [-Wunused-function] ‘s3c2440_nand_enable_hwecc’ defined but not used [-Wunused-function] ‘s3c2410_nand_calculate_ecc’ defined but not used [-Wunused-function] ‘s3c2412_nand_calculate_ecc’ defined but not used [-Wunused-function] ‘s3c2440_nand_calculate_ecc’ defined but not used [-Wunused-function] The above functions are called only when CONFIG_MTD_NAND_S3C2410_HWECC is defined. Thus making them conditional. Signed-off-by:
-
Sachin Kamat authored
devm_* functions are device managed functions and make cleanup code simpler and smaller. devm_kzalloc, devm_clk_get and devm_request_and_ioremap functions are used. Signed-off-by:
-
Julia Lawall authored
Err has only been initialized to 0 at this, so it is not possible that this test can be true. Signed-off-by:
-
Randy Dunlap authored
Fix kernel-doc warning in <linux/mtd/nand.h>: Warning(include/linux/mtd/nand.h:659): No description found for parameter 'read_byte' Signed-off-by:
Randy Dunlap <rdunlap@xenotime.net> Acked-by:
-
Huang Shijie authored
We may cause a memory leak when the @types has more then one parser. Take the `default_mtd_part_types` for example. The default_mtd_part_types has two parsers now: `cmdlinepart` and `ofpart`. Assume the following case: The kernel command line sets the partitions like: #gpmi-nand:20m(boot),20m(kernel),1g(rootfs),-(user) But the devicetree file(such as arch/arm/boot/dts/imx28-evk.dts) also sets the same partitions as the kernel command line does. In the current code, the partitions parsed out by the `ofpart` will overwrite the @pparts which has already set by the `cmdlinepart` parser, and the the partitions parsed out by the `cmdlinepart` is missed. A memory leak occurs. So we should break the code as soon as we parse out the partitions, In actually, this patch makes a priority order between the parsers. If one parser has already parsed out the partitions successfully, it's no need to use another parser anymore. Signed-off-by:
Huang Shijie <shijie8@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Stefan Roese authored
On some platforms (e.g. MPC5200) a direct 1:1 mapping may cause problems with JFFS2 usage, as the local bus (LPB) doesn't support unaligned accesses as implemented in the JFFS2 code via memcpy(). By defining "no-unaligned-direct-access", the flash will not be exposed directly to the MTD users (e.g. JFFS2) any more. Signed-off-by:
-
