IB/mthca: Fix IB_QP_ACCESS_FLAGS handling.
commitd1646f86a2a05a956adbb163c81a81bd621f055e
authorJack Morgenstein <jackm@mellanox.co.il>
Thu, 15 Dec 2005 22:36:24 +0000 (15 14:36 -0800)
committerRoland Dreier <rolandd@cisco.com>
Thu, 15 Dec 2005 22:36:24 +0000 (15 14:36 -0800)
treee7b321e9b424682ea08b5214e1c415131e7d215d
parent576d2e4e40315e8140c04be99cd057720d8a3817
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>
drivers/infiniband/hw/mthca/mthca_qp.c