1. 15 Aug, 2019 1 commit
  2. 03 Jun, 2019 2 commits
  3. 03 May, 2019 1 commit
  4. 25 Apr, 2019 1 commit
  5. 22 Feb, 2019 1 commit
  6. 09 Nov, 2018 1 commit
  7. 25 Jun, 2018 1 commit
    • Alan Stern's avatar
      USB: Report wakeup events on root-hub ports · 379cacc5
      Alan Stern authored
      
      
      When a USB device attached to a root-hub port sends a wakeup request
      to a sleeping system, we do not report the wakeup event to the PM
      core.  This is because a system resume involves waking up all
      suspended USB ports as quickly as possible; without the normal
      USB_RESUME_TIMEOUT delay, the host controller driver doesn't set the
      USB_PORT_STAT_C_SUSPEND flag and so usb_port_resume() doesn't realize
      that a wakeup request was received.
      
      However, some environments (such as Chrome OS) want to have all wakeup
      events reported so they can be ascribed to the appropriate device.  To
      accommodate these environments, this patch adds a new routine to the
      hub driver and a corresponding new HCD method to be used when a root
      hub resumes.  The HCD method returns a bitmap of ports that have
      initiated a wakeup signal but not yet completed resuming.  The hub
      driver can then report to the PM core that the child devices attached
      to these ports initiated a wakeup event.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Suggested-by: default avatarAnshuman Gupta <anshuman.gupta@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      379cacc5
  8. 22 Apr, 2018 2 commits
  9. 09 Mar, 2018 3 commits
  10. 04 Nov, 2017 1 commit
  11. 13 Jun, 2017 1 commit
  12. 18 May, 2017 1 commit
  13. 23 Mar, 2017 1 commit
  14. 17 Mar, 2017 1 commit
  15. 05 Dec, 2016 1 commit
    • Tal Shorer's avatar
      usb: hcd.h: construct hub class request constants from simpler constants · b9c2a2a3
      Tal Shorer authored
      
      
      Currently, each hub class request constant is defined by a line like:
      #define ClearHubFeature		(0x2000 | USB_REQ_CLEAR_FEATURE)
      
      The "magic" number for the high byte is one of 0x20, 0xa0, 0x23, 0xa3.
      The 0x80 bit that changes inditace USB_DIR_IN, and the 0x03 that
      pops up is the difference between USB_RECIP_DEVICE (0x00) and
      USB_RECIP_OTHER (0x03). The constant 0x20 bit is USB_TYPE_CLASS.
      
      This patch eliminates those magic numbers by defining a macro to help
      construct these hub class request from simpler constants.
      Note that USB_RT_HUB is defined as (USB_TYPE_CLASS | USB_RECIP_DEVICE)
      and that USB_RT_PORT is defined as (USB_TYPE_CLASS | USB_RECIP_OTHER).
      Signed-off-by: default avatarTal Shorer <tal.shorer@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b9c2a2a3
  16. 28 Apr, 2016 1 commit
    • Chris Bainbridge's avatar
      usb: core: hub: hub_port_init lock controller instead of bus · feb26ac3
      Chris Bainbridge authored
      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/748
      
      Signed-off-by: default avatarChris Bainbridge <chris.bainbridge@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Acked-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      feb26ac3
  17. 07 Feb, 2016 1 commit
  18. 03 Feb, 2016 1 commit
  19. 01 Dec, 2015 1 commit
  20. 04 Oct, 2015 1 commit
  21. 22 Sep, 2015 2 commits
  22. 18 Aug, 2015 2 commits
  23. 14 Aug, 2015 2 commits
  24. 08 Aug, 2015 1 commit
  25. 31 May, 2015 1 commit
  26. 31 Jan, 2015 1 commit
  27. 09 Jan, 2015 1 commit
    • Sebastian Andrzej Siewior's avatar
      usb: core: buffer: smallest buffer should start at ARCH_DMA_MINALIGN · 5efd2ea8
      Sebastian Andrzej Siewior authored
      
      
      the following error pops up during "testusb -a -t 10"
      | musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128,	f134e000/be842000 (bad dma)
      hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of
      size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in
      hcd_buffer_alloc() returning memory which is 32 bytes aligned and it
      might by identified by buffer_offset() as another buffer. This means the
      buffer which is on a 32 byte boundary will not get freed, instead it
      tries to free another buffer with the error message.
      
      This patch fixes the issue by creating the smallest DMA buffer with the
      size of ARCH_KMALLOC_MINALIGN (or 32 in case ARCH_KMALLOC_MINALIGN is
      smaller). This might be 32, 64 or even 128 bytes. The next three pools
      will have the size 128, 512 and 2048.
      In case the smallest pool is 128 bytes then we have only three pools
      instead of four (and zero the first entry in the array).
      The last pool size is always 2048 bytes which is the assumed PAGE_SIZE /
      2 of 4096. I doubt it makes sense to continue using PAGE_SIZE / 2 where
      we would end up with 8KiB buffer in case we have 16KiB pages.
      Instead I think it makes sense to have a common size(s) and extend them
      if there is need to.
      There is a BUILD_BUG_ON() now in case someone has a minalign of more than
      128 bytes.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5efd2ea8
  28. 03 Dec, 2014 1 commit
  29. 03 Nov, 2014 1 commit
  30. 29 Sep, 2014 2 commits
  31. 24 Sep, 2014 1 commit
  32. 04 Mar, 2014 1 commit