1. 07 4月, 2014 32 次提交
  2. 14 3月, 2014 3 次提交
  3. 10 3月, 2014 1 次提交
  4. 08 3月, 2014 4 次提交
    • M
      Revert "USBNET: ax88179_178a: enable tso if usb host supports sg dma" · 469d417b
      Mathias Nyman 提交于
      This reverts commit 3804fad4.
      
      This commit, together with commit 247bf557
      "xhci 1.0: Limit arbitrarily-aligned scatter gather." were
      origially added to get xHCI 1.0 hosts and usb ethernet ax88179_178a devices
      working together with scatter gather. xHCI 1.0 hosts pose some requirement on how transfer
      buffers are aligned, setting this requirement for 1.0 hosts caused USB 3.0 mass
      storage devices to fail more frequently.
      
      USB 3.0 mass storage devices used to work before 3.14-rc1.  Theoretically,
      the TD fragment rules could have caused an occasional disk glitch.
      Now the devices *will* fail, instead of theoretically failing.
      >From a user perspective, this looks like a regression; the USB device obviously
      fails on 3.14-rc1, and may sometimes silently fail on prior kernels.
      
      The proper soluition is to implement the TD fragment rules for xHCI 1.0 hosts,
      but for now, revert this patch until scatter gather can be properly supported.
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      469d417b
    • M
      Revert "xhci 1.0: Limit arbitrarily-aligned scatter gather." · e2ed5114
      Mathias Nyman 提交于
      This reverts commit 247bf557.
      
      This commit, together with commit 3804fad4
      "USBNET: ax88179_178a: enable tso if usb host supports sg dma" were
      origially added to get xHCI 1.0 hosts and usb ethernet ax88179_178a devices
      working together with scatter gather. xHCI 1.0 hosts pose some requirement on how transfer
      buffers are aligned, setting this requirement for 1.0 hosts caused USB 3.0 mass
      storage devices to fail more frequently.
      
      USB 3.0 mass storage devices used to work before 3.14-rc1.  Theoretically,
      the TD fragment rules could have caused an occasional disk glitch.
      Now the devices *will* fail, instead of theoretically failing.
      >From a user perspective, this looks like a regression; the USB device obviously
      fails on 3.14-rc1, and may sometimes silently fail on prior kernels.
      
      The proper soluition is to implement the TD fragment rules required, but for now
      this patch needs to be reverted to get USB 3.0 mass storage devices working at the
      level they used to.
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e2ed5114
    • J
      usb: Make DELAY_INIT quirk wait 100ms between Get Configuration requests · d86db25e
      Julius Werner 提交于
      The DELAY_INIT quirk only reduces the frequency of enumeration failures
      with the Logitech HD Pro C920 and C930e webcams, but does not quite
      eliminate them. We have found that adding a delay of 100ms between the
      first and second Get Configuration request makes the device enumerate
      perfectly reliable even after several weeks of extensive testing. The
      reasons for that are anyone's guess, but since the DELAY_INIT quirk
      already delays enumeration by a whole second, wating for another 10th of
      that isn't really a big deal for the one other device that uses it, and
      it will resolve the problems with these webcams.
      Signed-off-by: NJulius Werner <jwerner@chromium.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d86db25e
    • J
      usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e · e0429362
      Julius Werner 提交于
      We've encountered a rare issue when enumerating two Logitech webcams
      after a reboot that doesn't power cycle the USB ports. They are spewing
      random data (possibly some leftover UVC buffers) on the second
      (full-sized) Get Configuration request of the enumeration phase. Since
      the data is random this can potentially cause all kinds of odd behavior,
      and since it occasionally happens multiple times (after the kernel
      issues another reset due to the garbled configuration descriptor), it is
      not always recoverable. Set the USB_DELAY_INIT quirk that seems to work
      around the issue.
      Signed-off-by: NJulius Werner <jwerner@chromium.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e0429362