1. 31 Jul, 2013 1 commit
    • Julius Werner's avatar
      usb: core: don't try to reset_device() a port that got just disconnected · 481f2d4f
      Julius Werner authored
      The USB hub driver's event handler contains a check to catch SuperSpeed
      devices that transitioned into the SS.Inactive state and tries to fix
      them with a reset. It decides whether to do a plain hub port reset or
      call the usb_reset_device() function based on whether there was a device
      attached to the port.
      
      However, there are device/hub combinations (found with a JetFlash
      Transcend mass storage stick (8564:1000) on the root hub of an Intel
      LynxPoint PCH) which can transition to the SS.Inactive state on
      disconnect (and stay there long enough for the host to notice). In this
      case, above-mentioned reset check will call usb_reset_device() on the
      stale device data structure. The kernel will send pointless LPM control
      messages to the no longer connected device address and can even cause
      several 5 second khubd stalls on some (buggy?) host controllers, before
      finally accepting the device's fate amongst a flurry of error messages.
      
      This patch makes the choice of reset dependent on the port status that
      has just been read from the hub in addition to the existence of an
      in-kernel data structure for the device, and only proceeds with the more
      extensive reset if both are valid.
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      481f2d4f
  2. 29 Jul, 2013 7 commits
  3. 28 Jul, 2013 1 commit
  4. 26 Jul, 2013 4 commits
  5. 25 Jul, 2013 15 commits
  6. 24 Jul, 2013 1 commit
  7. 23 Jul, 2013 2 commits
    • Bjørn Mork's avatar
      usb: option: add TP-LINK MA260 · 94190301
      Bjørn Mork authored
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      94190301
    • Alexandr \"Sky\" Ivanov's avatar
      USB: option: add D-Link DWM-152/C1 and DWM-156/C1 · ca247635
      Alexandr \"Sky\" Ivanov authored
      Adding support for D-Link DWM-152/C1 and DWM-156/C1 devices.
      
      DWM-152/C1:
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=07d1 ProdID=3e01 Rev= 0.00
      S:  Product=USB Configuration
      S:  SerialNumber=1234567890ABCDEF
      C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
      E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      
      DWM-156/C1:
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  8 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=07d1 ProdID=3e02 Rev= 0.00
      S:  Product=DataCard Device
      S:  SerialNumber=1234567890ABCDEF
      C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
      E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      Signed-off-by: default avatarAlexandr Ivanov <alexandr.sky@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ca247635
  8. 22 Jul, 2013 7 commits
  9. 17 Jul, 2013 1 commit
  10. 16 Jul, 2013 1 commit
    • Alan Stern's avatar
      USB: global suspend and remote wakeup don't mix · e583d9db
      Alan Stern authored
      The hub driver was recently changed to use "global" suspend for system
      suspend transitions on non-SuperSpeed buses.  This means that we don't
      suspend devices individually by setting the suspend feature on the
      upstream hub port; instead devices all go into suspend automatically
      when the root hub stops transmitting packets.  The idea was to save
      time and to avoid certain kinds of wakeup races.
      
      Now it turns out that many hubs are buggy; they don't relay wakeup
      requests from a downstream port to their upstream port if the
      downstream port's suspend feature is not set (depending on the speed
      of the downstream port, whether or not the hub is enabled for remote
      wakeup, and possibly other factors).
      
      We can't have hubs dropping wakeup requests.  Therefore this patch
      goes partway back to the old policy: It sets the suspend feature for a
      port if the device attached to that port or any of its descendants is
      enabled for wakeup.  People will still be able to benefit from the
      time savings if they don't care about wakeup and leave it disabled on
      all their devices.
      
      In order to accomplish this, the patch adds a new field to the usb_hub
      structure: wakeup_enabled_descendants is a count of how many devices
      below a suspended hub are enabled for remote wakeup.  A corresponding
      new subroutine determines the number of wakeup-enabled devices at or
      below an arbitrary suspended USB device.
      
      This should be applied to the 3.10 stable kernel.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: default avatarToralf Förster <toralf.foerster@gmx.de>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e583d9db