1. 01 Jun, 2012 2 commits
    • Marek Vasut's avatar
      mtd: gpmi-nand: define ecc.strength · 5636ce0f
      Marek Vasut authored
      Fix an issue which was introduced by the recent addition of ecc.strength.
      
      The ecc.strength wasn't set in gpmi-nand, resulting in the following crash:
      [    2.550000] kernel BUG at drivers/mtd/nand/nand_base.c:3347!
      ...
      [    2.550000] [<c020841c>] (nand_scan_tail+0x328/0x650) from [<c02f68e0>] (gpmi_nand_probe+0x43c/0x5a4)
      [    2.550000] [<c02f68e0>] (gpmi_nand_probe+0x43c/0x5a4) from [<c01f6618>] (platform_drv_probe+0x14/0x18)
      [    2.550000] [<c01f6618>] (platform_drv_probe+0x14/0x18) from [<c01f55b0>] (driver_probe_device+0x74/0x1fc)
      [    2.550000] [<c01f55b0>] (driver_probe_device+0x74/0x1fc) from [<c01f57cc>] (__driver_attach+0x94/0x98)
      [    2.550000] [<c01f57cc>] (__driver_attach+0x94/0x98) from [<c01f3d40>] (bus_for_each_dev+0x50/0x80)
      [    2.550000] [<c01f3d40>] (bus_for_each_dev+0x50/0x80) from [<c01f4e18>] (bus_add_driver+0x188/0x25c)
      [    2.550000] [<c01f4e18>] (bus_add_driver+0x188/0x25c) from [<c01f5a70>] (driver_register+0x78/0x138)
      [    2.550000] [<c01f5a70>] (driver_register+0x78/0x138) from [<c043dc7c>] (gpmi_nand_init+0xc/0x30)
      [    2.550000] [<c043dc7c>] (gpmi_nand_init+0xc/0x30) from [<c0008824>] (do_one_initcall+0x108/0x17c)
      [    2.550000] [<c0008824>] (do_one_initcall+0x108/0x17c) from [<c042a8b8>] (kernel_init+0xfc/0x1bc)
      [    2.550000] [<c042a8b8>] (kernel_init+0xfc/0x1bc) from [<c000fab4>] (kernel_thread_exit+0x0/0x8)
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      5636ce0f
    • Frank Svendsboe's avatar
      mtd: of_parts: fix breakage in Kconfig · 2e929d00
      Frank Svendsboe authored
      MTD_OF_PARTS and the default setting is not working due to using 'Y'
      instead of 'y', introduced in commit
      d6137bad. 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: default avatarFrank Svendsboe <frank.svendsboe@gmail.com>
      Cc: stable@kernel.org [3.2+]
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      2e929d00
  2. 29 May, 2012 2 commits
    • Dmitry Maluka's avatar
      mtd: nand: fix scan_read_raw_oob · 34a5704d
      Dmitry Maluka authored
      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: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Cc: stable@kernel.org
      34a5704d
    • Robert Jarzmik's avatar
      mtd: docg3 fix in-middle of blocks reads · 52c2d9aa
      Robert Jarzmik authored
      Corner case reads do not work, and return false data and
      ECC. This case is typically seen in a ubifs usage, with a
      read of type:
       - docg3 docg3: doc_read_oob(from=14882415, mode=1,
       data=(c30eca40:12), oob=(  (null):0))
      
      This results in the following reads:
       - docg3 docg3: doc_read_data_area(buf=  (null), len=111)
       - docg3 docg3: doc_read_data_area(buf=c30eca40, len=12)
       - docg3 docg3: doc_read_data_area(buf=  (null), len=389)
       - docg3 docg3: doc_read_data_area(buf=  (null), len=0)
       - docg3 docg3: doc_read_data_area(buf=  (null), len=16)
      
      If we suppose that the pages content is :
       - bytes 0 .. 111   : 0x0a
       - bytes 112 .. 255 : 0x0f
      Then the returned bytes will be :
       - 111 times 0x0a (correct)
       - 0x0a 2 times and 0x0f 10 times (incorrect, should be
       0x0a,0x0f)
       - 0x0f 389 times (correct)
       - nothing
       - correct OOB
      
      The reason seams that the first 111 bytes read ends between
      the 2 docg3 planes, and that the first following read (in
      the 12 bytes sequence, read of 16 bit word) returns the byte
      of the rightmost plane duplicated in high and lower byte of
      the word.
      
      Fix this behaviour by ensuring that if the previous read
      ended up in-between the 2 planes, there will be a first 1
      byte read to get back to the beginning of leftmost plane.
      Signed-off-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      52c2d9aa
  3. 14 May, 2012 36 commits