1. 02 12月, 2015 2 次提交
    • L
      usb: core: lpm: add sysfs node for usb3 lpm permit · 513072d9
      Lu Baolu 提交于
      USB3 LPM is default on in Linux kernel if both xHCI host controller
      and the USB devices declare to be LPM-capable. Unfortunately, some
      devices are known to work well with LPM disabled, but to be broken
      if LPM is enabled, although it declares the LPM capability.  Users
      won't be able to use this kind of devices, until someone puts them
      in the kernel blacklist and gets the kernel upgraded.
      
      This patch adds a sysfs node to permit or forbit USB3 LPM U1 or U2
      entry for a port. The settings apply to both before and after device
      enumeration. Supported values are "0" - neither u1 nor u2 permitted,
      "u1" - only u1 is permitted, "u2" - only u2 is permitted, "u1_u2" -
      both u1 and u2 are permitted. With this interface, users can use an
      LPM-unfriendly USB device on a released Linux kernel.
      Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
      Signed-off-by: NZhuang Jin Can <jin.can.zhuang@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      513072d9
    • L
      usb: core: lpm: fix usb3_hardware_lpm sysfs node · bf5ce5bf
      Lu Baolu 提交于
      Commit 655fe4ef ("usbcore: add sysfs support to xHCI usb3
      hardware LPM") introduced usb3_hardware_lpm sysfs node. This
      doesn't show the correct status of USB3 U1 and U2 LPM status.
      
      This patch fixes this by replacing usb3_hardware_lpm with two
      nodes, usb3_hardware_lpm_u1 (for U1) and usb3_hardware_lpm_u2
      (for U2), and recording the U1/U2 LPM status in right places.
      
      This patch should be back-ported to kernels as old as 4.3,
      that contains Commit 655fe4ef ("usbcore: add sysfs support
      to xHCI usb3 hardware LPM").
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bf5ce5bf
  2. 04 10月, 2015 3 次提交
  3. 15 8月, 2015 2 次提交
  4. 09 8月, 2015 1 次提交
  5. 23 7月, 2015 2 次提交
  6. 31 5月, 2015 1 次提交
    • R
      usb: core: Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset · fb6d1f7d
      Robert Schlabbach 提交于
      Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset.
      
      Dissolve the function hub_port_finish_reset() completely and divide the
      actions to be taken into those which need to be done after each reset
      attempt and those which need to be done after the full procedure is
      complete, and place them in the appropriate places in hub_port_reset().
      Also, remove an unneeded forward declaration of hub_port_reset().
      
      Verbose Problem Description:
      
      USB 3.0 devices may be "lost for good" during a hub port reset.
      This makes Linux unable to boot from USB 3.0 devices in certain
      constellations of host controllers and devices, because the USB device is
      lost during initialization, preventing the rootfs from being mounted.
      
      The underlying problem is that in the affected constellations, during the
      processing inside hub_port_reset(), the hub link state goes from 0 to
      SS.inactive after the initial reset, and back to 0 again only after the
      following "warm" reset.
      
      However, hub_port_finish_reset() is called after each reset attempt and
      sets the state the connected USB device based on the "preliminary" status
      of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when
      the following warm reset is complete and hub_port_finish_reset() is
      called again, its call to set the device to USB_STATE_DEFAULT is blocked
      by usb_set_device_state() which does not allow taking USB devices out of
      USB_STATE_NOTATTACHED state.
      
      Thanks to Alan Stern for guiding me to the proper solution and how to
      submit it.
      
      Link: http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27Signed-off-by: NRobert Schlabbach <robert_s@gmx.net>
      Cc: stable <stable@vger.kernel.org>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fb6d1f7d
  7. 10 5月, 2015 1 次提交
  8. 08 5月, 2015 3 次提交
  9. 08 4月, 2015 1 次提交
  10. 09 2月, 2015 1 次提交
  11. 04 2月, 2015 2 次提交
  12. 25 1月, 2015 2 次提交
    • D
      usb: core: hub: modify hub reset logic in hub driver · fbaecff0
      Deepak Das 提交于
      Currently if port power is turned off by user on hub port
      using USBDEVFS then port power is turned back ON
      by hub driver.
      This commit modifies hub reset logic in hub_port_connect() to prevent
      hub driver from turning back the port power ON if port is not owned
      by kernel.
      Signed-off-by: NDeepak Das <deepakdas.linux@gmail.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fbaecff0
    • A
      USB: don't cancel queued resets when unbinding drivers · 524134d4
      Alan Stern 提交于
      The USB stack provides a mechanism for drivers to request an
      asynchronous device reset (usb_queue_reset_device()).  The mechanism
      uses a work item (reset_ws) embedded in the usb_interface structure
      used by the driver, and the reset is carried out by a work queue
      routine.
      
      The asynchronous reset can race with driver unbinding.  When this
      happens, we try to cancel the queued reset before unbinding the
      driver, on the theory that the driver won't care about any resets once
      it is unbound.
      
      However, thanks to the fact that lockdep now tracks work queue
      accesses, this can provoke a lockdep warning in situations where the
      device reset causes another interface's driver to be unbound; see
      
      	http://marc.info/?l=linux-usb&m=141893165203776&w=2
      
      for an example.  The reason is that the work routine for reset_ws in
      one interface calls cancel_queued_work() for the reset_ws in another
      interface.  Lockdep thinks this might lead to a work routine trying to
      cancel itself.  The simplest solution is not to cancel queued resets
      when unbinding drivers.
      
      This means we now need to acquire a reference to the usb_interface
      when queuing a reset_ws work item and to drop the reference when the
      work routine finishes.  We also need to make sure that the
      usb_interface structure doesn't outlive its parent usb_device; this
      means acquiring and dropping a reference when the interface is created
      and destroyed.
      
      In addition, cancelling a queued reset can fail (if the device is in
      the middle of an earlier reset), and this can cause usb_reset_device()
      to try to rebind an interface that has been deallocated (see
      http://marc.info/?l=linux-usb&m=142175717016628&w=2 for details).
      Acquiring the extra references prevents this failure.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NRussell King - ARM Linux <linux@arm.linux.org.uk>
      Reported-by: NOlivier Sobrie <olivier@sobrie.be>
      Tested-by: NOlivier Sobrie <olivier@sobrie.be>
      Cc: stable <stable@vger.kernel.org> # 3.19
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      524134d4
  13. 04 12月, 2014 1 次提交
  14. 04 11月, 2014 4 次提交
  15. 29 9月, 2014 2 次提交
  16. 24 9月, 2014 9 次提交
  17. 11 9月, 2014 1 次提交
  18. 28 8月, 2014 1 次提交
  19. 27 8月, 2014 1 次提交