1. 13 Oct, 2015 5 commits
  2. 12 Oct, 2015 3 commits
  3. 11 Oct, 2015 2 commits
    • Sheng Yong's avatar
      mtd: nand_bbt: set the smallest size of bbt table · 192db1ca
      Sheng Yong authored
      When using nandsim to simulate a 128K block nand with `overridesize = 1',
      the size of mtd device is too small (mtd_size = 4 * block_size) to get the
      right length of bbt. Then when creating bbt, kzmalloc() will return
      ZERO_SIZE_PTR. This causes a NULL pointer oops when scanning bbt.
      
      [  952.156166] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
      [  952.157064] IP: [<ffffffff8148ad4a>] nand_isreserved_bbt+0x2a/0x40
      [  952.157064] PGD 0
      [  952.157064] Oops: 0000 [#1] SMP
      [  952.157064] Modules linked in: nandsim(+) [last unloaded: nandsim]
      [  952.157064] CPU: 1 PID: 7103 Comm: modprobe Not tainted 4.2.0-rc3-next-20150724 #4
      [  952.157064] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [  952.157064] task: ffff88003e24b980 ti: ffff88003d274000 task.ti: ffff88003d274000
      [  952.157064] RIP: 0010:[<ffffffff8148ad4a>]  [<ffffffff8148ad4a>] nand_isreserved_bbt+0x2a/0x40
      [  952.157064] RSP: 0018:ffff88003d277b90  EFLAGS: 00010246
      [  952.157064] RAX: 0000000000000010 RBX: ffff88003d5a1000 RCX: 0000000000000000
      [  952.157064] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88003d919000
      [  952.157064] RBP: ffff88003d277b98 R08: 0000000000020000 R09: 0000000000000000
      [  952.157064] R10: 0000000000000000 R11: 0000000000000195 R12: ffff88003d919000
      [  952.157064] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
      [  952.157064] FS:  00007fada4d07700(0000) GS:ffff88003fd00000(0000) knlGS:0000000000000000
      [  952.157064] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [  952.157064] CR2: 0000000000000010 CR3: 0000000037924000 CR4: 00000000000006a0
      [  952.157064] Stack:
      [  952.157064]  ffffffff814851ec ffff88003d277ba8 ffffffff8147e35f ffff88003d277bf8
      [  952.157064]  ffffffff814816f3 ffff88003d277c08 ffff88003d277bc8 0000000000000282
      [  952.157064]  0000000000000001 0000000000000000 ffff88003d209540 0000000000000001
      [  952.157064] Call Trace:
      [  952.157064]  [<ffffffff814851ec>] ? nand_block_isreserved+0x1c/0x20
      [  952.157064]  [<ffffffff8147e35f>] mtd_block_isreserved+0x1f/0x30
      [  952.157064]  [<ffffffff814816f3>] allocate_partition+0x463/0x6a0
      [  952.157064]  [<ffffffff81481b3b>] add_mtd_partitions+0x4b/0xe0
      [  952.157064]  [<ffffffff8147f14c>] mtd_device_parse_register+0x4c/0xe0
      [  952.157064]  [<ffffffffa0013daf>] ns_init_module+0xdaf/0xde4 [nandsim]
      [  952.157064]  [<ffffffff8128d7c8>] ? kasprintf+0x38/0x40
      [  952.157064]  [<ffffffffa0013000>] ? 0xffffffffa0013000
      [  952.157064]  [<ffffffff810002c3>] do_one_initcall+0x83/0x1b0
      [  952.157064]  [<ffffffff8113afab>] ? kmem_cache_alloc_trace+0x6b/0x120
      [  952.157064]  [<ffffffff8160b503>] do_init_module+0x5c/0x1dd
      [  952.157064]  [<ffffffff810aa4db>] load_module+0x1bbb/0x20b0
      [  952.157064]  [<ffffffff810a6fc0>] ? __symbol_put+0x30/0x30
      [  952.157064]  [<ffffffff810aaac9>] SyS_init_module+0xf9/0x110
      [  952.157064]  [<ffffffff810aa9d1>] ? SyS_init_module+0x1/0x110
      [  952.157064]  [<ffffffff81615f57>] entry_SYSCALL_64_fastpath+0x12/0x6a
      [  952.157064] Code: 00 55 48 8b 87 80 01 00 00 48 89 e5 8b 88 cc 00 00 00 48 8b 80 f0 03 00 00 5d 48 d3 fe 89 f2 83 e6 03 c1 fa 02 8d 0c 36 48 63 d2 <0f> b6 04 10 d3 f8 83 e0 03 3c 02 0f 94 c0 0f b6 c0 c3 0f 1f 40
      [  952.157064] RIP  [<ffffffff8148ad4a>] nand_isreserved_bbt+0x2a/0x40
      [  952.157064]  RSP <ffff88003d277b90>
      [  952.157064] CR2: 0000000000000010
      [  952.204010] ---[ end trace 6ca2e1c041fdba36 ]---
      
      This patch gives a smallest length to bbt, 1 byte, which is enough to
      represent up to 4 blocks.
      Signed-off-by: default avatarSheng Yong <shengyong1@huawei.com>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      192db1ca
    • Michal Suchanek's avatar
      mtd: mtdpart: add debug prints to partition parser. · 8e2c992b
      Michal Suchanek authored
      The probe of a mtd device can fail when a partition parser returns
      error. The failure due to partition parsing can be quite mysterious when
      multiple partitioning schemes are compiled in and any of them can fail
      the probe.
      
      Add debug prints which show what parsers were tried and what they
      returned.
      Signed-off-by: default avatarMichal Suchanek <hramrach@gmail.com>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      8e2c992b
  4. 04 Oct, 2015 4 commits
  5. 02 Oct, 2015 9 commits
  6. 01 Oct, 2015 1 commit
  7. 30 Sep, 2015 9 commits
  8. 29 Sep, 2015 7 commits
    • Dongsheng Yang's avatar
      mtd: mtdram: check offs and len in mtdram->erase · 7827e3ac
      Dongsheng Yang authored
      We should prevent user to erasing mtd device with
      an unaligned offset or length.
      Signed-off-by: default avatarDongsheng Yang <yangds.fnst@cn.fujitsu.com>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      7827e3ac
    • Stefan Agner's avatar
      mtd: nand: vf610_nfc: add device tree bindings · 8a799590
      Stefan Agner authored
      Signed-off-by: default avatarBill Pringlemeir <bpringlemeir@nbsps.com>
      Acked-by: default avatarShawn Guo <shawnguo@kernel.org>
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      [Brian: fixup #size-cells in example]
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      8a799590
    • Stefan Agner's avatar
      mtd: nand: vf610_nfc: add hardware BCH-ECC support · 049f4250
      Stefan Agner authored
      This adds hardware ECC support using the BCH encoder in the NFC IP.
      The ECC encoder supports up to 32-bit correction by using 60 error
      correction bytes. There is no sub-page ECC step, ECC is calculated
      always across the whole page (up to 2k pages).
      
      Limitations:
      - HW ECC: Only 2K page with 64+ OOB.
      - HW ECC: Only 24 and 32-bit error correction implemented.
      
      Raw writes have been tested using the generic nand_write_page_raw
      implementation. However, raw reads are currently not possible
      because the controller need to know whether we are going to use
      the ECC mode already at NAND_CMD_READ0 command time. At this point
      we do not have the information whether it is a raw read or a
      regular read at driver level...
      Signed-off-by: default avatarBill Pringlemeir <bpringlemeir@nbsps.com>
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      049f4250
    • Stefan Agner's avatar
      mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others · 456930d8
      Stefan Agner authored
      This driver supports Freescale NFC (NAND flash controller) found on
      Vybrid (VF610), MPC5125, MCF54418 and Kinetis K70. The driver has
      been tested using 8-bit and 16-bit NAND interface on the ARM based
      Vybrid SoC VF500 and VF610 platform.
      parameter page reading.
      
      Limitations:
      - Untested on MPC5125 and M54418.
      - DMA and pipelining not used.
      - 2K pages or less.
      - No chip select, one NAND chip per controller.
      - No hardware ECC.
      
      Some paths have been hand-optimized and evaluated by measurements
      made using mtd_speedtest.ko on a 100MB MTD partition.
      
      Colibri VF50
              eb write     %   eb read     %   page write      %   page read     %
      rel/opt     5175           11537                4560             11039
      opt         5164 -0.21     11420 -1.01          4737 +3.88       10918 -1.10
      none        5113 -1.20     11352 -1.60          4490 -1.54       10865 -1.58
      
      Colibri VF61
              eb write     %   eb read     %   page write      %   page read     %
      rel/opt     5766           13096                5459             12846
      opt         5883 +2.03     13064 -0.24          5561 +1.87       12802 -0.34
      none        5701 -1.13     12980 -0.89          5488 +0.53       12735 -0.86
      
      rel = using readl_relaxed/writel_relaxed in optimized paths
      opt = hand-optimized by combining multiple accesses into one read/write
      
      The measurements have not been statistically verfied, hence use them
      with care. The author came to the conclusion that using the relaxed
      variants of readl/writel are not worth the additional code.
      Signed-off-by: default avatarBill Pringlemeir <bpringlemeir@nbsps.com>
      Tested-by: default avatarAlbert ARIBAUD <albert.aribaud@3adev.fr>
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Reviewed-by: default avatarAlexey Klimov <klimov.linux@gmail.com>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      456930d8
    • Brian Norris's avatar
      mtd: provide proper 32/64-bit compat_ioctl() support for BLKPG · 53bb724f
      Brian Norris authored
      After a bit of poking around wondering why my 32-bit user-space can't
      seem to send a proper ioctl(BLKPG) to an MTD on my 64-bit kernel
      (ARM64), I noticed that struct blkpg_ioctl_arg is actually pretty
      unsuitable for use in the ioctl() ABI, due to its use of raw pointers,
      and its lack of alignment/packing restrictions (32-bit arch'es tend to
      pack the 4 fields into 4 32-bit words, whereas 64-bit arch'es would add
      padding after the third int, and make this 6 32-bit words).
      
      Anyway, this means BLKPG deserves some special compat_ioctl handling. Do
      the conversion in a small shim for MTD.
      
      block/compat_ioctl.c already has compat support for the block subsystem,
      but it does so by a re-marshalling data to/from user-space (see
      compat_blkpg_ioctl()). Personally, I think this approach is cleaner.
      
      Tested only on MTD, with an ARM32 user space on an ARM64 kernel.
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      53bb724f
    • Brian Norris's avatar
      mtd: spi-nor: add support for w25q128fw · 4404bd74
      Brian Norris authored
      Tested only with single I/O, but the datasheet says it supports dual and
      quad.
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      4404bd74
    • Furquan Shaikh's avatar
      mtd: spi-nor: scale up timeout for full-chip erase · 09b6a377
      Furquan Shaikh authored
      This patch fixes timeout issues seen on large NOR flash (e.g., 16MB
      w25q128fw) when using ioctl(MEMERASE) with offset=0 and length=16M. The
      input parameters matter because spi_nor_erase() uses a different code
      path for full-chip erase, where we use the SPINOR_OP_CHIP_ERASE (0xc7)
      opcode.
      
      Fix: use a different timeout for full-chip erase than for other
      commands.
      
      While most operations can be expected to perform relatively similarly
      across a variety of NOR flash types and sizes (and therefore might as
      well use a similar timeout to keep things simple), full-chip erase is
      unique, because the time it typically takes to complete:
      (1) is much larger than most operations and
      (2) scales with the size of the flash.
      
      Let's base our timeout on the original comments stuck here -- that a 2MB
      flash requires max 40s to erase.
      
      Small survey of a few flash datasheets I have lying around:
      
        Chip         Size (MB)   Max chip erase (seconds)
        ----         --------    ------------------------
        w25q32fw     4           50
        w25q64cv     8           30
        w25q64fw     8           100
        w25q128fw    16          200
        s25fl128s    16          ~256
        s25fl256s    32          ~512
      
      From this data, it seems plenty sufficient to say we need to wait for
      40 seconds for each 2MB of flash.
      
      After this change, it might make some sense to decrease the timeout for
      everything else, as even the most extreme operations (single block
      erase?) shouldn't take more than a handful of seconds. But for safety,
      let's leave it as-is. It's only an error case, after all, so we don't
      exactly need to optimize it.
      Signed-off-by: default avatarFurquan Shaikh <furquan@google.com>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      09b6a377