1. 27 6月, 2008 4 次提交
  2. 27 5月, 2008 1 次提交
  3. 26 5月, 2008 3 次提交
  4. 17 5月, 2008 1 次提交
  5. 04 5月, 2008 1 次提交
    • U
      unified (weak) sys_pipe implementation · d35c7b0e
      Ulrich Drepper 提交于
      This replaces the duplicated arch-specific versions of "sys_pipe()" with
      one unified implementation.  This removes almost 250 lines of duplicated
      code.
      
      It's marked __weak, so that *if* an architecture wants to override the
      default implementation it can do so by simply having its own replacement
      version, since many architectures use alternate calling conventions for
      the 'pipe()' system call for legacy reasons (ie traditional UNIX
      implementations often return the two file descriptors in registers)
      
      I still haven't changed the cris version even though Linus says the BKL
      isn't needed.  The arch maintainer can easily do it if there are really
      no obstacles.
      Signed-off-by: NUlrich Drepper <drepper@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d35c7b0e
  6. 29 4月, 2008 2 次提交
  7. 28 4月, 2008 1 次提交
    • H
      atmel_lcdfb: don't initialize a pre-allocated framebuffer · 01d3a5e7
      Haavard Skinnemoen 提交于
      If the user specified a fixed framebuffer address on the command line, it may
      have been initialized already with a splash image or something, so we
      shouldn't clear it.
      
      Therefore, we should only initialize the framebuffer if we allocated it
      ourselves.  This patch also updates the AVR32 setup code to clear the
      framebuffer if it allocated it itself, i.e.  the user didn't provide a fixed
      address or the reservation failed.
      
      I've updated the at91 platform code as well so that it initializes the
      framebuffer if it is located in SRAM, but I haven't tested that it actually
      works.
      Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Cc: Nicolas FERRE <nicolas.ferre@rfo.atmel.com>
      Cc: Andrew Victor <andrew@sanpeople.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      01d3a5e7
  8. 20 4月, 2008 8 次提交
  9. 17 4月, 2008 2 次提交
  10. 07 4月, 2008 1 次提交
  11. 27 3月, 2008 1 次提交
  12. 14 3月, 2008 1 次提交
  13. 27 2月, 2008 1 次提交
    • H
      avr32: Fix OCD refcounting bug · 325d6f55
      Haavard Skinnemoen 提交于
      Iff the parent has TIF_DEBUG set, _and_ clone_flags includes
      CLONE_PTRACE we should set the TIF_DEBUG flag for the child and
      increment the ocd refcount. Otherwise, the TIF_DEBUG flag must be
      unset.
      
      Currently, the child inherits TIF_DEBUG from the parent before
      copy_thread is called, so TIF_DEBUG may be already be set before we
      determine whether the child is supposed to inherit debugging
      capabilities from the parent or not. This means that ocd_enable()
      won't increment the refcount, because TIF_DEBUG is already set, and
      that TIF_DEBUG will be set for processes that aren't being debugged.
      
      This leads to a refcounting asymmetry, which may show up as
      
      ------------[ cut here ]------------
      Badness at arch/avr32/kernel/ocd.c:73
      PC is at ocd_disable+0x34/0x60
      LR is at put_lock_stats+0xa/0x20
      
      as reported by David Brownell. Happens when strace'ing a process that
      forks a new child process, e.g. "strace mount -tjffs2 mtd1 /mnt", and
      subsequently killing the child process (e.g. "umount /mnt".)
      Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      325d6f55
  14. 15 2月, 2008 1 次提交
  15. 13 2月, 2008 2 次提交
  16. 09 2月, 2008 3 次提交
  17. 08 2月, 2008 1 次提交
    • B
      Introduce flags for reserve_bootmem() · 72a7fe39
      Bernhard Walle 提交于
      This patchset adds a flags variable to reserve_bootmem() and uses the
      BOOTMEM_EXCLUSIVE flag in crashkernel reservation code to detect collisions
      between crashkernel area and already used memory.
      
      This patch:
      
      Change the reserve_bootmem() function to accept a new flag BOOTMEM_EXCLUSIVE.
      If that flag is set, the function returns with -EBUSY if the memory already
      has been reserved in the past.  This is to avoid conflicts.
      
      Because that code runs before SMP initialisation, there's no race condition
      inside reserve_bootmem_core().
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: fix powerpc build]
      Signed-off-by: NBernhard Walle <bwalle@suse.de>
      Cc: <linux-arch@vger.kernel.org>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Vivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      72a7fe39
  18. 07 2月, 2008 1 次提交
    • A
      read_current_timer() cleanups · 941e492b
      Andrew Morton 提交于
      - All implementations can be __devinit
      
      - The function prototypes were in asm/timex.h but they all must be the same,
        so create a single declaration in linux/timex.h.
      
      - uninline the sparc64 version to match the other architectures
      
      - Don't bother #defining ARCH_HAS_READ_CURRENT_TIMER to a particular value.
      
      [ezk@cs.sunysb.edu: fix build]
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      941e492b
  19. 06 2月, 2008 2 次提交
  20. 04 2月, 2008 1 次提交
  21. 03 2月, 2008 2 次提交
    • M
      Add HAVE_KPROBES · 3f550096
      Mathieu Desnoyers 提交于
      Linus:
      
      On the per-architecture side, I do think it would be better to *not* have
      internal architecture knowledge in a generic file, and as such a line like
      
              depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
      
      really shouldn't exist in a file like kernel/Kconfig.instrumentation.
      
      It would be much better to do
      
              depends on ARCH_SUPPORTS_KPROBES
      
      in that generic file, and then architectures that do support it would just
      have a
      
              bool ARCH_SUPPORTS_KPROBES
                      default y
      
      in *their* architecture files. That would seem to be much more logical,
      and is readable both for arch maintainers *and* for people who have no
      clue - and don't care - about which architecture is supposed to support
      which interface...
      
      Changelog:
      
      Actually, I know I gave this as the magic incantation, but now that I see
      it, I realize that I should have told you to just use
      
              config KPROBES_SUPPORT
                      def_bool y
      
      instead, which is a bit denser.
      
      We seem to use both kinds of syntax for these things, but this is really
      what "def_bool" is there for...
      
      - Use HAVE_KPROBES
      - Use a select
      
      - Yet another update :
      Moving to HAVE_* now.
      
      - Update ARM for kprobes support.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      3f550096
    • M
      Add HAVE_OPROFILE · 42d4b839
      Mathieu Desnoyers 提交于
      Linus:
      On the per-architecture side, I do think it would be better to *not* have
      internal architecture knowledge in a generic file, and as such a line like
      
              depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
      
      really shouldn't exist in a file like kernel/Kconfig.instrumentation.
      
      It would be much better to do
      
              depends on ARCH_SUPPORTS_KPROBES
      
      in that generic file, and then architectures that do support it would just
      have a
      
              bool ARCH_SUPPORTS_KPROBES
                      default y
      
      in *their* architecture files. That would seem to be much more logical,
      and is readable both for arch maintainers *and* for people who have no
      clue - and don't care - about which architecture is supposed to support
      which interface...
      
      Changelog:
      
      Actually, I know I gave this as the magic incantation, but now that I see
      it, I realize that I should have told you to just use
      
              config ARCH_SUPPORTS_KPROBES
                      def_bool y
      
      instead, which is a bit denser.
      
      We seem to use both kinds of syntax for these things, but this is really
      what "def_bool" is there for...
      
      Changelog :
      
      - Moving to HAVE_*.
      - Add AVR32 oprofile.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      42d4b839