1. 07 2月, 2008 1 次提交
  2. 03 2月, 2008 3 次提交
  3. 12 1月, 2008 1 次提交
  4. 11 1月, 2008 1 次提交
  5. 03 12月, 2007 3 次提交
  6. 26 11月, 2007 1 次提交
    • A
      [MTD] [NOR] Prevent erase command invocation on suspended chip · 6c24e416
      Alexander Belyakov 提交于
      while running stress tests we have met cfi_cmdset_0001.c driver issue.
      Working on multipartitional devices with erase suspend on write
      feature enabled it is possible to get erase operation invoked on chip
      with suspended erase. get_chip() looses information about earlier
      suspended erase and new erase operation gets issued. New erase
      operations report successful completion, but blocks remain dirty
      causing, for example, JFFS2 error messages like:
      
      ...
      Newly-erased block contained word 0x20031985 at offset 0x00200000
      Newly-erased block contained word 0x20031985 at offset 0x00280000
      Newly-erased block contained word 0x20031985 at offset 0x00240000
      ...
      
      The patch below fixes that issue.
      Signed-off-by: NAlexander Belyakov <alexander.belyakov@intel.com>
      Acked-by: NNicolas Pitre <nico@cam.org>
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      6c24e416
  7. 23 11月, 2007 1 次提交
  8. 10 11月, 2007 1 次提交
  9. 31 10月, 2007 1 次提交
  10. 23 10月, 2007 1 次提交
  11. 13 10月, 2007 1 次提交
  12. 24 9月, 2007 1 次提交
  13. 23 7月, 2007 1 次提交
  14. 06 7月, 2007 1 次提交
  15. 05 7月, 2007 1 次提交
  16. 29 6月, 2007 3 次提交
  17. 09 5月, 2007 1 次提交
  18. 20 4月, 2007 1 次提交
  19. 18 4月, 2007 1 次提交
    • S
      [MTD] Fix fwh_lock locking · e6be133b
      Shashi Rao 提交于
      This is on a custom board with a mapping driver access to an ST
      M50LPW080 chip. This chip is probed successfully with
      do_map_probe("jedec_probe",...). If I use the mtdchar interface to
      perform unlock->erase->program->lock on any of the 16 eraseblocks in the
      chip, the chip is left in FL_STATUS mode while the data structures
      believe that the chip is in FL_READY mode. Hence, any subsequent reads
      to any flash byte results in 0x80 being read.
      Signed-off-by: NShashi Rao <shashi@sun.com>
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      e6be133b
  20. 03 4月, 2007 1 次提交
  21. 08 3月, 2007 1 次提交
  22. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
      recently, it makes sense again to remove other superfluous sched.h includes.
      There are quite a lot of files which include it but don't actually need
      anything defined in there.  Presumably these includes were once needed for
      macros that used to live in sched.h, but moved to other header files in the
      course of cleaning it up.
      
      To ease the pain, this time I did not fiddle with any header files and only
      removed #includes from .c-files, which tend to cause less trouble.
      
      Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
      arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
      allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
      configs in arch/arm/configs on arm.  I also checked that no new warnings were
      introduced by the patch (actually, some warnings are removed that were emitted
      by unnecessarily included header files).
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  23. 09 2月, 2007 3 次提交
  24. 30 11月, 2006 1 次提交
  25. 29 11月, 2006 2 次提交
  26. 21 10月, 2006 3 次提交
  27. 04 10月, 2006 1 次提交
  28. 22 9月, 2006 1 次提交
  29. 16 9月, 2006 1 次提交