1. 28 Aug, 2017 17 commits
    • Jack Pham's avatar
      usb: misc: lvstest: add entry to place port in compliance mode · f624ec70
      Jack Pham authored
      Add support for the SuperSpeed Link Layer test case TD.7.34
      which requires the operator to place the port into compliance
      mode, and to subsequently bring it out via reset. Historically
      according to the (now deprecated) USB 3.0 specification a
      SuperSpeed host downstream port would automatically transition
      to Compliance mode from the Polling state if LFPS polling times
      out. However the language in USB 3.1 as well as xHCI 1.1 states
      it may be required to explicitly enable this transition. For
      such hosts this is done by sending a SET_FEATURE(PORT_LINK_STATE)
      with the state set to Compliance to the root hub port.
      
      Similar to the other supported commands, to do this via sysfs:
      
           echo  > /sys/bus/usb/devices/2-0\:1.0/enable_compliance
      
      According to xHCI 1.1 section 4.19.1.2.4.1, this enables the
      transition to compliance mode upon LFPS timeout. Note that this
      can only be issued when the port is in disconnected state. And
      in order to disable this behavior on subsequent transitions, a
      warm reset should be issued. So add another entry to do that:
      
           echo  > /sys/bus/usb/devices/2-0\:1.0/warm_reset
      
      In general these attributes can also be useful for other USB
      SuperSpeed compliance tests such as electrical and eye diagram
      testing which require CPn patterns to be transmitted.
      Signed-off-by: default avatarJack Pham <jackp@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f624ec70
    • Jack Pham's avatar
      usb: xhci: Support enabling of compliance mode for xhci 1.1 · 4b562bd2
      Jack Pham authored
      To perform SuperSpeed compliance testing the port should first
      be placed into compliance mode. For xHCI 1.0 and prior this
      transition happens automatically when the port is in Training
      and encounters an LFPS timeout. Thus running compliance tests
      against a test appliance may simply just work by simply plugging
      in to the downstream port.
      
      However starting with xHCI 1.1 the transition from Polling.LFPS
      to compliance mode may be disabled by default and needs to be
      explicitly enabled by writing to the PLS field of the PORTSC
      register, which sets an internal 'CTE' (Compliance Transition
      Enabled) flag so that the port will perform the transition the
      next time it encounters LFPS timeout. Whether this is disabled or
      not is determined by the 'CTC' (Compliance Transition Capability)
      bit in the HCCPARAMS2 capability register.
      
      In order to allow a test operator to change this if needed, allow
      a test driver (such as drivers/usb/misc/lvstest.c) to send a
      SET_FEATURE(PORT_LINK_STATE) control message to the root hub to
      update the link state prior to connecting to the port. Subsequently,
      placing the port in warm reset would then disable the flag.
      Signed-off-by: default avatarJack Pham <jackp@codeaurora.org>
      Acked-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4b562bd2
    • Sandeep Singh's avatar
      usb:xhci:Fix regression when ATI chipsets detected · e6b422b8
      Sandeep Singh authored
      The following commit cause a regression on ATI chipsets.
      'commit e788787e ("usb:xhci:Add quirk for Certain
      failing HP keyboard on reset after resume")'
      
      This causes pinfo->smbus_dev to be wrongly set to NULL on
      systems with the ATI chipset that this function checks for first.
      
      Added conditional check for AMD chipsets to avoid the overwriting
      pinfo->smbus_dev.
      Reported-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Fixes: e788787e ("usb:xhci:Add quirk for Certain
      failing HP keyboard on reset after resume")
      cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com>
      cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarSandeep Singh <Sandeep.Singh@amd.com>
      Signed-off-by: default avatarShyam Sundar S K <Shyam-sundar.S-k@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e6b422b8
    • Kai-Heng Feng's avatar
      usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard · de3af5bf
      Kai-Heng Feng authored
      Corsair Strafe RGB keyboard has trouble to initialize:
      
      [ 1.679455] usb 3-6: new full-speed USB device number 4 using xhci_hcd
      [ 6.871136] usb 3-6: unable to read config index 0 descriptor/all
      [ 6.871138] usb 3-6: can't read configurations, error -110
      [ 6.991019] usb 3-6: new full-speed USB device number 5 using xhci_hcd
      [ 12.246642] usb 3-6: unable to read config index 0 descriptor/all
      [ 12.246644] usb 3-6: can't read configurations, error -110
      [ 12.366555] usb 3-6: new full-speed USB device number 6 using xhci_hcd
      [ 17.622145] usb 3-6: unable to read config index 0 descriptor/all
      [ 17.622147] usb 3-6: can't read configurations, error -110
      [ 17.742093] usb 3-6: new full-speed USB device number 7 using xhci_hcd
      [ 22.997715] usb 3-6: unable to read config index 0 descriptor/all
      [ 22.997716] usb 3-6: can't read configurations, error -110
      
      Although it may work after several times unpluging/pluging:
      
      [ 68.195240] usb 3-6: new full-speed USB device number 11 using xhci_hcd
      [ 68.337459] usb 3-6: New USB device found, idVendor=1b1c, idProduct=1b20
      [ 68.337463] usb 3-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
      [ 68.337466] usb 3-6: Product: Corsair STRAFE RGB Gaming Keyboard
      [ 68.337468] usb 3-6: Manufacturer: Corsair
      [ 68.337470] usb 3-6: SerialNumber: 0F013021AEB8046755A93ED3F5001941
      
      Tried three quirks: USB_QUIRK_DELAY_INIT, USB_QUIRK_NO_LPM and
      USB_QUIRK_DEVICE_QUALIFIER, user confirmed that USB_QUIRK_DELAY_INIT alone
      can workaround this issue. Hence add the quirk for Corsair Strafe RGB.
      
      BugLink: https://bugs.launchpad.net/bugs/1678477Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de3af5bf
    • Bhumika Goyal's avatar
      usb: gadget: make snd_pcm_hardware const · 2ab3c34c
      Bhumika Goyal authored
      Make this const as it is only used during a copy operation.
      Done using Coccinelle.
      Signed-off-by: default avatarBhumika Goyal <bhumirks@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2ab3c34c
    • Sergei Shtylyov's avatar
      usb: common: use of_property_read_bool() · 334007d5
      Sergei Shtylyov authored
      Use more compact of_property_read_bool() calls for the boolean properties
      instead  of of_find_property() calls  in of_usb_host_tpl_support() and
      of_usb_update_otg_caps().
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      334007d5
    • Arvind Yadav's avatar
      USB: core: constify vm_operations_struct · b64d47ae
      Arvind Yadav authored
      vm_operations_struct are not supposed to change at runtime.
      All functions working with const vm_operations_struct.
      So mark the non-const structs as const.
      Signed-off-by: default avatarArvind Yadav <arvind.yadav.cs@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b64d47ae
    • Gustavo A. R. Silva's avatar
      usb: misc: ftdi-elan: fix duplicated code for different branches · d527d1ea
      Gustavo A. R. Silva authored
      Refactor code in order to avoid identical code for different branches.
      
      This issue was detected with the help of Coccinelle.
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d527d1ea
    • Douglas Anderson's avatar
      USB: core: Avoid race of async_completed() w/ usbdev_release() · ed62ca2f
      Douglas Anderson authored
      While running reboot tests w/ a specific set of USB devices (and
      slub_debug enabled), I found that once every few hours my device would
      be crashed with a stack that looked like this:
      
      [   14.012445] BUG: spinlock bad magic on CPU#0, modprobe/2091
      [   14.012460]  lock: 0xffffffc0cb055978, .magic: ffffffc0, .owner: cryption contexts: %lu/%lu
      [   14.012460] /1025536097, .owner_cpu: 0
      [   14.012466] CPU: 0 PID: 2091 Comm: modprobe Not tainted 4.4.79 #352
      [   14.012468] Hardware name: Google Kevin (DT)
      [   14.012471] Call trace:
      [   14.012483] [<....>] dump_backtrace+0x0/0x160
      [   14.012487] [<....>] show_stack+0x20/0x28
      [   14.012494] [<....>] dump_stack+0xb4/0xf0
      [   14.012500] [<....>] spin_dump+0x8c/0x98
      [   14.012504] [<....>] spin_bug+0x30/0x3c
      [   14.012508] [<....>] do_raw_spin_lock+0x40/0x164
      [   14.012515] [<....>] _raw_spin_lock_irqsave+0x64/0x74
      [   14.012521] [<....>] __wake_up+0x2c/0x60
      [   14.012528] [<....>] async_completed+0x2d0/0x300
      [   14.012534] [<....>] __usb_hcd_giveback_urb+0xc4/0x138
      [   14.012538] [<....>] usb_hcd_giveback_urb+0x54/0xf0
      [   14.012544] [<....>] xhci_irq+0x1314/0x1348
      [   14.012548] [<....>] usb_hcd_irq+0x40/0x50
      [   14.012553] [<....>] handle_irq_event_percpu+0x1b4/0x3f0
      [   14.012556] [<....>] handle_irq_event+0x4c/0x7c
      [   14.012561] [<....>] handle_fasteoi_irq+0x158/0x1c8
      [   14.012564] [<....>] generic_handle_irq+0x30/0x44
      [   14.012568] [<....>] __handle_domain_irq+0x90/0xbc
      [   14.012572] [<....>] gic_handle_irq+0xcc/0x18c
      
      Investigation using kgdb() found that the wait queue that was passed
      into wake_up() had been freed (it was filled with slub_debug poison).
      
      I analyzed and instrumented the code and reproduced.  My current
      belief is that this is happening:
      
      1. async_completed() is called (from IRQ).  Moves "as" onto the
         completed list.
      2. On another CPU, proc_reapurbnonblock_compat() calls
         async_getcompleted().  Blocks on spinlock.
      3. async_completed() releases the lock; keeps running; gets blocked
         midway through wake_up().
      4. proc_reapurbnonblock_compat() => async_getcompleted() gets the
         lock; removes "as" from completed list and frees it.
      5. usbdev_release() is called.  Frees "ps".
      6. async_completed() finally continues running wake_up().  ...but
         wake_up() has a pointer to the freed "ps".
      
      The instrumentation that led me to believe this was based on adding
      some trace_printk() calls in a select few functions and then using
      kdb's "ftdump" at crash time.  The trace follows (NOTE: in the trace
      below I cheated a little bit and added a udelay(1000) in
      async_completed() after releasing the spinlock because I wanted it to
      trigger quicker):
      
      <...>-2104   0d.h2 13759034us!: async_completed at start: as=ffffffc0cc638200
      mtpd-2055    3.... 13759356us : async_getcompleted before spin_lock_irqsave
      mtpd-2055    3d..1 13759362us : async_getcompleted after list_del_init: as=ffffffc0cc638200
      mtpd-2055    3.... 13759371us+: proc_reapurbnonblock_compat: free_async(ffffffc0cc638200)
      mtpd-2055    3.... 13759422us+: async_getcompleted before spin_lock_irqsave
      mtpd-2055    3.... 13759479us : usbdev_release at start: ps=ffffffc0cc042080
      mtpd-2055    3.... 13759487us : async_getcompleted before spin_lock_irqsave
      mtpd-2055    3.... 13759497us!: usbdev_release after kfree(ps): ps=ffffffc0cc042080
      <...>-2104   0d.h2 13760294us : async_completed before wake_up(): as=ffffffc0cc638200
      
      To fix this problem we can just move the wake_up() under the ps->lock.
      There should be no issues there that I'm aware of.
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ed62ca2f
    • Bhumika Goyal's avatar
      usb: make device_type const · 53ec7f27
      Bhumika Goyal authored
      Make this const as it is only stored in the type field of a device
      structure, which is const.
      Done using Coccinelle.
      Signed-off-by: default avatarBhumika Goyal <bhumirks@gmail.com>
      Acked-by: default avatarHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      53ec7f27
    • Johan Hovold's avatar
      USB: musb: dsps: add explicit runtime resume at suspend · 706d61b2
      Johan Hovold authored
      The musb_dsps driver is special in that the parent (glue) device's
      driver is accessing registers mapped by the child. The clock is however
      shared and is managed by the grandparent device.
      
      Since commit 869c5978 ("usb: musb: dsps: add support for suspend and
      resume") the dsps driver has been accessing these registers as part of
      suspend and resume.
      
      The parent driver obviously cannot runtime resume the child during
      system suspend and is currently relying on the fact that the child will
      be RPM_ACTIVE throughout suspend. The suspend implementation also makes
      sure to check that the child is indeed present (and hence the clock
      enabled) before accessing the registers.
      
      Let's add an explicit runtime resume of the glue device itself to enable
      the clock before doing the register accesses in case these assumptions ever
      change (i.e. if the child is left runtime suspended).
      
      Note that the glue-timer cancellation is moved after the child-presence
      check to keep error handling simple. This should be fine as the timer is
      not setup until the controller is being registered and at that time
      glue->musb and its driver data have already been initialised.
      
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Daniel Mack <zonque@gmail.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      706d61b2
    • Johan Hovold's avatar
      USB: musb: fix external abort on suspend · 082df8be
      Johan Hovold authored
      Make sure that the controller is runtime resumed when system suspending
      to avoid an external abort when accessing the interrupt registers:
      
        Unhandled fault: external abort on non-linefetch (0x1008) at 0xd025840a
        ...
        [<c05481a4>] (musb_default_readb) from [<c0545abc>] (musb_disable_interrupts+0x84/0xa8)
        [<c0545abc>] (musb_disable_interrupts) from [<c0546b08>] (musb_suspend+0x38/0xb8)
        [<c0546b08>] (musb_suspend) from [<c04a57f8>] (platform_pm_suspend+0x3c/0x64)
      
      This is easily reproduced on a BBB by enabling the peripheral port only
      (as the host port may enable the shared clock) and keeping it
      disconnected so that the controller is runtime suspended. (Well, you
      would also need to the not-yet-merged am33xx-suspend patches by Dave
      Gerlach to be able to suspend the BBB.)
      
      This is a regression that was introduced by commit 1c4d0b4e ("usb:
      musb: Remove pm_runtime_set_irq_safe") which allowed the parent glue
      device to runtime suspend and thereby exposed a couple of older issues:
      
      Register accesses without explicitly making sure the controller is
      runtime resumed during suspend was first introduced by commit c338412b
      ("usb: musb: unconditionally save and restore the context on suspend")
      in 3.14.
      
      Commit a1fc1920 ("usb: musb: core: make sure musb is in RPM_ACTIVE on
      resume") later started setting the RPM status to active during resume,
      and this was also implicitly relying on the parent always being active.
      Since commit 71723f95 ("PM / runtime: print error when activating a
      child to unactive parent") this now also results in the following
      warning:
      
        musb-hdrc musb-hdrc.0: runtime PM trying to activate child device
          musb-hdrc.0 but parent (47401400.usb) is not active
      
      This patch has been verified on 4.13-rc2, 4.12 and 4.9 using a BBB
      (the dsps glue would always be active also in 4.8).
      
      Fixes: c338412b ("usb: musb: unconditionally save and restore the context on suspend")
      Fixes: a1fc1920 ("usb: musb: core: make sure musb is in RPM_ACTIVE on resume")
      Fixes: 1c4d0b4e ("usb: musb: Remove pm_runtime_set_irq_safe")
      Cc: stable <stable@vger.kernel.org>	# 4.8+
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Daniel Mack <zonque@gmail.com>
      Cc: Dave Gerlach <d-gerlach@ti.com>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Tony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      082df8be
    • Bin Liu's avatar
      usb: musb: fix endpoint fifo allocation for 4KB fifo memory · 55aad53f
      Bin Liu authored
      The fifo memory allocation in mode_2_cfg[] doesn't utilize all the 4KB
      memory.
      
      Increse some endpoint fifo buffers to fully use all the 4KB memory. Now
      we can support more webcam usecases on DA8xx.
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      55aad53f
    • Bin Liu's avatar
      usb: musb: print an error message when high bandwidth is unsupported · 1bff25ea
      Bin Liu authored
      There are multiple places in usb core or controller driver which returns
      -EMSGSIZE when a class driver queueing urb failed, so the "Message too
      long" log doesn't help much for understanding the error.
      
      Let the musb driver to specifically print a error message when
      musb_urb_enqueue() returns -EMSGSIZE.
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1bff25ea
    • Bin Liu's avatar
      usb: musb: print an error message when hwep alloc failed · a2f65606
      Bin Liu authored
      Print an error message with qh maxpacket size and hb_mult when hwep
      allocation failed, so we have a better idea why it is failed.
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a2f65606
    • Bin Liu's avatar
      usb: musb: add helper function musb_ep_xfertype_string · 0ccbadaf
      Bin Liu authored
      Add helper function musb_ep_xfertype_string() to return the ep transfer
      type string.
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ccbadaf
    • Greg Kroah-Hartman's avatar
      Merge tag 'usb-ci-v4.14-rc1' of... · 17e15f6f
      Greg Kroah-Hartman authored
      Merge tag 'usb-ci-v4.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb into usb-next
      
      Peter writes:
      
      Chipidea changes for v4.14-rc1
      - Add chipidea support at Nvidia SoCs
      - Improvement for extcon support
      - Some code refines
      17e15f6f
  2. 25 Aug, 2017 1 commit
  3. 24 Aug, 2017 2 commits
  4. 22 Aug, 2017 15 commits
  5. 20 Aug, 2017 5 commits