1. 13 6月, 2017 1 次提交
    • J
      USB: of: fix root-hub device-tree node handling · 2bf69867
      Johan Hovold 提交于
      In an attempt to work around a pinmux over-allocation issue in driver
      core, commit dc5878ab ("usb: core: move root hub's device node
      assignment after it is added to bus") moved the device-tree node
      assignment until after the root hub had been registered.
      
      This not only makes the device-tree node unavailable to the usb driver
      during probe, but also prevents the of_node from being linked to in
      sysfs and causes a race with user-space for the (recently added) devspec
      attribute.
      
      Use the new device_set_of_node_from_dev() helper to reuse the node of
      the sysdev device, something which now prevents driver core from trying
      to reclaim any pinctrl pins during probe.
      
      Fixes: dc5878ab ("usb: core: move root hub's device node assignment after it is added to bus")
      Fixes: 51fa9147 ("usb/core: Added devspec sysfs entry for devices behind the usb hub")
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2bf69867
  2. 17 5月, 2017 3 次提交
  3. 08 4月, 2017 1 次提交
  4. 27 3月, 2017 1 次提交
  5. 23 3月, 2017 1 次提交
  6. 19 1月, 2017 1 次提交
    • W
      usb: hcd: initialize hcd->flags to 0 when rm hcd · 76b8db0d
      William wu 提交于
      On some platforms(e.g. rk3399 board), we can call hcd_add/remove
      consecutively without calling usb_put_hcd/usb_create_hcd in between,
      so hcd->flags can be stale.
      
      If the HC dies due to whatever reason then without this patch we get
      the below error on next hcd_add.
      
      [173.296154] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
      [173.296209] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
      [173.296762] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 6
      [173.296931] usb usb6: We don't know the algorithms for LPM for this host, disabling LPM.
      [173.297179] usb usb6: New USB device found, idVendor=1d6b, idProduct=0003
      [173.297203] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
      [173.297222] usb usb6: Product: xHCI Host Controller
      [173.297240] usb usb6: Manufacturer: Linux 4.4.21 xhci-hcd
      [173.297257] usb usb6: SerialNumber: xhci-hcd.2.auto
      [173.298680] hub 6-0:1.0: USB hub found
      [173.298749] hub 6-0:1.0: 1 port detected
      [173.299382] rockchip-dwc3 usb@fe800000: USB HOST connected
      [173.395418] hub 5-0:1.0: activate --> -19
      [173.603447] irq 228: nobody cared (try booting with the "irqpoll" option)
      [173.603493] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.21 #9
      [173.603513] Hardware name: Google Kevin (DT)
      [173.603531] Call trace:
      [173.603568] [<ffffffc0002087dc>] dump_backtrace+0x0/0x160
      [173.603596] [<ffffffc00020895c>] show_stack+0x20/0x28
      [173.603623] [<ffffffc0004b28a8>] dump_stack+0x90/0xb0
      [173.603650] [<ffffffc00027347c>] __report_bad_irq+0x48/0xe8
      [173.603674] [<ffffffc0002737cc>] note_interrupt+0x1e8/0x28c
      [173.603698] [<ffffffc000270a38>] handle_irq_event_percpu+0x1d4/0x25c
      [173.603722] [<ffffffc000270b0c>] handle_irq_event+0x4c/0x7c
      [173.603748] [<ffffffc00027456c>] handle_fasteoi_irq+0xb4/0x124
      [173.603777] [<ffffffc00026fe3c>] generic_handle_irq+0x30/0x44
      [173.603804] [<ffffffc0002701a8>] __handle_domain_irq+0x90/0xbc
      [173.603827] [<ffffffc0002006f4>] gic_handle_irq+0xcc/0x188
      ...
      [173.604500] [<ffffffc000203700>] el1_irq+0x80/0xf8
      [173.604530] [<ffffffc000261388>] cpu_startup_entry+0x38/0x3cc
      [173.604558] [<ffffffc00090f7d8>] rest_init+0x8c/0x94
      [173.604585] [<ffffffc000e009ac>] start_kernel+0x3d0/0x3fc
      [173.604607] [<0000000000b16000>] 0xb16000
      [173.604622] handlers:
      [173.604648] [<ffffffc000642084>] usb_hcd_irq
      [173.604673] Disabling IRQ #228
      Signed-off-by: NWilliam wu <wulf@rock-chips.com>
      Acked-by: NRoger Quadros <rogerq@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      76b8db0d
  7. 27 9月, 2016 1 次提交
  8. 02 9月, 2016 1 次提交
  9. 31 8月, 2016 1 次提交
  10. 27 6月, 2016 1 次提交
    • A
      USB: don't free bandwidth_mutex too early · ab2a4bf8
      Alan Stern 提交于
      The USB core contains a bug that can show up when a USB-3 host
      controller is removed.  If the primary (USB-2) hcd structure is
      released before the shared (USB-3) hcd, the core will try to do a
      double-free of the common bandwidth_mutex.
      
      The problem was described in graphical form by Chung-Geol Kim, who
      first reported it:
      
      =================================================
           At *remove USB(3.0) Storage
           sequence <1> --> <5> ((Problem Case))
      =================================================
                                        VOLD
      ------------------------------------|------------
                                       (uevent)
                                  ________|_________
                                 |<1>               |
                                 |dwc3_otg_sm_work  |
                                 |usb_put_hcd       |
                                 |peer_hcd(kref=2)|
                                 |__________________|
                                  ________|_________
                                 |<2>               |
                                 |New USB BUS #2    |
                                 |                  |
                                 |peer_hcd(kref=1)  |
                                 |                  |
                               --(Link)-bandXX_mutex|
                               | |__________________|
                               |
          ___________________  |
         |<3>                | |
         |dwc3_otg_sm_work   | |
         |usb_put_hcd        | |
         |primary_hcd(kref=1)| |
         |___________________| |
          _________|_________  |
         |<4>                | |
         |New USB BUS #1     | |
         |hcd_release        | |
         |primary_hcd(kref=0)| |
         |                   | |
         |bandXX_mutex(free) |<-
         |___________________|
                                     (( VOLD ))
                                  ______|___________
                                 |<5>               |
                                 |      SCSI        |
                                 |usb_put_hcd       |
                                 |peer_hcd(kref=0)  |
                                 |*hcd_release      |
                                 |bandXX_mutex(free*)|<- double free
                                 |__________________|
      
      =================================================
      
      This happens because hcd_release() frees the bandwidth_mutex whenever
      it sees a primary hcd being released (which is not a very good idea
      in any case), but in the course of releasing the primary hcd, it
      changes the pointers in the shared hcd in such a way that the shared
      hcd will appear to be primary when it gets released.
      
      This patch fixes the problem by changing hcd_release() so that it
      deallocates the bandwidth_mutex only when the _last_ hcd structure
      referencing it is released.  The patch also removes an unnecessary
      test, so that when an hcd is released, both the shared_hcd and
      primary_hcd pointers in the hcd's peer will be cleared.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NChung-Geol Kim <chunggeol.kim@samsung.com>
      Tested-by: NChung-Geol Kim <chunggeol.kim@samsung.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ab2a4bf8
  11. 29 4月, 2016 2 次提交
    • P
      usb: core: move root hub's device node assignment after it is added to bus · dc5878ab
      Peter Chen 提交于
      When the root hub device is added to the bus, it tries to get pins
      information from pinctrl (see pinctrl_bind_pins, at really_probe), if
      the pin information is described at DT, it will show below error since
      the root hub's device node is the same with controller's, but controller's
      pin has already been requested when it is added to platform bus.
      
      	imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_GPIO_1 already
             	requested by 2184000.usb; cannot claim for usb1
      	imx6q-pinctrl 20e0000.iomuxc: pin-137 (usb1) status -22
      	imx6q-pinctrl 20e0000.iomuxc: could not request pin 137
             	(MX6Q_PAD_GPIO_1) from group usbotggrp-3 on device 20e0000.iomuxc
      	usb usb1: Error applying setting, reverse things back
      
      To fix this issue, we move the root hub's device node assignment (equals
      to contrller's) after device is added to bus, we only need to know root
      hub's device node information after the device under root hub is created,
      so this movement will not affect current function.
      Signed-off-by: NPeter Chen <peter.chen@nxp.com>
      Reported-by: NLars Steubesand <lars.steubesand@philips.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc5878ab
    • 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
  12. 21 2月, 2016 1 次提交
  13. 07 2月, 2016 1 次提交
  14. 04 2月, 2016 1 次提交
  15. 25 1月, 2016 5 次提交
  16. 02 12月, 2015 1 次提交
  17. 17 10月, 2015 1 次提交
  18. 04 10月, 2015 1 次提交
  19. 23 9月, 2015 2 次提交
  20. 19 8月, 2015 2 次提交
  21. 15 8月, 2015 2 次提交
  22. 23 7月, 2015 2 次提交
    • K
      usb: move assignment out of if condition · 0faaad46
      Kris Borer 提交于
      Fix four occurrences of checkpatch.pl error:
      
      ERROR: do not use assignment in if condition
      
      The semantic patch that makes this change is:
      
      // <smpl>
      @@
      identifier i;
      expression E;
      statement S;
      constant c;
      binary operator b;
      @@
      
      + i = E;
        if (
      - (i = E)
      + i
        b
        c ) S
      
      @@
      identifier i, i2;
      expression E1, E2;
      constant c;
      @@
      
      + if( E1->i ) {
      +  	i2 = E2;
      + 	if (i2 < c) {
      - if( E1->i && (i2 = E2) < c ) {
        ...
      - }
      + 	}
      + }
      // </smpl>
      Signed-off-by: NKris Borer <kborer@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0faaad46
    • L
      usb: core: lpm: set lpm_capable for root hub device · 2d2a3167
      Lu Baolu 提交于
      Commit 25cd2882 ("usb/xhci: Change how we indicate a host supports
      Link PM.") removed the code to set lpm_capable for USB 3.0 super-speed
      root hub. The intention of that change was to avoid touching usb core
      internal field, a.k.a. lpm_capable, and let usb core to set it by
      checking U1 and U2 exit latency values in the descriptor.
      
      Usb core checks and sets lpm_capable in hub_port_init(). Unfortunately,
      root hub is a special usb device as it has no parent. Hub_port_init()
      will never be called for a root hub device. That means lpm_capable will
      by no means be set for the root hub. As the result, lpm isn't functional
      at all in Linux kernel.
      
      This patch add the code to check and set lpm_capable when registering a
      root hub device. It could be back-ported to kernels as old as v3.15,
      that contains the Commit 25cd2882 ("usb/xhci: Change how we indicate
      a host supports Link PM.").
      
      Cc: stable@vger.kernel.org # 3.15
      Reported-by: NKevin Strasser <kevin.strasser@linux.intel.com>
      Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2d2a3167
  23. 10 5月, 2015 1 次提交
  24. 01 2月, 2015 1 次提交
  25. 04 12月, 2014 1 次提交
  26. 04 11月, 2014 2 次提交
    • H
      usb: Do not allow usb_alloc_streams on unconfigured devices · 90a646c7
      Hans de Goede 提交于
      This commit fixes the following oops:
      
      [10238.622067] scsi host3: uas_eh_bus_reset_handler start
      [10240.766164] usb 3-4: reset SuperSpeed USB device number 3 using xhci_hcd
      [10245.779365] usb 3-4: device descriptor read/8, error -110
      [10245.883331] usb 3-4: reset SuperSpeed USB device number 3 using xhci_hcd
      [10250.897603] usb 3-4: device descriptor read/8, error -110
      [10251.058200] BUG: unable to handle kernel NULL pointer dereference at  0000000000000040
      [10251.058244] IP: [<ffffffff815ac6e1>] xhci_check_streams_endpoint+0x91/0x140
      <snip>
      [10251.059473] Call Trace:
      [10251.059487]  [<ffffffff815aca6c>] xhci_calculate_streams_and_bitmask+0xbc/0x130
      [10251.059520]  [<ffffffff815aeb5f>] xhci_alloc_streams+0x10f/0x5a0
      [10251.059548]  [<ffffffff810a4685>] ? check_preempt_curr+0x75/0xa0
      [10251.059575]  [<ffffffff810a46dc>] ? ttwu_do_wakeup+0x2c/0x100
      [10251.059601]  [<ffffffff810a49e6>] ? ttwu_do_activate.constprop.111+0x66/0x70
      [10251.059635]  [<ffffffff815779ab>] usb_alloc_streams+0xab/0xf0
      [10251.059662]  [<ffffffffc0616b48>] uas_configure_endpoints+0x128/0x150 [uas]
      [10251.059694]  [<ffffffffc0616bac>] uas_post_reset+0x3c/0xb0 [uas]
      [10251.059722]  [<ffffffff815727d9>] usb_reset_device+0x1b9/0x2a0
      [10251.059749]  [<ffffffffc0616f42>] uas_eh_bus_reset_handler+0xb2/0x190 [uas]
      [10251.059781]  [<ffffffff81514293>] scsi_try_bus_reset+0x53/0x110
      [10251.059808]  [<ffffffff815163b7>] scsi_eh_bus_reset+0xf7/0x270
      <snip>
      
      The problem is the following call sequence (simplified):
      
      1) usb_reset_device
      2)  usb_reset_and_verify_device
      2)   hub_port_init
      3)    hub_port_finish_reset
      3)     xhci_discover_or_reset_device
              This frees xhci->devs[slot_id]->eps[ep_index].ring for all eps but 0
      4)    usb_get_device_descriptor
             This fails
      5)   hub_port_init fails
      6)  usb_reset_and_verify_device fails, does not restore device config
      7)  uas_post_reset
      8)   xhci_alloc_streams
            NULL deref on the free-ed ring
      
      This commit fixes this by not allowing usb_alloc_streams to continue if
      the device is not configured.
      
      Note that we do allow usb_free_streams to continue after a (logical)
      disconnect, as it is necessary to explicitly free the streams at the xhci
      controller level.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      90a646c7
    • A
      usb: allow to supply the PHY in the drivers when using HCD · ef44cb42
      Antoine Tenart 提交于
      This patch modify the generic code handling PHYs to allow them to be
      supplied from the drivers. This adds checks to ensure no PHY was already
      there when looking for one in the generic code. This also makes sure we
      do not modify its state in the generic HCD functions, it was provided by
      the driver.
      Signed-off-by: NAntoine Tenart <antoine.tenart@free-electrons.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      ef44cb42
  27. 29 9月, 2014 2 次提交