summaryrefslogtreecommitdiff
path: root/drivers/infiniband/hw/cxgb3
diff options
context:
space:
mode:
authorRoland Dreier <rdreier@cisco.com>2008-03-28 10:28:17 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2008-03-28 10:45:32 -0700
commit1f71f50342c6fe4fbdebe63b0fd196972a70e281 (patch)
tree44e39c73f0e194e3a7df6c5a34e667161b2f0dc4 /drivers/infiniband/hw/cxgb3
parent8c178beeb20ce3801c4851d41342d0ca32ad292c (diff)
RDMA/cxgb3: Program hardware IRD with correct value
Because of a typo in iwch_accept_cr(), the cxgb3 connection handling code programs the hardware IRD (incoming RDMA read queue depth) with the value that is passed in for the ORD (outgoing RDMA read queue depth). In particular this means that if an application passes in IRD > 0 and ORD = 0 (which is a completely sane and valid thing to do for an app that expects only incoming RDMA read requests), then the hardware will end up programmed with IRD = 0 and the app will fail in a mysterious way. Fix this by using "ep->ird" instead of "ep->ord" in the intended place. Signed-off-by: Roland Dreier <rolandd@cisco.com> Acked-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/infiniband/hw/cxgb3')
-rw-r--r--drivers/infiniband/hw/cxgb3/iwch_cm.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c b/drivers/infiniband/hw/cxgb3/iwch_cm.c
index 320f2b6ddee6..99f2f2a46bf7 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_cm.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_cm.c
@@ -1745,7 +1745,7 @@ int iwch_accept_cr(struct iw_cm_id *cm_id, struct iw_cm_conn_param *conn_param)
/* bind QP to EP and move to RTS */
attrs.mpa_attr = ep->mpa_attr;
- attrs.max_ird = ep->ord;
+ attrs.max_ird = ep->ird;
attrs.max_ord = ep->ord;
attrs.llp_stream_handle = ep;
attrs.next_state = IWCH_QP_STATE_RTS;