1. 11 6月, 2009 2 次提交
  2. 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
  3. 22 7月, 2008 1 次提交
  4. 25 4月, 2008 1 次提交
  5. 02 2月, 2008 1 次提交
  6. 28 4月, 2007 1 次提交
  7. 22 6月, 2006 1 次提交
  8. 05 1月, 2006 1 次提交
  9. 28 6月, 2005 1 次提交
  10. 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