[ofw] incorrect SID generation in WvGetServiceId

[Hefty, Sean]

> WvGetServiceId swaps the port number in the sockaddr but shouldn't.  The
> port number in a sockaddr structure is already in network order.  See
> http://msdn.microsoft.com/en-us/library/ff570823(VS.85).aspx, the remarks
> section:
> " All of the data in the SOCKADDR_IN structure, except for the address
> family, must be specified in network-byte-order (big-endian)."

Here's WvGetServiceId:

static UINT64 WvGetServiceId(UINT16 EpType, WV_IO_SOCKADDR_DATA *pAddress)
{
	return RtlUlonglongByteSwap(((UINT64)EpType << 16) +
		   RtlUshortByteSwap(pAddress->SockAddr.In.SinPort));
}

It swaps the port to host order, forms the SID in host order, then swaps the SID back to network order.  This matches the Linux implementation:

static __be64 cma_get_service_id(enum rdma_port_space ps, struct sockaddr *addr)
{
	return cpu_to_be64(((u64)ps << 16) + be16_to_cpu(cma_port(addr)));
}

>From the RDMA CM Annex to the IB spec:

"The last two bytes of the Service ID are the ULP port for the IP protocol number. For
example, for SCTP NFSv4-RDMA default port the Service ID is 0x0000000001840801 (port 2049)"

Based on the example, the port is stored in the service ID in host order (2049 = 0x0801), not network order.

- Sean