1. 25 3月, 2018 1 次提交
  2. 23 3月, 2018 1 次提交
  3. 22 3月, 2018 1 次提交
    • R
      usb: core: introduce per-port over-current counters · 1cbd53c8
      Richard Leitner 提交于
      For some userspace applications information on the number of
      over-current conditions at specific USB hub ports is relevant.
      
      In our case we have a series of USB hardware (using the cp210x driver)
      which communicates using a proprietary protocol. These devices sometimes
      trigger an over-current situation on some hubs. In case of such an
      over-current situation the USB devices offer an interface for reducing
      the max used power. As these conditions are quite rare and imply
      performance reductions of the device we don't want to reduce the max
      power always.
      
      Therefore give user-space applications the possibility to react
      adequately by introducing an over_current_counter in the usb port struct
      which is exported via sysfs.
      Signed-off-by: NRichard Leitner <richard.leitner@skidata.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1cbd53c8
  4. 10 3月, 2018 1 次提交
    • M
      usb: Don't disable Latency tolerance Messaging (LTM) before port reset · 57edd462
      Mathias Nyman 提交于
      Disabing Latency Tolerance Messaging before port reset is unnecessary.
      LTM is automatically disabled at port reset.
      
      If host can't communicate with the device the LTM message will fail, and
      the hub driver will unnecessarily do a logical disconnect.
      Broken communication is ofter the reason for a reset in the first place.
      
      Additionally we can't guarantee device is in a configured state,
      epecially in reset-resume case when root hub lost power.
      LTM can't be modified unless device is in a configured state.
      
      Just remove LTM disabling before port reset.
      
      Details about LTM and port reset in USB 3 specification:
      
      USB 3 spec section 9.4.5
      "The LTM Enable field can be modified by the SetFeature() and
      ClearFeature() requests using the LTM_ENABLE feature selector.
      This field is reset to zero when the device is reset."
      
      USB 3 spec section 9.4.1
      "The device shall process a Clear Feature (U1_Enable or U2_Enable or
      LTM_Enable) only if the device is in the configured state."
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      57edd462
  5. 16 12月, 2017 1 次提交
  6. 06 12月, 2017 1 次提交
  7. 28 11月, 2017 1 次提交
    • M
      usb: hub: Cycle HUB power when initialization fails · 973593a9
      Mike Looijmans 提交于
      Sometimes the USB device gets confused about the state of the initialization and
      the connection fails. In particular, the device thinks that it's already set up
      and running while the host thinks the device still needs to be configured. To
      work around this issue, power-cycle the hub's output to issue a sort of "reset"
      to the device. This makes the device restart its state machine and then the
      initialization succeeds.
      
      This fixes problems where the kernel reports a list of errors like this:
      
      usb 1-1.3: device not accepting address 19, error -71
      
      The end result is a non-functioning device. After this patch, the sequence
      becomes like this:
      
      usb 1-1.3: new high-speed USB device number 18 using ci_hdrc
      usb 1-1.3: device not accepting address 18, error -71
      usb 1-1.3: new high-speed USB device number 19 using ci_hdrc
      usb 1-1.3: device not accepting address 19, error -71
      usb 1-1-port3: attempt power cycle
      usb 1-1.3: new high-speed USB device number 21 using ci_hdrc
      usb-storage 1-1.3:1.2: USB Mass Storage device detected
      Signed-off-by: NMike Looijmans <mike.looijmans@topic.nl>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      973593a9
  8. 07 11月, 2017 1 次提交
  9. 03 11月, 2017 1 次提交
  10. 23 10月, 2017 1 次提交
    • D
      USB: Force disconnect Huawei 4G modem during suspend · 8dd8d2c9
      Daniel Drake 提交于
      When going into S3 suspend, the Acer TravelMate P648-M and P648-G3
      laptops immediately wake up 3-4 seconds later for no obvious reason.
      
      Unbinding the integrated Huawei 4G LTE modem before suspend avoids
      the issue, even though we are not using the modem at all (checked
      from rescue.target/runlevel1). The problem also occurs when the option
      and cdc-ether modem drivers aren't loaded; it reproduces just with the
      base usb driver. Under Windows the system can suspend fine.
      
      Seeking a better fix, we've tried a lot of things, including:
       - Check that the device's power/wakeup is disabled
       - Check that remote wakeup is off at the USB level
       - All the quirks in drivers/usb/core/quirks.c e.g. USB_QUIRK_RESET_RESUME,
         USB_QUIRK_RESET, USB_QUIRK_IGNORE_REMOTE_WAKEUP, USB_QUIRK_NO_LPM.
      
      but none of that makes any difference.
      
      There are no errors in the logs showing any suspend/resume-related issues.
      When the system wakes up due to the modem, log-wise it appears to be a
      normal resume.
      
      Introduce a quirk to disable the port during suspend when the modem is
      detected.
      
      The modem from the P648-G3 model is:
      T:  Bus=01 Lev=01 Prnt=01 Port=08 Cnt=04 Dev#=  5 Spd=480  MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=ff MxPS=64 #Cfgs=  3
      P:  Vendor=12d1 ProdID=15c3 Rev= 1.02
      S:  Manufacturer=Huawei Technologies Co., Ltd.
      S:  Product=HUAWEI Mobile
      S:  SerialNumber=0123456789ABCDEF
      C:  #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=  2mA
      I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=10 Driver=
      E:  Ad=82(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
      E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=13 Driver=
      E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=12 Driver=
      E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:  If#= 3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=06 Prot=16 Driver=
      E:  Ad=86(I) Atr=03(Int.) MxPS=  16 Ivl=2ms
      I:  If#= 3 Alt= 1 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=16 Driver=
      E:  Ad=86(I) Atr=03(Int.) MxPS=  16 Ivl=2ms
      E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=1b Driver=
      E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      C:* #Ifs= 6 Cfg#= 2 Atr=a0 MxPwr=  2mA
      I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether
      E:  Ad=82(I) Atr=03(Int.) MxPS=  16 Ivl=2ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=06 Prot=00 Driver=cdc_ether
      E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=10 Driver=option
      E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
      E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=13 Driver=option
      E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=12 Driver=option
      E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=1b Driver=option
      E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      C:  #Ifs= 2 Cfg#= 3 Atr=a0 MxPwr=  2mA
      A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
      I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=
      E:  Ad=82(I) Atr=03(Int.) MxPS=  16 Ivl=2ms
      I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=
      E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      
      Based on an earlier patch by Chris Chiu.
      Signed-off-by: NDaniel Drake <drake@endlessm.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8dd8d2c9
  11. 19 10月, 2017 1 次提交
  12. 18 9月, 2017 1 次提交
    • D
      usb: Increase quirk delay for USB devices · b2a542bb
      Dmitry Fleytman 提交于
      Commit e0429362
      ("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e")
      introduced quirk to workaround an issue with some Logitech webcams.
      
      The workaround is introducing delay for some USB operations.
      
      According to our testing, delay introduced by original commit
      is not long enough and in rare cases we still see issues described
      by the aforementioned commit.
      
      This patch increases delays introduced by original commit.
      Having this patch applied we do not see those problems anymore.
      Signed-off-by: NDmitry Fleytman <dmitry@daynix.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2a542bb
  13. 17 8月, 2017 1 次提交
    • M
      usb: Increase root hub reset signaling time to prevent retry · 74072bae
      Mathias Nyman 提交于
      Save 80ms device enumeration time by increasing root hub port reset time
      
      The 50ms reset signaling time is not enough for most root hub ports.
      Increasing the reset time to 60ms allows host controllers to finish port
      reset and removes a retry causing an extra 50ms delay.
      
      The USB 2 specification requires "at least 50ms" for driving root
      port reset. The current msleep is exactly 50ms which may not be
      enough if there are any delays between writing the reset bit to host
      controller portsc register and phy actually driving reset.
      
      On Haswell, Skylake and Kabylake xHC port reset took in average 52-59ms
      
      The 80ms improvement comes from (40ms * 2 port resets) save at enumeration
      for each device connected to a root hub port.
      
      more details about root port reset in USB2 section 7.1.7.5:.
      "Software must ensure that resets issued to the root ports drive reset
      long enough to overwhelm any concurrent resume attempts by downstream
      devices. It is required that resets from root ports have a duration of
      at least 50 ms (TDRSTR).
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      74072bae
  14. 11 8月, 2017 1 次提交
    • A
      USB: Check for dropped connection before switching to full speed · 94c43b98
      Alan Stern 提交于
      Some buggy USB disk adapters disconnect and reconnect multiple times
      during the enumeration procedure.  This may lead to a device
      connecting at full speed instead of high speed, because when the USB
      stack sees that a device isn't able to enumerate at high speed, it
      tries to hand the connection over to a full-speed companion
      controller.
      
      The logic for doing this is careful to check that the device is still
      connected.  But this check is inadequate if the device disconnects and
      reconnects before the check is done.  The symptom is that a device
      works, but much more slowly than it is capable of operating.
      
      The situation was made worse recently by commit 22547c4c ("usb:
      hub: Wait for connection to be reestablished after port reset"), which
      increases the delay following a reset before a disconnect is
      recognized, thus giving the device more time to reconnect.
      
      This patch makes the check more robust.  If the device was
      disconnected at any time during enumeration, we will now skip the
      full-speed handover.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: NZdenek Kabelac <zkabelac@redhat.com>
      Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      94c43b98
  15. 22 7月, 2017 1 次提交
  16. 29 6月, 2017 1 次提交
  17. 16 6月, 2017 1 次提交
    • M
      usb: Avoid unnecessary LPM enabling and disabling during suspend and resume · d590c231
      Mathias Nyman 提交于
      The original motivation for disabling/enabling Link PM at device
      suspend/resume was to force link state to go via U0 before suspend sets
      the link state to U3. Going directly from U2 to U3 is not allowed.
      
      Disabling LPM will forced the link state to U0, but will send a lot of
      Set port feature requests for evert suspend and resume.
      
      This is not needed as Hub hardware will take care of going via U0
      when a U2 -> U3 transition is requested [1]
      
      [1] USB 3.1 specification section 10.16.2.10 Set Port Feature:
      
      "If the value is 3, then host software wants to selectively suspend the
      device connected to this port. The hub shall transition the link to U3
      from any of the other U states using allowed link state transitions.
      If the port is not already in the U0 state, then it shall transition the
      port to the U0 state and then initiate the transition to U3.
      While this state is active, the hub does not propagate downstream-directed
      traffic to this port, but the hub will respond to resume signaling from the
      port"
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d590c231
  18. 17 5月, 2017 3 次提交
  19. 23 3月, 2017 2 次提交
    • G
      usb: hub: Do not attempt to autosuspend disconnected devices · f5cccf49
      Guenter Roeck 提交于
      While running a bind/unbind stress test with the dwc3 usb driver on rk3399,
      the following crash was observed.
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000218
      pgd = ffffffc00165f000
      [00000218] *pgd=000000000174f003, *pud=000000000174f003,
      				*pmd=0000000001750003, *pte=00e8000001751713
      Internal error: Oops: 96000005 [#1] PREEMPT SMP
      Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac
      ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat rfcomm
      xt_mark fuse bridge stp llc zram btusb btrtl btbcm btintel bluetooth
      ip6table_filter mwifiex_pcie mwifiex cfg80211 cdc_ether usbnet r8152 mii joydev
      snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device ppp_async
      ppp_generic slhc tun
      CPU: 1 PID: 29814 Comm: kworker/1:1 Not tainted 4.4.52 #507
      Hardware name: Google Kevin (DT)
      Workqueue: pm pm_runtime_work
      task: ffffffc0ac540000 ti: ffffffc0af4d4000 task.ti: ffffffc0af4d4000
      PC is at autosuspend_check+0x74/0x174
      LR is at autosuspend_check+0x70/0x174
      ...
      Call trace:
      [<ffffffc00080dcc0>] autosuspend_check+0x74/0x174
      [<ffffffc000810500>] usb_runtime_idle+0x20/0x40
      [<ffffffc000785ae0>] __rpm_callback+0x48/0x7c
      [<ffffffc000786af0>] rpm_idle+0x1e8/0x498
      [<ffffffc000787cdc>] pm_runtime_work+0x88/0xcc
      [<ffffffc000249bb8>] process_one_work+0x390/0x6b8
      [<ffffffc00024abcc>] worker_thread+0x480/0x610
      [<ffffffc000251a80>] kthread+0x164/0x178
      [<ffffffc0002045d0>] ret_from_fork+0x10/0x40
      
      Source:
      
      (gdb) l *0xffffffc00080dcc0
      0xffffffc00080dcc0 is in autosuspend_check
      (drivers/usb/core/driver.c:1778).
      1773		/* We don't need to check interfaces that are
      1774		 * disabled for runtime PM.  Either they are unbound
      1775		 * or else their drivers don't support autosuspend
      1776		 * and so they are permanently active.
      1777		 */
      1778		if (intf->dev.power.disable_depth)
      1779			continue;
      1780		if (atomic_read(&intf->dev.power.usage_count) > 0)
      1781			return -EBUSY;
      1782		w |= intf->needs_remote_wakeup;
      
      Code analysis shows that intf is set to NULL in usb_disable_device() prior
      to setting actconfig to NULL. At the same time, usb_runtime_idle() does not
      lock the usb device, and neither does any of the functions in the
      traceback. This means that there is no protection against a race condition
      where usb_disable_device() is removing dev->actconfig->interface[] pointers
      while those are being accessed from autosuspend_check().
      
      To solve the problem, synchronize and validate device state between
      autosuspend_check() and usb_disconnect().
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5cccf49
    • G
      usb: hub: Fix error loop seen after hub communication errors · 245b2eec
      Guenter Roeck 提交于
      While stress testing a usb controller using a bind/unbind looop, the
      following error loop was observed.
      
      usb 7-1.2: new low-speed USB device number 3 using xhci-hcd
      usb 7-1.2: hub failed to enable device, error -108
      usb 7-1-port2: cannot disable (err = -22)
      usb 7-1-port2: couldn't allocate usb_device
      usb 7-1-port2: cannot disable (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      ** 57 printk messages dropped ** hub 7-1:1.0: activate --> -22
      ** 82 printk messages dropped ** hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      
      This continues forever. After adding tracebacks into the code,
      the call sequence leading to this is found to be as follows.
      
      [<ffffffc0007fc8e0>] hub_activate+0x368/0x7b8
      [<ffffffc0007fceb4>] hub_resume+0x2c/0x3c
      [<ffffffc00080b3b8>] usb_resume_interface.isra.6+0x128/0x158
      [<ffffffc00080b5d0>] usb_suspend_both+0x1e8/0x288
      [<ffffffc00080c9c4>] usb_runtime_suspend+0x3c/0x98
      [<ffffffc0007820a0>] __rpm_callback+0x48/0x7c
      [<ffffffc00078217c>] rpm_callback+0xa8/0xd4
      [<ffffffc000786234>] rpm_suspend+0x84/0x758
      [<ffffffc000786ca4>] rpm_idle+0x2c8/0x498
      [<ffffffc000786ed4>] __pm_runtime_idle+0x60/0xac
      [<ffffffc00080eba8>] usb_autopm_put_interface+0x6c/0x7c
      [<ffffffc000803798>] hub_event+0x10ac/0x12ac
      [<ffffffc000249bb8>] process_one_work+0x390/0x6b8
      [<ffffffc00024abcc>] worker_thread+0x480/0x610
      [<ffffffc000251a80>] kthread+0x164/0x178
      [<ffffffc0002045d0>] ret_from_fork+0x10/0x40
      
      kick_hub_wq() is called from hub_activate() even after failures to
      communicate with the hub. This results in an endless sequence of
      hub event -> hub activate -> wq trigger -> hub event -> ...
      
      Provide two solutions for the problem.
      
      - Only trigger the hub event queue if communication with the hub
        is successful.
      - After a suspend failure, only resume already suspended interfaces
        if the communication with the device is still possible.
      
      Each of the changes fixes the observed problem. Use both to improve
      robustness.
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      245b2eec
  20. 17 3月, 2017 1 次提交
    • G
      usb: hub: Fix crash after failure to read BOS descriptor · 7b2db29f
      Guenter Roeck 提交于
      If usb_get_bos_descriptor() returns an error, usb->bos will be NULL.
      Nevertheless, it is dereferenced unconditionally in
      hub_set_initial_usb2_lpm_policy() if usb2_hw_lpm_capable is set.
      This results in a crash.
      
      usb 5-1: unable to get BOS descriptor
      ...
      Unable to handle kernel NULL pointer dereference at virtual address 00000008
      pgd = ffffffc00165f000
      [00000008] *pgd=000000000174f003, *pud=000000000174f003,
      		*pmd=0000000001750003, *pte=00e8000001751713
      Internal error: Oops: 96000005 [#1] PREEMPT SMP
      Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac [ ... ]
      CPU: 5 PID: 3353 Comm: kworker/5:3 Tainted: G    B 4.4.52 #480
      Hardware name: Google Kevin (DT)
      Workqueue: events driver_set_config_work
      task: ffffffc0c3690000 ti: ffffffc0ae9a8000 task.ti: ffffffc0ae9a8000
      PC is at hub_port_init+0xc3c/0xd10
      LR is at hub_port_init+0xc3c/0xd10
      ...
      Call trace:
      [<ffffffc0007fbbfc>] hub_port_init+0xc3c/0xd10
      [<ffffffc0007fbe2c>] usb_reset_and_verify_device+0x15c/0x82c
      [<ffffffc0007fc5e0>] usb_reset_device+0xe4/0x298
      [<ffffffbffc0e3fcc>] rtl8152_probe+0x84/0x9b0 [r8152]
      [<ffffffc00080ca8c>] usb_probe_interface+0x244/0x2f8
      [<ffffffc000774a24>] driver_probe_device+0x180/0x3b4
      [<ffffffc000774e48>] __device_attach_driver+0xb4/0xe0
      [<ffffffc000772168>] bus_for_each_drv+0xb4/0xe4
      [<ffffffc0007747ec>] __device_attach+0xd0/0x158
      [<ffffffc000775080>] device_initial_probe+0x24/0x30
      [<ffffffc0007739d4>] bus_probe_device+0x50/0xe4
      [<ffffffc000770bd0>] device_add+0x414/0x738
      [<ffffffc000809fe8>] usb_set_configuration+0x89c/0x914
      [<ffffffc00080a120>] driver_set_config_work+0xc0/0xf0
      [<ffffffc000249bb8>] process_one_work+0x390/0x6b8
      [<ffffffc00024abcc>] worker_thread+0x480/0x610
      [<ffffffc000251a80>] kthread+0x164/0x178
      [<ffffffc0002045d0>] ret_from_fork+0x10/0x40
      
      Since we don't know anything about LPM capabilities without BOS descriptor,
      don't attempt to enable LPM if it is not available.
      
      Fixes: 890dae88 ("xhci: Enable LPM support only for hardwired ...")
      Cc: stable <stable@vger.kernel.org>
      Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Acked-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7b2db29f
  21. 02 3月, 2017 1 次提交
  22. 06 1月, 2017 1 次提交
  23. 25 12月, 2016 1 次提交
  24. 05 12月, 2016 1 次提交
    • G
      usb: hub: Wait for connection to be reestablished after port reset · 22547c4c
      Guenter Roeck 提交于
      On a system with a defective USB device connected to an USB hub,
      an endless sequence of port connect events was observed. The sequence
      of events as observed is as follows:
      
      - Port reports connected event (port status=USB_PORT_STAT_CONNECTION).
      - Event handler debounces port and resets it by calling hub_port_reset().
      - hub_port_reset() calls hub_port_wait_reset() to wait for the reset
        to complete.
      - The reset completes, but USB_PORT_STAT_CONNECTION is not immediately
        set in the port status register.
      - hub_port_wait_reset() returns -ENOTCONN.
      - Port initialization sequence is aborted.
      - A few milliseconds later, the port again reports a connected event,
        and the sequence repeats.
      
      This continues either forever or, randomly, stops if the connection
      is already re-established when the port status is read. It results in
      a high rate of udev events. This in turn destabilizes userspace since
      the above sequence holds the device mutex pretty much continuously
      and prevents userspace from actually reading the device status.
      
      To prevent the problem from happening, let's wait for the connection
      to be re-established after a port reset. If the device was actually
      disconnected, the code will still return an error, but it will do so
      only after the long reset timeout.
      
      Cc: Douglas Anderson <dianders@chromium.org>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22547c4c
  25. 17 11月, 2016 1 次提交
  26. 30 10月, 2016 1 次提交
  27. 27 9月, 2016 1 次提交
    • Y
      usb: hub: change CLEAR_FEATURE to SET_FEATURE · 4e248000
      Yonglong Wu 提交于
      In USB20 specification, describes in chapter 9.4.5: The Remote Wakeup
      field can be modified by the SetFeature() and ClearFeature() requests
      using the DEVICE_REMOTE_WAKEUP feature selector.
      
      In USB30 specification, also describes in chapter 9.4.5: The Function
      Remote Wakeup field can be modified by the SetFeature() requests
      using the FUNCTION_SUSPEND feature selector. In chapter 9.4.9 Set
      Feature reference, it describes Function Remote Wake Enabled/Disabled
      at suspend options by SET_FEATURE.
      
      In USB30 specification only mentioned SetFeature(), so we need use
      SET_FEATURE replace CLEAR_FEATURE to disable USB30 function remote
      wakeup in suspend options.
      Signed-off-by: NYonglong Wu <yonglong.wu@mediatek.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e248000
  28. 31 8月, 2016 1 次提交
  29. 09 8月, 2016 3 次提交
    • A
      USB: hub: change the locking in hub_activate · 07d316a2
      Alan Stern 提交于
      The locking in hub_activate() is not adequate to provide full mutual
      exclusion with hub_quiesce().  The subroutine locks the hub's
      usb_interface, but the callers of hub_quiesce() (such as
      hub_pre_reset() and hub_event()) hold the lock to the hub's
      usb_device.
      
      This patch changes hub_activate() to make it acquire the same lock as
      those other routines.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@vger.kernel.org> #4.4+
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      07d316a2
    • A
      USB: hub: fix up early-exit pathway in hub_activate · ca5cbc8b
      Alan Stern 提交于
      The early-exit pathway in hub_activate, added by commit e50293ef
      ("USB: fix invalid memory access in hub_activate()") needs
      improvement.  It duplicates code that is already present at the end of
      the subroutine, and it neglects to undo the effect of a
      usb_autopm_get_interface_no_resume() call.
      
      This patch fixes both problems by making the early-exit pathway jump
      directly to the end of the subroutine.  It simplifies the code at the
      end by merging two conditionals that actually test the same condition
      although they appear different: If type < HUB_INIT3 then type must be
      either HUB_INIT2 or HUB_INIT, and it can't be HUB_INIT because in that
      case the subroutine would have exited earlier.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@vger.kernel.org> #4.4+
      Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ca5cbc8b
    • V
      usb: hub: Fix unbalanced reference count/memory leak/deadlocks · 6bb47e8a
      Viresh Kumar 提交于
      Memory leak and unbalanced reference count:
      
      If the hub gets disconnected while the core is still activating it, this
      can result in leaking memory of few USB structures.
      
      This will happen if we have done a kref_get() from hub_activate() and
      scheduled a delayed work item for HUB_INIT2/3. Now if hub_disconnect()
      gets called before the delayed work expires, then we will cancel the
      work from hub_quiesce(), but wouldn't do a kref_put(). And so the
      unbalance.
      
      kmemleak reports this as (with the commit e50293ef backported to
      3.10 kernel with other changes, though the same is true for mainline as
      well):
      
      unreferenced object 0xffffffc08af5b800 (size 1024):
        comm "khubd", pid 73, jiffies 4295051211 (age 6482.350s)
        hex dump (first 32 bytes):
          30 68 f3 8c c0 ff ff ff 00 a0 b2 2e c0 ff ff ff  0h..............
          01 00 00 00 00 00 00 00 00 94 7d 40 c0 ff ff ff  ..........}@....
        backtrace:
          [<ffffffc0003079ec>] create_object+0x148/0x2a0
          [<ffffffc000cc150c>] kmemleak_alloc+0x80/0xbc
          [<ffffffc000303a7c>] kmem_cache_alloc_trace+0x120/0x1ac
          [<ffffffc0006fa610>] hub_probe+0x120/0xb84
          [<ffffffc000702b20>] usb_probe_interface+0x1ec/0x298
          [<ffffffc0005d50cc>] driver_probe_device+0x160/0x374
          [<ffffffc0005d5308>] __device_attach+0x28/0x4c
          [<ffffffc0005d3164>] bus_for_each_drv+0x78/0xac
          [<ffffffc0005d4ee0>] device_attach+0x6c/0x9c
          [<ffffffc0005d42b8>] bus_probe_device+0x28/0xa0
          [<ffffffc0005d23a4>] device_add+0x324/0x604
          [<ffffffc000700fcc>] usb_set_configuration+0x660/0x6cc
          [<ffffffc00070a350>] generic_probe+0x44/0x84
          [<ffffffc000702914>] usb_probe_device+0x54/0x74
          [<ffffffc0005d50cc>] driver_probe_device+0x160/0x374
          [<ffffffc0005d5308>] __device_attach+0x28/0x4c
      
      Deadlocks:
      
      If the hub gets disconnected early enough (i.e. before INIT2/INIT3 are
      finished and the init_work is still queued), the core may call
      hub_quiesce() after acquiring interface device locks and it will wait
      for the work to be cancelled synchronously. But if the work handler is
      already running in parallel, it may try to acquire the same interface
      device lock and this may result in deadlock.
      
      Fix both the issues by removing the call to cancel_delayed_work_sync().
      
      CC: <stable@vger.kernel.org> #4.4+
      Fixes: e50293ef ("USB: fix invalid memory access in hub_activate()")
      Reported-by: NManu Gautam <mgautam@codeaurora.org>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6bb47e8a
  30. 29 4月, 2016 1 次提交
    • C
      usb: core: hub: hub_port_init lock controller instead of bus · feb26ac3
      Chris Bainbridge 提交于
      The XHCI controller presents two USB buses to the system - one for USB2
      and one for USB3. The hub init code (hub_port_init) is reentrant but
      only locks one bus per thread, leading to a race condition failure when
      two threads attempt to simultaneously initialise a USB2 and USB3 device:
      
      [    8.034843] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
      [   13.183701] usb 3-3: device descriptor read/all, error -110
      
      On a test system this failure occurred on 6% of all boots.
      
      The call traces at the point of failure are:
      
      Call Trace:
       [<ffffffff81b9bab7>] schedule+0x37/0x90
       [<ffffffff817da7cd>] usb_kill_urb+0x8d/0xd0
       [<ffffffff8111e5e0>] ? wake_up_atomic_t+0x30/0x30
       [<ffffffff817dafbe>] usb_start_wait_urb+0xbe/0x150
       [<ffffffff817db10c>] usb_control_msg+0xbc/0xf0
       [<ffffffff817d07de>] hub_port_init+0x51e/0xb70
       [<ffffffff817d4697>] hub_event+0x817/0x1570
       [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
       [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
       [<ffffffff810f4684>] worker_thread+0x64/0x4b0
       [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
       [<ffffffff810fa7f5>] kthread+0x105/0x120
       [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
       [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
       [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
      
      Call Trace:
       [<ffffffff817fd36d>] xhci_setup_device+0x53d/0xa40
       [<ffffffff817fd87e>] xhci_address_device+0xe/0x10
       [<ffffffff817d047f>] hub_port_init+0x1bf/0xb70
       [<ffffffff811247ed>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff817d4697>] hub_event+0x817/0x1570
       [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
       [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
       [<ffffffff810f4684>] worker_thread+0x64/0x4b0
       [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
       [<ffffffff810fa7f5>] kthread+0x105/0x120
       [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
       [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
       [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
      
      Which results from the two call chains:
      
      hub_port_init
       usb_get_device_descriptor
        usb_get_descriptor
         usb_control_msg
          usb_internal_control_msg
           usb_start_wait_urb
            usb_submit_urb / wait_for_completion_timeout / usb_kill_urb
      
      hub_port_init
       hub_set_address
        xhci_address_device
         xhci_setup_device
      
      Mathias Nyman explains the current behaviour violates the XHCI spec:
      
       hub_port_reset() will end up moving the corresponding xhci device slot
       to default state.
      
       As hub_port_reset() is called several times in hub_port_init() it
       sounds reasonable that we could end up with two threads having their
       xhci device slots in default state at the same time, which according to
       xhci 4.5.3 specs still is a big no no:
      
       "Note: Software shall not transition more than one Device Slot to the
        Default State at a time"
      
       So both threads fail at their next task after this.
       One fails to read the descriptor, and the other fails addressing the
       device.
      
      Fix this in hub_port_init by locking the USB controller (instead of an
      individual bus) to prevent simultaneous initialisation of both buses.
      
      Fixes: 638139eb ("usb: hub: allow to process more usb hub events in parallel")
      Link: https://lkml.org/lkml/2016/2/8/312
      Link: https://lkml.org/lkml/2016/2/4/748Signed-off-by: NChris Bainbridge <chris.bainbridge@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Acked-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      feb26ac3
  31. 27 4月, 2016 1 次提交
  32. 04 3月, 2016 1 次提交
  33. 21 2月, 2016 1 次提交
    • G
      Revert "usb: hub: do not clear BOS field during reset device" · e5bdfd50
      Greg Kroah-Hartman 提交于
      This reverts commit d8f00cd6.
      
      Tony writes:
      
      This upstream commit is causing an oops:
      d8f00cd6 ("usb: hub: do not clear BOS field during reset device")
      
      This patch has already been included in several -stable kernels.  Here
      are the affected kernels:
      4.5.0-rc4 (current git)
      4.4.2
      4.3.6 (currently in review)
      4.1.18
      3.18.27
      3.14.61
      
      How to reproduce the problem:
      Boot kernel with slub debugging enabled (otherwise memory corruption
      will cause random oopses later instead of immediately)
      Plug in USB 3.0 disk to xhci USB 3.0 port
      dd if=/dev/sdc of=/dev/null bs=65536
      (where /dev/sdc is the USB 3.0 disk)
      Unplug USB cable while dd is still going
      Oops is immediate:
      Reported-by: NTony Battersby <tonyb@cybernetics.com>
      Cc: Du, Changbin <changbin.du@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e5bdfd50
  34. 15 2月, 2016 1 次提交
  35. 10 2月, 2016 1 次提交