Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 18 6月, 2007 4 次提交
    • R
      IB/mlx4: Handle FW command interface rev 3 · 5ae2a7a8
      由 Roland Dreier 提交于 
      Upcoming firmware introduces command interface revision 3, which
changes the way port capabilities are queried and set.  Update the
driver to handle both the new and old command interfaces by adding a
new MLX4_FLAG_OLD_PORT_CMDS that it is set after querying the firmware
interface revision and then using the correct interface based on the
setting of the flag.
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      5ae2a7a8
    • J
      IB/mlx4: Handle buffer wraparound in __mlx4_ib_cq_clean() · 082dee32
      由 Jack Morgenstein 提交于 
      When compacting CQ entries, we need to set the correct value of the
ownership bit in case the value is different between the index we copy
the CQE from and the index we copy it to.

Found by Ronni Zimmerman of Mellanox.
Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      082dee32
    • R
      IB/mlx4: Get rid of max_inline_data calculation · 54e95f8d
      由 Roland Dreier 提交于 
      The calculation of max_inline_data in set_kernel_sq_size() is bogus,
since it doesn't take into account the fact that inline segments may
not cross a 64-byte boundary, and hence multiple inline segments will
probably need to be used to post large inline sends.

We don't support inline sends for kernel QPs anyway, so there's no
point in doing this calculation anyway, since the field is just zeroed
out a little later.  So just delete the bogus calculation.
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      54e95f8d
    • R
      IB/mlx4: Handle new FW requirement for send request prefetching · 0e6e7416
      由 Roland Dreier 提交于 
      New ConnectX firmware introduces FW command interface revision 2,
which requires that for each QP, a chunk of send queue entries (the
"headroom") is kept marked as invalid, so that the HCA doesn't get
confused if it prefetches entries that haven't been posted yet.  Add
code to the driver to do this, and also update the user ABI so that
userspace can request that the prefetcher be turned off for userspace
QPs (we just leave the prefetcher on for all kernel QPs).

Unfortunately, marking send queue entries this way is confuses older
firmware, so we change the driver to allow only FW command interface
revisions 2.  This means that users will have to update their firmware
to work with the new driver, but the firmware is changing quickly and
the old firmware has lots of other bugs anyway, so this shouldn't be too
big a deal.

Based on a patch from Jack Morgenstein <jackm@dev.mellanox.co.il>.
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      0e6e7416
  3. 13 6月, 2007 2 次提交
  5. 12 6月, 2007 21 次提交
  7. 11 6月, 2007 2 次提交
    • T
      libata: limit post SRST nsect/lbal wait to ~100ms · e141d999
      由 Tejun Heo 提交于 
      After SRST, libata used to wait for nsect/lbal to be set to 1/1 for
the slave device.  However, some ATAPI devices don't set nsect/lbal
after SRST and the wait itself isn't too useful as we're gonna wait
for !BSY right after that anyway.

Before reset-seq update, nsect/lbal wait failure used to be ignored
and caused 30sec delay during detection.  After reset-seq, all
timeouts are considered error conditions making libata fail to detect
such ATAPI devices.

This patch limits nsect/lbal wait to around 100ms.  This should give
acceptable behavior to such ATAPI devices while not disturbing the
heavily used code path too much.
Signed-off-by: NTejun Heo <htejun@gmail.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
      e141d999
    • T
      libata: force PIO on IOMEGA ZIP 250 ATAPI · 5acd50f6
      由 Tejun Heo 提交于 
      IOMEGA ZIP 250 ATAPI claims MWDMA0 support but fails SETXFERMODE if
asked to configure itself to MWDMA0.  Force PIO.

This fixes bugzilla bug#8497.
Signed-off-by: NTejun Heo <htejun@gmail.com>
Cc: Calvin Walton <calvin.walton@gmail.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
      5acd50f6
  9. 10 6月, 2007 11 次提交