aboutsummaryrefslogtreecommitdiff
path: root/drivers/scsi
diff options
context:
space:
mode:
authorJack Morgenstein <jackm@mellanox.co.il>2005-12-15 14:36:24 -0800
committerRoland Dreier <rolandd@cisco.com>2005-12-15 14:36:24 -0800
commitd1646f86a2a05a956adbb163c81a81bd621f055e (patch)
treee7b321e9b424682ea08b5214e1c415131e7d215d /drivers/scsi
parent576d2e4e40315e8140c04be99cd057720d8a3817 (diff)
IB/mthca: Fix IB_QP_ACCESS_FLAGS handling.
This patch corrects some corner cases in managing the RAE/RRE bits in the mthca qp context. These bits need to be zero if the user requests max_dest_rd_atomic of zero. The bits need to be restored to the value implied by the qp access flags attribute in a previous (or the current) modify-qp command if the dest_rd_atomic variable is changed to non-zero. In the current implementation, the following scenario will not work: RESET-to-INIT set QP access flags to all disabled (zeroes) INIT-to-RTR set max_dest_rd_atomic=10, AND set qp_access_flags = IB_ACCESS_REMOTE_READ | IB_ACCESS_REMOTE_ATOMIC The current code will incorrectly take the access-flags value set in the RESET-to-INIT transition. We can simplify, and correct, this IB_QP_ACCESS_FLAGS handling: it is always safe to set qp access flags in the firmware command if either of IB_QP_MAX_DEST_RD_ATOMIC or IB_QP_ACCESS_FLAGS is set, so let's just set it to the correct value, always. Signed-off-by: Jack Morgenstein <jackm@mellanox.co.il> Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by: Roland Dreier <rolandd@cisco.com>
Diffstat (limited to 'drivers/scsi')
0 files changed, 0 insertions, 0 deletions