1. 20 4月, 2011 9 次提交
  2. 18 4月, 2011 1 次提交
  3. 12 4月, 2011 2 次提交
  4. 01 4月, 2011 8 次提交
  5. 31 3月, 2011 1 次提交
  6. 30 3月, 2011 7 次提交
  7. 24 3月, 2011 6 次提交
    • F
      remove dma64_addr_t · 85477277
      FUJITA Tomonori 提交于
      There is no user now.
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: David Miller <davem@davemloft.net>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Matt Turner <mattst88@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      85477277
    • A
      bitops: remove minix bitops from asm/bitops.h · 61f2e7b0
      Akinobu Mita 提交于
      minix bit operations are only used by minix filesystem and useless by
      other modules.  Because byte order of inode and block bitmaps is different
      on each architecture like below:
      
      m68k:
      	big-endian 16bit indexed bitmaps
      
      h8300, microblaze, s390, sparc, m68knommu:
      	big-endian 32 or 64bit indexed bitmaps
      
      m32r, mips, sh, xtensa:
      	big-endian 32 or 64bit indexed bitmaps for big-endian mode
      	little-endian bitmaps for little-endian mode
      
      Others:
      	little-endian bitmaps
      
      In order to move minix bit operations from asm/bitops.h to architecture
      independent code in minix filesystem, this provides two config options.
      
      CONFIG_MINIX_FS_BIG_ENDIAN_16BIT_INDEXED is only selected by m68k.
      CONFIG_MINIX_FS_NATIVE_ENDIAN is selected by the architectures which use
      native byte order bitmaps (h8300, microblaze, s390, sparc, m68knommu,
      m32r, mips, sh, xtensa).  The architectures which always use little-endian
      bitmaps do not select these options.
      
      Finally, we can remove minix bit operations from asm/bitops.h for all
      architectures.
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NGreg Ungerer <gerg@uclinux.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Andreas Schwab <schwab@linux-m68k.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NPaul Mundt <lethal@linux-sh.org>
      Cc: Chris Zankel <chris@zankel.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      61f2e7b0
    • A
      bitops: remove ext2 non-atomic bitops from asm/bitops.h · f312eff8
      Akinobu Mita 提交于
      As the result of conversions, there are no users of ext2 non-atomic bit
      operations except for ext2 filesystem itself.  Now we can put them into
      architecture independent code in ext2 filesystem, and remove from
      asm/bitops.h for all architectures.
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f312eff8
    • A
      powerpc: introduce little-endian bitops · f57d7ff1
      Akinobu Mita 提交于
      Introduce little-endian bit operations by renaming existing powerpc native
      little-endian bit operations and changing them to take any pointer types.
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      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>
      f57d7ff1
    • A
      asm-generic: change little-endian bitops to take any pointer types · a56560b3
      Akinobu Mita 提交于
      This makes the little-endian bitops take any pointer types by changing the
      prototypes and adding casts in the preprocessor macros.
      
      That would seem to at least make all the filesystem code happier, and they
      can continue to do just something like
      
        #define ext2_set_bit __test_and_set_bit_le
      
      (or whatever the exact sequence ends up being).
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Matthew Wilcox <willy@debian.org>
      Cc: Grant Grundler <grundler@parisc-linux.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a56560b3
    • A
      asm-generic: rename generic little-endian bitops functions · c4945b9e
      Akinobu Mita 提交于
      As a preparation for providing little-endian bitops for all architectures,
      This renames generic implementation of little-endian bitops.  (remove
      "generic_" prefix and postfix "_le")
      
      s/generic_find_next_le_bit/find_next_bit_le/
      s/generic_find_next_zero_le_bit/find_next_zero_bit_le/
      s/generic_find_first_zero_le_bit/find_first_zero_bit_le/
      s/generic___test_and_set_le_bit/__test_and_set_bit_le/
      s/generic___test_and_clear_le_bit/__test_and_clear_bit_le/
      s/generic_test_le_bit/test_bit_le/
      s/generic___set_le_bit/__set_bit_le/
      s/generic___clear_le_bit/__clear_bit_le/
      s/generic_test_and_set_le_bit/test_and_set_bit_le/
      s/generic_test_and_clear_le_bit/test_and_clear_bit_le/
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NHans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Andreas Schwab <schwab@linux-m68k.org>
      Cc: Greg Ungerer <gerg@uclinux.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c4945b9e
  8. 23 3月, 2011 2 次提交
  9. 21 3月, 2011 2 次提交
    • M
      powerpc/ptrace: Remove BUG_ON when full register set not available · a71f5d5d
      Mike Wolf 提交于
      In some cases during a threaded core dump not all the threads will have
      a full register set. This happens when the signal causing the core dump
      races with a thread exiting.  The race happens when the exiting thread
      has entered the kernel for the last time before the signal arrives, but
      doesn't get far enough through the exit code to avoid being included
      in the core dump.
      
      So we get a thread included in the core dump which is never going to go
      out to userspace again and only has a partial register set recorded
      
      Normally we would catch each thread as it is about to go into userspace
      and capture the full register set then.
      
      However, this exiting thread is never going to go out to userspace
      again, so we have no way to capture its full register set.  It doesn't
      really matter, though, as this is a thread which is effectively
      already dead.
      
      So instead of hitting a BUG() in this case (a really bad choice of
      action in the first place), we use a poison value for the register
      values.
      
      [BenH]: Some cosmetic/stylistic changes and fix build on ppc32
      Signed-off-by: NMike Wolf <mjw@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      a71f5d5d
    • M
      powerpc: Make MPIC honor the "pic-no-reset" device tree property · dfec2202
      Meador Inge 提交于
      This property, defined in the Open PIC binding, tells the kernel not to use
      the reset bit in the global configuration register.  Additionally, its
      presence mandates that only sources which are actually used (i.e. appear in
      the device tree) should have their VECPRI bits initialized.
      
      Although, "pic-no-reset" can be used for the same use cases that
      "protected-sources" is covering, the "protected-sources" implementation was
      left completely intact.  This is a more pragmatic approach as there are
      already several existing systems which use protected sources.  If
      "pic-no-reset" *and* "protected-sources" are both used, however, then
      "pic-no-reset" takes precedence in terms of the init behavior and the
      sanity checks done by protected sources will still take place.
      Signed-off-by: NMeador Inge <meador_inge@mentor.com>
      Cc: Hollis Blanchard <hollis_blanchard@mentor.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      dfec2202
  10. 16 3月, 2011 1 次提交
  11. 15 3月, 2011 1 次提交
    • L
      powerpc/85xx: Workaroudn e500 CPU erratum A005 · ac6f1203
      Liu Yu 提交于
      This erratum can occur if a single-precision floating-point,
      double-precision floating-point or vector floating-point instruction on a
      mispredicted branch path signals one of the floating-point data interrupts
      which are enabled by the SPEFSCR (FINVE, FDBZE, FUNFE or FOVFE bits).  This
      interrupt must be recorded in a one-cycle window when the misprediction is
      resolved.  If this extremely rare event should occur, the result could be:
      
      The SPE Data Exception from the mispredicted path may be reported
      erroneously if a single-precision floating-point, double-precision
      floating-point or vector floating-point instruction is the second
      instruction on the correct branch path.
      
      According to errata description, some efp instructions which are not
      supposed to trigger SPE exceptions can trigger the exceptions in this case.
      However, as we haven't emulated these instructions here, a signal will
      send to userspace, and userspace application would exit.
      
      This patch re-issue the efp instruction that we haven't emulated,
      so that hardware can properly execute it again if this case happen.
      Signed-off-by: NLiu Yu <yu.liu@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      ac6f1203