1. 21 11月, 2016 3 次提交
  2. 15 8月, 2016 1 次提交
  3. 15 2月, 2016 1 次提交
  4. 25 1月, 2016 1 次提交
  5. 09 6月, 2015 1 次提交
  6. 25 5月, 2015 1 次提交
  7. 07 11月, 2014 1 次提交
  8. 04 11月, 2014 1 次提交
  9. 28 5月, 2014 2 次提交
  10. 04 12月, 2013 1 次提交
  11. 12 3月, 2013 1 次提交
  12. 10 12月, 2011 1 次提交
    • H
      USB: cdc-acm: Fix potential deadlock (lockdep warning) · 7fb57a01
      Havard Skinnemoen 提交于
      Rework the locking and lifecycle management in the cdc-acm driver.
      Instead of using a global mutex to prevent the 'acm' object from being
      freed, use the tty_port kref to keep the device alive when either the
      USB side or TTY side is still active.
      
      This allows us to use the global mutex purely for protecting the
      acm_table, while use acm->mutex to guard against disconnect during
      TTY port activation and shutdown.
      
      The USB-side kref is taken during port initialization in probe(), and
      released at the end of disconnect(). The TTY-side kref is taken in
      install() and released in cleanup(). On disconnect, tty_vhangup() is
      called instead of tty_hangup() to ensure the TTY hangup processing is
      completed before the USB device is taken down.
      
      The TTY open and close handlers have been gutted and replaced with
      tty_port_open() and tty_port_close() respectively. The driver-specific
      code which used to be there was spread across install(), activate() and
      shutdown().
      Reported-by: NDave Jones <davej@redhat.com>
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Signed-off-by: NHavard Skinnemoen <hskinnemoen@google.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7fb57a01
  13. 12 5月, 2011 1 次提交
  14. 14 4月, 2011 2 次提交
  15. 31 3月, 2011 1 次提交
  16. 21 5月, 2010 1 次提交
  17. 03 3月, 2010 2 次提交
  18. 08 8月, 2009 1 次提交
  19. 16 6月, 2009 1 次提交
  20. 11 6月, 2009 2 次提交
  21. 14 8月, 2008 2 次提交
    • D
      usb: cdc-acm: drain writes on close · e5fbab51
      David Brownell 提交于
      Add a mechanism to let the write queue drain naturally before
      closing the TTY, rather than always losing that data.  There
      is a timeout, so it can't wait too long.
      
      Provide missing locking inside acm_wb_is_avail(); it matters
      more now.  Note, this presumes an earlier patch was applied,
      removing a call to this routine where the lock was held.
      
      Slightly improved diagnostics on write URB completion, so we
      can tell when a write URB gets killed and, if so, how much
      data it wrote first ... and so that I/O path is normally
      silent (and can't much change timings).
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e5fbab51
    • D
      usb: cdc-acm: stop dropping tx buffers · 934da463
      David Brownell 提交于
      The "increase cdc-acm write throughput" patch left in place two
      now-obsolete mechanisms, either of which can make the cdc-acm
      driver drop TX data (nasty!).  This patch removes them:
      
        - The write_ready flag ... if an URB and buffer were found,
          they can (and should!) always be used.
      
        - TX path acm_wb_is_used() ... used when the buffer was just
          allocated, so that check is pointless.
      
      Also fix a won't-yet-matter leak of a write buffer on a disconnect path.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Cc:  David Engraf <david.engraf@netcom.eu>
      Acked-by: NOliver Neukum <oneukum@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      934da463
  22. 22 7月, 2008 1 次提交
  23. 25 4月, 2008 1 次提交
  24. 02 2月, 2008 1 次提交
  25. 28 4月, 2007 1 次提交
  26. 22 6月, 2006 1 次提交
  27. 05 1月, 2006 1 次提交
  28. 28 6月, 2005 1 次提交
  29. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4