1. 03 8月, 2013 1 次提交
    • D
      x86: provide platform-devices for boot-framebuffers · e3263ab3
      David Herrmann 提交于
      The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
      x86 causes troubles when loading multiple fbdev drivers. The global
      "struct screen_info" does not provide any state-tracking about which
      drivers use the FBs. request_mem_region() theoretically works, but
      unfortunately vesafb/efifb ignore it due to quirks for broken boards.
      
      Avoid this by creating a platform framebuffer devices with a pointer
      to the "struct screen_info" as platform-data. Drivers can now create
      platform-drivers and the driver-core will refuse multiple drivers being
      active simultaneously.
      
      We keep the screen_info available for backwards-compatibility. Drivers
      can be converted in follow-up patches.
      
      Different devices are created for VGA/VESA/EFI FBs to allow multiple
      drivers to be loaded on distro kernels. We create:
       - "vesa-framebuffer" for VBE/VESA graphics FBs
       - "efi-framebuffer" for EFI FBs
       - "platform-framebuffer" for everything else
      This allows to load vesafb, efifb and others simultaneously and each
      picks up only the supported FB types.
      
      Apart from platform-framebuffer devices, this also introduces a
      compatibility option for "simple-framebuffer" drivers which recently got
      introduced for OF based systems. If CONFIG_X86_SYSFB is selected, we
      try to match the screen_info against a simple-framebuffer supported
      format. If we succeed, we create a "simple-framebuffer" device instead
      of a platform-framebuffer.
      This allows to reuse the simplefb.c driver across architectures and also
      to introduce a SimpleDRM driver. There is no need to have vesafb.c,
      efifb.c, simplefb.c and more just to have architecture specific quirks
      in their setup-routines.
      
      Instead, we now move the architecture specific quirks into x86-setup and
      provide a generic simple-framebuffer. For backwards-compatibility (if
      strange formats are used), we still allow vesafb/efifb to be loaded
      simultaneously and pick up all remaining devices.
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Link: http://lkml.kernel.org/r/1375445127-15480-4-git-send-email-dh.herrmann@gmail.comTested-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      e3263ab3
  2. 10 7月, 2013 1 次提交
  3. 05 7月, 2013 1 次提交
  4. 04 7月, 2013 2 次提交
    • A
      rapidio: add modular build option for the subsystem core · fdf90abc
      Alexandre Bounine 提交于
      Add a configuration option to build RapidIO subsystem core code as a
      loadable kernel module.  Currently this option is available only for
      x86-based platforms, with the additional patch for PowerPC planned to be
      provided later.
      
      This patch replaces kernel command line parameter "riohdid=" with its
      module-specific analog "rapidio.hdid=".
      Signed-off-by: NAlexandre Bounine <alexandre.bounine@idt.com>
      Cc: Matt Porter <mporter@kernel.crashing.org>
      Cc: Li Yang <leoli@freescale.com>
      Cc: Kumar Gala <galak@kernel.crashing.org>
      Cc: Andre van Herk <andre.van.herk@Prodrive.nl>
      Cc: Micha Nelissen <micha.nelissen@Prodrive.nl>
      Cc: Stef van Os <stef.van.os@Prodrive.nl>
      Cc: Jean Delvare <jdelvare@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fdf90abc
    • P
      mm: soft-dirty bits for user memory changes tracking · 0f8975ec
      Pavel Emelyanov 提交于
      The soft-dirty is a bit on a PTE which helps to track which pages a task
      writes to.  In order to do this tracking one should
      
        1. Clear soft-dirty bits from PTEs ("echo 4 > /proc/PID/clear_refs)
        2. Wait some time.
        3. Read soft-dirty bits (55'th in /proc/PID/pagemap2 entries)
      
      To do this tracking, the writable bit is cleared from PTEs when the
      soft-dirty bit is.  Thus, after this, when the task tries to modify a
      page at some virtual address the #PF occurs and the kernel sets the
      soft-dirty bit on the respective PTE.
      
      Note, that although all the task's address space is marked as r/o after
      the soft-dirty bits clear, the #PF-s that occur after that are processed
      fast.  This is so, since the pages are still mapped to physical memory,
      and thus all the kernel does is finds this fact out and puts back
      writable, dirty and soft-dirty bits on the PTE.
      
      Another thing to note, is that when mremap moves PTEs they are marked
      with soft-dirty as well, since from the user perspective mremap modifies
      the virtual memory at mremap's new address.
      Signed-off-by: NPavel Emelyanov <xemul@parallels.com>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
      Cc: Glauber Costa <glommer@parallels.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0f8975ec
  5. 26 6月, 2013 1 次提交
  6. 19 6月, 2013 1 次提交
    • R
      x86: fix build error and kconfig for ia32_emulation and binfmt · d1603990
      Randy Dunlap 提交于
      Fix kconfig warning and build errors on x86_64 by selecting BINFMT_ELF
      when COMPAT_BINFMT_ELF is being selected.
      
      warning: (IA32_EMULATION) selects COMPAT_BINFMT_ELF which has unmet direct dependencies (COMPAT && BINFMT_ELF)
      
      fs/built-in.o: In function `elf_core_dump':
      compat_binfmt_elf.c:(.text+0x3e093): undefined reference to `elf_core_extra_phdrs'
      compat_binfmt_elf.c:(.text+0x3ebcd): undefined reference to `elf_core_extra_data_size'
      compat_binfmt_elf.c:(.text+0x3eddd): undefined reference to `elf_core_write_extra_phdrs'
      compat_binfmt_elf.c:(.text+0x3f004): undefined reference to `elf_core_write_extra_data'
      
      [ hpa: This was sent to me for -next but it is a low risk build fix ]
      Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
      Link: http://lkml.kernel.org/r/51C0B614.5000708@infradead.org
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      d1603990
  7. 14 6月, 2013 2 次提交
  8. 04 6月, 2013 1 次提交
  9. 01 6月, 2013 1 次提交
  10. 31 5月, 2013 1 次提交
  11. 15 5月, 2013 1 次提交
    • J
      time: Revert ALWAYS_USE_PERSISTENT_CLOCK compile time optimizaitons · b4f711ee
      John Stultz 提交于
      Kay Sievers noted that the ALWAYS_USE_PERSISTENT_CLOCK config,
      which enables some minor compile time optimization to avoid
      uncessary code in mostly the suspend/resume path could cause
      problems for userland.
      
      In particular, the dependency for RTC_HCTOSYS on
      !ALWAYS_USE_PERSISTENT_CLOCK, which avoids setting the time
      twice and simplifies suspend/resume, has the side effect
      of causing the /sys/class/rtc/rtcN/hctosys flag to always be
      zero, and this flag is commonly used by udev to setup the
      /dev/rtc symlink to /dev/rtcN, which can cause pain for
      older applications.
      
      While the udev rules could use some work to be less fragile,
      breaking userland should strongly be avoided. Additionally
      the compile time optimizations are fairly minor, and the code
      being optimized is likely to be reworked in the future, so
      lets revert this change.
      Reported-by: NKay Sievers <kay@vrfy.org>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      Cc: stable <stable@vger.kernel.org> #3.9
      Cc: Feng Tang <feng.tang@intel.com>
      Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Link: http://lkml.kernel.org/r/1366828376-18124-1-git-send-email-john.stultz@linaro.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      b4f711ee
  12. 01 5月, 2013 1 次提交
    • S
      Kconfig: consolidate CONFIG_DEBUG_STRICT_USER_COPY_CHECKS · 446f24d1
      Stephen Boyd 提交于
      The help text for this config is duplicated across the x86, parisc, and
      s390 Kconfig.debug files.  Arnd Bergman noted that the help text was
      slightly misleading and should be fixed to state that enabling this
      option isn't a problem when using pre 4.4 gcc.
      
      To simplify the rewording, consolidate the text into lib/Kconfig.debug
      and modify it there to be more explicit about when you should say N to
      this config.
      
      Also, make the text a bit more generic by stating that this option
      enables compile time checks so we can cover architectures which emit
      warnings vs.  ones which emit errors.  The details of how an
      architecture decided to implement the checks isn't as important as the
      concept of compile time checking of copy_from_user() calls.
      
      While we're doing this, remove all the copy_from_user_overflow() code
      that's duplicated many times and place it into lib/ so that any
      architecture supporting this option can get the function for free.
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Acked-by: NHelge Deller <deller@gmx.de>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      446f24d1
  13. 17 4月, 2013 2 次提交
  14. 16 4月, 2013 1 次提交
  15. 10 4月, 2013 1 次提交
  16. 08 4月, 2013 1 次提交
  17. 16 3月, 2013 1 次提交
    • P
      x86: Do full rtc synchronization with ntp · 3195ef59
      Prarit Bhargava 提交于
      Every 11 minutes ntp attempts to update the x86 rtc with the current
      system time.  Currently, the x86 code only updates the rtc if the system
      time is within +/-15 minutes of the current value of the rtc. This
      was done originally to avoid setting the RTC if the RTC was in localtime
      mode (common with Windows dualbooting).  Other architectures do a full
      synchronization and now that we have better infrastructure to detect
      when the RTC is in localtime, there is no reason that x86 should be
      software limited to a 30 minute window.
      
      This patch changes the behavior of the kernel to do a full synchronization
      (year, month, day, hour, minute, and second) of the rtc when ntp requests
      a synchronization between the system time and the rtc.
      
      I've used the RTC library functions in this patchset as they do all the
      required bounds checking.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: x86@kernel.org
      Cc: Matt Fleming <matt.fleming@intel.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: linux-efi@vger.kernel.org
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      [jstultz: Tweak commit message, fold in build fix found by fengguang
      Also add select RTC_LIB to X86, per new dependency, as found by prarit]
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      3195ef59
  18. 13 3月, 2013 1 次提交
  19. 05 3月, 2013 2 次提交
  20. 28 2月, 2013 1 次提交
  21. 18 2月, 2013 1 次提交
  22. 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
  23. 04 2月, 2013 5 次提交
  24. 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
  25. 30 1月, 2013 1 次提交
  26. 29 1月, 2013 1 次提交
  27. 26 1月, 2013 1 次提交
  28. 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
  29. 22 1月, 2013 1 次提交