1. 21 4月, 2012 1 次提交
  2. 20 4月, 2012 1 次提交
  3. 21 3月, 2012 1 次提交
  4. 16 3月, 2012 1 次提交
    • C
      [PATCH v3] ipc: provide generic compat versions of IPC syscalls · 48b25c43
      Chris Metcalf 提交于
      When using the "compat" APIs, architectures will generally want to
      be able to make direct syscalls to msgsnd(), shmctl(), etc., and
      in the kernel we would want them to be handled directly by
      compat_sys_xxx() functions, as is true for other compat syscalls.
      
      However, for historical reasons, several of the existing compat IPC
      syscalls do not do this.  semctl() expects a pointer to the fourth
      argument, instead of the fourth argument itself.  msgsnd(), msgrcv()
      and shmat() expect arguments in different order.
      
      This change adds an ARCH_WANT_OLD_COMPAT_IPC config option that can be
      set to preserve this behavior for ports that use it (x86, sparc, powerpc,
      s390, and mips).  No actual semantics are changed for those architectures,
      and there is only a minimal amount of code refactoring in ipc/compat.c.
      
      Newer architectures like tile (and perhaps future architectures such
      as arm64 and unicore64) should not select this option, and thus can
      avoid having any IPC-specific code at all in their architecture-specific
      compat layer.  In the same vein, if this option is not selected, IPC_64
      mode is assumed, since that's what the <asm-generic> headers expect.
      
      The workaround code in "tile" for msgsnd() and msgrcv() is removed
      with this change; it also fixes the bug that shmat() and semctl() were
      not being properly handled.
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      48b25c43
  5. 09 3月, 2012 1 次提交
  6. 06 3月, 2012 1 次提交
  7. 28 2月, 2012 1 次提交
  8. 24 2月, 2012 1 次提交
  9. 21 2月, 2012 1 次提交
  10. 27 1月, 2012 3 次提交
  11. 26 1月, 2012 2 次提交
  12. 17 1月, 2012 1 次提交
  13. 13 1月, 2012 3 次提交
  14. 11 1月, 2012 1 次提交
  15. 30 12月, 2011 1 次提交
  16. 18 12月, 2011 2 次提交
  17. 16 12月, 2011 1 次提交
  18. 13 12月, 2011 1 次提交
    • M
      x86, efi: EFI boot stub support · 291f3632
      Matt Fleming 提交于
      There is currently a large divide between kernel development and the
      development of EFI boot loaders. The idea behind this patch is to give
      the kernel developers full control over the EFI boot process. As
      H. Peter Anvin put it,
      
      "The 'kernel carries its own stub' approach been very successful in
      dealing with BIOS, and would make a lot of sense to me for EFI as
      well."
      
      This patch introduces an EFI boot stub that allows an x86 bzImage to
      be loaded and executed by EFI firmware. The bzImage appears to the
      firmware as an EFI application. Luckily there are enough free bits
      within the bzImage header so that it can masquerade as an EFI
      application, thereby coercing the EFI firmware into loading it and
      jumping to its entry point. The beauty of this masquerading approach
      is that both BIOS and EFI boot loaders can still load and run the same
      bzImage, thereby allowing a single kernel image to work in any boot
      environment.
      
      The EFI boot stub supports multiple initrds, but they must exist on
      the same partition as the bzImage. Command-line arguments for the
      kernel can be appended after the bzImage name when run from the EFI
      shell, e.g.
      
      Shell> bzImage console=ttyS0 root=/dev/sdb initrd=initrd.img
      
      v7:
       - Fix checkpatch warnings.
      
      v6:
      
       - Try to allocate initrd memory just below hdr->inird_addr_max.
      
      v5:
      
       - load_options_size is UTF-16, which needs dividing by 2 to convert
         to the corresponding ASCII size.
      
      v4:
      
       - Don't read more than image->load_options_size
      
      v3:
      
       - Fix following warnings when compiling CONFIG_EFI_STUB=n
      
         arch/x86/boot/tools/build.c: In function ‘main’:
         arch/x86/boot/tools/build.c:138:24: warning: unused variable ‘pe_header’
         arch/x86/boot/tools/build.c:138:15: warning: unused variable ‘file_sz’
      
       - As reported by Matthew Garrett, some Apple machines have GOPs that
         don't have hardware attached. We need to weed these out by
         searching for ones that handle the PCIIO protocol.
      
       - Don't allocate memory if no initrds are on cmdline
       - Don't trust image->load_options_size
      
      Maarten Lankhorst noted:
       - Don't strip first argument when booted from efibootmgr
       - Don't allocate too much memory for cmdline
       - Don't update cmdline_size, the kernel considers it read-only
       - Don't accept '\n' for initrd names
      
      v2:
      
       - File alignment was too large, was 8192 should be 512. Reported by
         Maarten Lankhorst on LKML.
       - Added UGA support for graphics
       - Use VIDEO_TYPE_EFI instead of hard-coded number.
       - Move linelength assignment until after we've assigned depth
       - Dynamically fill out AddressOfEntryPoint in tools/build.c
       - Don't use magic number for GDT/TSS stuff. Requested by Andi Kleen
       - The bzImage may need to be relocated as it may have been loaded at
         a high address address by the firmware. This was required to get my
         macbook booting because the firmware loaded it at 0x7cxxxxxx, which
         triggers this error in decompress_kernel(),
      
      	if (heap > ((-__PAGE_OFFSET-(128<<20)-1) & 0x7fffffff))
      		error("Destination address too large");
      
      Cc: Mike Waychison <mikew@google.com>
      Cc: Matthew Garrett <mjg@redhat.com>
      Tested-by: NHenrik Rydberg <rydberg@euromail.se>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      291f3632
  19. 09 12月, 2011 1 次提交
    • T
      memblock: Kill early_node_map[] · 0ee332c1
      Tejun Heo 提交于
      Now all ARCH_POPULATES_NODE_MAP archs select HAVE_MEBLOCK_NODE_MAP -
      there's no user of early_node_map[] left.  Kill early_node_map[] and
      replace ARCH_POPULATES_NODE_MAP with HAVE_MEMBLOCK_NODE_MAP.  Also,
      relocate for_each_mem_pfn_range() and helper from mm.h to memblock.h
      as page_alloc.c would no longer host an alternative implementation.
      
      This change is ultimately one to one mapping and shouldn't cause any
      observable difference; however, after the recent changes, there are
      some functions which now would fit memblock.c better than page_alloc.c
      and dependency on HAVE_MEMBLOCK_NODE_MAP instead of HAVE_MEMBLOCK
      doesn't make much sense on some of them.  Further cleanups for
      functions inside HAVE_MEMBLOCK_NODE_MAP in mm.h would be nice.
      
      -v2: Fix compile bug introduced by mis-spelling
       CONFIG_HAVE_MEMBLOCK_NODE_MAP to CONFIG_MEMBLOCK_HAVE_NODE_MAP in
       mmzone.h.  Reported by Stephen Rothwell.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Chen Liqin <liqin.chen@sunplusct.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      0ee332c1
  20. 06 12月, 2011 4 次提交
  21. 05 12月, 2011 1 次提交
  22. 25 11月, 2011 1 次提交
  23. 23 11月, 2011 1 次提交
  24. 01 11月, 2011 1 次提交
  25. 13 10月, 2011 1 次提交
  26. 28 9月, 2011 1 次提交
    • P
      doc: fix broken references · 395cf969
      Paul Bolle 提交于
      There are numerous broken references to Documentation files (in other
      Documentation files, in comments, etc.). These broken references are
      caused by typo's in the references, and by renames or removals of the
      Documentation files. Some broken references are simply odd.
      
      Fix these broken references, sometimes by dropping the irrelevant text
      they were part of.
      Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      395cf969
  27. 21 9月, 2011 2 次提交
    • E
      x86: geode: New PCEngines Alix system driver · d4f3e350
      Ed Wildgoose 提交于
      This new driver replaces the old PCEngines Alix 2/3 LED driver with a
      new driver that controls the LEDs through the leds-gpio driver. The
      old driver accessed GPIOs directly, which created a conflict and
      prevented also loading the cs5535-gpio driver to read other GPIOs on
      the Alix board. With this new driver, we hook into leds-gpio which in
      turn uses GPIO to control the LEDs and therefore it's possible to
      control both the LEDs and access onboard GPIOs
      
      Driver is moved to platform/geode as requested by Grant and any other
      geode initialisation modules should move here also
      
      This driver is inspired by leds-net5501.c by Alessandro Zummo.
      
      Ideally, leds-net5501.c should also be moved to platform/geode. 
      Additionally the driver relies on parts of the patch: 7f131cf3 ("leds:
      leds-alix2c - take port address from MSR) by Daniel Mack to perform
      detection of the Alix board.
      
      [akpm@linux-foundation.org: include module.h]
      Signed-off-by: NEd Wildgoose <kernel@wildgooses.com>
      Cc: git@wildgooses.com
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Daniel Mack <daniel@caiaq.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Reviewed-by: NGrant Likely <grant.likely@secretlab.ca>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      d4f3e350
    • S
      iommu: Rename the DMAR and INTR_REMAP config options · d3f13810
      Suresh Siddha 提交于
      Change the CONFIG_DMAR to CONFIG_INTEL_IOMMU to be consistent
      with the other IOMMU options.
      
      Rename the CONFIG_INTR_REMAP to CONFIG_IRQ_REMAP to match the
      irq subsystem name.
      
      And define the CONFIG_DMAR_TABLE for the common ACPI DMAR
      routines shared by both CONFIG_INTEL_IOMMU and CONFIG_IRQ_REMAP.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: yinghai@kernel.org
      Cc: youquan.song@intel.com
      Cc: joerg.roedel@amd.com
      Cc: tony.luck@intel.com
      Cc: dwmw2@infradead.org
      Link: http://lkml.kernel.org/r/20110824001456.558630224@sbsiddha-desk.sc.intel.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      d3f13810
  28. 08 9月, 2011 1 次提交
  29. 03 8月, 2011 1 次提交
  30. 01 8月, 2011 1 次提交
    • H
      x86, random: Architectural inlines to get random integers with RDRAND · 628c6246
      H. Peter Anvin 提交于
      Architectural inlines to get random ints and longs using the RDRAND
      instruction.
      
      Intel has introduced a new RDRAND instruction, a Digital Random Number
      Generator (DRNG), which is functionally an high bandwidth entropy
      source, cryptographic whitener, and integrity monitor all built into
      hardware.  This enables RDRAND to be used directly, bypassing the
      kernel random number pool.
      
      For technical documentation, see:
      
      http://software.intel.com/en-us/articles/download-the-latest-bull-mountain-software-implementation-guide/
      
      In this patch, this is *only* used for the nonblocking random number
      pool.  RDRAND is a nonblocking source, similar to our /dev/urandom,
      and is therefore not a direct replacement for /dev/random.  The
      architectural hooks presented in the previous patch only feed the
      kernel internal users, which only use the nonblocking pool, and so
      this is not a problem.
      
      Since this instruction is available in userspace, there is no reason
      to have a /dev/hw_rng device driver for the purpose of feeding rngd.
      This is especially so since RDRAND is a nonblocking source, and needs
      additional whitening and reduction (see the above technical
      documentation for details) in order to be of "pure entropy source"
      quality.
      
      The CONFIG_EXPERT compile-time option can be used to disable this use
      of RDRAND.
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Originally-by: NFenghua Yu <fenghua.yu@intel.com>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      628c6246