1. 20 9月, 2009 1 次提交
  2. 06 6月, 2009 1 次提交
  3. 21 3月, 2009 1 次提交
  4. 05 11月, 2008 1 次提交
    • E
      [MTD] [NOR] Fix cfi_send_gen_cmd handling of x16 devices in x8 mode (v4) · 467622ef
      Eric W. Biederman 提交于
      For "unlock" cycles to 16bit devices in 8bit compatibility mode we need
      to use the byte addresses 0xaaa and 0x555. These effectively match
      the word address 0x555 and 0x2aa, except the latter has its low bit set.
      
      Most chips don't care about the value of the 'A-1' pin in x8 mode,
      but some -- like the ST M29W320D -- do. So we need to be careful to
      set it where appropriate.
      
      cfi_send_gen_cmd is only ever passed addresses where the low byte
      is 0x00, 0x55 or 0xaa. Of those, only addresses ending 0xaa are
      affected by this patch, by masking in the extra low bit when the device
      is known to be in compatibility mode.
      
      [dwmw2: Do it only when (cmd_ofs & 0xff) == 0xaa]
      v4: Fix  stupid typo in cfi_build_cmd_addr that failed to compile
          I'm writing this patch way to late at night.
      v3: Bring all of the work back into cfi_build_cmd_addr
          including calling of map_bankwidth(map) and cfi_interleave(cfi)
          So every caller doesn't need to.
      v2: Only modified the address if we our device_type is larger than our
          bus width.
      
      Cc: stable@kernel.org
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      467622ef
  5. 31 7月, 2008 1 次提交
  6. 25 7月, 2008 1 次提交
  7. 05 6月, 2008 4 次提交
  8. 14 5月, 2008 1 次提交
  9. 23 4月, 2008 1 次提交
  10. 22 4月, 2008 2 次提交
  11. 03 2月, 2008 2 次提交
  12. 03 12月, 2007 3 次提交
  13. 10 11月, 2007 1 次提交
  14. 23 7月, 2007 1 次提交
  15. 06 7月, 2007 1 次提交
  16. 21 10月, 2006 2 次提交
  17. 15 8月, 2006 1 次提交
  18. 01 7月, 2006 1 次提交
  19. 01 4月, 2006 2 次提交
  20. 07 11月, 2005 1 次提交
  21. 23 5月, 2005 2 次提交
  22. 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