1. 22 9月, 2010 2 次提交
  2. 21 9月, 2010 1 次提交
  3. 13 9月, 2010 1 次提交
  4. 09 9月, 2010 1 次提交
  5. 24 8月, 2010 1 次提交
    • D
      sparc64: Get rid of indirect p1275 PROM call buffer. · 25edd694
      David S. Miller 提交于
      This is based upon a report by Meelis Roos showing that it's possible
      that we'll try to fetch a property that is 32K in size with some
      devices.  With the current fixed 3K buffer we use for moving data in
      and out of the firmware during PROM calls, that simply won't work.
      
      In fact, it will scramble random kernel data during bootup.
      
      The reasoning behind the temporary buffer is entirely historical.  It
      used to be the case that we had problems referencing dynamic kernel
      memory (including the stack) early in the boot process before we
      explicitly told the firwmare to switch us over to the kernel trap
      table.
      
      So what we did was always give the firmware buffers that were locked
      into the main kernel image.
      
      But we no longer have problems like that, so get rid of all of this
      indirect bounce buffering.
      
      Besides fixing Meelis's bug, this also makes the kernel data about 3K
      smaller.
      
      It was also discovered during these conversions that the
      implementation of prom_retain() was completely wrong, so that was
      fixed here as well.  Currently that interface is not in use.
      Reported-by: NMeelis Roos <mroos@linux.ee>
      Tested-by: NMeelis Roos <mroos@linux.ee>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      25edd694
  6. 20 8月, 2010 1 次提交
  7. 19 8月, 2010 2 次提交
  8. 18 8月, 2010 4 次提交
  9. 17 8月, 2010 2 次提交
    • D
      sparc: Hook up new fanotify and prlimit64 syscalls. · 8e8073a4
      David S. Miller 提交于
      The only tricky bit is the compat version of fanotify_mark, which
      which on 32-bit the 64-bit mark argument is passed in as "high32",
      "low32".
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8e8073a4
    • D
      sparc: Really fix "console=" for serial consoles. · 0a492896
      David S. Miller 提交于
      If a video head and keyboard are hooked up, specifying "console=ttyS0"
      or similar to use a serial console will not work properly.
      
      The key issue is that we must register all serial console capable
      devices with register_console(), otherwise the command line specified
      device won't be found.  The sun serial drivers would only register
      themselves as console devices if the OpenFirmware specified console
      device node matched.  To fix this part we now unconditionally get
      the serial console register by setting serial_drv->cons always.
      
      Secondarily we must not add_preferred_console() using the firmware
      provided console setting if the user gaven an override on the kernel
      command line using "console="  The "primary framebuffer" matching
      logic was always triggering o n openfirmware device node match, make
      it not when a command line override was given.
      Reported-by: NFrans Pop <elendil@planet.nl>
      Tested-by: NFrans Pop <elendil@planet.nl>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0a492896
  10. 15 8月, 2010 1 次提交
  11. 14 8月, 2010 1 次提交
  12. 11 8月, 2010 3 次提交
    • F
      dma-mapping: remove dma_is_consistent API · 3b9c6c11
      FUJITA Tomonori 提交于
      Architectures implement dma_is_consistent() in different ways (some
      misinterpret the definition of API in DMA-API.txt).  So it hasn't been so
      useful for drivers.  We have only one user of the API in tree.  Unlikely
      out-of-tree drivers use the API.
      
      Even if we fix dma_is_consistent() in some architectures, it doesn't look
      useful at all.  It was invented long ago for some old systems that can't
      allocate coherent memory at all.  It's better to export only APIs that are
      definitely necessary for drivers.
      
      Let's remove this API.
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3b9c6c11
    • F
      dma-mapping: unify dma_get_cache_alignment implementations · 4565f017
      FUJITA Tomonori 提交于
      dma_get_cache_alignment returns the minimum DMA alignment.  Architectures
      defines it as ARCH_DMA_MINALIGN (formally ARCH_KMALLOC_MINALIGN).  So we
      can unify dma_get_cache_alignment implementations.
      
      Note that some architectures implement dma_get_cache_alignment wrongly.
      dma_get_cache_alignment() should return the minimum DMA alignment.  So
      fully-coherent architectures should return 1.  This patch also fixes this
      issue.
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4565f017
    • H
      tty: Add EXTPROC support for LINEMODE · 26df6d13
      hyc@symas.com 提交于
      This patch is against the 2.6.34 source.
      
      Paraphrased from the 1989 BSD patch by David Borman @ cray.com:
      
           These are the changes needed for the kernel to support
           LINEMODE in the server.
      
           There is a new bit in the termios local flag word, EXTPROC.
           When this bit is set, several aspects of the terminal driver
           are disabled.  Input line editing, character echo, and mapping
           of signals are all disabled.  This allows the telnetd to turn
           off these functions when in linemode, but still keep track of
           what state the user wants the terminal to be in.
      
           New ioctl:
               TIOCSIG         Generate a signal to processes in the
                               current process group of the pty.
      
           There is a new mode for packet driver, the TIOCPKT_IOCTL bit.
           When packet mode is turned on in the pty, and the EXTPROC bit
           is set, then whenever the state of the pty is changed, the
           next read on the master side of the pty will have the TIOCPKT_IOCTL
           bit set.  This allows the process on the server side of the pty
           to know when the state of the terminal has changed; it can then
           issue the appropriate ioctl to retrieve the new state.
      
      Since the original BSD patches accompanied the source code for telnet
      I've left that reference here, but obviously the feature is useful for
      any remote terminal protocol, including ssh.
      
      The corresponding feature has existed in the BSD tty driver since 1989.
      For historical reference, a good copy of the relevant files can be found
      here:
      
      http://anonsvn.mit.edu/viewvc/krb5/trunk/src/appl/telnet/?pathrev=17741Signed-off-by: NHoward Chu <hyc@symas.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      26df6d13
  13. 10 8月, 2010 1 次提交
    • C
      kmap_atomic: make kunmap_atomic() harder to misuse · 597781f3
      Cesar Eduardo Barros 提交于
      kunmap_atomic() is currently at level -4 on Rusty's "Hard To Misuse"
      list[1] ("Follow common convention and you'll get it wrong"), except in
      some architectures when CONFIG_DEBUG_HIGHMEM is set[2][3].
      
      kunmap() takes a pointer to a struct page; kunmap_atomic(), however, takes
      takes a pointer to within the page itself.  This seems to once in a while
      trip people up (the convention they are following is the one from
      kunmap()).
      
      Make it much harder to misuse, by moving it to level 9 on Rusty's list[4]
      ("The compiler/linker won't let you get it wrong").  This is done by
      refusing to build if the type of its first argument is a pointer to a
      struct page.
      
      The real kunmap_atomic() is renamed to kunmap_atomic_notypecheck()
      (which is what you would call in case for some strange reason calling it
      with a pointer to a struct page is not incorrect in your code).
      
      The previous version of this patch was compile tested on x86-64.
      
      [1] http://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html
      [2] In these cases, it is at level 5, "Do it right or it will always
          break at runtime."
      [3] At least mips and powerpc look very similar, and sparc also seems to
          share a common ancestor with both; there seems to be quite some
          degree of copy-and-paste coding here. The include/asm/highmem.h file
          for these three archs mention x86 CPUs at its top.
      [4] http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html
      [5] As an aside, could someone tell me why mn10300 uses unsigned long as
          the first parameter of kunmap_atomic() instead of void *?
      Signed-off-by: NCesar Eduardo Barros <cesarb@cesarb.net>
      Cc: Russell King <linux@arm.linux.org.uk> (arch/arm)
      Cc: Ralf Baechle <ralf@linux-mips.org> (arch/mips)
      Cc: David Howells <dhowells@redhat.com> (arch/frv, arch/mn10300)
      Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com> (arch/mn10300)
      Cc: Kyle McMartin <kyle@mcmartin.ca> (arch/parisc)
      Cc: Helge Deller <deller@gmx.de> (arch/parisc)
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> (arch/parisc)
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> (arch/powerpc)
      Cc: Paul Mackerras <paulus@samba.org> (arch/powerpc)
      Cc: "David S. Miller" <davem@davemloft.net> (arch/sparc)
      Cc: Thomas Gleixner <tglx@linutronix.de> (arch/x86)
      Cc: Ingo Molnar <mingo@redhat.com> (arch/x86)
      Cc: "H. Peter Anvin" <hpa@zytor.com> (arch/x86)
      Cc: Arnd Bergmann <arnd@arndb.de> (include/asm-generic)
      Cc: Rusty Russell <rusty@rustcorp.com.au> ("Hard To Misuse" list)
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      597781f3
  14. 09 8月, 2010 4 次提交
  15. 08 8月, 2010 1 次提交
  16. 03 8月, 2010 1 次提交
    • J
      arch/sparc/mm: Use GFP_KERNEL · 71cd03b0
      Julia Lawall 提交于
      GFP_ATOMIC is not needed here, as evidenced by the other two uses of
      GFP_KERNEL in the same function.
      
      The semantic match that finds this problem is as follows:
      (http://coccinelle.lip6.fr/)
      
      // <smpl>
      @@ identifier f; @@
      
      *f(...,GFP_ATOMIC,...)
      ... when != spin_unlock(...)
          when != read_unlock(...)
          when != write_unlock(...)
          when != read_unlock_irq(...)
          when != write_unlock_irq(...)
          when != read_unlock_irqrestore(...)
          when != write_unlock_irqrestore(...)
          when != spin_unlock_irq(...)
          when != spin_unlock_irqrestore(...)
      *f(...,GFP_KERNEL,...)
      // </smpl>
      Signed-off-by: NJulia Lawall <julia@diku.dk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      71cd03b0
  17. 30 7月, 2010 1 次提交
  18. 27 7月, 2010 1 次提交
  19. 24 7月, 2010 7 次提交
  20. 15 7月, 2010 1 次提交
  21. 14 7月, 2010 1 次提交
  22. 06 7月, 2010 2 次提交