- 11 Mar, 2014 40 commits
-
-
Rafał Miłecki authored
Home routers based on SoCs like BCM53010 (AKA BCM4708) use flashes which can be nicely partitioned with bcm47xxpart. Header bcm47xx_nvram.h is not available on bcm53xx, so don't include it. Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
Brian Norris <computersforpeace@gmail.com>
-
Rafał Miłecki authored
Our code parsing "trx" header registers few partitions at once (in one loop iteration). Add extra check in that place. Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Philippe De Muyter authored
Up to now mtd-ram devices described in device trees were only accessible if mtd-flash or mtd-rom were also configured at linux configuration time, because MTD_PHYSMAP_OF was only available if (MTD_CFI || MTD_JEDECPROBE || MTD_ROM). Allow MTD_PHYSMAP_OF selection also when only MTD_RAM is set. Signed-off-by:
Philippe De Muyter <phdm@macqel.be> Signed-off-by:
-
Brian Norris authored
Signed-off-by:
Marek Vasut <marex@denx.de>
-
Ezequiel Garcia authored
Some flashes can only be properly accessed when the ECC mode is specified, so a way to describe such mode is required. Together, the ECC strength and step size define the correction capability, so that we say we will correct "{strength} bit errors per {size} bytes". The interpretation of these parameters is implementation-defined, but they often have ramifications on the formation, interpretation, and placement of correction metadata on the flash. Not all implementations must support all possible combinations. Implementations are encouraged to further define the value(s) they support. Acked-by:Boris BREZILLON <b.brezillon.dev@gmail.com> Acked-by:
Grant Likely <grant.likely@secretlab.ca> Signed-off-by:
Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by:
-
Ezequiel Garcia authored
This commit adds simple helpers to obtain the devicetree properties that specify the ECC strength and ECC step size to use on a given NAND controller. Acked-by:
-
Christian Riesch authored
Signed-off-by:
Christian Riesch <christian.riesch@omicron.at> Cc: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com> Signed-off-by:
-
Ajesh Kunhipurayil Vijayan authored
mounting JFFS2 partition sometimes crashes with this call trace: [ 1322.240000] Kernel bug detected[#1]: [ 1322.244000] Cpu 2 [ 1322.244000] $ 0 : 0000000000000000 0000000000000018 000000003ff00070 0000000000000001 [ 1322.252000] $ 4 : 0000000000000000 c0000000f3980150 0000000000000000 0000000000010000 [ 1322.260000] $ 8 : ffffffffc09cd5f8 0000000000000001 0000000000000088 c0000000ed300de8 [ 1322.268000] $12 : e5e19d9c5f613a45 ffffffffc046d464 0000000000000000 66227ba5ea67b74e [ 1322.276000] $16 : c0000000f1769c00 c0000000ed1e0200 c0000000f3980150 0000000000000000 [ 1322.284000] $20 : c0000000f3a80000 00000000fffffffc c0000000ed2cfbd8 c0000000f39818f0 [ 1322.292000] $24 : 0000000000000004 0000000000000000 [ 1322.300000] $28 : c0000000ed2c0000 c0000000ed2cfab8 0000000000010000 ffffffffc039c0b0 [ 1322.308000] Hi : 000000000000023c [ 1322.312000] Lo : 000000000003f802 [ 1322.316000] epc : ffffffffc039a9f8 check_tn_node+0x88/0x3b0 [ 1322.320000] Not tainted [ 1322.324000] ra : ffffffffc039c0b0 jffs2_do_read_inode_internal+0x1250/0x1e48 [ 1322.332000] Status: 5400f8e3 KX SX UX KERNEL EXL IE [ 1322.336000] Cause : 00800034 [ 1322.340000] PrId : 000c1004 (Netlogic XLP) [ 1322.344000] Modules linked in: [ 1322.348000] Process jffs2_gcd_mtd7 (pid: 264, threadinfo=c0000000ed2c0000, task=c0000000f0e68dd8, tls=0000000000000000) [ 1322.356000] Stack : c0000000f1769e30 c0000000ed010780 c0000000ed010780 c0000000ed300000 c0000000f1769c00 c0000000f3980150 c0000000f3a80000 00000000fffffffc c0000000ed2cfbd8 ffffffffc039c0b0 ffffffffc09c6340 0000000000001000 0000000000000dec ffffffffc016c9d8 c0000000f39805a0 c0000000f3980180 0000008600000000 0000000000000000 0000000000000000 0000000000000000 0001000000000dec c0000000f1769d98 c0000000ed2cfb18 0000000000010000 0000000000010000 0000000000000044 c0000000f3a80000 c0000000f1769c00 c0000000f3d207a8 c0000000f1769d98 c0000000f1769de0 ffffffffc076f9c0 0000000000000009 0000000000000000 0000000000000000 ffffffffc039cf90 0000000000000017 ffffffffc013fbdc 0000000000000001 000000010003e61c ... [ 1322.424000] Call Trace: [ 1322.428000] [<ffffffffc039a9f8>] check_tn_node+0x88/0x3b0 [ 1322.432000] [<ffffffffc039c0b0>] jffs2_do_read_inode_internal+0x1250/0x1e48 [ 1322.440000] [<ffffffffc039cf90>] jffs2_do_crccheck_inode+0x70/0xd0 [ 1322.448000] [<ffffffffc03a1b80>] jffs2_garbage_collect_pass+0x160/0x870 [ 1322.452000] [<ffffffffc03a392c>] jffs2_garbage_collect_thread+0xdc/0x1f0 [ 1322.460000] [<ffffffffc01541c8>] kthread+0xb8/0xc0 [ 1322.464000] [<ffffffffc0106d18>] kernel_thread_helper+0x10/0x18 [ 1322.472000] [ 1322.472000] Code: 67bd0050 94a4002c 2c830001 <00038036> de050218 2403fffc 0080a82d 00431824 24630044 [ 1322.480000] ---[ end trace b052bb90e97dfbf5 ]--- The variable csize in structure jffs2_tmp_dnode_info is of type uint16_t, but it is used to hold the compressed data length(csize) which is declared as uint32_t. So, when the value of csize exceeds 16bits, it gets truncated when assigned to tn->csize. This is causing a kernel BUG. Changing the definition of csize in jffs2_tmp_dnode_info to uint32_t fixes the issue. Signed-off-by:Ajesh Kunhipurayil Vijayan <ajesh@broadcom.com> Signed-off-by:
Kamlakant Patel <kamlakant.patel@broadcom.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Kamlakant Patel authored
Creating a large file on a JFFS2 partition sometimes crashes with this call trace: [ 306.476000] CPU 13 Unable to handle kernel paging request at virtual address c0000000dfff8002, epc == ffffffffc03a80a8, ra == ffffffffc03a8044 [ 306.488000] Oops[#1]: [ 306.488000] Cpu 13 [ 306.492000] $ 0 : 0000000000000000 0000000000000000 0000000000008008 0000000000008007 [ 306.500000] $ 4 : c0000000dfff8002 000000000000009f c0000000e0007cde c0000000ee95fa58 [ 306.508000] $ 8 : 0000000000000001 0000000000008008 0000000000010000 ffffffffffff8002 [ 306.516000] $12 : 0000000000007fa9 000000000000ff0e 000000000000ff0f 80e55930aebb92bb [ 306.524000] $16 : c0000000e0000000 c0000000ee95fa5c c0000000efc80000 ffffffffc09edd70 [ 306.532000] $20 : ffffffffc2b60000 c0000000ee95fa58 0000000000000000 c0000000efc80000 [ 306.540000] $24 : 0000000000000000 0000000000000004 [ 306.548000] $28 : c0000000ee950000 c0000000ee95f738 0000000000000000 ffffffffc03a8044 [ 306.556000] Hi : 00000000000574a5 [ 306.560000] Lo : 6193b7a7e903d8c9 [ 306.564000] epc : ffffffffc03a80a8 jffs2_rtime_compress+0x98/0x198 [ 306.568000] Tainted: G W [ 306.572000] ra : ffffffffc03a8044 jffs2_rtime_compress+0x34/0x198 [ 306.580000] Status: 5000f8e3 KX SX UX KERNEL EXL IE [ 306.584000] Cause : 00800008 [ 306.588000] BadVA : c0000000dfff8002 [ 306.592000] PrId : 000c1100 (Netlogic XLP) [ 306.596000] Modules linked in: [ 306.596000] Process dd (pid: 170, threadinfo=c0000000ee950000, task=c0000000ee6e0858, tls=0000000000c47490) [ 306.608000] Stack : 7c547f377ddc7ee4 7ffc7f967f5d7fae 7f617f507fc37ff4 7e7d7f817f487f5f 7d8e7fec7ee87eb3 7e977ff27eec7f9e 7d677ec67f917f67 7f3d7e457f017ed7 7fd37f517f867eb2 7fed7fd17ca57e1d 7e5f7fe87f257f77 7fd77f0d7ede7fdb 7fba7fef7e197f99 7fde7fe07ee37eb5 7f5c7f8c7fc67f65 7f457fb87f847e93 7f737f3e7d137cd9 7f8e7e9c7fc47d25 7dbb7fac7fb67e52 7ff17f627da97f64 7f6b7df77ffa7ec5 80057ef17f357fb3 7f767fa27dfc7fd5 7fe37e8e7fd07e53 7e227fcf7efb7fa1 7f547e787fa87fcc 7fcb7fc57f5a7ffb 7fc07f6c7ea97e80 7e2d7ed17e587ee0 7fb17f9d7feb7f31 7f607e797e887faa 7f757fdd7c607ff3 7e877e657ef37fbd 7ec17fd67fe67ff7 7ff67f797ff87dc4 7eef7f3a7c337fa6 7fe57fc97ed87f4b 7ebe7f097f0b8003 7fe97e2a7d997cba 7f587f987f3c7fa9 ... [ 306.676000] Call Trace: [ 306.680000] [<ffffffffc03a80a8>] jffs2_rtime_compress+0x98/0x198 [ 306.684000] [<ffffffffc0394f10>] jffs2_selected_compress+0x110/0x230 [ 306.692000] [<ffffffffc039508c>] jffs2_compress+0x5c/0x388 [ 306.696000] [<ffffffffc039dc58>] jffs2_write_inode_range+0xd8/0x388 [ 306.704000] [<ffffffffc03971bc>] jffs2_write_end+0x16c/0x2d0 [ 306.708000] [<ffffffffc01d3d90>] generic_file_buffered_write+0xf8/0x2b8 [ 306.716000] [<ffffffffc01d4e7c>] __generic_file_aio_write+0x1ac/0x350 [ 306.720000] [<ffffffffc01d50a0>] generic_file_aio_write+0x80/0x168 [ 306.728000] [<ffffffffc021f7dc>] do_sync_write+0x94/0xf8 [ 306.732000] [<ffffffffc021ff6c>] vfs_write+0xa4/0x1a0 [ 306.736000] [<ffffffffc02202e8>] SyS_write+0x50/0x90 [ 306.744000] [<ffffffffc0116cc0>] handle_sys+0x180/0x1a0 [ 306.748000] [ 306.748000] Code: 020b202d 0205282d 90a50000 <90840000> 14a40038 00000000 0060602d 0000282d 016c5823 [ 306.760000] ---[ end trace 79dd088435be02d0 ]--- Segmentation fault This crash is caused because the 'positions' is declared as an array of signed short. The value of position is in the range 0..65535, and will be converted to a negative number when the position is greater than 32767 and causes a corruption and crash. Changing the definition to 'unsigned short' fixes this issue Signed-off-by:Jayachandran C <jchandra@broadcom.com> Signed-off-by:
-
Wang Guoli authored
If jffs2_new_inode() succeeds, it returns with f->sem held, and the caller is responsible for releasing the lock. If it fails, it still returns with the lock held, but the caller won't release the lock, which will lead to deadlock. Fix it by releasing the lock in jffs2_new_inode() on error. Signed-off-by:
Wang Guoli <andy.wangguoli@huawei.com> Signed-off-by:
Wang Nan <wangnan0@huawei.com> Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Wang Guoli <andy.wangguoli@huawei.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> [Brian: not marked for stable; no one observed deadlock, and I don't think it can happen here] Signed-off-by:
-
Li Zefan authored
We triggered soft-lockup under stress test on 2.6.34 kernel. BUG: soft lockup - CPU#1 stuck for 60009ms! [lockf2.test:14488] ... [<bf09a4d4>] (jffs2_do_reserve_space+0x420/0x440 [jffs2]) [<bf09a528>] (jffs2_reserve_space_gc+0x34/0x78 [jffs2]) [<bf0a1350>] (jffs2_garbage_collect_dnode.isra.3+0x264/0x478 [jffs2]) [<bf0a2078>] (jffs2_garbage_collect_pass+0x9c0/0xe4c [jffs2]) [<bf09a670>] (jffs2_reserve_space+0x104/0x2a8 [jffs2]) [<bf09dc48>] (jffs2_write_inode_range+0x5c/0x4d4 [jffs2]) [<bf097d8c>] (jffs2_write_end+0x198/0x2c0 [jffs2]) [<c00e00a4>] (generic_file_buffered_write+0x158/0x200) [<c00e14f4>] (__generic_file_aio_write+0x3a4/0x414) [<c00e15c0>] (generic_file_aio_write+0x5c/0xbc) [<c012334c>] (do_sync_write+0x98/0xd4) [<c0123a84>] (vfs_write+0xa8/0x150) [<c0123d74>] (sys_write+0x3c/0xc0)] Fix this by adding a cond_resched() in the while loop. [akpm@linux-foundation.org: don't initialize `ret'] Signed-off-by:
Li Zefan <lizefan@huawei.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Li Zefan authored
@wait is a local variable, so if we don't remove it from the wait queue list, later wake_up() may end up accessing invalid memory. This was spotted by eyes. Signed-off-by:
-
Jean Delvare authored
There is no point in displaying the TS5500-specific driver entries if TS5500 board support itself isn't enabled. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by:
-
Dan Carpenter authored
Instead of writing to "nand->reg + REG_FMICSR" we write to "REG_FMICSR" which is NULL and not a valid register. Fixes: 8bff82cb ('mtd: add nand support for w90p910 (v2)') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Huang Shijie authored
Check the chip->jedec_version, and print out the right information for JEDEC compliant NAND. Signed-off-by:
Huang Shijie <b32955@freescale.com> Signed-off-by:
-
Huang Shijie authored
This patch adds the parsing code for the JEDEC compliant NAND. Since we need the 0x40 as the column address, this patch also makes the NAND_CMD_PARAM to use the 8-bit address only. Signed-off-by:
-
Huang Shijie authored
Add a helper to get the supported features for JEDEC compliant NAND. Also add a macro JEDEC_FEATURE_16_BIT_BUS. Signed-off-by:
-
Huang Shijie authored
Add the jedec_version field, and add an anonymous union which contains the nand_onfi_params and nand_jedec_params. Signed-off-by:
-
Huang Shijie authored
Create the nand_jedec_params{} and jedec_ecc_info{} according to the JESD230A (Revision of JESD230, October 2012). Signed-off-by: -
Sachin Kamat authored
Commit 436d42c6 ("ARM: samsung: move platform_data definitions") moved the files to the current location but forgot to remove the pointer to its previous location. Clean it up. While at it also add the header file protection macros appropriately. Signed-off-by:
Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by:
-
Fabio Estevam authored
Check the return value from platform_get_irq() and propagate it in the case of error. Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
-
Dan Carpenter authored
"rc" is an error code here, no need to check it a second time. Signed-off-by:
-
Nicolas Ferre authored
PIO fall back is not an issue, so don't make this much noise. Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Kuninori Morimoto authored
Signed-off-by:
Yusuke Goda <yusuke.goda.sx@renesas.com> Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
Geert Uytterhoeven <geert+renesas@linux-m68k.org> Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
Pekon Gupta <pekon@ti.com> Signed-off-by:
-
Stefan Sørensen authored
The ELM driver incorrectly reagard any non-zero return value from pm_runtime_get_sync as an error, but it may return 1 if the device was already active. Fix to only error when return value is negative. Signed-off-by:
Stefan Sørensen <stefan.sorensen@spectralink.com> Signed-off-by:
-
Boris BREZILLON authored
read_buf is called in place of write_buf in the nand_write_page_raw_syndrome function. Signed-off-by:
-
Richard Weinberger authored
On archs like S390 or um this driver cannot build nor work. Make it depend on HAS_IOMEM and HAS_DMA to bypass build failures. drivers/built-in.o: In function `flctl_probe': drivers/mtd/nand/sh_flctl.c:1097: undefined reference to `devm_ioremap_resource' drivers/built-in.o: In function `flctl_dma_fifo0_transfer': drivers/mtd/nand/sh_flctl.c:368: undefined reference to `dma_map_single' drivers/mtd/nand/sh_flctl.c:407: undefined reference to `dma_unmap_single' Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Axel Lin authored
For slightly better readability. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Signed-off-by:
-
Brian Norris authored
Use a repeated read_byte() instead of read_buf(), since for x16 buswidth devices, we need to avoid the upper I/O[16:9] bits. See the following commit for reference: commit 05f78359 Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Date: Thu Dec 5 22:22:04 2013 +0100 mtd: nand: don't use {read,write}_buf for 8-bit transfers Now, I think that all barriers to probing ONFI on x16 devices are removed, so remove the check from nand_flash_detect_onfi(). Tested on 8-bit ONFI NAND (Micron MT29F32G08CBADAWP). Signed-off-by:
-
Brian Norris authored
The NAND command helpers tend to automatically shift the column address for x16 bus devices, since most commands expect a word address, not a byte address. The Read ID command, however, expects an 8-bit address (i.e., 0x00, 0x20, or 0x40 should not be translated to 0x00, 0x10, or 0x20). This fixes the column address for a few drivers which imitate the nand_base defaults. Note that I don't touch sh_flctl.c, since it already handles this problem slightly differently (note its comment "READID is always performed using an 8-bit bus"). I have not tested this patch, as I only have x8 parts up for testing at this point. Hopefully that can change soon... Signed-off-by:
-
Huang Shijie authored
The datasheet does not tell us how to parse out the ID data, so handle it as a full ID nand. Signed-off-by:
-
