Hi all,
Today's linux-next merge of the rdma tree got a conflict in:
drivers/infiniband/hw/mlx5/mlx5_ib.h
between commit:
0e6613b41edd ("IB/mlx5: Consolidate use_umr checks into single function")
from the rdma-fixes tree and commit:
3e1f000ff746 ("IB/mlx5: Support per device q counters in switchdev mode")
from the rdma tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/infiniband/hw/mlx5/mlx5_ib.h
index 9ae587b74b12,cb41a7e6255a..000000000000
--- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
+++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
@@@ -1475,18 -1475,5 +1475,19 @@@ int bfregn_to_uar_index(struct mlx5_ib_
bool dyn_bfreg);
int mlx5_ib_qp_set_counter(struct ib_qp *qp, struct rdma_counter *counter);
+ u16 mlx5_ib_get_counters_id(struct mlx5_ib_dev *dev, u8 port_num);
+
+static inline bool mlx5_ib_can_use_umr(struct mlx5_ib_dev *dev,
+ bool do_modify_atomic)
+{
+ if (MLX5_CAP_GEN(dev->mdev, umr_modify_entity_size_disabled))
+ return false;
+
+ if (do_modify_atomic &&
+ MLX5_CAP_GEN(dev->mdev, atomic) &&
+ MLX5_CAP_GEN(dev->mdev, umr_modify_atomic_disabled))
+ return false;
+
+ return true;
+}
#endif /* MLX5_IB_H */
On Fri, Aug 23, 2019 at 12:22:27PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the rdma tree got a conflict in:
>
> drivers/infiniband/hw/mlx5/mlx5_ib.h
>
> between commit:
>
> 0e6613b41edd ("IB/mlx5: Consolidate use_umr checks into single function")
>
> from the rdma-fixes tree and commit:
>
> 3e1f000ff746 ("IB/mlx5: Support per device q counters in switchdev mode")
>
> from the rdma tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Looks OK to me, thanks
Jason