[GIT PULL] Please Pull Mellanox Shared Code

[GIT PULL] Please Pull Mellanox Shared Code

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]

Hi Doug and David,

This is Mellanox mlx5_core shared code for both net-next and RDMA
trees for 4.8 kernel cycle.

This mlx5_ifc update introduces following ConnectX-4 features.

* netdev part:
 - MLX5_CQ_PERIOD_NUM_MODES for adaptive moderation support
 - QoS rate limiting
 - SQ context rate limiting
 - Auto negotiation fields in PTYS register
 - Source SQN field in flow table entry match structure
 - DCBX parameters

* RDMA part:
 - New XRQ opcodes, commands and capabilities layout
 - Extend Q counters definition to support IB.

Thank you,
  Saeed and Leon.

The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b:

  Linux 4.7-rc2 (2016-06-05 14:31:26 -0700)

are available in the git repository at:

  git@gitolite.kernel.org:pub/scm/linux/kernel/git/leon/linux-rdma tags/shared

for you to fetch changes up to 7486216b3a0bd26375b17b2cc168a311106cea70:

  {net,IB}/mlx5: mlx5_ifc updates (2016-06-10 13:29:14 +0300)

----------------------------------------------------------------
Saeed Mahameed (1):
      {net,IB}/mlx5: mlx5_ifc updates

 include/linux/mlx5/mlx5_ifc.h | 275 ++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 263 insertions(+), 12 deletions(-)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [GIT PULL] Please Pull Mellanox Shared Code

[Or Gerlitz]

On Mon, Jun 13, 2016 at 3:03 PM, Leon Romanovsky <leon@kernel.org> wrote:
> Hi Doug and David,
>
> This is Mellanox mlx5_core shared code for both net-next and RDMA
> trees for 4.8 kernel cycle.
>
> This mlx5_ifc update introduces following ConnectX-4 features.
>
> * netdev part:
>  - MLX5_CQ_PERIOD_NUM_MODES for adaptive moderation support
>  - QoS rate limiting
>  - SQ context rate limiting
>  - Auto negotiation fields in PTYS register
>  - Source SQN field in flow table entry match structure
>  - DCBX parameters
>
> * RDMA part:
>  - New XRQ opcodes, commands and capabilities layout
>  - Extend Q counters definition to support IB.

Leon, any reason not to send the actual patch over the list as any
other submission we do? please send it over.

Or.

Re: [GIT PULL] Please Pull Mellanox Shared Code

[David Miller]

A bare pull request does not work.

You must post the actual patches so that they can be reviewed
properly.

Re: [GIT PULL] Please Pull Mellanox Shared Code

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 378 bytes --]

On Tue, Jun 14, 2016 at 02:12:49AM -0400, David Miller wrote:
> 
> A bare pull request does not work.
> 
> You must post the actual patches so that they can be reviewed
> properly.

Sorry, It was first time attempt to get the sense for the proper procedure.

I will send the patch as a reply to this pull request and my hope that it will
be fine with you.

Thanks.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [GIT PULL] Please Pull Mellanox Shared Code

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 14773 bytes --]

On Mon, Jun 13, 2016 at 03:03:01PM +0300, Leon Romanovsky wrote:
> Hi Doug and David,
> 
> This is Mellanox mlx5_core shared code for both net-next and RDMA
> trees for 4.8 kernel cycle.
> 
> This mlx5_ifc update introduces following ConnectX-4 features.
> 
> * netdev part:
>  - MLX5_CQ_PERIOD_NUM_MODES for adaptive moderation support
>  - QoS rate limiting
>  - SQ context rate limiting
>  - Auto negotiation fields in PTYS register
>  - Source SQN field in flow table entry match structure
>  - DCBX parameters
> 
> * RDMA part:
>  - New XRQ opcodes, commands and capabilities layout
>  - Extend Q counters definition to support IB.
> 
> Thank you,
>   Saeed and Leon.
> 
> The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b:
> 
>   Linux 4.7-rc2 (2016-06-05 14:31:26 -0700)
> 
> are available in the git repository at:
> 
>   git@gitolite.kernel.org:pub/scm/linux/kernel/git/leon/linux-rdma tags/shared
> 
> for you to fetch changes up to 7486216b3a0bd26375b17b2cc168a311106cea70:
> 
>   {net,IB}/mlx5: mlx5_ifc updates (2016-06-10 13:29:14 +0300)
> 
> ----------------------------------------------------------------
> Saeed Mahameed (1):
>       {net,IB}/mlx5: mlx5_ifc updates
> 
>  include/linux/mlx5/mlx5_ifc.h | 275 ++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 263 insertions(+), 12 deletions(-)

