1. 05 Jul, 2012 4 commits
    • Johan Hovold's avatar
      USB: metro-usb: fix tty_flip_buffer_push use · b7d28e32
      Johan Hovold authored
      Do not set low_latency flag at open as tty_flip_buffer_push must not be
      called in IRQ context with low_latency set.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohan Hovold <jhovold@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b7d28e32
    • Gaosen Zhang's avatar
      USB: option: Add MEDIATEK product ids · aacef9c5
      Gaosen Zhang authored
      Signed-off-by: default avatarGaosen Zhang <gaosen.zhang@mediatek.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aacef9c5
    • Bjørn Mork's avatar
      USB: option: add ZTE MF60 · 8e16e33c
      Bjørn Mork authored
      Switches into a composite device by ejecting the initial
      driver CD.  The four interfaces are: QCDM, AT, QMI/wwan
      and mass storage.  Let this driver manage the two serial
      interfaces:
      
      T:  Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 28 Spd=480  MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=19d2 ProdID=1402 Rev= 0.00
      S:  Manufacturer=ZTE,Incorporated
      S:  Product=ZTE WCDMA Technologies MSM
      S:  SerialNumber=xxxxx
      C:* #Ifs= 4 Cfg#= 1 Atr=c0 MxPwr=500mA
      I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
      E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      I:* If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
      E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8e16e33c
    • Greg Kroah-Hartman's avatar
      Merge tag 'for-usb-linus-2012-07-02' of... · d25ae369
      Greg Kroah-Hartman authored
      Merge tag 'for-usb-linus-2012-07-02' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus
      
      xhci: Fix driver hang and resume error path.
      
      Hi Greg,
      
      Here's two bug fixes for 3.5.  The first fixes an issue with port
      connections not being reported to the USB core after a system resume.
      The second fixes a driver hang when there are two back to back stalls on
      an endpoint.
      
      Sarah Sharp
      d25ae369
  2. 02 Jul, 2012 2 commits
    • Sarah Sharp's avatar
      xhci: Fix hang on back-to-back Set TR Deq Ptr commands. · 0d9f78a9
      Sarah Sharp authored
      The Microsoft LifeChat 3000 USB headset was causing a very reproducible
      hang whenever it was plugged in.  At first, I thought the host
      controller was producing bad transfer events, because the log was filled
      with errors like:
      
      xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD
      
      However, it turned out to be an xHCI driver bug in the ring expansion
      patches.  The bug is triggered When there are two ring segments, and a
      TD that ends just before a link TRB, like so:
      
       ______________                     _____________
      |              |              ---> | setup TRB B |
       ______________               |     _____________
      |              |              |    |  data TRB B |
       ______________               |     _____________
      | setup TRB A  | <-- deq      |    |  data TRB B |
       ______________               |     _____________
      | data TRB A   |              |    |             | <-- enq, deq''
       ______________               |     _____________
      | status TRB A |              |    |             |
       ______________               |     _____________
      |  link TRB    |---------------    |  link TRB   |
       _____________  <--- deq'           _____________
      
      TD A (the first control transfer) stalls on the data phase.  That halts
      the ring.  The xHCI driver moves the hardware dequeue pointer to the
      first TRB after the stalled transfer, which happens to be the link TRB.
      
      Once the Set TR dequeue pointer command completes, the function
      update_ring_for_set_deq_completion runs.  That function is supposed to
      update the xHCI driver's dequeue pointer to match the internal hardware
      dequeue pointer.  On the first call this would work fine, and the
      software dequeue pointer would move to deq'.
      
      However, if the transfer immediately after that stalled (TD B in this
      case), another Set TR Dequeue command would be issued.  That would move
      the hardware dequeue pointer to deq''.  Once that command completed,
      update_ring_for_set_deq_completion would run again.
      
      The original code would unconditionally increment the software dequeue
      pointer, which moved the pointer off the ring segment into la-la-land.
      The while loop would happy increment the dequeue pointer (possibly
      wrapping it) until it matched the hardware pointer value.
      
      The while loop would also access all the memory in between the first
      ring segment and the second ring segment to determine if it was a link
      TRB.  This could cause general protection faults, although it was
      unlikely because the ring segments came from a DMA pool, and would often
      have consecutive memory addresses.
      
      If nothing in that space looked like a link TRB, the deq_seg pointer for
      the ring would remain on the first segment.  Thus, the deq_seg and the
      software dequeue pointer would get out of sync.
      
      When the next transfer event came in after the stalled transfer, the
      xHCI driver code would attempt to convert the software dequeue pointer
      into a DMA address in order to compare the DMA address for the completed
      transfer.  Since the deq_seg and the dequeue pointer were out of sync,
      xhci_trb_virt_to_dma would return NULL.
      
      The transfer event would get ignored, the transfer would eventually
      timeout, and we would mistakenly convert the finished transfer to no-op
      TRBs.  Some kernel driver (maybe xHCI?) would then get stuck in an
      infinite loop in interrupt context, and the whole machine would hang.
      
      This patch should be backported to kernels as old as 3.4, that contain
      the commit b008df60 "xHCI: count free
      TRBs on transfer ring"
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Andiry Xu <andiry.xu@amd.com>
      Cc: stable@vger.kernel.org
      0d9f78a9
    • Stanislaw Ledwon's avatar
      usb: Add support for root hub port status CAS · 8bea2bd3
      Stanislaw Ledwon authored
      The host controller port status register supports CAS (Cold Attach
      Status) bit. This bit could be set when USB3.0 device is connected
      when system is in Sx state. When the system wakes to S0 this port
      status with CAS bit is reported and this port can't be used by any
      device.
      
      When CAS bit is set the port should be reset by warm reset. This
      was not supported by xhci driver.
      
      The issue was found when pendrive was connected to suspended
      platform. The link state of "Compliance Mode" was reported together
      with CAS bit. This link state was also not supported by xhci and
      core/hub.c.
      
      The CAS bit is defined only for xhci root hub port and it is
      not supported on regular hubs. The link status is used to force
      warm reset on port. Make the USB core issue a warm reset when port
      is in ether the 'inactive' or 'compliance mode'. Change the xHCI driver
      to report 'compliance mode' when the CAS is set. This force warm reset
      on the root hub port.
      
      This patch should be backported to stable kernels as old as 3.2, that
      contain the commit 10d674a8 "USB: When
      hot reset for USB3 fails, try warm reset."
      Signed-off-by: default avatarStanislaw Ledwon <staszek.ledwon@linux.intel.com>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: default avatarAndiry Xu <andiry.xu@amd.com>
      Cc: stable@vger.kernel.org
      8bea2bd3
  3. 30 Jun, 2012 13 commits
  4. 29 Jun, 2012 13 commits
  5. 28 Jun, 2012 8 commits