[openib-general] FW: [PATCH fixed] [RFC] IB/srp: enable multiple connections to the same target

[Roland Dreier]

 > I am also having new problems configuring SRP with OFED 1.1 rc7, I have
 > asked Roland to take a look on my test networks.

The problem is that Cisco SRP targets insist on the initiator ID being
8 bytes of 0 followed by the initiator node GUID.  The source says

	/*
	 * Topspin/Cisco SRP targets will reject our login unless we
	 * zero out the first 8 bytes of our initiator port ID.  The
	 * second 8 bytes must be our local node GUID, but we always
	 * use that anyway.
	 */

but with the change to allow userspace-specified initiator IDs, we
don't use the node GUID anyway.

I added the following on top of the "multiple connections" patch that
was queued for 2.6.19.  Can this be put into OFED as well?

 - R.

diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c
index 3bf0c5b..4b09147 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -359,15 +359,16 @@ static int srp_send_req(struct srp_targe
 
 	/*
 	 * Topspin/Cisco SRP targets will reject our login unless we
-	 * zero out the first 8 bytes of our initiator port ID.  The
-	 * second 8 bytes must be our local node GUID, but we always
-	 * use that anyway.
+	 * zero out the first 8 bytes of our initiator port ID and set
+	 * the second 8 bytes to the local node GUID.
 	 */
 	if (topspin_workarounds && !memcmp(&target->ioc_guid, topspin_oui, 3)) {
 		printk(KERN_DEBUG PFX "Topspin/Cisco initiator port ID workaround "
 		       "activated for target GUID %016llx\n",
 		       (unsigned long long) be64_to_cpu(target->ioc_guid));
 		memset(req->priv.initiator_port_id, 0, 8);
+		memcpy(req->priv.initiator_port_id + 8,
+		       &target->srp_host->dev->dev->node_guid, 8);
 	}
 
 	status = ib_send_cm_req(target->cm_id, &req->param);