1. 17 4月, 2013 1 次提交
  2. 10 4月, 2013 1 次提交
  3. 08 4月, 2013 1 次提交
  4. 13 3月, 2013 1 次提交
  5. 28 2月, 2013 1 次提交
  6. 18 2月, 2013 1 次提交
  7. 14 2月, 2013 1 次提交
    • A
      burying unused conditionals · d64008a8
      Al Viro 提交于
      __ARCH_WANT_SYS_RT_SIGACTION,
      __ARCH_WANT_SYS_RT_SIGSUSPEND,
      __ARCH_WANT_COMPAT_SYS_RT_SIGSUSPEND,
      __ARCH_WANT_COMPAT_SYS_SCHED_RR_GET_INTERVAL - not used anymore
      CONFIG_GENERIC_{SIGALTSTACK,COMPAT_RT_SIG{ACTION,QUEUEINFO,PENDING,PROCMASK}} -
      can be assumed always set.
      d64008a8
  8. 04 2月, 2013 5 次提交
  9. 01 2月, 2013 2 次提交
    • D
      x86-32, mm: Rip out x86_32 NUMA remapping code · f03574f2
      Dave Hansen 提交于
      This code was an optimization for 32-bit NUMA systems.
      
      It has probably been the cause of a number of subtle bugs over
      the years, although the conditions to excite them would have
      been hard to trigger.  Essentially, we remap part of the kernel
      linear mapping area, and then sometimes part of that area gets
      freed back in to the bootmem allocator.  If those pages get
      used by kernel data structures (say mem_map[] or a dentry),
      there's no big deal.  But, if anyone ever tried to use the
      linear mapping for these pages _and_ cared about their physical
      address, bad things happen.
      
      For instance, say you passed __GFP_ZERO to the page allocator
      and then happened to get handed one of these pages, it zero the
      remapped page, but it would make a pte to the _old_ page.
      There are probably a hundred other ways that it could screw
      with things.
      
      We don't need to hang on to performance optimizations for
      these old boxes any more.  All my 32-bit NUMA systems are long
      dead and buried, and I probably had access to more than most
      people.
      
      This code is causing real things to break today:
      
      	https://lkml.org/lkml/2013/1/9/376
      
      I looked in to actually fixing this, but it requires surgery
      to way too much brittle code, as well as stuff like
      per_cpu_ptr_to_phys().
      
      [ hpa: Cc: this for -stable, since it is a memory corruption issue.
        However, an alternative is to simply mark NUMA as depends BROKEN
        rather than EXPERIMENTAL in the X86_32 subclause... ]
      
      Link: http://lkml.kernel.org/r/20130131005616.1C79F411@kernel.stglabs.ibm.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      f03574f2
    • F
      x86/Kconfig: Make early microcode loading a configuration feature · da76f64e
      Fenghua Yu 提交于
      MICROCODE_INTEL_LIB, MICROCODE_INTEL_EARLY, and MICROCODE_EARLY are three new
      configurations to enable or disable the feature.
      Signed-off-by: NFenghua Yu <fenghua.yu@intel.com>
      Link: http://lkml.kernel.org/r/1356075872-3054-13-git-send-email-fenghua.yu@intel.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      da76f64e
  10. 30 1月, 2013 1 次提交
  11. 29 1月, 2013 1 次提交
  12. 26 1月, 2013 1 次提交
  13. 24 1月, 2013 3 次提交
    • R
      x86/olpc: Fix olpc-xo1-sci.c build errors · ed8e47fe
      Randy Dunlap 提交于
      Fix build errors when CONFIG_INPUT=m.  This is not pretty, but
      all of the OLPC kconfig options are bool instead of tristate.
      
        arch/x86/built-in.o: In function `send_lid_state':
          olpc-xo1-sci.c:(.text+0x1d323): undefined reference to `input_event'
          olpc-xo1-sci.c:(.text+0x1d338): undefined reference to `input_event'
        ...
      
      In the long run, fixing this driver kconfig to be tristate
      instead of bool would be a very good change.
      Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
      Cc: Andres Salomon <dilinger@queued.net>
      Cc: Chris Ball <cjb@laptop.org>
      Cc: Jon Nettleton <jon.nettleton@gmail.com>
      Cc: Daniel Drake <dsd@laptop.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      ed8e47fe
    • K
      x86/cpu/hotplug: Remove CONFIG_EXPERIMENTAL dependency · 2c922cd0
      Kees Cook 提交于
      The CONFIG_EXPERIMENTAL config item has not carried much meaning
      for a while now and is almost always enabled by default. As
      agreed during the Linux kernel summit, remove it from any
      "depends on" lines in Kconfigs.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Link: http://lkml.kernel.org/r/20130122210119.GA311@www.outflux.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      2c922cd0
    • M
      x86: add support for Intel Low Power Subsystem · 3d48aab1
      Mika Westerberg 提交于
      We are starting to see traditional SoC peripherals also in the x86 world in
      chips like Intel Lynxpoint. Typically we already have a Linux driver for
      the peripheral but it takes advantage of the common clk framework to
      control and retrieve information about the peripheral clock.
      
      So far there hasn't been a standard way on x86 to pass information such as
      clock rate from whatever the configuration system is used to the driver,
      but instead different variations have emerged, like adding this information
      to the platform data.
      
      Solve this by adding a new config option X86_INTEL_LPSS. If this is
      selected we enable common clk framework (and everything else) that is
      needed to support the Intel LPSS drivers.
      
      Enabling common clk framework on x86 was originally proposed by Mark Brown.
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3d48aab1
  14. 22 1月, 2013 3 次提交
  15. 16 1月, 2013 1 次提交
  16. 12 1月, 2013 1 次提交
  17. 21 12月, 2012 1 次提交
    • D
      x86: Default to ARCH=x86 to avoid overriding CONFIG_64BIT · ffee0de4
      David Woodhouse 提交于
      It is easy to waste a bunch of time when one takes a 32-bit .config
      from a test machine and try to build it on a faster 64-bit system, and
      its existing setting of CONFIG_64BIT=n gets *changed* to match the
      build host.  Similarly, if one has an existing build tree it is easy
      to trash an entire build tree that way.
      
      This is because the default setting for $ARCH when discovered from
      'uname' is one of the legacy pre-x86-merge values (i386 or x86_64),
      which effectively force the setting of CONFIG_64BIT to match. We should
      default to ARCH=x86 instead, finally completing the merge that we
      started so long ago.
      
      This patch preserves the behaviour of the legacy ARCH settings for commands
      such as:
      
         make ARCH=x86_64 randconfig
         make ARCH=i386 randconfig
      
      ... since making the value of CONFIG_64BIT actually random in that situation
      is not desirable.
      
      In time, perhaps we can retire this legacy use of the old ARCH= values.
      We already have a way to override values for *any* config option, using
      $KCONFIG_ALLCONFIG, so it could be argued that we don't necessarily need
      to keep ARCH={i386,x86_64} around as a special case just for overriding
      CONFIG_64BIT.
      
      We'd probably at least want to add a way to override config options from
      the command line ('make CONFIG_FOO=y oldconfig') before we talk about doing
      that though.
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      Link: http://lkml.kernel.org/r/1356040315.3198.51.camel@shinybook.infradead.orgSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      ffee0de4
  18. 20 12月, 2012 2 次提交
  19. 11 12月, 2012 1 次提交
    • P
      mm: numa: Add fault driven placement and migration · cbee9f88
      Peter Zijlstra 提交于
      NOTE: This patch is based on "sched, numa, mm: Add fault driven
      	placement and migration policy" but as it throws away all the policy
      	to just leave a basic foundation I had to drop the signed-offs-by.
      
      This patch creates a bare-bones method for setting PTEs pte_numa in the
      context of the scheduler that when faulted later will be faulted onto the
      node the CPU is running on.  In itself this does nothing useful but any
      placement policy will fundamentally depend on receiving hints on placement
      from fault context and doing something intelligent about it.
      Signed-off-by: NMel Gorman <mgorman@suse.de>
      Acked-by: NRik van Riel <riel@redhat.com>
      cbee9f88
  20. 08 12月, 2012 1 次提交
  21. 01 12月, 2012 1 次提交
    • F
      context_tracking: New context tracking susbsystem · 91d1aa43
      Frederic Weisbecker 提交于
      Create a new subsystem that probes on kernel boundaries
      to keep track of the transitions between level contexts
      with two basic initial contexts: user or kernel.
      
      This is an abstraction of some RCU code that use such tracking
      to implement its userspace extended quiescent state.
      
      We need to pull this up from RCU into this new level of indirection
      because this tracking is also going to be used to implement an "on
      demand" generic virtual cputime accounting. A necessary step to
      shutdown the tick while still accounting the cputime.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Gilad Ben-Yossef <gilad@benyossef.com>
      Reviewed-by: NSteven Rostedt <rostedt@goodmis.org>
      [ paulmck: fix whitespace error and email address. ]
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      91d1aa43
  22. 30 11月, 2012 2 次提交
  23. 29 11月, 2012 1 次提交
  24. 18 11月, 2012 1 次提交
  25. 15 11月, 2012 2 次提交
    • F
      x86, topology: Debug CPU0 hotplug · a71c8bc5
      Fenghua Yu 提交于
      CONFIG_DEBUG_HOTPLUG_CPU0 is for debugging the CPU0 hotplug feature. The switch
      offlines CPU0 as soon as possible and boots userspace up with CPU0 offlined.
      User can online CPU0 back after boot time. The default value of the switch is
      off.
      
      To debug CPU0 hotplug, you need to enable CPU0 offline/online feature by either
      turning on CONFIG_BOOTPARAM_HOTPLUG_CPU0 during compilation or giving
      cpu0_hotplug kernel parameter at boot.
      
      It's safe and early place to take down CPU0 after all hotplug notifiers
      are installed and SMP is booted.
      
      Please note that some applications or drivers, e.g. some versions of udevd,
      during boot time may put CPU0 online again in this CPU0 hotplug debug mode.
      
      In this debug mode, setup_local_APIC() may report a warning on max_loops<=0
      when CPU0 is onlined back after boot time. This is because pending interrupt in
      IRR can not move to ISR. The warning is not CPU0 specfic and it can happen on
      other CPUs as well. It is harmless except the first CPU0 online takes a bit
      longer time. And so this debug mode is useful to expose this issue. I'll send
      a seperate patch to fix this generic warning issue.
      Signed-off-by: NFenghua Yu <fenghua.yu@intel.com>
      Link: http://lkml.kernel.org/r/1352835171-3958-15-git-send-email-fenghua.yu@intel.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      a71c8bc5
    • F
      x86, Kconfig: Add config switch for CPU0 hotplug · 80aa1dff
      Fenghua Yu 提交于
      New config switch CONFIG_BOOTPARAM_HOTPLUG_CPU0 sets default state of whether
      the CPU0 hotplug is on or off.
      
      If the switch is off, CPU0 is not hotpluggable by default. But the CPU0 hotplug
      feature can still be turned on by kernel parameter cpu0_hotplug at boot.
      
      If the switch is on, CPU0 is always hotpluggable.
      
      The default value of the switch is off.
      Signed-off-by: NFenghua Yu <fenghua.yu@intel.com>
      Link: http://lkml.kernel.org/r/1352835171-3958-3-git-send-email-fenghua.yu@intel.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      80aa1dff
  26. 26 10月, 2012 1 次提交
  27. 13 10月, 2012 1 次提交
  28. 09 10月, 2012 1 次提交
    • G
      thp, x86: introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE · 15626062
      Gerald Schaefer 提交于
      Cleanup patch in preparation for transparent hugepage support on s390.
      Adding new architectures to the TRANSPARENT_HUGEPAGE config option can
      make the "depends" line rather ugly, like "depends on (X86 || (S390 &&
      64BIT)) && MMU".
      
      This patch adds a HAVE_ARCH_TRANSPARENT_HUGEPAGE instead.  x86 already has
      MMU "def_bool y", so the MMU check is superfluous there and
      HAVE_ARCH_TRANSPARENT_HUGEPAGE can be selected in arch/x86/Kconfig.
      Signed-off-by: NGerald Schaefer <gerald.schaefer@de.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Hillf Danton <dhillf@gmail.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      15626062