Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 07 4月, 2014 27 次提交
  3. 14 3月, 2014 3 次提交
  5. 10 3月, 2014 1 次提交
  7. 08 3月, 2014 9 次提交
    • 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
    • S
      IB/mlx5: Expose support for signature MR feature · 2dea9094
      由 Sagi Grimberg 提交于 
      Currently support only T10-DIF types of signature handover operations
(types 1|2|3).
Signed-off-by: NSagi Grimberg <sagig@mellanox.com>
Signed-off-by: NRoland Dreier <roland@purestorage.com>
      2dea9094
    • S
      IB/mlx5: Collect signature error completion · d5436ba0
      由 Sagi Grimberg 提交于 
      This commit takes care of the generated signature error CQE generated
by the HW (if happened).  The underlying mlx5 driver will handle
signature error completions and will mark the relevant memory region
as dirty.

Once the consumer gets the completion for the transaction, it must
check for signature errors on signature memory region using a new
lightweight verb ib_check_mr_status().

In case the user doesn't check for signature error (i.e. doesn't call
ib_check_mr_status() with status check IB_MR_CHECK_SIG_STATUS), the
memory region cannot be used for another signature operation
(REG_SIG_MR work request will fail).
Signed-off-by: NSagi Grimberg <sagig@mellanox.com>
Signed-off-by: NRoland Dreier <roland@purestorage.com>
      d5436ba0
    • S
      IB/mlx5: Support IB_WR_REG_SIG_MR · e6631814
      由 Sagi Grimberg 提交于 
      This patch implements IB_WR_REG_SIG_MR posted by the user.

Baisically this WR involves 3 WQEs in order to prepare and properly
register the signature layout:

1. post UMR WR to register the sig_mr in one of two possible ways:
    * In case the user registered a single MR for data so the UMR data segment
      consists of:
      - single klm (data MR) passed by the user
      - BSF with signature attributes requested by the user.
    * In case the user registered 2 MRs, one for data and one for protection,
      the UMR consists of:
      - strided block format which includes data and protection MRs and
        their repetitive block format.
      - BSF with signature attributes requested by the user.

2. post SET_PSV in order to set the memory domain initial
   signature parameters passed by the user.
   SET_PSV is not signaled and solicited CQE.

3. post SET_PSV in order to set the wire domain initial
   signature parameters passed by the user.
   SET_PSV is not signaled and solicited CQE.

* After this compound WR we place a small fence for next WR to come.

This patch also introduces some helper functions to set the BSF correctly
and determining the signature format selectors.
Signed-off-by: NSagi Grimberg <sagig@mellanox.com>
Signed-off-by: NRoland Dreier <roland@purestorage.com>
      e6631814
    • S
      IB/mlx5: Keep mlx5 MRs in a radix tree under device · 3bcdb17a
      由 Sagi Grimberg 提交于 
      This will be useful when processing signature errors on a specific
key.  The mlx5 driver will lookup the matching mlx5 memory region
structure and mark it as dirty (contains signature errors).
Signed-off-by: NSagi Grimberg <sagig@mellanox.com>
Signed-off-by: NRoland Dreier <roland@purestorage.com>
      3bcdb17a
    • S
      IB/mlx5: Remove MTT access mode from umr flags helper function · 2ac45934
      由 Sagi Grimberg 提交于 
      get_umr_flags helper function might be used for types of access modes
other than ACCESS_MODE_MTT, such as ACCESS_MODE_KLM.  So remove it from
helper, and callers will add their own access mode flag.

This commit does not add/change functionality.
Signed-off-by: NSagi Grimberg <sagig@mellanox.com>
Signed-off-by: NRoland Dreier <roland@purestorage.com>
      2ac45934