1. 28 2月, 2009 2 次提交
  2. 10 2月, 2009 1 次提交
  3. 28 1月, 2009 4 次提交
  4. 08 1月, 2009 2 次提交
    • A
      USB: Enhance usage of pm_message_t · 65bfd296
      Alan Stern 提交于
      This patch (as1177) modifies the USB core suspend and resume
      routines.  The resume functions now will take a pm_message_t argument,
      so they will know what sort of resume is occurring.  The new argument
      is also passed to the port suspend/resume and bus suspend/resume
      routines (although they don't use it for anything but debugging).
      
      In addition, special pm_message_t values are used for user-initiated,
      device-initiated (i.e., remote wakeup), and automatic suspend/resume.
      By testing these values, drivers can tell whether or not a particular
      suspend was an autosuspend.  Unfortunately, they can't do the same for
      resumes -- not until the pm_message_t argument is also passed to the
      drivers' resume methods.  That will require a bigger change.
      
      IMO, the whole Power Management framework should have been set up this
      way in the first place.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      65bfd296
    • I
      USB: usbtmc: indent & braces disagree, something else is desired · 857cc4df
      Ilpo Järvinen 提交于
      It seems that there's rather involved way to say something
      which is commonly written in a plain simple form.
      
      Some type changes would probably be necessary to get gcc
      to do bitops instead of divide but it's no worse after my
      change than before I think.
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      857cc4df
  5. 18 12月, 2008 1 次提交
  6. 14 11月, 2008 1 次提交
    • B
      USB: cdc-acm.c: fix recursive lock in acm_start_wb error path · ad0b65ef
      Brandon Philips 提交于
      Fixes an obvious bug in cdc-acm by avoiding a recursive lock on
      acm_start_wb()'s error path. Should apply towards 2.6.27 stable and
      2.6.28.
      
      =============================================
      [ INFO: possible recursive locking detected ]
      2.6.27-2-pae #109
      ---------------------------------------------
      python/31449 is trying to acquire lock:
       (&acm->write_lock){++..}, at: [<f89a0348>] acm_start_wb+0x5c/0x7b [cdc_acm]
      
      but task is already holding lock:
       (&acm->write_lock){++..}, at: [<f89a04fb>] acm_tty_write+0xe1/0x167 [cdc_acm]
      
      other info that might help us debug this:
      2 locks held by python/31449:
       #0:  (&tty->atomic_write_lock){--..}, at: [<c0260fae>] tty_write_lock+0x14/0x3b
       #1:  (&acm->write_lock){++..}, at: [<f89a04fb>] acm_tty_write+0xe1/0x167 [cdc_acm]
      
      stack backtrace:
      Pid: 31449, comm: python Not tainted 2.6.27-2-pae #109
       [<c030f42f>] ? printk+0xf/0x18
       [<c0149f33>] __lock_acquire+0xc7b/0x1316
       [<c014a63e>] lock_acquire+0x70/0x97
       [<f89a0348>] ? acm_start_wb+0x5c/0x7b [cdc_acm]
       [<c0312109>] _spin_lock_irqsave+0x37/0x47
       [<f89a0348>] ? acm_start_wb+0x5c/0x7b [cdc_acm]
       [<f89a0348>] acm_start_wb+0x5c/0x7b [cdc_acm]
       [<f89a055d>] acm_tty_write+0x143/0x167 [cdc_acm]
       [<c0262a98>] write_chan+0x1cd/0x297
       [<c012527e>] ? default_wake_function+0x0/0xd
       [<c026111e>] tty_write+0x149/0x1b9
       [<c02628cb>] ? write_chan+0x0/0x297
       [<c01912c5>] ? rw_verify_area+0x76/0x98
       [<c0260fd5>] ? tty_write+0x0/0x1b9
       [<c01919ba>] vfs_write+0x8c/0x136
       [<c0191afd>] sys_write+0x3b/0x60
       [<c0103beb>] sysenter_do_call+0x12/0x3f
       =======================
      Signed-off-by: NBrandon Philips <bphilips@suse.de>
      Cc: Oliver Neukum <oliver@neukum.org>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ad0b65ef
  7. 30 10月, 2008 1 次提交
  8. 23 10月, 2008 2 次提交
  9. 18 10月, 2008 4 次提交
  10. 22 8月, 2008 2 次提交
  11. 14 8月, 2008 4 次提交
  12. 23 7月, 2008 1 次提交
  13. 22 7月, 2008 5 次提交
  14. 04 7月, 2008 1 次提交
  15. 04 6月, 2008 1 次提交
  16. 21 5月, 2008 1 次提交
  17. 15 5月, 2008 1 次提交
  18. 29 4月, 2008 1 次提交
  19. 25 4月, 2008 5 次提交