1. 25 10月, 2013 2 次提交
    • M
      arm64: read enable-method for CPU0 · e8765b26
      Mark Rutland 提交于
      With the advent of CPU_HOTPLUG, the enable-method property for CPU0 may
      tells us something useful (i.e. how to hotplug it back on), so we must
      read it along with all the enable-method for all the other CPUs.  Even
      on UP the enable-method may tell us useful information (e.g. if a core
      has some mechanism that might be usable for cpuidle), so we should
      always read it.
      
      This patch factors out the reading of the enable method, and ensures
      that CPU0's enable method is read regardless of whether the kernel is
      built with SMP support.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      e8765b26
    • M
      arm64: reorganise smp_enable_ops · cd1aebf5
      Mark Rutland 提交于
      For hotplug support, we're going to want a place to store operations
      that do more than bring CPUs online, and it makes sense to group these
      with our current smp_enable_ops. For cpuidle support, we'll want to
      group additional functions, and we may want them even for UP kernels.
      
      This patch renames smp_enable_ops to the more general cpu_operations,
      and pulls the definitions out of smp code such that they can be used in
      UP kernels. While we're at it, fix up instances of the cpu parameter to
      be an unsigned int, drop the init markings and rename the *_cpu
      functions to cpu_* to reduce future churn when cpu_operations is
      extended.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      cd1aebf5
  2. 22 3月, 2013 2 次提交
  3. 17 9月, 2012 3 次提交
  4. 18 7月, 2007 1 次提交
  5. 19 6月, 2006 1 次提交
  6. 10 1月, 2006 2 次提交
  7. 16 11月, 2005 1 次提交
  8. 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