1. 06 8月, 2008 1 次提交
    • A
      [MTD] [NOR] Add qry_mode_on()/qry_omde_off() to deal with odd chips · 2e489e07
      Alexey Korolev 提交于
      There are some CFI chips which require non standard procedures to get 
      into QRY mode. The possible way to support them would be trying 
      different modes till QRY will be read. This patch introduce two new 
      functions qry_mode_on qry_mode_off. qry_mode_on tries different commands 
      in order switch chip into QRY mode.
      
      So if we have one more "odd" chip - we just could add several lines to 
      qry_mode_on. Also using these functions remove unnecessary code 
      duplicaton in porbe procedure.
      
      Currently there are two "odd" cases
      1. Some old intel chips which require 0xFF before 0x98
      2. ST M29DW chip which requires 0x98 to be sent at 0x555 (according to
      CFI should be 0x55)
      
      This patch is partialy based on the patch from Uwe
      (see "[PATCH 2/4] [RFC][MTD] cfi_probe: remove Intel chip workaround"
      thread )
      Signed-off-by: NAlexey Korolev <akorolev@infradead.org>
      Signed-off-by: NAlexander Belyakov <abelyako@gmail.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      2e489e07
  2. 05 6月, 2008 1 次提交
  3. 23 4月, 2008 1 次提交
  4. 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
  5. 07 11月, 2005 1 次提交
  6. 04 8月, 2005 1 次提交
    • T
      [MTD] CHIPS: Recognize Spansion CFI 1.4 chips · d88f977b
      Todd Poynor 提交于
      Modify Amd/Fujitsu CFI NOR flash primary vendor extension table revision
      check to recognize version 1.4.  Verified the existing driver can
      handle version 1.4 chips without additional info from 1.4 extended table.
      
      Move the primary vendor extension table revision check from common file
      to the 3 CFI chip driver files, since the data structures and revisions
      handled by those data structures are specific to the chip driver.
      
      Modify the error message printed when the revision is unknown to be a
      KERN_ERR instead of WARNING since this will cause mtd to ignore the chip.
      Signed-off-by: NTodd Poynor <tpoynor@mvista.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      d88f977b
  7. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4