1. 29 9月, 2012 4 次提交
    • A
      mtd: omap2: fix module loading · 4d3d688d
      Andreas Bießmann 提交于
      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: NAndreas Bießmann <andreas@biessmann.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      4d3d688d
    • A
      mtd: omap2: fix omap_nand_remove segfault · 7d9b1102
      Andreas Bießmann 提交于
      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: NAndreas Bießmann <andreas@biessmann.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      7d9b1102
    • H
      mtd: kill MTD_NAND_VERIFY_WRITE · 657f28f8
      Huang Shijie 提交于
      Just as Artem suggested:
      
      "Both UBI and JFFS2 are able to read verify what they wrote already.
      There are also MTD tests which do this verification. So I think there
      is no reason to keep this in the NAND layer, let alone wasting RAM in
      the driver to support this feature. Besides, it does not work for sub-pages
      and many drivers have it broken. It hurts more than it provides benefits."
      
      So kill MTD_NAND_VERIFY_WRITE entirely.
      Signed-off-by: NHuang Shijie <shijie8@gmail.com>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      657f28f8
    • P
  2. 19 9月, 2012 1 次提交
    • A
      ARM: omap: move platform_data definitions · 2203747c
      Arnd Bergmann 提交于
      Platform data for device drivers should be defined in
      include/linux/platform_data/*.h, not in the architecture
      and platform specific directories.
      
      This moves such data out of the omap include directories
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: "Benoît Cousson" <b-cousson@ti.com>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Cc: Ohad Ben-Cohen <ohad@wizery.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
      Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
      Cc: Liam Girdwood <lrg@ti.com>
      Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Cc: Jean Pihet <j-pihet@ti.com>
      Cc: J Keerthy <j-keerthy@ti.com>
      Cc: linux-omap@vger.kernel.org
      2203747c
  3. 31 8月, 2012 3 次提交
  4. 10 8月, 2012 1 次提交
    • A
      mtd/omap2: fix dmaengine_slave_config error handling · d680e2c1
      Arnd Bergmann 提交于
      The newly added dmaengine support in the omap2 nand driver
      potentially causes an undefined return value from the
      omap_nand_probe function when dmaengine_slave_config
      reports an error. Let's handle this by returning the
      same error back to the caller.
      
      Without this patch, building omap2plus_defconfig results in:
      
      drivers/mtd/nand/omap2.c: In function 'omap_nand_probe':
      drivers/mtd/nand/omap2.c:1154:6: warning: 'err' may be used uninitialized in this function [-Wuninitialized]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Grazvydas Ignotas <notasas@gmail.com>
      d680e2c1
  5. 31 7月, 2012 2 次提交
  6. 14 5月, 2012 3 次提交
  7. 27 3月, 2012 2 次提交
    • M
      mtd: flash drivers set ecc strength · 6a918bad
      Mike Dunn 提交于
      Flash device drivers initialize 'ecc_strength' in struct mtd_info, which is the
      maximum number of bit errors that can be corrected in one writesize region.
      
      Drivers using the nand interface intitialize 'strength' in struct nand_ecc_ctrl,
      which is the maximum number of bit errors that can be corrected in one ecc step.
      Nand infrastructure code translates this to 'ecc_strength'.
      
      Also for nand drivers, the nand infrastructure code sets ecc.strength for ecc
      modes NAND_ECC_SOFT, NAND_ECC_SOFT_BCH, and NAND_ECC_NONE.  It is set in the
      driver for all other modes.
      Signed-off-by: NMike Dunn <mikedunn@newsguy.com>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      6a918bad
    • A
      mtd: do not use plain 0 as NULL · 42d7fbe2
      Artem Bityutskiy 提交于
      The first 3 arguments of 'mtd_device_parse_register()' are pointers,
      but many callers pass '0' instead of 'NULL'. Fix this globally. Thanks
      to coccinelle for making it easy to do with the following semantic patch:
      
       @@
       expression mtd, types, parser_data, parts, nr_parts;
       @@
       (
       -mtd_device_parse_register(mtd, 0, parser_data, parts, nr_parts)
       +mtd_device_parse_register(mtd, NULL, parser_data, parts, nr_parts)
       |
       -mtd_device_parse_register(mtd, types, 0, parts, nr_parts)
       +mtd_device_parse_register(mtd, types, NULL, parts, nr_parts)
       |
       -mtd_device_parse_register(mtd, types, parser_data, 0, nr_parts)
       +mtd_device_parse_register(mtd, types, parser_data, NULL, nr_parts)
       )
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      42d7fbe2
  8. 10 1月, 2012 1 次提交
  9. 01 11月, 2011 1 次提交
  10. 11 9月, 2011 4 次提交
  11. 25 5月, 2011 3 次提交
  12. 11 3月, 2011 2 次提交
  13. 18 2月, 2011 6 次提交
  14. 07 12月, 2010 1 次提交
  15. 25 10月, 2010 1 次提交
  16. 30 9月, 2010 1 次提交
  17. 02 8月, 2010 2 次提交
  18. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  19. 27 2月, 2010 1 次提交
    • V
      mtd: omap2 fix prefetch mode read issue · c3341d0c
      Vimal Singh 提交于
      There is a bug in nand prefetch read routine, which comes into effect
      only if nand device is a 16-bit device (as we have in zoom boards).
      This bug is effective only with below combination of conditions:
      1. nand deivce, in use, is a 16 bit device
      2. nand driver supports 'subpage' read
      3. SW ECC is in use
      
      This was not seen old  kernel (ex: .23), because when, in early days,
      we tested this (nand prefetch read in LDP boards) there was no
      'subpage read' support.
      Later when we had subpage read in (.27) kernel, we had hw ecc enabled
      always in our internal tree. So, we missed this bug.
      
      This patch fixes the issue.
      Signed-off-by: NVimal Singh <vimalsingh@ti.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      c3341d0c