RE: Endianess in cxgb4

["Steve Wise" <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>]

> On Tue, Oct 24, 2017 at 09:37:59PM +0300, Leon Romanovsky wrote:
> > Hi Steve,
> >
> > I reviewed my reports from various static checkers and saw strange code
> > in build_tpte_memreg() function that in drivers/infiniband/hw/cxgb4/qp.c.
> >
> > That function has following code:
> >  614         fr->r2 = cpu_to_be32(0);
> >  615         fr->stag = cpu_to_be32(mhp->ibmr.rkey);
> >
> > The r2, stag and rkey are u32, why do you need cpu_to_be32() conversion?
> >
> > The error report which I got is:
> >
> >  134 drivers/infiniband/hw/cxgb4/qp.c:614:16: warning: incorrect type in
> assignment (different base types)
> >  135 drivers/infiniband/hw/cxgb4/qp.c:614:16:    expected unsigned int
[unsigned]
> [usertype] r2
> >  136 drivers/infiniband/hw/cxgb4/qp.c:614:16:    got restricted __be32
[usertype]
> <noident>
> >  137 drivers/infiniband/hw/cxgb4/qp.c:615:18: warning: incorrect type in
> assignment (different base types)
> >  138 drivers/infiniband/hw/cxgb4/qp.c:615:18:    expected unsigned int
[unsigned]
> [usertype] stag
> >  139 drivers/infiniband/hw/cxgb4/qp.c:615:18:    got restricted __be32
[usertype]
> <noident>
> 
> I looked at cxgb in userspace and gave up. It seemed to be storing be
> and host values in the same memory locations :(

The Terminator HW/FW WRs are in BE always, with the exception that something
"opaque and owned by the host" is in HBO.  The only one I can think of is the
wrid field in each Terminator SQE.  It is provided by the host in each WR, and
is opaque to the HW/FW.  That is, the HW/FW does not interpret this 16b field,
but simply reflects it in the corresponding CQE.  

See my reply to Leon regarding the above issue...

Steve.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html