Change alloc_response_msg() in mad_rmpp.c to return the struct
it allocates directly (or an error code a la ERR_PTR), rather than
returning a status and passing the struct back in a pointer param.
This simplifies the code and gets rid of warnings like
drivers/infiniband/core/mad_rmpp.c: In function nack_recv:
drivers/infiniband/core/mad_rmpp.c:192: warning: msg may be used uninitialized in this function
with newer versions of gcc.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
The MAD layer was violating the DMA API by touching data buffers used
for sends after the DMA mapping was done. This causes problems on
non-cache-coherent architectures, because the device doing DMA won't
see updates to the payload buffers that exist only in the CPU cache.
Fix this by having all MAD consumers use ib_create_send_mad() to
allocate their send buffers, and moving the DMA mapping into the MAD
layer so it can be done just before calling send (and after any
modifications of the send buffer by the MAD layer).
Tested on a non-cache-coherent PowerPC 440SPe system.
Signed-off-by: Sean Hefty <sean.hefty@intel.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Based on simplification idea from Sean Hefty <sean.hefty@intel.com>
Signed-off-by: Hal Rosenstock <halr@voltaire.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Clean up code by using enums instead of hard-coded magic numbers.
Signed-off-by: Sean Hefty <sean.hefty@intel.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
- Fix payload length of middle RMPP sent segments. Middle payload
lengths should be 0 on the send side.
(This is perhaps a compliance and should not be an interop issue as
middle payload lengths are supposed to be ignored on receive).
- Fix length in first segment of multipacket sends
(This is a compliance issue but does not affect at least OpenIB to
OpenIB RMPP transfers).
Signed-off-by: Hal Rosenstock <halr@voltaire.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Roland Dreier