From 7486216b3a0bd26375b17b2cc168a311106cea70 Mon Sep 17 00:00:00 2001
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Thu, 9 Jun 2016 15:11:34 +0300
Subject: [PATCH] {net,IB}/mlx5: mlx5_ifc updates

Introducing mlx5_ifc updates for upcoming ConnectX-4 features.

Needed bits and hardware structures for mlx5e netdev:
	- MLX5_CQ_PERIOD_NUM_MODES for adaptive moderation
	  support
	- QoS rate limiting
	- SQ context rate limiting
	- Auto negotiation fields in PTYS register
	- Source SQN field in flow table entry match structure
	- DCBX parameters

Needed bits and hardware structures for IB:
	- New XRQ opcodes, commands and capabilities layout
	- Extend q counters definition to support IB.

Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
---
 include/linux/mlx5/mlx5_ifc.h | 275 ++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 263 insertions(+), 12 deletions(-)

diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index 9a05cd7..209add9 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -123,6 +123,10 @@ enum {
 	MLX5_CMD_OP_DRAIN_DCT                     = 0x712,
 	MLX5_CMD_OP_QUERY_DCT                     = 0x713,
 	MLX5_CMD_OP_ARM_DCT_FOR_KEY_VIOLATION     = 0x714,
+	MLX5_CMD_OP_CREATE_XRQ                    = 0x717,
+	MLX5_CMD_OP_DESTROY_XRQ                   = 0x718,
+	MLX5_CMD_OP_QUERY_XRQ                     = 0x719,
+	MLX5_CMD_OP_ARM_XRQ                       = 0x71a,
 	MLX5_CMD_OP_QUERY_VPORT_STATE             = 0x750,
 	MLX5_CMD_OP_MODIFY_VPORT_STATE            = 0x751,
 	MLX5_CMD_OP_QUERY_ESW_VPORT_CONTEXT       = 0x752,
@@ -139,6 +143,8 @@ enum {
 	MLX5_CMD_OP_ALLOC_Q_COUNTER               = 0x771,
 	MLX5_CMD_OP_DEALLOC_Q_COUNTER             = 0x772,
 	MLX5_CMD_OP_QUERY_Q_COUNTER               = 0x773,
+	MLX5_CMD_OP_SET_RATE_LIMIT                = 0x780,
+	MLX5_CMD_OP_QUERY_RATE_LIMIT              = 0x781,
 	MLX5_CMD_OP_ALLOC_PD                      = 0x800,
 	MLX5_CMD_OP_DEALLOC_PD                    = 0x801,
 	MLX5_CMD_OP_ALLOC_UAR                     = 0x802,
@@ -361,7 +367,8 @@ struct mlx5_ifc_fte_match_set_lyr_2_4_bits {
 };
 
 struct mlx5_ifc_fte_match_set_misc_bits {
-	u8         reserved_at_0[0x20];
+	u8         reserved_at_0[0x8];
+	u8         source_sqn[0x18];
 
 	u8         reserved_at_20[0x10];
 	u8         source_port[0x10];
@@ -505,6 +512,17 @@ struct mlx5_ifc_e_switch_cap_bits {
 	u8         reserved_at_20[0x7e0];
 };
 
+struct mlx5_ifc_qos_cap_bits {
+	u8         packet_pacing[0x1];
+	u8         reserved_0[0x1f];
+	u8         reserved_1[0x20];
+	u8         packet_pacing_max_rate[0x20];
+	u8         packet_pacing_min_rate[0x20];
+	u8         reserved_2[0x10];
+	u8         packet_pacing_rate_table_size[0x10];
+	u8         reserved_3[0x760];
+};
+
 struct mlx5_ifc_per_protocol_networking_offload_caps_bits {
 	u8         csum_cap[0x1];
 	u8         vlan_cap[0x1];
@@ -744,7 +762,8 @@ struct mlx5_ifc_cmd_hca_cap_bits {
 
 	u8         out_of_seq_cnt[0x1];
 	u8         vport_counters[0x1];
-	u8         reserved_at_182[0x4];
+	u8         retransmission_q_counters[0x1];
+	u8         reserved_at_183[0x3];
 	u8         max_qp_cnt[0xa];
 	u8         pkey_table_size[0x10];
 
@@ -771,7 +790,9 @@ struct mlx5_ifc_cmd_hca_cap_bits {
 	u8         log_max_msg[0x5];
 	u8         reserved_at_1c8[0x4];
 	u8         max_tc[0x4];
-	u8         reserved_at_1d0[0x6];
+	u8         reserved_at_1d0[0x1];
+	u8         dcbx[0x1];
+	u8         reserved_at_1d2[0x4];
 	u8         rol_s[0x1];
 	u8         rol_g[0x1];
 	u8         reserved_at_1d8[0x1];
@@ -803,7 +824,7 @@ struct mlx5_ifc_cmd_hca_cap_bits {
 	u8         tph[0x1];
 	u8         rf[0x1];
 	u8         dct[0x1];
-	u8         reserved_at_21b[0x1];
+	u8         qos[0x1];
 	u8         eth_net_offloads[0x1];
 	u8         roce[0x1];
 	u8         atomic[0x1];
@@ -929,7 +950,15 @@ struct mlx5_ifc_cmd_hca_cap_bits {
 	u8         cqe_compression_timeout[0x10];
 	u8         cqe_compression_max_num[0x10];
 
-	u8         reserved_at_5e0[0x220];
+	u8         reserved_at_5e0[0x10];
+	u8         tag_matching[0x1];
+	u8         rndv_offload_rc[0x1];
+	u8         rndv_offload_dc[0x1];
+	u8         log_tag_matching_list_sz[0x5];
+	u8         reserved_at_5e8[0x3];
+	u8         log_max_xrq[0x5];
+
+	u8         reserved_at_5f0[0x200];
 };
 
 enum mlx5_flow_destination_type {
@@ -1967,7 +1996,7 @@ struct mlx5_ifc_qpc_bits {
 
 	u8         reserved_at_560[0x5];
 	u8         rq_type[0x3];
-	u8         srqn_rmpn[0x18];
+	u8         srqn_rmpn_xrqn[0x18];
 
 	u8         reserved_at_580[0x8];
 	u8         rmsn[0x18];
@@ -2018,6 +2047,7 @@ union mlx5_ifc_hca_cap_union_bits {
 	struct mlx5_ifc_flow_table_eswitch_cap_bits flow_table_eswitch_cap;
 	struct mlx5_ifc_e_switch_cap_bits e_switch_cap;
 	struct mlx5_ifc_vector_calc_cap_bits vector_calc_cap;
+	struct mlx5_ifc_qos_cap_bits qos_cap;
 	u8         reserved_at_0[0x8000];
 };
 
@@ -2244,8 +2274,9 @@ struct mlx5_ifc_sqc_bits {
 	u8         reserved_at_40[0x8];
 	u8         cqn[0x18];
 
-	u8         reserved_at_60[0xa0];
+	u8         reserved_at_60[0x90];
 
+	u8         packet_pacing_rate_limit_index[0x10];
 	u8         tis_lst_sz[0x10];
 	u8         reserved_at_110[0x10];
 
@@ -2593,7 +2624,7 @@ struct mlx5_ifc_dctc_bits {
 	u8         reserved_at_98[0x8];
 
 	u8         reserved_at_a0[0x8];
-	u8         srqn[0x18];
+	u8         srqn_xrqn[0x18];
 
 	u8         reserved_at_c0[0x8];
 	u8         pd[0x18];
@@ -2645,6 +2676,7 @@ enum {
 enum {
 	MLX5_CQ_PERIOD_MODE_START_FROM_EQE = 0x0,
 	MLX5_CQ_PERIOD_MODE_START_FROM_CQE = 0x1,
+	MLX5_CQ_PERIOD_NUM_MODES
 };
 
 struct mlx5_ifc_cqc_bits {
@@ -2722,6 +2754,54 @@ struct mlx5_ifc_query_adapter_param_block_bits {
 	u8         vsd_contd_psid[16][0x8];
 };
 
+enum {
+	MLX5_XRQC_STATE_GOOD   = 0x0,
+	MLX5_XRQC_STATE_ERROR  = 0x1,
+};
+
+enum {
+	MLX5_XRQC_TOPOLOGY_NO_SPECIAL_TOPOLOGY = 0x0,
+	MLX5_XRQC_TOPOLOGY_TAG_MATCHING        = 0x1,
+};
+
+enum {
+	MLX5_XRQC_OFFLOAD_RNDV = 0x1,
+};
+
+struct mlx5_ifc_tag_matching_topology_context_bits {
+	u8         log_matching_list_sz[0x4];
+	u8         reserved_at_4[0xc];
+	u8         append_next_index[0x10];
+
+	u8         sw_phase_cnt[0x10];
+	u8         hw_phase_cnt[0x10];
+
+	u8         reserved_at_40[0x40];
+};
+
+struct mlx5_ifc_xrqc_bits {
+	u8         state[0x4];
+	u8         rlkey[0x1];
+	u8         reserved_at_5[0xf];
+	u8         topology[0x4];
+	u8         reserved_at_18[0x4];
+	u8         offload[0x4];
+
+	u8         reserved_at_20[0x8];
+	u8         user_index[0x18];
+
+	u8         reserved_at_40[0x8];
+	u8         cqn[0x18];
+
+	u8         reserved_at_60[0xa0];
+
+	struct mlx5_ifc_tag_matching_topology_context_bits tag_matching_topology_context;
+
+	u8         reserved_at_180[0x180];
+
+	struct mlx5_ifc_wq_bits wq;
+};
+
 union mlx5_ifc_modify_field_select_resize_field_select_auto_bits {
 	struct mlx5_ifc_modify_field_select_bits modify_field_select;
 	struct mlx5_ifc_resize_field_select_bits resize_field_select;
@@ -3144,6 +3224,30 @@ struct mlx5_ifc_rst2init_qp_in_bits {
 	u8         reserved_at_800[0x80];
 };
 
+struct mlx5_ifc_query_xrq_out_bits {
+	u8         status[0x8];
+	u8         reserved_at_8[0x18];
+
+	u8         syndrome[0x20];
+
+	u8         reserved_at_40[0x40];
+
+	struct mlx5_ifc_xrqc_bits xrq_context;
+};
+
+struct mlx5_ifc_query_xrq_in_bits {
+	u8         opcode[0x10];
+	u8         reserved_at_10[0x10];
+
+	u8         reserved_at_20[0x10];
+	u8         op_mod[0x10];
+
+	u8         reserved_at_40[0x8];
+	u8         xrqn[0x18];
+
+	u8         reserved_at_60[0x20];
+};
+
 struct mlx5_ifc_query_xrc_srq_out_bits {
 	u8         status[0x8];
 	u8         reserved_at_8[0x18];
@@ -3547,7 +3651,27 @@ struct mlx5_ifc_query_q_counter_out_bits {
 
 	u8         out_of_sequence[0x20];
 
-	u8         reserved_at_1e0[0x620];
+	u8         reserved_at_1e0[0x20];
+
+	u8         duplicate_request[0x20];
+
+	u8         reserved_at_220[0x20];
+
+	u8         rnr_nak_retry_err[0x20];
+
+	u8         reserved_at_260[0x20];
+
+	u8         packet_seq_err[0x20];
+
+	u8         reserved_at_2a0[0x20];
+
+	u8         implied_nak_seq_err[0x20];
+
+	u8         reserved_at_2e0[0x20];
+
+	u8         local_ack_timeout_err[0x20];
+
+	u8         reserved_at_320[0x4e0];
 };
 
 struct mlx5_ifc_query_q_counter_in_bits {
@@ -4998,6 +5122,28 @@ struct mlx5_ifc_detach_from_mcg_in_bits {
 	u8         multicast_gid[16][0x8];
 };
 
+struct mlx5_ifc_destroy_xrq_out_bits {
+	u8         status[0x8];
+	u8         reserved_at_8[0x18];
+
+	u8         syndrome[0x20];
+
+	u8         reserved_at_40[0x40];
+};
+
+struct mlx5_ifc_destroy_xrq_in_bits {
+	u8         opcode[0x10];
+	u8         reserved_at_10[0x10];
+
+	u8         reserved_at_20[0x10];
+	u8         op_mod[0x10];
+
+	u8         reserved_at_40[0x8];
+	u8         xrqn[0x18];
+
+	u8         reserved_at_60[0x20];
+};
+
 struct mlx5_ifc_destroy_xrc_srq_out_bits {
 	u8         status[0x8];
 	u8         reserved_at_8[0x18];
@@ -5583,6 +5729,30 @@ struct mlx5_ifc_dealloc_flow_counter_in_bits {
 	u8         reserved_at_60[0x20];
 };
 
+struct mlx5_ifc_create_xrq_out_bits {
+	u8         status[0x8];
+	u8         reserved_at_8[0x18];
+
+	u8         syndrome[0x20];
+
+	u8         reserved_at_40[0x8];
+	u8         xrqn[0x18];
+
+	u8         reserved_at_60[0x20];
+};
+
+struct mlx5_ifc_create_xrq_in_bits {
+	u8         opcode[0x10];
+	u8         reserved_at_10[0x10];
+
+	u8         reserved_at_20[0x10];
+	u8         op_mod[0x10];
+
+	u8         reserved_at_40[0x40];
+
+	struct mlx5_ifc_xrqc_bits xrq_context;
+};
+
 struct mlx5_ifc_create_xrc_srq_out_bits {
 	u8         status[0x8];
 	u8         reserved_at_8[0x18];
@@ -6124,6 +6294,29 @@ struct mlx5_ifc_attach_to_mcg_in_bits {
 	u8         multicast_gid[16][0x8];
 };
 
+struct mlx5_ifc_arm_xrq_out_bits {
+	u8         status[0x8];
+	u8         reserved_at_8[0x18];
+
+	u8         syndrome[0x20];
+
+	u8         reserved_at_40[0x40];
+};
+
+struct mlx5_ifc_arm_xrq_in_bits {
+	u8         opcode[0x10];
+	u8         reserved_at_10[0x10];
+
+	u8         reserved_at_20[0x10];
+	u8         op_mod[0x10];
+
+	u8         reserved_at_40[0x8];
+	u8         xrqn[0x18];
+
+	u8         reserved_at_60[0x10];
+	u8         lwm[0x10];
+};
+
 struct mlx5_ifc_arm_xrc_srq_out_bits {
 	u8         status[0x8];
 	u8         reserved_at_8[0x18];
@@ -6161,7 +6354,8 @@ struct mlx5_ifc_arm_rq_out_bits {
 };
 
 enum {
-	MLX5_ARM_RQ_IN_OP_MOD_SRQ_  = 0x1,
+	MLX5_ARM_RQ_IN_OP_MOD_SRQ = 0x1,
+	MLX5_ARM_RQ_IN_OP_MOD_XRQ = 0x2,
 };
 
 struct mlx5_ifc_arm_rq_in_bits {
@@ -6354,6 +6548,30 @@ struct mlx5_ifc_add_vxlan_udp_dport_in_bits {
 	u8         vxlan_udp_port[0x10];
 };
 
+struct mlx5_ifc_set_rate_limit_out_bits {
+	u8         status[0x8];
+	u8         reserved_at_8[0x18];
+
+	u8         syndrome[0x20];
+
+	u8         reserved_at_40[0x40];
+};
+
+struct mlx5_ifc_set_rate_limit_in_bits {
+	u8         opcode[0x10];
+	u8         reserved_at_10[0x10];
+
+	u8         reserved_at_20[0x10];
+	u8         op_mod[0x10];
+
+	u8         reserved_at_40[0x10];
+	u8         rate_limit_index[0x10];
+
+	u8         reserved_at_60[0x20];
+
+	u8         rate_limit[0x20];
+};
+
 struct mlx5_ifc_access_register_out_bits {
 	u8         status[0x8];
 	u8         reserved_at_8[0x18];
@@ -6478,12 +6696,15 @@ struct mlx5_ifc_pude_reg_bits {
 };
 
 struct mlx5_ifc_ptys_reg_bits {
-	u8         reserved_at_0[0x8];
+	u8         an_disable_cap[0x1];
+	u8         an_disable_admin[0x1];
+	u8         reserved_at_2[0x6];
 	u8         local_port[0x8];
 	u8         reserved_at_10[0xd];
 	u8         proto_mask[0x3];
 
-	u8         reserved_at_20[0x40];
+	u8         an_status[0x4];
+	u8         reserved_at_24[0x3c];
 
 	u8         eth_proto_capability[0x20];
 
@@ -7444,4 +7665,34 @@ struct mlx5_ifc_mcia_reg_bits {
 	u8         dword_11[0x20];
 };
 
+struct mlx5_ifc_dcbx_param_bits {
+	u8         dcbx_cee_cap[0x1];
+	u8         dcbx_ieee_cap[0x1];
+	u8         dcbx_standby_cap[0x1];
+	u8         reserved_at_0[0x5];
+	u8         port_number[0x8];
+	u8         reserved_at_10[0xa];
+	u8         max_application_table_size[6];
+	u8         reserved_at_20[0x15];
+	u8         version_oper[0x3];
+	u8         reserved_at_38[5];
+	u8         version_admin[0x3];
+	u8         willing_admin[0x1];
+	u8         reserved_at_41[0x3];
+	u8         pfc_cap_oper[0x4];
+	u8         reserved_at_48[0x4];
+	u8         pfc_cap_admin[0x4];
+	u8         reserved_at_50[0x4];
+	u8         num_of_tc_oper[0x4];
+	u8         reserved_at_58[0x4];
+	u8         num_of_tc_admin[0x4];
+	u8         remote_willing[0x1];
+	u8         reserved_at_61[3];
+	u8         remote_pfc_cap[4];
+	u8         reserved_at_68[0x14];
+	u8         remote_num_of_tc[0x4];
+	u8         reserved_at_80[0x18];
+	u8         error[0x8];
+	u8         reserved_at_a0[0x160];
+};
 #endif /* MLX5_IFC_H */
-- 
2.1.4


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [GIT PULL] Please Pull Mellanox Shared Code

[David Miller]

Please, just stop right now.

We're not asking for the a huge patch covering the entire pull
request.

We're asking for you to post a patch series, one per commit, and as
numbered, fresh, new mailing list patch postings.  As if you were
submitting these changes for the very first time to the list.

Please ask a colleague for how to do this properly before you spam the
list again with more unnecessary and improperly formatted submissions.

Thank.

Re: [GIT PULL] Please Pull Mellanox Shared Code

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 1626 bytes --]

On 6/14/2016 3:02 AM, David Miller wrote:
> 
> Please, just stop right now.
> 
> We're not asking for the a huge patch covering the entire pull
> request.
> 
> We're asking for you to post a patch series, one per commit, and as
> numbered, fresh, new mailing list patch postings.  As if you were
> submitting these changes for the very first time to the list.
> 
> Please ask a colleague for how to do this properly before you spam the
> list again with more unnecessary and improperly formatted submissions.

Dave,

He's doing what Linus requested from Mellanox.  They were instructed to
identify all of the coming changes in the next release where patches
sent through your tree and patches sent through my tree would have
conflicts.  They were then instructed to make git commits that merged
those changes and have both you and I pull them (please note "pull", not
git am patches) so that we have the exact same commit hashes in our
trees and git will do the right thing when your tree and my tree are
merged in the next merge window.  As it turns out the conflicts are
mainly in this firmware offset definition file.  They just put all of
the needed changes in there in one commit.  I doubt they have individual
patches here.  This was a custom made patch who's sole purpose is to
combine all the otherwise possibly conflicting changes in one place.
I'm sure they could split it out into different commits, but they
wouldn't be full commits, just the portion that applies to this firmware
file.

--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
	GPG Key ID: 0E572FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: [GIT PULL] Please Pull Mellanox Shared Code

[Or Gerlitz]

On Tue, Jun 14, 2016 at 8:16 PM, Doug Ledford <dledford@redhat.com> wrote:

> Dave,
>
> He's doing what Linus requested from Mellanox.  They were instructed to
> identify all of the coming changes in the next release where patches
> sent through your tree and patches sent through my tree would have
> conflicts.  They were then instructed to make git commits that merged
> those changes and have both you and I pull them (please note "pull", not
> git am patches) so that we have the exact same commit hashes in our
> trees and git will do the right thing when your tree and my tree are
> merged in the next merge window.  As it turns out the conflicts are
> mainly in this firmware offset definition file.  They just put all of
> the needed changes in there in one commit.  I doubt they have individual
> patches here.

Doug,

The main comment was that the submission lacked posting of the actual
changes inline as patch/es along with a cover letter that gives the
background plus the URL for git pulling of this. In this case (4.8
shared code), the submission only touches the mlx5_ifc.c FW file and
indeed it makes sense to have only one patch that covers it all, in
prev/future cases we had/would have that in multiple patches.

Leon re-submitted that later today in the proper way

Or.

> This was a custom made patch who's sole purpose is to
> combine all the otherwise possibly conflicting changes in one place.
> I'm sure they could split it out into different commits, but they
> wouldn't be full commits, just the portion that applies to this firmware file

Re: [GIT PULL] Please Pull Mellanox Shared Code

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 2372 bytes --]

On Tue, Jun 14, 2016 at 01:16:50PM -0400, Doug Ledford wrote:
> On 6/14/2016 3:02 AM, David Miller wrote:
> > 
> > Please, just stop right now.
> > 
> > We're not asking for the a huge patch covering the entire pull
> > request.
> > 
> > We're asking for you to post a patch series, one per commit, and as
> > numbered, fresh, new mailing list patch postings.  As if you were
> > submitting these changes for the very first time to the list.
> > 
> > Please ask a colleague for how to do this properly before you spam the
> > list again with more unnecessary and improperly formatted submissions.
> 
> Dave,
> 
> He's doing what Linus requested from Mellanox.  They were instructed to
> identify all of the coming changes in the next release where patches
> sent through your tree and patches sent through my tree would have
> conflicts.  They were then instructed to make git commits that merged
> those changes and have both you and I pull them (please note "pull", not
> git am patches) so that we have the exact same commit hashes in our
> trees and git will do the right thing when your tree and my tree are
> merged in the next merge window.  As it turns out the conflicts are
> mainly in this firmware offset definition file.  They just put all of
> the needed changes in there in one commit.  I doubt they have individual
> patches here.  This was a custom made patch who's sole purpose is to
> combine all the otherwise possibly conflicting changes in one place.
> I'm sure they could split it out into different commits, but they
> wouldn't be full commits, just the portion that applies to this firmware
> file.

Thanks Doug,

In addition to your accurate description. We don't have separate commits
for this file (mlx5_ifc.h) for many reasons: auto generated file, one
logical change (enable FW features), no helpful for bisect e.t.c.

My goal was to simplify the maintainers' work by sending minimal
possible pull request with easy for review information.

I also resent the pull request [1] as a cover letter together with patch itself [2].

[1] http://lkml.kernel.org/r/1465900500-1578-1-git-send-email-leonro+()+mellanox+!+com
[2] http://lkml.kernel.org/r/1465900500-1578-2-git-send-email-leonro+()+mellanox+!+com

Thanks.

> 
> --
> Doug Ledford <dledford@redhat.com>
> 	GPG Key ID: 0E572FDD
> 




[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]