1. 17 10月, 2008 3 次提交
    • C
      compat: generic compat get/settimeofday · b418da16
      Christoph Hellwig 提交于
      Nothing arch specific in get/settimeofday.  The details of the timeval
      conversion varied a little from arch to arch, but all with the same
      results.
      
      Also add an extern declaration for sys_tz to linux/time.h because externs
      in .c files are fowned upon.  I'll kill the externs in various other files
      in a sparate patch.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: David S. Miller <davem@davemloft.net> [ sparc bits ]
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Acked-by: NKyle McMartin <kyle@mcmartin.ca>
      Cc: Matthew Wilcox <matthew@wil.cx>
      Cc: Grant Grundler <grundler@parisc-linux.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b418da16
    • C
      compat: move cp_compat_stat to common code · f7a5000f
      Christoph Hellwig 提交于
      struct stat / compat_stat is the same on all architectures, so
      cp_compat_stat should be, too.
      
      Turns out it is, except that various architectures have slightly and some
      high2lowuid/high2lowgid or the direct assignment instead of the
      SET_UID/SET_GID that expands to the correct one anyway.
      
      This patch replaces the arch-specific cp_compat_stat implementations with
      a common one based on the x86-64 one.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: David S. Miller <davem@davemloft.net> [ sparc bits ]
      Acked-by: Kyle McMartin <kyle@mcmartin.ca> [ parisc bits ]
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f7a5000f
    • J
      Kconfig: eliminate "def_bool n" constructs · 9ba16087
      Jan Beulich 提交于
      Using "def_bool n" is pointless, simply using bool here appears more
      appropriate.
      
      Further, retaining such options that don't have a prompt and aren't
      selected by anything seems also at least questionable.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9ba16087
  2. 16 10月, 2008 1 次提交
  3. 15 10月, 2008 10 次提交
  4. 30 9月, 2008 1 次提交
  5. 23 9月, 2008 3 次提交
    • S
      signals: demultiplexing SIGTRAP signal · da654b74
      Srinivasa Ds 提交于
      Currently a SIGTRAP can denote any one of below reasons.
      	- Breakpoint hit
      	- H/W debug register hit
      	- Single step
      	- Signal sent through kill() or rasie()
      
      Architectures like powerpc/parisc provides infrastructure to demultiplex
      SIGTRAP signal by passing down the information for receiving SIGTRAP through
      si_code of siginfot_t structure. Here is an attempt is generalise this
      infrastructure by extending it to x86 and x86_64 archs.
      Signed-off-by: NSrinivasa DS <srinivasa@in.ibm.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: akpm@linux-foundation.org
      Cc: paulus@samba.org
      Cc: linuxppc-dev@ozlabs.org
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      da654b74
    • J
      [IA64] kexec fails on systems with blocks of uncached memory · d3758f87
      Jay Lan 提交于
      Currently a memory segment in memory map with attribute of EFI_MEMORY_UC
      is denoted as "System RAM" in /proc/iomem, while memory of attribute
      (EFI_MEMORY_WB|EFI_MEMORY_UC) is also labeled the same.
      
      The kexec utility then includes uncached memory as part of vmcore. The
      kdump kernel MCA'ed when it tries to save the vmcore to a disk. A normal
      "cached" access may cause MCAs.
      
      This patch would label memory with attribute of EFI_MEMORY_UC only as
      "Uncached RAM" so that kexec would know not to include it in the vmcore.
      I will submit a separate kexec-tools patch to the kexec list.
      Signed-off-by: NJay Lan <jlan@sgi.com>
      Acked-by: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      d3758f87
    • A
      [IA64] Ski simulator doesn't need check_sal_cache_flush · 06f95ea8
      Alex Chiang 提交于
      Peter Chubb reported that commit 3463a93d
      (Update check_sal_cache_flush to use platform_send_ipi()) broke
      Ski because it does not implement IPIs.
      
      Tony Luck suggested we just #ifndef out the call (since the simulator
      does not have the SAL bug that this code is attempting to detect and
      workaround)
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      06f95ea8
  6. 20 9月, 2008 1 次提交
  7. 11 9月, 2008 4 次提交
  8. 10 9月, 2008 1 次提交
  9. 09 9月, 2008 1 次提交
    • M
      kernel/cpu.c: create a CPU_STARTING cpu_chain notifier · e545a614
      Manfred Spraul 提交于
      Right now, there is no notifier that is called on a new cpu, before the new
      cpu begins processing interrupts/softirqs.
      Various kernel function would need that notification, e.g. kvm works around
      by calling smp_call_function_single(), rcu polls cpu_online_map.
      
      The patch adds a CPU_STARTING notification. It also adds a helper function
      that sends the message to all cpu_chain handlers.
      
      Tested on x86-64.
      All other archs are untested. Especially on sparc, I'm not sure if I got
      it right.
      Signed-off-by: NManfred Spraul <manfred@colorfullife.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e545a614
  10. 08 9月, 2008 1 次提交
    • F
      ia64: dma_alloc_coherent always use GFP_DMA · 3a80b6aa
      FUJITA Tomonori 提交于
      This patch makes dma_alloc_coherent use GFP_DMA at all times. This is
      necessary for swiotlb, which requires the callers to set up the gfp
      flags properly.
      
      swiotlb_alloc_coherent tries to allocate pages with the gfp flags. If
      the allocated memory isn't fit for dev->coherent_dma_mask,
      swiotlb_alloc_coherent reserves some of the swiotlb memory area, which
      is precious resource. So the callers need to set up the gfp flags
      properly.
      
      This patch means that other IA64 IOMMUs' dma_alloc_coherent also use
      GFP_DMA. These IOMMUs (e.g. SBA IOMMU) don't need GFP_DMA since they
      can map a memory to any address. But IA64's GFP_DMA is large,
      generally drivers allocate small memory with dma_alloc_coherent only
      at startup. So I chose the simplest way to set up the gfp flags for
      swiotlb.
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Acked-by: NJoerg Roedel <joerg.roedel@amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3a80b6aa
  11. 07 9月, 2008 1 次提交
  12. 04 9月, 2008 1 次提交
  13. 26 8月, 2008 2 次提交
  14. 19 8月, 2008 4 次提交
  15. 15 8月, 2008 1 次提交
  16. 13 8月, 2008 2 次提交
    • A
      [IA64] use bcd2bin/bin2bcd · 430ac5ba
      Adrian Bunk 提交于
      This patch changes ia64 to use the new bcd2bin/bin2bcd functions instead
      of the obsolete BCD2BIN/BIN2BCD macros.
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      430ac5ba
    • T
      [IA64] Ensure cpu0 can access per-cpu variables in early boot code · 10617bbe
      Tony Luck 提交于
      ia64 handles per-cpu variables a litle differently from other architectures
      in that it maps the physical memory allocated for each cpu at a constant
      virtual address (0xffffffffffff0000). This mapping is not enabled until
      the architecture specific cpu_init() function is run, which causes problems
      since some generic code is run before this point. In particular when
      CONFIG_PRINTK_TIME is enabled, the boot cpu will trap on the access to
      per-cpu memory at the first printk() call so the boot will fail without
      the kernel printing anything to the console.
      
      Fix this by allocating percpu memory for cpu0 in the kernel data section
      and doing all initialization to enable percpu access in head.S before
      calling any generic code.
      
      Other cpus must take care not to access per-cpu variables too early, but
      their code path from start_secondary() to cpu_init() is all in arch/ia64
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      10617bbe
  17. 05 8月, 2008 3 次提交