1. 25 Oct, 2012 3 commits
    • Ming Lei's avatar
      USB: check port changes before hub runtime suspend for some bug device · e6f30dea
      Ming Lei authored
      The hub status endpoint has a long 'bInterval', which is 255ms
      for FS/LS device and 256ms for HS device according to USB 2.0 spec,
      so the device connection change may be reported later more than 255ms
      via status pipe.
      
      The connection change in hub may have been happened already on the
      downstream ports, but no status URB completes when it is killed
      in hub_suspend(auto), so the connection change may be missed by some
      buggy hub devices, which won't generate remote wakeup signal after
      their remote wakeup is enabled and they are put into suspend state.
      
      The problem can be observed at least on the below Genesys Logic, Inc.
      hub devices:
      
      	0x05e3,0x0606
      	0x05e3,0x0608
      
      In theory, there is no way to fix the problem completely, but we
      can make it less likely to occur by this patch.
      
      This patch introduces one quirk of HUB_QUIRK_CHECK_PORTS_AUTOSUSPEND
      to check ports' change during hub_suspend(auto) for the buggy
      devices. If ports' change is found, terminate the auto suspend and
      return to working state.
      
      So for the buggy hubs, if the connection change happend before
      the ports' check, it can be handled correctly. If it happens between
      the ports' check and enabling remote wakeup/entering suspend, it
      will be missed. Considered the interval is quite short, it is very
      less likely to happen during the window.
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarMing Lei <ming.lei@canonical.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e6f30dea
    • Claudio Scordino's avatar
      umc-bus.c: fix usage of device_trylock · b717727e
      Claudio Scordino authored
      Fix usage of device_trylock. It has the same semantics of mutex_trylock, so it
      returns 1 if the lock has been acquired successfully.
      Signed-off-by: default avatarClaudio Scordino <claudio@evidence.eu.com>
      Signed-off-by: default avatarBruno Morelli <bruno@evidence.eu.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b717727e
    • Jarkko Huijts's avatar
      usb: serial: ftdi_sio: Add missing chars_in_buffer function · 6f602912
      Jarkko Huijts authored
      The driver does not wait until the hardware buffer (for data from the PC to the
      UART line) is drained when tcdrain or close is called in an application.
      Solution: Implement a chars_in_buffer function that checks both the software
      and hardware buffer. If the TEMT (TX empty) bit of the line status register
      indicates the hw buffer is not empty, let the function return at least 1. This
      has been verified to work correctly with an FT232RL. The check on the hw buffer
      can not be done for the original SIO device.
      Signed-off-by: default avatarJarkko Huijts <jarkko.huijts@gmail.com>
      Acked-by: default avatarAlan Cox <alan@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f602912
  2. 24 Oct, 2012 16 commits
  3. 23 Oct, 2012 2 commits
  4. 22 Oct, 2012 19 commits