1. 03 Dec, 2012 2 commits
    • Liming Wang's avatar
      mtd: m25p80: modify info for Micron N25Q128 · 98a9e245
      Liming Wang authored
      Micron N25Q128 has two types of flash:
      
       - One is for 1.8v supply voltage, prefixed with "n25q128a11" and the jedec
         code is 0x20bb18.
      
       - Another is for 3v supply voltage, prefixed with "n25q128a13" and the jedec
         code is 0x20ba18.
      
      So modify the original type info and add another type for Micron N25Q128.
      Signed-off-by: default avatarLiming Wang <walimisdev@gmail.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      98a9e245
    • Nathan Williams's avatar
      mtd cs553x_nand: Initialise ecc.strength before nand_scan() · d1f3b65d
      Nathan Williams authored
      Loading cs553x_nand with Hynix H27U1G8F2BTR NAND flash causes this bug:
      
      kernel BUG at drivers/mtd/nand/nand_base.c:3345!
      invalid opcode: 0000 [#1]
      Modules linked in: cs553x_nand(+) vfat fat usb_storage ehci_hcd usbcore usb_comr
      Pid: 436, comm: modprobe Not tainted 3.6.7 #1
      EIP: 0060:[<c118d205>] EFLAGS: 00010296 CPU: 0
      EIP is at nand_scan_tail+0x64c/0x69c
      EAX: 00000034 EBX: cea6ed98 ECX: 00000000 EDX: 00000000
      ESI: cea6ec00 EDI: cea6ec00 EBP: 20000000 ESP: cdd17e48
       DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
      CR0: 8005003b CR2: 0804e119 CR3: 0d850000 CR4: 00000090
      DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
      DR6: ffff0ff0 DR7: 00000400
      Process modprobe (pid: 436, ti=cdd16000 task=cdd1c320 task.ti=cdd16000)
      Stack:
       c12e962c c118f7ef 00000003 cea6ed98 d014b25c 20000000 fffff007 00000001
       00000000 cdd53b00 d014b000 c1001021 cdd53b00 d01493c0 cdd53b00 cdd53b00
       d01493c0 c1047f83 d014b4a0 00000000 cdd17f9c ce4be454 cdd17f48 cdd1c320
      Call Trace:
       [<c118f7ef>] ? nand_scan+0x1b/0x4d
       [<d014b25c>] ? init_module+0x25c/0x2de [cs553x_nand]
       [<d014b000>] ? 0xd014afff
       [<c1001021>] ? do_one_initcall+0x21/0x111
       [<c1047f83>] ? sys_init_module+0xe4/0x1261
       [<c1031207>] ? task_work_run+0x36/0x43
       [<c1265ced>] ? syscall_call+0x7/0xb
      Code: fa ff ff c7 86 d8 00 00 00 01 00 00 00 e9 5f fc ff ff 68 f8 26 2e c1 e8 a7
      EIP: [<c118d205>] nand_scan_tail+0x64c/0x69c SS:ESP 0068:cdd17e48
      
      Initialising ecc.strength before the call to nand_scan() fixes this.
      Signed-off-by: default avatarNathan Williams <nathan@traverse.com.au>
      Cc: stable@vger.kernel.org [3.4+]
      Acked-by: default avatarBrian Norris <computersforpeace@gmail.com>
      Acked-by: default avatarMike Dunn <mikedunn@newsguy.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      d1f3b65d
  2. 22 Nov, 2012 15 commits
  3. 21 Nov, 2012 8 commits
  4. 18 Nov, 2012 4 commits
  5. 16 Nov, 2012 5 commits
  6. 15 Nov, 2012 6 commits
    • Matthieu CASTET's avatar
      mtd: nand_wait: warn if the nand is busy on exit · f251b8df
      Matthieu CASTET authored
      This patch allow to detect buggy driver/hardware with
      bad RnB (dev_ready) management or when timeout occurs in polling mode.
      
      This works when dev_ready is set or not set.
      There are 2 methods to wait for an erase/program command completion:
      
      1. Wait until nand RnB pin goes high (that's what chip->dev_ready usually does)
      2. Poll the device: send a status (0x70) command and read status byte in a loop
         until bit NAND_STATUS_READY is set
      
      In all cases, you should send a status command after completion, to check if
      the operation was successful. And if the operation completed, the status should
      have bit NAND_STATUS_READY set.
      Signed-off-by: default avatarMatthieu CASTET <matthieu.castet@parrot.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      f251b8df
    • Murali Karicheri's avatar
      mtd: davinci: add support for parition binding nodes · 192afdbf
      Murali Karicheri authored
      Enhance the driver to support partition subnodes inside the nand
      device bindings to describe partions on the nand device.
      Signed-off-by: default avatarMurali Karicheri <m-karicheri2@ti.com>
      Reviewed-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      192afdbf
    • Huang Shijie's avatar
      mtd: cmdlinepart: fix the overflow of big mtd partitions · 6f9f59ee
      Huang Shijie authored
      When the kernel parses the following cmdline
      
      	#mtdparts=gpmi-nand:16m(boot),16m(kernel),1g(home),4g(test),-(usr)
      
      for a big nand chip Micron MT29F64G08AFAAAWP(8GB), we got the following wrong
      result:
      
      	.............................................
      		"mtd: partition size too small (0)"
      	.............................................
      
      We can not get any partition.
      
      The "4g(test)" partition triggers a overflow of the "size". The memparse()
      returns 4g to the "size", but the size is "unsigned long" type, so a overflow
      occurs, the "size" becomes zero in the end.
      
      This patch changes the "size"/"offset" to "unsigned long long" type,
      and replaces the UINT_MAX with ULLONG_MAX for macros SIZE_REMAINING and
      OFFSET_CONTINUOUS.
      Signed-off-by: default avatarHuang Shijie <b32955@freescale.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      6f9f59ee
    • Viresh Kumar's avatar
      mtd: map: Fix compilation warning · 3e9ce49e
      Viresh Kumar authored
      This patch is an attempt to fix following compilation warning.
      
      In file included from drivers/mtd/chips/cfi_cmdset_0001.c:35:0:
      drivers/mtd/chips/cfi_cmdset_0001.c: In function 'cfi_intelext_write_words':
      include/linux/mtd/map.h:331:11: warning: 'r.x[0]' may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      I could have used uninitialized_var() too, but didn't used it as the final else
      part of map_word_load() is missing. So there is a chance that it might be passed
      uninitialized. Better initialize to zero.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      3e9ce49e
    • Robert P. J. Day's avatar
      mtd: Fix kernel-doc content to avoid warning. · 9ef525a9
      Robert P. J. Day authored
      Add missing colons to fix kernel-doc generation warnings.
      Signed-off-by: default avatarRobert P. J. Day <rpjday@crashcourse.ca>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      9ef525a9
    • Matthieu CASTET's avatar
      mtdoops: don't erase flash at each boot · cd409c61
      Matthieu CASTET authored
      The current version on mtdoops erase first block of mtdoops partition at each
      boot if there is no oops stored in flash. This can wear the flash.
      
      When mtdoops start, find_next_position is called to find the next free entry in
      the circular buffer. But if the flash is erased, find_next_position don't find
      anything (maxcount == 0xffffffff) and start with the first entry after erasing it.
      
      The scanning that is done in find_next_position already track free/used entries.
      So if at the end of the scanning we don't find anything, we can start at the
      first entry and erased the entry only if it is marked as used.
      Most of this is implemented in mtdoops_inc_counter, so to avoid duplicating
      code, if we don't find anything we set position to -1. mtdoops_inc_counter with
      increment it, erase the entry if needed and start as before with nextpage = 0
      and nextcount = 1).
      
      Also during the scan phase, we use the MTDOOPS_KERNMSG_MAGIC to detect corruped
      entries.
      
      Signed-off-by: Matthieu Castet <matthieu.castet@parrot@com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      cd409c61