1. 12 12月, 2015 1 次提交
  2. 02 12月, 2015 1 次提交
  3. 04 10月, 2015 2 次提交
  4. 10 5月, 2015 1 次提交
  5. 25 1月, 2015 1 次提交
  6. 25 11月, 2014 1 次提交
  7. 20 11月, 2014 1 次提交
  8. 04 11月, 2014 2 次提交
  9. 24 9月, 2014 2 次提交
  10. 02 8月, 2014 1 次提交
    • J
      usb-core bInterval quirk · cd83ce9e
      James P Michels III 提交于
      This patch adds a usb quirk to support devices with interupt endpoints
      and bInterval values expressed as microframes. The quirk causes the
      parse endpoint function to modify the reported bInterval to a standards
      conforming value.
      
      There is currently code in the endpoint parser that checks for
      bIntervals that are outside of the valid range (1-16 for USB 2+ high
      speed and super speed interupt endpoints). In this case, the code assumes
      the bInterval is being reported in 1ms frames. As well, the correction
      is only applied if the original bInterval value is out of the 1-16 range.
      
      With this quirk applied to the device, the bInterval will be
      accurately adjusted from microframes to an exponent.
      Signed-off-by: NJames P Michels III <james.p.michels@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cd83ce9e
  11. 12 7月, 2014 1 次提交
    • J
      USB: add reset resume quirk for usb3503 · 526a4045
      Joonyoung Shim 提交于
      The usb device will autoresume from choose_wakeup() if it is
      autosuspended with the wrong wakeup setting, but below errors occur
      because usb3503 misc driver will switch to standby mode when suspended.
      
      As add USB_QUIRK_RESET_RESUME, it can stop setting wrong wakeup from
      autosuspend_check().
      
      [    7.734717] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
      [    7.854658] usb 1-3: device descriptor read/64, error -71
      [    8.079657] usb 1-3: device descriptor read/64, error -71
      [    8.294664] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
      [    8.414658] usb 1-3: device descriptor read/64, error -71
      [    8.639657] usb 1-3: device descriptor read/64, error -71
      [    8.854667] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
      [    9.264598] usb 1-3: device not accepting address 3, error -71
      [    9.374655] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
      [    9.784601] usb 1-3: device not accepting address 3, error -71
      [    9.784838] usb usb1-port3: device 1-3 not suspended yet
      Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      526a4045
  12. 08 3月, 2014 1 次提交
    • J
      usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e · e0429362
      Julius Werner 提交于
      We've encountered a rare issue when enumerating two Logitech webcams
      after a reboot that doesn't power cycle the USB ports. They are spewing
      random data (possibly some leftover UVC buffers) on the second
      (full-sized) Get Configuration request of the enumeration phase. Since
      the data is random this can potentially cause all kinds of odd behavior,
      and since it occasionally happens multiple times (after the kernel
      issues another reset due to the garbled configuration descriptor), it is
      not always recoverable. Set the USB_DELAY_INIT quirk that seems to work
      around the issue.
      Signed-off-by: NJulius Werner <jwerner@chromium.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e0429362
  13. 09 12月, 2013 1 次提交
  14. 17 10月, 2013 1 次提交
  15. 15 10月, 2013 1 次提交
  16. 27 9月, 2013 1 次提交
  17. 26 9月, 2013 1 次提交
    • H
      usb: core: implement AMD remote wakeup quirk · 7868943d
      Huang Rui 提交于
      The following patch is required to resolve remote wake issues with
      certain devices.
      
      Issue description:
      If the remote wake is issued from the device in a specific timing
      condition while the system is entering sleep state then it may cause
      system to auto wake on subsequent sleep cycle.
      
      Root cause:
      Host controller rebroadcasts the Resume signal > 100 µseconds after
      receiving the original resume event from the device. For proper
      function, some devices may require the rebroadcast of resume event
      within the USB spec of 100µS.
      
      Workaroud:
      1. Filter the AMD platforms with Yangtze chipset, then judge of all the usb
      devices are mouse or not. And get out the port id which attached a mouse
      with Pixart controller.
      2. Then reset the port which attached issue device during system resume
      from S3.
      
      [Q] Why the special devices are only mice? Would high speed devices
      such as 3G modem or USB Bluetooth adapter trigger this issue?
      - Current this sensitivity is only confined to devices that use Pixart
        controllers. This controller is designed for use with LS mouse
      devices only. We have not observed any other devices failing. There
      may be a small risk for other devices also but this patch (reset
      device in resume phase) will cover the cases if required.
      
      [Q] Shouldn’t the resume signal be sent within 100 us for every
      device?
      - The Host controller may not send the resume signal within 100us,
        this our host controller specification change. This is why we
      require the patch to prevent side effects on certain known devices.
      
      [Q] Why would clicking mouse INTENSELY to wake the system up trigger
      this issue?
      - This behavior is specific to the devices that use Pixart controller.
        It is timing dependent on when the resume event is triggered during
      the sleep state.
      
      [Q] Is it a host controller issue or mouse?
      - It is the host controller behavior during resume that triggers the
        device incorrect behavior on the next resume.
      
      This patch sets USB_QUIRK_RESET_RESUME flag for these Pixart-based mice
      when they attached to platforms with AMD Yangtze chipset.
      Signed-off-by: NHuang Rui <ray.huang@amd.com>
      Suggested-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7868943d
  18. 15 8月, 2013 1 次提交
  19. 17 5月, 2013 1 次提交
  20. 30 3月, 2013 1 次提交
    • J
      usb: Make USB persist default configurable · 4f482038
      Julius Werner 提交于
      Commit 9214d1d8 set the USB persist flag as a default for all devices.
      This might be desirable for some distributions, but it certainly has its
      trade-offs... most importantly, it can significantly increase system
      resume time, because the kernel blocks on resuming (and sometimes
      resetting) USB devices before it unfreezes userspace.
      
      This patch introduces a new config option CONFIG_USB_DEFAULT_PERSIST,
      which allows distributions to make this decision on their own without
      the need to carry a custom patch or revert the kernel's setting in
      userspace.
      
      [edited the Kconfig help text a bit - gregkh]
      Signed-off-by: NJulius Werner <jwerner@chromium.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f482038
  21. 12 1月, 2013 1 次提交
  22. 06 9月, 2012 1 次提交
  23. 21 8月, 2012 1 次提交
  24. 20 7月, 2012 2 次提交
  25. 30 4月, 2012 1 次提交
  26. 04 1月, 2012 1 次提交
  27. 15 11月, 2011 2 次提交
  28. 30 9月, 2011 1 次提交
  29. 18 9月, 2011 1 次提交
  30. 18 2月, 2011 2 次提交
  31. 17 11月, 2010 2 次提交
    • A
      USB: improve uses of usb_mark_last_busy · c08512c7
      Alan Stern 提交于
      This patch (as1434) cleans up the uses of usb_mark_last_busy() in
      usbcore.  The function will be called when a device is resumed and
      whenever a usage count is decremented.  A call that was missing from
      the hub driver is added: A hub is used whenever one of its ports gets
      suspended (this prevents hubs from suspending immediately after their
      last child).
      
      In addition, the call to disable autosuspend support for new devices
      by default is moved from usb_detect_quirks() (where it doesn't really
      belong) into usb_new_device() along with all the other runtime-PM
      initializations.  Finally, an extra pm_runtime_get_noresume() is added
      to prevent new devices from autosuspending while they are being
      registered.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c08512c7
    • A
      USB: use the runtime-PM autosuspend implementation · fcc4a01e
      Alan Stern 提交于
      This patch (as1428) converts USB over to the new runtime-PM core
      autosuspend framework.  One slightly awkward aspect of the conversion
      is that USB devices will now have two suspend-delay attributes: the
      old power/autosuspend file and the new power/autosuspend_delay_ms
      file.  One expresses the delay time in seconds and the other in
      milliseconds, but otherwise they do the same thing.  The old attribute
      can be deprecated and then removed eventually.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      fcc4a01e
  32. 11 8月, 2010 1 次提交
  33. 27 7月, 2010 1 次提交