1. 23 8月, 2008 1 次提交
  2. 21 7月, 2008 1 次提交
    • A
      tty: Ldisc revamp · a352def2
      Alan Cox 提交于
      Move the line disciplines towards a conventional ->ops arrangement.  For
      the moment the actual 'tty_ldisc' struct in the tty is kept as part of
      the tty struct but this can then be changed if it turns out that when it
      all settles down we want to refcount ldiscs separately to the tty.
      
      Pull the ldisc code out of /proc and put it with our ldisc code.
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a352def2
  3. 15 7月, 2008 1 次提交
  4. 10 7月, 2008 1 次提交
  5. 03 7月, 2008 1 次提交
  6. 21 6月, 2008 1 次提交
  7. 11 6月, 2008 1 次提交
  8. 03 5月, 2008 1 次提交
  9. 30 4月, 2008 2 次提交
  10. 20 4月, 2008 2 次提交
  11. 08 3月, 2008 1 次提交
  12. 06 3月, 2008 1 次提交
  13. 13 2月, 2008 1 次提交
    • D
      hci_ldisc: fix null pointer deref · 3611f4d2
      David Newall 提交于
      Arjan:
      
        With the help of kerneloops.org I've spotted a nice little interaction
        between the TTY layer and the bluetooth code, however the tty layer is not
        something I'm all too familiar with so I rather ask than brute-force fix the
        code incorrectly.
      
        The raw details are at:
        http://www.kerneloops.org/search.php?search=uart_flush_buffer
      
        What happens is that, on closing the bluetooth tty, the tty layer goes
        into the release_dev() function, which first does a bunch of stuff, then
        sets the file->private_data to NULL, does some more stuff and then calls the
        ldisc close function.  Which in this case, is hci_uart_tty_close().
      
        Now, hci_uart_tty_close() calls hci_uart_close() which clears some
        internal bit, and then calls hci_uart_flush()...  which calls back to the
        tty layers' uart_flush_buffer() function.  (in drivers/bluetooth/hci_tty.c
        around line 194) Which then WARN_ON()'s because that's not allowed/supposed
        to be called this late in the shutdown of the port....
      
        Should the bluetooth driver even call this flush function at all??
      
      David:
      
        This seems to be what happens: Hci_uart_close() flushes using
        hci_uart_flush().  Subsequently, in hci_dev_do_close(), (one step in
        hci_unregister_dev()), hci_uart_flush() is called again.  The comment in
        uart_flush_buffer(), relating to the WARN_ON(), indicates you can't flush
        after the port is closed; which sounds reasonable.  I think hci_uart_close()
        should set hdev->flush to NULL before returning.  Hci_dev_do_close() does
        check for this.  The code path is rather involved and I'm not entirely clear
        of all steps, but I think that's what should be done.
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3611f4d2
  14. 06 2月, 2008 1 次提交
  15. 05 2月, 2008 3 次提交
  16. 03 2月, 2008 1 次提交
  17. 11 1月, 2008 1 次提交
  18. 22 10月, 2007 6 次提交
  19. 09 9月, 2007 1 次提交
  20. 11 7月, 2007 2 次提交
  21. 24 5月, 2007 1 次提交
  22. 11 5月, 2007 3 次提交
  23. 05 5月, 2007 2 次提交
  24. 26 4月, 2007 2 次提交
  25. 27 2月, 2007 1 次提交
  26. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
      recently, it makes sense again to remove other superfluous sched.h includes.
      There are quite a lot of files which include it but don't actually need
      anything defined in there.  Presumably these includes were once needed for
      macros that used to live in sched.h, but moved to other header files in the
      course of cleaning it up.
      
      To ease the pain, this time I did not fiddle with any header files and only
      removed #includes from .c-files, which tend to cause less trouble.
      
      Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
      arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
      allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
      configs in arch/arm/configs on arm.  I also checked that no new warnings were
      introduced by the patch (actually, some warnings are removed that were emitted
      by unnecessarily included header files).
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a