1. 30 9月, 2015 2 次提交
  2. 21 1月, 2014 1 次提交
  3. 27 3月, 2012 4 次提交
    • A
      mtd: harmonize mtd_point interface implementation · 0dd5235f
      Artem Bityutskiy 提交于
      Some MTD drivers return -EINVAL if the 'phys' parameter is not NULL, trying to
      convey that they cannot return the physical address. However, this is not very
      logical because they still can return the virtual address ('virt'). But some
      drivers (lpddr) just ignore the 'phys' parameter instead, which is a more
      logical thing to do.
      
      Let's harmonize this and:
      
      1. Always initialize 'virt' and 'phys' to 'NULL' in 'mtd_point()'.
      2. Do not return an error if the physical address cannot be found.
      
      So as a result, all drivers will set 'phys' to 'NULL' if it is not supported.
      None of the 'mtd_point()' users use 'phys' anyway, so this should not break
      anything. I guess we could also just delete this parameter later.
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      0dd5235f
    • A
      mtd: do not duplicate length and offset checks in drivers · 5def4898
      Artem Bityutskiy 提交于
      We already verify that offset and length are within the MTD device size
      in the MTD API functions. Let's remove the duplicated checks in drivers.
      This patch only affects the following API's:
      
      'mtd_erase()'
      'mtd_point()'
      'mtd_unpoint()'
      'mtd_get_unmapped_area()'
      'mtd_read()'
      'mtd_write()'
      'mtd_panic_write()'
      'mtd_lock()'
      'mtd_unlock()'
      'mtd_is_locked()'
      'mtd_block_isbad()'
      'mtd_block_markbad()'
      
      This patch adds a bit of noise by removing too sparse empty lines, but this is
      not too bad.
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      5def4898
    • A
      mtd: return error code from mtd_unpoint · 5e4e6e3f
      Artem Bityutskiy 提交于
      The 'mtd_unpoint()' API function should be able to return an error code because
      it may fail if you specify incorrect offset. This patch changes this MTD API
      function and amends all the drivers correspondingly.
      
      Also return '-EOPNOTSUPP' from 'mtd_unpoint()' when the '->unpoint()' method is
      undefined. We do not really need this currently, but this just makes
      sense to be consistent with 'mtd_point()'.
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      5e4e6e3f
    • A
      mtd: add leading underscore to all mtd functions · 3c3c10bb
      Artem Bityutskiy 提交于
      This patch renames all MTD functions by adding a "_" prefix:
      
      mtd->erase -> mtd->_erase
      mtd->read_oob -> mtd->_read_oob
      ...
      
      The reason is that we are re-working the MTD API and from now on it is
      an error to use MTD function pointers directly - we have a corresponding
      API call for every pointer. By adding a leading "_" we achieve the following:
      
      1. Make sure we convert every direct pointer users
      2. A leading "_" suggests that this interface is internal and it becomes
         less likely that people will use them directly
      3. Make sure all the out-of-tree modules stop compiling and the owners
         spot the big API change and amend them.
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      3c3c10bb
  4. 25 5月, 2011 1 次提交
  5. 11 3月, 2011 1 次提交
  6. 09 8月, 2010 1 次提交
  7. 24 3月, 2009 1 次提交
  8. 05 6月, 2008 1 次提交
  9. 02 5月, 2008 1 次提交
  10. 22 4月, 2008 1 次提交
  11. 01 7月, 2006 1 次提交
  12. 15 6月, 2006 1 次提交
  13. 14 6月, 2006 1 次提交
  14. 30 5月, 2006 1 次提交
  15. 11 9月, 2005 1 次提交
  16. 23 5月, 2005 1 次提交
  17. 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