1. 17 Jul, 2014 1 commit
  2. 23 May, 2014 1 commit
    • Alan Stern's avatar
      USB: Avoid runtime suspend loops for HCDs that can't handle suspend/resume · 8ef42ddd
      Alan Stern authored
      Not all host controller drivers have bus-suspend and bus-resume
      methods.  When one doesn't, it will cause problems if runtime PM is
      enabled in the kernel.  The PM core will attempt to suspend the
      controller's root hub, the suspend will fail because there is no
      bus-suspend routine, and a -EBUSY error code will be returned to the
      PM core.  This will cause the suspend attempt to be repeated shortly
      thereafter, in a never-ending loop.
      Part of the problem is that the original error code -ENOENT gets
      changed to -EBUSY in usb_runtime_suspend(), on the grounds that the PM
      core will interpret -ENOENT as meaning that the root hub has gotten
      into a runtime-PM error state.  While this change is appropriate for
      real USB devices, it's not such a good idea for a root hub.  In fact,
      considering the root hub to be in a runtime-PM error state would not
      be far from the truth.  Therefore this patch updates
      usb_runtime_suspend() so that it adjusts error codes only for
      non-root-hub devices.
      Furthermore, the patch attempts to prevent the problem from occurring
      in the first place by not enabling runtime PM by default for root hubs
      whose host controller driver doesn't have bus_suspend and bus_resume
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarWill Deacon <will.deacon@arm.com>
      Tested-by: default avatarWill Deacon <will.deacon@arm.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  3. 17 Mar, 2014 1 commit
    • Alan Stern's avatar
      USB: unbind all interfaces before rebinding any · 6aec044c
      Alan Stern authored
      When a driver doesn't have pre_reset, post_reset, or reset_resume
      methods, the USB core unbinds that driver when its device undergoes a
      reset or a reset-resume, and then rebinds it afterward.
      The existing straightforward implementation can lead to problems,
      because each interface gets unbound and rebound before the next
      interface is handled.  If a driver claims additional interfaces, the
      claim may fail because the old binding instance may still own the
      additional interface when the new instance tries to claim it.
      This patch fixes the problem by first unbinding all the interfaces
      that are marked (i.e., their needs_binding flag is set) and then
      rebinding all of them.
      The patch also makes the helper functions in driver.c a little more
      uniform and adjusts some out-of-date comments.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: default avatar"Poulain, Loic" <loic.poulain@intel.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  4. 04 Mar, 2014 1 commit
  5. 07 Feb, 2014 1 commit
  6. 05 Feb, 2014 1 commit
  7. 13 Jan, 2014 1 commit
  8. 12 Jan, 2014 1 commit
  9. 10 Jan, 2014 2 commits
  10. 03 Dec, 2013 1 commit
  11. 19 Oct, 2013 1 commit
  12. 16 Oct, 2013 1 commit
    • Sarah Sharp's avatar
      usb: Don't enable USB 2.0 Link PM by default. · de68bab4
      Sarah Sharp authored
      How it's supposed to work:
      USB 2.0 Link PM is a lower power state that some newer USB 2.0 devices
      support.  USB 3.0 devices certified by the USB-IF are required to
      support it if they are plugged into a USB 2.0 only port, or a USB 2.0
      cable is used.  USB 2.0 Link PM requires both a USB device and a host
      controller that supports USB 2.0 hardware-enabled LPM.
      USB 2.0 Link PM is designed to be enabled once by software, and the host
      hardware handles transitions to the L1 state automatically.  The premise
      of USB 2.0 Link PM is to be able to put the device into a lower power
      link state when the bus is idle or the device NAKs USB IN transfers for
      a specified amount of time.
      ...but hardware is broken:
      It turns out many USB 3.0 devices claim to support USB 2.0 Link PM (by
      setting the LPM bit in their USB 2.0 BOS descriptor), but they don't
      actually implement it correctly.  This manifests as the USB device
      refusing to respond to transfers when it is plugged into a USB 2.0 only
      port under the Haswell-ULT/Lynx Point LP xHCI host.
      These devices pass the xHCI driver's simple test to enable USB 2.0 Link
      PM, wait for the port to enter L1, and then bring it back into L0.  They
      only start to break when L1 entry is interleaved with transfers.
      Some devices then fail to respond to the next control transfer (usually
      a Set Configuration).  This results in devices never enumerating.
      Other mass storage devices (such as a later model Western Digital My
      Passport USB 3.0 hard drive) respond fine to going into L1 between
      control transfers.  They ACK the entry, come out of L1 when the host
      needs to send a control transfer, and respond properly to those control
      transfers.  However, when the first READ10 SCSI command is sent, the
      device NAKs the data phase while it's reading from the spinning disk.
      Eventually, the host requests to put the link into L1, and the device
      ACKs that request.  Then it never responds to the data phase of the
      READ10 command.  This results in not being able to read from the drive.
      Some mass storage devices (like the Corsair Survivor USB 3.0 flash
      drive) are well behaved.  They ACK the entry into L1 during control
      transfers, and when SCSI commands start coming in, they NAK the requests
      to go into L1, because they need to be at full power.
      Not all USB 3.0 devices advertise USB 2.0 link PM support.  My Point
      Grey USB 3.0 webcam advertises itself as a USB 2.1 device, but doesn't
      have a USB 2.0 BOS descriptor, so we don't enable USB 2.0 Link PM.  I
      suspect that means the device isn't certified.
      What do we do about it?
      There's really no good way for the kernel to test these devices.
      Therefore, the kernel needs to disable USB 2.0 Link PM by default, and
      distros will have to enable it by writing 1 to the sysfs file
      /sys/bus/usb/devices/../power/usb2_hardware_lpm.  Rip out the xHCI Link
      PM test, since it's not sufficient to detect these buggy devices, and
      don't automatically enable LPM after the device is addressed.
      This patch should be backported to kernels as old as 3.11, that
      contain the commit a558ccdc
       "usb: xhci:
      add USB2 Link power management BESL support".  Without this fix, some
      USB 3.0 devices will not enumerate or work properly under USB 2.0 ports
      on Haswell-ULT systems.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
  13. 23 Aug, 2013 1 commit
  14. 02 Aug, 2013 1 commit
  15. 03 Jun, 2013 1 commit
  16. 01 Apr, 2013 1 commit
  17. 28 Mar, 2013 1 commit
    • Alan Stern's avatar
      USB: remove CONFIG_USB_SUSPEND option · 84ebc102
      Alan Stern authored
      This patch (as1675) removes the CONFIG_USB_SUSPEND option, essentially
      replacing it everywhere with CONFIG_PM_RUNTIME (except for one place
      in hub.c, where it is replaced with CONFIG_PM because the code needs
      to be used in both runtime and system PM).  The net result is code
      shrinkage and simplification.
      There's very little point in keeping CONFIG_USB_SUSPEND because almost
      everybody enables it.  The few that don't will find that the usbcore
      module has gotten somewhat bigger and they will have to take active
      measures if they want to prevent hubs from being runtime suspended.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      CC: Peter Chen <peter.chen@freescale.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  18. 25 Mar, 2013 1 commit
  19. 21 Nov, 2012 1 commit
  20. 19 Nov, 2012 1 commit
  21. 08 Oct, 2012 1 commit
    • Sarah Sharp's avatar
      USB: Enable LPM after a failed probe. · d01f87c0
      Sarah Sharp authored
      Before a driver is probed, we want to disable USB 3.0 Link Power
      Management (LPM), in case the driver needs hub-initiated LPM disabled.
      After the probe finishes, we want to attempt to re-enable LPM, order to
      balance the LPM ref count.
      When a probe fails (such as when libusual doesn't want to bind to a USB
      3.0 mass storage device), make sure to balance the LPM ref counts by
      re-enabling LPM.
      This patch should be backported to kernels as old as 3.5, that contain
      the commit 8306095f
       "USB: Disable USB
      3.0 LPM in critical sections."
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
  22. 17 Sep, 2012 1 commit
  23. 19 Jul, 2012 1 commit
  24. 13 Jun, 2012 2 commits
    • Hans de Goede's avatar
      usb-core: Set intfdata to NULL if a driver's probe method failed · e714fad0
      Hans de Goede authored
      Ensure that intfdata always is NULL if no driver is bound:
      1) drvdata is for a driver to store a pointer to driver specific data
      2) If no driver is bound, there is no driver specific data associated with
         the device
      3) Thus logically drvdata should be NULL if no driver is bound.
      We already set intfdata to NULL when a driver is unbound, to ensure that
      intfdata will be NULL even if the drivers disconnect method does not properly
      clear it. This ensures that intfdata will also be NULL after a failed probe,
      even if the driver's probe method left a (likely dangling) pointer in there.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Bjørn Mork's avatar
      USB: allow match on bInterfaceNumber · 81df2d59
      Bjørn Mork authored
      Some composite USB devices provide multiple interfaces
      with different functions, all using "vendor-specific"
      for class/subclass/protocol.  Another OS use interface
      numbers to match the driver and interface. It seems
      these devices are designed with that in mind - using
      static interface numbers for the different functions.
      This adds support for matching against the
      bInterfaceNumber, allowing such devices to be supported
      without having to resort to testing against interface
      number whitelists and/or blacklists in the probe.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  25. 18 May, 2012 1 commit
    • Sarah Sharp's avatar
      USB: Disable USB 3.0 LPM in critical sections. · 8306095f
      Sarah Sharp authored
      There are several places where the USB core needs to disable USB 3.0
      Link PM:
       - usb_bind_interface
       - usb_unbind_interface
       - usb_driver_claim_interface
       - usb_port_suspend/usb_port_resume
       - usb_reset_and_verify_device
       - usb_set_interface
       - usb_reset_configuration
       - usb_set_configuration
      Use the new LPM disable/enable functions to temporarily disable LPM
      around these critical sections.
      We need to protect the critical section around binding and unbinding USB
      interface drivers.  USB drivers may want to disable hub-initiated USB
      3.0 LPM, which will change the value of the U1/U2 timeouts that the xHCI
      driver will install.  We need to disable LPM completely until the driver
      is bound to the interface, and the driver has a chance to enable
      whatever alternate interface setting it needs in its probe routine.
      Then re-enable USB3 LPM, and recalculate the U1/U2 timeout values.
      We also need to disable LPM in usb_driver_claim_interface,
      because drivers like usbfs can bind to an interface through that
      function.  Note, there is no way currently for userspace drivers to
      disable hub-initiated USB 3.0 LPM.  Revisit this later.
      When a driver is unbound, the U1/U2 timeouts may change because we are
      unbinding the last driver that needed hub-initiated USB 3.0 LPM to be
      USB LPM must be disabled when a USB device is going to be suspended.
      The USB 3.0 spec does not define a state transition from U1 or U2 into
      U3, so we need to bring the device into U0 by disabling LPM before we
      can place it into U3.  Therefore, call usb_unlocked_disable_lpm() in
      usb_port_suspend(), and call usb_unlocked_enable_lpm() in
      usb_port_resume().  If the port suspend fails, make sure to re-enable
      LPM by calling usb_unlocked_enable_lpm(), since usb_port_resume() will
      not be called on a failed port suspend.
      USB 3.0 devices lose their USB 3.0 LPM settings (including whether USB
      device-initiated LPM is enabled) across device suspend.  Therefore,
      disable LPM before the device will be reset in
      usb_reset_and_verify_device(), and re-enable LPM after the reset is
      complete and the configuration/alt settings are re-installed.
      The calculated U1/U2 timeout values are heavily dependent on what USB
      device endpoints are currently enabled.  When any of the enabled
      endpoints on the device might change, due to a new configuration, or new
      alternate interface setting, we need to first disable USB 3.0 LPM, add
      or delete endpoints from the xHCI schedule, install the new interfaces
      and alt settings, and then re-enable LPM.  Do this in usb_set_interface,
      usb_reset_configuration, and usb_set_configuration.
      Basically, there is a call to disable and then enable LPM in all
      functions that lock the bandwidth_mutex.  One exception is
      usb_disable_device, because the device is disconnecting or otherwise
      going away, and we should not care about whether USB 3.0 LPM is enabled.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
  26. 14 May, 2012 2 commits
  27. 29 Apr, 2012 1 commit
  28. 09 Apr, 2012 1 commit
    • Alan Stern's avatar
      USB: don't ignore suspend errors for root hubs · cd4376e2
      Alan Stern authored
      This patch (as1532) fixes a mistake in the USB suspend code.  When the
      system is going to sleep, we should ignore errors in powering down USB
      devices, because they don't really matter.  The devices will go to low
      power anyway when the entire USB bus gets suspended (except for
      SuperSpeed devices; maybe they will need special treatment later).
      However we should not ignore errors in suspending root hubs,
      especially if the error indicates that the suspend raced with a wakeup
      request.  Doing so might leave the bus powered on while the system was
      supposed to be asleep, or it might cause the suspend of the root hub's
      parent controller device to fail, or it might cause a wakeup request
      to be ignored.
      The patch fixes the problem by ignoring errors only when the device in
      question is not a root hub.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarChen Peter <B29397@freescale.com>
      CC: <stable@vger.kernel.org>
      Tested-by: default avatarChen Peter <peter.chen@freescale.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  29. 26 Jan, 2012 1 commit
  30. 24 Jan, 2012 3 commits
  31. 03 Jan, 2012 1 commit
  32. 15 Nov, 2011 1 commit
  33. 04 Nov, 2011 1 commit
    • Alan Stern's avatar
      USB: Update last_busy time after autosuspend fails · b2c0a863
      Alan Stern authored
      Originally, the runtime PM core would send an idle notification
      whenever a suspend attempt failed.  The idle callback routine could
      then schedule a delayed suspend for some time later.
      However this behavior was changed by commit
       (PM / Runtime: Remove idle
      notification after failing suspend).  No notifications were sent, and
      there was no clear mechanism to retry failed suspends.
      This caused problems for the usbhid driver, because it fails
      autosuspend attempts as long as a key is being held down.  A companion
      patch changes the PM core's behavior, but we also need to change the
      USB core.  In particular, this patch (as1493) updates the device's
      last_busy time when an autosuspend fails, so that the PM core will
      retry the autosuspend in the future when the delay time expires
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Tested-by: default avatarHenrik Rydberg <rydberg@euromail.se>
      Cc: <stable@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
  34. 31 Oct, 2011 1 commit
  35. 26 Sep, 2011 1 commit