1. 14 Dec, 2016 3 commits
    • Bart Van Assche's avatar
      IB/mlx4: Rework special QP creation error path · b42dde47
      Bart Van Assche authored
      The special QP creation error path relies on offset_of(struct mlx4_ib_sqp,
      qp) == 0. Remove this assumption because that makes the QP creation
      code easier to understand.
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Yishai Hadas <yishaih@mellanox.com>
      Reviewed-by: default avatarLaurence Oberman <loberman@redhat.com>
      Reviewed-by: default avatarYishai Hadas <yishaih@mellanox.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      b42dde47
    • Arnd Bergmann's avatar
      IB/mlx4: avoid a -Wmaybe-uninitialize warning · e9817246
      Arnd Bergmann authored
      There is an old warning about mlx4_SW2HW_EQ_wrapper on x86:
      
      ethernet/mellanox/mlx4/resource_tracker.c: In function ‘mlx4_SW2HW_EQ_wrapper’:
      ethernet/mellanox/mlx4/resource_tracker.c:3071:10: error: ‘eq’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      The problem here is that gcc won't track the state of the variable
      across a spin_unlock. Moving the assignment out of the lock is
      safe here and avoids the warning.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarYishai Hadas <yishaih@mellanox.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      e9817246
    • Arnd Bergmann's avatar
      IB/mlx5: avoid bogus -Wmaybe-uninitialized warning · 14ab8896
      Arnd Bergmann authored
      We get a false-positive warning in linux-next for the mlx5 driver:
      
      infiniband/hw/mlx5/mr.c: In function ‘mlx5_ib_reg_user_mr’:
      infiniband/hw/mlx5/mr.c:1172:5: error: ‘order’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
      infiniband/hw/mlx5/mr.c:1161:6: note: ‘order’ was declared here
      infiniband/hw/mlx5/mr.c:1173:6: error: ‘ncont’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
      infiniband/hw/mlx5/mr.c:1160:6: note: ‘ncont’ was declared here
      infiniband/hw/mlx5/mr.c:1173:6: error: ‘page_shift’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
      infiniband/hw/mlx5/mr.c:1158:6: note: ‘page_shift’ was declared here
      infiniband/hw/mlx5/mr.c:1143:13: error: ‘npages’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
      infiniband/hw/mlx5/mr.c:1159:6: note: ‘npages’ was declared here
      
      I had a trivial workaround for gcc-5 or higher, but that didn't work
      on gcc-4.9 unfortunately.
      
      The only way I found to avoid the warnings for gcc-4.9, short of
      initializing each of the arguments first was to change the calling
      conventions to separate the error code from the umem pointer. This
      avoids casting the error codes from one pointer to another incompatible
      pointer, and lets gcc figure out when that the data is actually valid
      whenever we return successfully.
      Acked-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      14ab8896
  2. 13 Dec, 2016 29 commits
  3. 17 Nov, 2016 8 commits