1. 09 10月, 2012 1 次提交
    • S
      USB: Enable LPM after a failed probe. · d01f87c0
      Sarah Sharp 提交于
      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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      d01f87c0
  2. 28 9月, 2012 1 次提交
    • A
      USB: Fix race condition when removing host controllers · 0d00dc26
      Alan Stern 提交于
      This patch (as1607) fixes a race that can occur if a USB host
      controller is removed while a process is reading the
      /sys/kernel/debug/usb/devices file.
      
      The usb_device_read() routine uses the bus->root_hub pointer to
      determine whether or not the root hub is registered.  The is not a
      valid test, because the pointer is set before the root hub gets
      registered and remains set even after the root hub is unregistered and
      deallocated.  As a result, usb_device_read() or usb_device_dump() can
      access freed memory, causing an oops.
      
      The patch changes the test to use the hcd->rh_registered flag, which
      does get set and cleared at the appropriate times.  It also makes sure
      to hold the usb_bus_list_lock mutex while setting the flag, so that
      usb_device_read() will become aware of new root hubs as soon as they
      are registered.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NDon Zickus <dzickus@redhat.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0d00dc26
  3. 27 9月, 2012 1 次提交
    • A
      USB: Fix race condition when removing host controllers · 0a231403
      Alan Stern 提交于
      This patch (as1607) fixes a race that can occur if a USB host
      controller is removed while a process is reading the
      /sys/kernel/debug/usb/devices file.
      
      The usb_device_read() routine uses the bus->root_hub pointer to
      determine whether or not the root hub is registered.  The is not a
      valid test, because the pointer is set before the root hub gets
      registered and remains set even after the root hub is unregistered and
      deallocated.  As a result, usb_device_read() or usb_device_dump() can
      access freed memory, causing an oops.
      
      The patch changes the test to use the hcd->rh_registered flag, which
      does get set and cleared at the appropriate times.  It also makes sure
      to hold the usb_bus_list_lock mutex while setting the flag, so that
      usb_device_read() will become aware of new root hubs as soon as they
      are registered.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NDon Zickus <dzickus@redhat.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0a231403
  4. 25 9月, 2012 1 次提交
  5. 18 9月, 2012 2 次提交
  6. 14 9月, 2012 1 次提交
  7. 13 9月, 2012 1 次提交
  8. 11 9月, 2012 11 次提交
  9. 06 9月, 2012 1 次提交
  10. 21 8月, 2012 2 次提交
  11. 11 8月, 2012 1 次提交
  12. 20 7月, 2012 2 次提交
  13. 17 7月, 2012 1 次提交
  14. 15 7月, 2012 1 次提交
  15. 11 7月, 2012 5 次提交
    • S
      USB: Add a sysfs file to show LTM capabilities. · 024f117c
      Sarah Sharp 提交于
      USB 3.0 devices can optionally support Latency Tolerance Messaging
      (LTM).  Add a new sysfs file in the device directory to show whether a
      device is LTM capable.  This file will be present for both USB 2.0 and
      USB 3.0 devices.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      024f117c
    • S
      USB: Enable Latency Tolerance Messaging (LTM). · f74631e3
      Sarah Sharp 提交于
      USB 3.0 devices may optionally support a new feature called Latency
      Tolerance Messaging.  If both the xHCI host controller and the device
      support LTM, it should be turned on in order to give the system hardware
      a better clue about the latency tolerance values of its PCI devices.
      
      Once a Set Feature request to enable LTM is received, the USB 3.0 device
      will begin to send LTM updates as its buffers fill or empty, and it can
      tolerate more or less latency.
      
      The USB 3.0 spec, section C.4.2 says that LTM should be disabled just
      before the device is placed into suspend.  Then the device will send an
      updated LTM notification, so that the system doesn't think it should
      remain in an active state in order to satisfy the latency requirements
      of the suspended device.
      
      The Set and Clear Feature LTM enable command can only be sent to a
      configured device.  The device will respond with an error if that
      command is sent while it is in the Default or Addressed state.  Make
      sure to check udev->actconfig in usb_enable_ltm() and usb_disable_ltm(),
      and don't send those commands when the device is unconfigured.
      
      LTM should be enabled once a new configuration is installed in
      usb_set_configuration().  If we end up sending duplicate Set Feature LTM
      Enable commands on a switch from one installed configuration to another
      configuration, that should be harmless.
      
      Make sure that LTM is disabled before the device is unconfigured in
      usb_disable_device().  If no drivers are bound to the device, it doesn't
      make sense to allow the device to control the latency tolerance of the
      xHCI host controller.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      f74631e3
    • S
      USB: Fix LPM disable count mismatch on driver unbind. · 24971912
      Sarah Sharp 提交于
      When a user runs `echo 0 > bConfigurationValue` for a USB 3.0 device,
      usb_disable_device() is called.  This function disables all drivers,
      deallocates interfaces, and sets the device configuration value to 0
      (unconfigured).
      
      With the new scheme to ensure that unconfigured devices have LPM
      disabled, usb_disable_device() must call usb_unlocked_disable_lpm() once
      it unconfigures the device.
      
      This commit 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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      24971912
    • S
      USB: Disable LPM while the device is unconfigured. · 9cf65991
      Sarah Sharp 提交于
      The USB 3.0 Set/Clear Feature U1/U2 Enable cannot be sent to a device in
      the Default or Addressed state.  It can only be sent to a configured
      device.  Change the USB core to initialize the LPM disable count to 1
      (disabled), which reflects this limitation.
      
      Change usb_set_configuration() to ensure that if the device is
      unconfigured on entry, usb_lpm_disable() is not called.  This avoids
      sending the Clear Feature U1/U2 when the device is in the Addressed
      state.  When usb_set_configuration() exits with a successfully installed
      configuration, usb_lpm_enable() will be called.
      
      Once the new configuration is installed, make sure
      usb_set_configuration() only calls usb_enable_lpm() if the device moved
      to the Configured state.  If we have unconfigured the device by sending
      it a Set Configuration for config 0, don't enable LPM.
      
      This commit 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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      9cf65991
    • S
      USB: Fix LPM disable/enable during device reset. · 6d1d0513
      Sarah Sharp 提交于
      The USB 3.0 specification says that sending a Set Feature or Clear
      Feature for U1/U2 Enable is not a valid request when the device is in
      the Default or Addressed state.  It is only valid when the device is in
      the Configured state.
      
      The original LPM patch attempted to disable LPM after the device had
      been reset by hub_port_init(), before it had the configuration
      reinstalled.  The TI hub I tested with did not fail the Clear Feature
      U1/U2 Enable request that khubd sent while it was in the addressed
      state, which is why I didn't catch it.
      
      Move the LPM disable before the device reset, so that we can send the
      Clear Feature U1/U2 Enable successfully, and balance the LPM disable
      count.
      
      Also delete any calls to usb_enable_lpm() on error paths that lead to
      re-enumeration.  The calls will fail because the device isn't
      configured, and it's not useful to balance the LPM disable count because
      the usb_device is about to be destroyed before re-enumeration.
      
      Fix the early exit path ("done" label) to call usb_enable_lpm() to
      balance the LPM disable count.
      
      Note that calling usb_reset_and_verify_device() with an unconfigured
      device may fail on the first call to usb_disable_lpm().  That's because
      the LPM disable count is initialized to 0 (LPM enabled), and
      usb_disable_lpm() will attempt to send a Clear Feature U1/U2 request to
      a device in the Addressed state.  The next patch will fix that.
      
      This commit 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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      6d1d0513
  16. 10 7月, 2012 1 次提交
  17. 07 7月, 2012 4 次提交
  18. 03 7月, 2012 1 次提交
    • S
      usb: Add support for root hub port status CAS · 8bea2bd3
      Stanislaw Ledwon 提交于
      The host controller port status register supports CAS (Cold Attach
      Status) bit. This bit could be set when USB3.0 device is connected
      when system is in Sx state. When the system wakes to S0 this port
      status with CAS bit is reported and this port can't be used by any
      device.
      
      When CAS bit is set the port should be reset by warm reset. This
      was not supported by xhci driver.
      
      The issue was found when pendrive was connected to suspended
      platform. The link state of "Compliance Mode" was reported together
      with CAS bit. This link state was also not supported by xhci and
      core/hub.c.
      
      The CAS bit is defined only for xhci root hub port and it is
      not supported on regular hubs. The link status is used to force
      warm reset on port. Make the USB core issue a warm reset when port
      is in ether the 'inactive' or 'compliance mode'. Change the xHCI driver
      to report 'compliance mode' when the CAS is set. This force warm reset
      on the root hub port.
      
      This patch should be backported to stable kernels as old as 3.2, that
      contain the commit 10d674a8 "USB: When
      hot reset for USB3 fails, try warm reset."
      Signed-off-by: NStanislaw Ledwon <staszek.ledwon@linux.intel.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: NAndiry Xu <andiry.xu@amd.com>
      Cc: stable@vger.kernel.org
      8bea2bd3
  19. 15 6月, 2012 1 次提交
    • D
      USB: fix gathering of interface associations · b3a3dd07
      Daniel Mack 提交于
      TEAC's UD-H01 (and probably other devices) have a gap in the interface
      number allocation of their descriptors:
      
        Configuration Descriptor:
          bLength                 9
          bDescriptorType         2
          wTotalLength          220
          bNumInterfaces          3
          [...]
          Interface Descriptor:
            bLength                 9
            bDescriptorType         4
            bInterfaceNumber        0
            bAlternateSetting       0
            [...]
          Interface Association:
            bLength                 8
            bDescriptorType        11
            bFirstInterface         2
            bInterfaceCount         2
            bFunctionClass          1 Audio
            bFunctionSubClass       0
            bFunctionProtocol      32
            iFunction               4
          Interface Descriptor:
            bLength                 9
            bDescriptorType         4
            bInterfaceNumber        2
            bAlternateSetting       0
            [...]
      
      Once a configuration is selected, usb_set_configuration() walks the
      known interfaces of a given configuration and calls find_iad() on
      each of them to set the interface association pointer the interface
      is included in.
      
      The problem here is that the loop variable is taken for the interface
      number in the comparison logic that gathers the association. Which is
      fine as long as the descriptors are sane.
      
      In the case above, however, the logic gets out of sync and the
      interface association fields of all interfaces beyond the interface
      number gap are wrong.
      
      Fix this by passing the interface's bInterfaceNumber to find_iad()
      instead.
      Signed-off-by: NDaniel Mack <zonque@gmail.com>
      Reported-by: NbEN <ml_all@circa.be>
      Reported-by: NIvan Perrone <ivanperrone@hotmail.com>
      Tested-by: Nivan perrone <ivanperrone@hotmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b3a3dd07
  20. 14 6月, 2012 1 次提交