[net-next 0/8][pull request] Intel Wired LAN Driver Updates

This series contains updates to e1000e, igb, ixgbevf and MAINTAINERS.

The following are changes since commit 598e74f32c6dd4b3dd0ed382c889be07a7c6cbc0:
  Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next
and are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master

Carolyn Wyborny (2):
  igb: Update get cable length function for i210/i211
  igb: Update version

Greg Rose (2):
  ixgbevf: Check for error on dma_map_single call
  ixgbevf: Update version string

Jesse Brandeburg (1):
  maintainers: update with official intel support link, new maintainer

John Fastabend (2):
  ixgbevf: make netif_napi_add and netif_napi_del symmetric
  ixgbevf: fix softirq-safe to unsafe splat on internal mbx_lock

Tushar Dave (1):
  e1000e: Minimum packet size must be 17 bytes

 MAINTAINERS                                       |  2 +
 drivers/net/ethernet/intel/e1000e/netdev.c        | 11 +++++
 drivers/net/ethernet/intel/igb/e1000_phy.c        | 20 ++++++++
 drivers/net/ethernet/intel/igb/igb_main.c         |  2 +-
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 59 ++++++++++++-----------
 5 files changed, 64 insertions(+), 30 deletions(-)

-- 
1.7.11.7

From: Tushar Dave <redacted>

This is a HW requirement. Although a buffer as short as 1 byte is allowed,
the total length of packet before, padding and CRC insertion, must be at
least 17 bytes.  So pad all small packets manually up to 17 bytes before
delivering them to HW.

Signed-off-by: Tushar Dave <redacted>
Tested-by: Jeff Pieper <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
 drivers/net/ethernet/intel/e1000e/netdev.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index f444eb0..dadb13b 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c

@@ -5067,6 +5067,17 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb,
 		return NETDEV_TX_OK;
 	}
 
+	/*
+	 * The minimum packet size with TCTL.PSP set is 17 bytes so
+	 * pad skb in order to meet this minimum size requirement
+	 */
+	if (unlikely(skb->len < 17)) {
+		if (skb_pad(skb, 17 - skb->len))
+			return NETDEV_TX_OK;
+		skb->len = 17;
+		skb_set_tail_pointer(skb, 17);
+	}
+
 	mss = skb_shinfo(skb)->gso_size;
 	if (mss) {
 		u8 hdr_len;

-- 
1.7.11.7

From: Jesse Brandeburg <redacted>

Add an official link which is designed to guide the user to the appropriate
support resource (be it community, OEM, Intel phone, Intel email, etc)

Add the current e1000 maintainer to the list of Intel maintainers.

Signed-off-by: Jesse Brandeburg <redacted>
Tested-by: Aaron Brown <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 41c5349..5655bcc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS

@@ -3869,7 +3869,9 @@ M:	Greg Rose <gregory.v.rose@intel.com>
 M:	Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
 M:	Alex Duyck <alexander.h.duyck@intel.com>
 M:	John Ronciak <john.ronciak@intel.com>
+M:	Tushar Dave <tushar.n.dave@intel.com>
 L:	e1000-devel@lists.sourceforge.net
+W:	http://www.intel.com/support/feedback.htm
 W:	http://e1000.sourceforge.net/
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net.git
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git

-- 
1.7.11.7

From: Carolyn Wyborny <redacted>

There was a problem in the initial implementation of the get cable length
function for i210 and it did not work properly.  This patch fixes that
problem for i210/i211 devices.

Signed-off-by: Carolyn Wyborny <redacted>
Tested-by: Aaron Brown <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
 drivers/net/ethernet/intel/igb/e1000_phy.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/net/ethernet/intel/igb/e1000_phy.c b/drivers/net/ethernet/intel/igb/e1000_phy.c
index 3404bc7..c62a4c3 100644
--- a/drivers/net/ethernet/intel/igb/e1000_phy.c
+++ b/drivers/net/ethernet/intel/igb/e1000_phy.c

@@ -1710,6 +1710,26 @@ s32 igb_get_cable_length_m88_gen2(struct e1000_hw *hw)
 
 	switch (hw->phy.id) {
 	case I210_I_PHY_ID:
+		/* Get cable length from PHY Cable Diagnostics Control Reg */
+		ret_val = phy->ops.read_reg(hw, (0x7 << GS40G_PAGE_SHIFT) +
+					    (I347AT4_PCDL + phy->addr),
+					    &phy_data);
+		if (ret_val)
+			return ret_val;
+
+		/* Check if the unit of cable length is meters or cm */
+		ret_val = phy->ops.read_reg(hw, (0x7 << GS40G_PAGE_SHIFT) +
+					    I347AT4_PCDC, &phy_data2);
+		if (ret_val)
+			return ret_val;
+
+		is_cm = !(phy_data2 & I347AT4_PCDC_CABLE_LENGTH_UNIT);
+
+		/* Populate the phy structure with cable length in meters */
+		phy->min_cable_length = phy_data / (is_cm ? 100 : 1);
+		phy->max_cable_length = phy_data / (is_cm ? 100 : 1);
+		phy->cable_length = phy_data / (is_cm ? 100 : 1);
+		break;
 	case I347AT4_E_PHY_ID:
 		/* Remember the original page select and set it to 7 */
 		ret_val = phy->ops.read_reg(hw, I347AT4_PAGE_SELECT,

-- 
1.7.11.7

From: Carolyn Wyborny <redacted>

This patch updates the igb driver version to 4.0.17.

Signed-off-by: Carolyn Wyborny <redacted>
Tested-by: Aaron Brown <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
 drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 87abb57..b07d679 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c

@@ -61,7 +61,7 @@
 
 #define MAJ 4
 #define MIN 0
-#define BUILD 1
+#define BUILD 17
 #define DRV_VERSION __stringify(MAJ) "." __stringify(MIN) "." \
 __stringify(BUILD) "-k"
 char igb_driver_name[] = "igb";

-- 
1.7.11.7

From: John Fastabend <redacted>

ixgbevf_alloc_q_vectors() calls netif_napi_add for each qvector
where qvectors is determined by the number of msix vectors. This
makes perfect sense.

However on cleanup when ixgbevf_free_q_vectors() is called and
for each qvector we should call netif_napi_del there is some
extra logic to add a dependency on RX queues. This patch makes
the add/del operations symmetric by removing the RX queues
dependency.

Without this if  free_netdev() is called we see the general
protection fault below in netif_napi_del when list_del_init()
is called.

# addr2line -e ./vmlinux ffffffff8140810c
net-next/include/linux/list.h:88

general protection fault: 0000 [#1] SMP
Modules linked in: bonding ixgbevf ixgbe(-) mdio libfc scsi_transport_fc scsi_tgt 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 uinput coretemp lpc_ich i2c_i801 shpchp hwmon i2c_core serio_raw crc32c_intel mfd_core joydev pcspkr microcode ioatdma igb dca pata_acpi ata_generic usb_storage pata_jmicron [last unloaded: bonding]
CPU 10
Pid: 4174, comm: rmmod Tainted: G        W    3.6.0-rc3jk-net-next+ #104 Supermicro X8DTN/X8DTN
RIP: 0010:[<ffffffff8140810c>]  [<ffffffff8140810c>] netif_napi_del+0x24/0x87
RSP: 0018:ffff88027f5e9b48  EFLAGS: 00010293
RAX: ffff8806224b4768 RBX: ffff8806224b46e8 RCX: 6b6b6b6b6b6b6b6b
RDX: 6b6b6b6b6b6b6b6b RSI: ffffffff810bf6c5 RDI: ffff8806224b46e8
RBP: ffff88027f5e9b58 R08: ffff88033200b180 R09: ffff88027f5e98a8
R10: ffff88033320b000 R11: ffff88027f5e9ae8 R12: 6b6b6b6b6b6b6aeb
R13: ffff8806221d11c0 R14: 0000000000000000 R15: ffff88027f5e9cf8
FS:  00007f5e58b9b700(0000) GS:ffff880333200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000010ef2b8 CR3: 0000000281fff000 CR4: 00000000000007e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process rmmod (pid: 4174, threadinfo ffff88027f5e8000, task ffff88032f888000)
Stack:
 ffff8806221d1160 6b6b6b6b6b6b6aeb ffff88027f5e9b88 ffffffff81408e46
 ffff8806221d1160 ffff8806221d1160 ffff8806221d1ae0 ffff8806221d5668
 ffff88027f5e9bb8 ffffffffa009153c ffffffffa0092a30 ffff8806221d5700
Call Trace:
 [<ffffffff81408e46>] free_netdev+0x64/0xd7
 [<ffffffffa009153c>] ixgbevf_remove+0xa6/0xbc [ixgbevf]
 [<ffffffff8127a7a1>] pci_device_remove+0x2d/0x51
 [<ffffffff8131f503>] __device_release_driver+0x6c/0xc2
 [<ffffffff8131f640>] device_release_driver+0x25/0x32
 [<ffffffff8131e821>] bus_remove_device+0x148/0x15d
 [<ffffffff8131cb6b>] device_del+0x130/0x1a4
 [<ffffffff8131cc2a>] device_unregister+0x4b/0x57
 [<ffffffff81275c27>] pci_stop_bus_device+0x63/0x85
 [...]

Signed-off-by: John Fastabend <redacted>
Acked-by: Greg Rose <redacted>
Acked-by: Alexander Duyck <redacted>
Tested-by: Sibai Li <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 33444b5..537ed19 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c

@@ -1912,18 +1912,13 @@ err_out:
  **/
 static void ixgbevf_free_q_vectors(struct ixgbevf_adapter *adapter)
 {
-	int q_idx, num_q_vectors;
-	int napi_vectors;
-
-	num_q_vectors = adapter->num_msix_vectors - NON_Q_VECTORS;
-	napi_vectors = adapter->num_rx_queues;
+	int q_idx, num_q_vectors = adapter->num_msix_vectors - NON_Q_VECTORS;
 
 	for (q_idx = 0; q_idx < num_q_vectors; q_idx++) {
 		struct ixgbevf_q_vector *q_vector = adapter->q_vector[q_idx];
 
 		adapter->q_vector[q_idx] = NULL;
-		if (q_idx < napi_vectors)
-			netif_napi_del(&q_vector->napi);
+		netif_napi_del(&q_vector->napi);
 		kfree(q_vector);
 	}
 }

-- 
1.7.11.7

From: Greg Rose <redacted>

Ignoring the return value from a call to the kernel dma_map API functions
can cause data corruption and system instability.  Check the return value
and take appropriate action.

Signed-off-by: Greg Rose <redacted>
Tested-by: Phil Schmitt <redacted>
Tested-by: Sibai Li <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 537ed19..805e02c 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c

@@ -359,6 +359,12 @@ static void ixgbevf_alloc_rx_buffers(struct ixgbevf_adapter *adapter,
 			bi->dma = dma_map_single(&pdev->dev, skb->data,
 						 rx_ring->rx_buf_len,
 						 DMA_FROM_DEVICE);
+			if (dma_mapping_error(&pdev->dev, bi->dma)) {
+				dev_kfree_skb(skb);
+				bi->skb = NULL;
+				dev_err(&pdev->dev, "RX DMA map failed\n");
+				break;
+			}
 		}
 		rx_desc->read.pkt_addr = cpu_to_le64(bi->dma);
 

@@ -2817,10 +2823,10 @@ static int ixgbevf_tx_map(struct ixgbevf_ring *tx_ring,
 			tx_buffer_info->dma =
 				skb_frag_dma_map(tx_ring->dev, frag,
 						 offset, size, DMA_TO_DEVICE);
-			tx_buffer_info->mapped_as_page = true;
 			if (dma_mapping_error(tx_ring->dev,
 					      tx_buffer_info->dma))
 				goto dma_error;
+			tx_buffer_info->mapped_as_page = true;
 			tx_buffer_info->next_to_watch = i;
 
 			len -= size;

-- 
1.7.11.7

From: John Fastabend <redacted>

The lockdep splat below identifies a case where irq safe to unsafe
lock order is detected. Resolved by making mbx_lock bh.

======================================================
[ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
3.6.0-rc5jk-net-next+ #119 Not tainted
------------------------------------------------------
ip/2608 [HC0[0]:SC0[2]:HE1:SE0] is trying to acquire:
 (&(&adapter->mbx_lock)->rlock){+.+...}, at: [<ffffffffa008114e>] ixgbevf_set_rx_mode+0x36/0xd2 [ixgbevf]

and this task is already holding:
 (_xmit_ETHER){+.....}, at: [<ffffffff814097c8>] dev_set_rx_mode+0x1e/0x33
which would create a new lock dependency:
 (_xmit_ETHER){+.....} -> (&(&adapter->mbx_lock)->rlock){+.+...}

but this new dependency connects a SOFTIRQ-irq-safe lock:
 (&(&mc->mca_lock)->rlock){+.-...}
... which became SOFTIRQ-irq-safe at:
  [<ffffffff81092ee5>] __lock_acquire+0x2f2/0xdf3
  [<ffffffff81093b11>] lock_acquire+0x12b/0x158
  [<ffffffff814bdbcd>] _raw_spin_lock_bh+0x4a/0x7d
  [<ffffffffa011a740>] mld_ifc_timer_expire+0x1b2/0x282 [ipv6]
  [<ffffffff81054580>] run_timer_softirq+0x2a2/0x3ee
  [<ffffffff8104cc42>] __do_softirq+0x161/0x2b9
  [<ffffffff814c6a7c>] call_softirq+0x1c/0x30
  [<ffffffff81011bc7>] do_softirq+0x4b/0xa3
  [<ffffffff8104c8d5>] irq_exit+0x53/0xd7
  [<ffffffff814c734d>] do_IRQ+0x9d/0xb4
  [<ffffffff814be56f>] ret_from_intr+0x0/0x1a
  [<ffffffff813de21c>] cpuidle_enter+0x12/0x14
  [<ffffffff813de235>] cpuidle_enter_state+0x17/0x3f
  [<ffffffff813deb6c>] cpuidle_idle_call+0x140/0x21c
  [<ffffffff8101764c>] cpu_idle+0x79/0xcd
  [<ffffffff814a59f5>] rest_init+0x149/0x150
  [<ffffffff81ca2cbc>] start_kernel+0x37c/0x389
  [<ffffffff81ca22dd>] x86_64_start_reservations+0xb8/0xbd
  [<ffffffff81ca23e3>] x86_64_start_kernel+0x101/0x110

to a SOFTIRQ-irq-unsafe lock:
 (&(&adapter->mbx_lock)->rlock){+.+...}
... which became SOFTIRQ-irq-unsafe at:
...  [<ffffffff81092f59>] __lock_acquire+0x366/0xdf3
  [<ffffffff81093b11>] lock_acquire+0x12b/0x158
  [<ffffffff814bd862>] _raw_spin_lock+0x45/0x7a
  [<ffffffffa0080fde>] ixgbevf_negotiate_api+0x3d/0x6d [ixgbevf]
  [<ffffffffa008404b>] ixgbevf_open+0x6c/0x43e [ixgbevf]
  [<ffffffff8140b2c1>] __dev_open+0xa0/0xe6
  [<ffffffff814099b6>] __dev_change_flags+0xbe/0x142
  [<ffffffff8140b1eb>] dev_change_flags+0x21/0x57
  [<ffffffff8141a523>] do_setlink+0x2e2/0x7f4
  [<ffffffff8141ad8c>] rtnl_newlink+0x277/0x4bb
  [<ffffffff81419c08>] rtnetlink_rcv_msg+0x236/0x253
  [<ffffffff8142f92d>] netlink_rcv_skb+0x43/0x94
  [<ffffffff814199cb>] rtnetlink_rcv+0x26/0x2d
  [<ffffffff8142f6dc>] netlink_unicast+0xee/0x174
  [<ffffffff8142ff12>] netlink_sendmsg+0x26a/0x288
  [<ffffffff813f5a0d>] __sock_sendmsg_nosec+0x58/0x61
  [<ffffffff813f7d57>] __sock_sendmsg+0x3d/0x48
  [<ffffffff813f7ed9>] sock_sendmsg+0x6e/0x87
  [<ffffffff813f93d4>] __sys_sendmsg+0x206/0x288
  [<ffffffff813f95ce>] sys_sendmsg+0x42/0x60
  [<ffffffff814c57a9>] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

Chain exists of:
  &(&mc->mca_lock)->rlock --> _xmit_ETHER --> &(&adapter->mbx_lock)->rlock

 Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&(&adapter->mbx_lock)->rlock);
                               local_irq_disable();
                               lock(&(&mc->mca_lock)->rlock);
                               lock(_xmit_ETHER);
  <Interrupt>
    lock(&(&mc->mca_lock)->rlock);

 *** DEADLOCK ***

Signed-off-by: John Fastabend <redacted>
Acked-by: Greg Rose <redacted>
Tested-by: Sibai Li <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 40 +++++++++++------------
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 805e02c..846ac51 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c

@@ -1138,12 +1138,12 @@ static int ixgbevf_vlan_rx_add_vid(struct net_device *netdev, u16 vid)
 	if (!hw->mac.ops.set_vfta)
 		return -EOPNOTSUPP;
 
-	spin_lock(&adapter->mbx_lock);
+	spin_lock_bh(&adapter->mbx_lock);
 
 	/* add VID to filter table */
 	err = hw->mac.ops.set_vfta(hw, vid, 0, true);
 
-	spin_unlock(&adapter->mbx_lock);
+	spin_unlock_bh(&adapter->mbx_lock);
 
 	/* translate error return types so error makes sense */
 	if (err == IXGBE_ERR_MBX)

@@ -1163,13 +1163,13 @@ static int ixgbevf_vlan_rx_kill_vid(struct net_device *netdev, u16 vid)
 	struct ixgbe_hw *hw = &adapter->hw;
 	int err = -EOPNOTSUPP;
 
-	spin_lock(&adapter->mbx_lock);
+	spin_lock_bh(&adapter->mbx_lock);
 
 	/* remove VID from filter table */
 	if (hw->mac.ops.set_vfta)
 		err = hw->mac.ops.set_vfta(hw, vid, 0, false);
 
-	spin_unlock(&adapter->mbx_lock);
+	spin_unlock_bh(&adapter->mbx_lock);
 
 	clear_bit(vid, adapter->active_vlans);
 

@@ -1225,7 +1225,7 @@ static void ixgbevf_set_rx_mode(struct net_device *netdev)
 	struct ixgbevf_adapter *adapter = netdev_priv(netdev);
 	struct ixgbe_hw *hw = &adapter->hw;
 
-	spin_lock(&adapter->mbx_lock);
+	spin_lock_bh(&adapter->mbx_lock);
 
 	/* reprogram multicast list */
 	if (hw->mac.ops.update_mc_addr_list)

@@ -1233,7 +1233,7 @@ static void ixgbevf_set_rx_mode(struct net_device *netdev)
 
 	ixgbevf_write_uc_addr_list(netdev);
 
-	spin_unlock(&adapter->mbx_lock);
+	spin_unlock_bh(&adapter->mbx_lock);
 }
 
 static void ixgbevf_napi_enable_all(struct ixgbevf_adapter *adapter)

@@ -1347,7 +1347,7 @@ static void ixgbevf_negotiate_api(struct ixgbevf_adapter *adapter)
 		      ixgbe_mbox_api_unknown };
 	int err = 0, idx = 0;
 
-	spin_lock(&adapter->mbx_lock);
+	spin_lock_bh(&adapter->mbx_lock);
 
 	while (api[idx] != ixgbe_mbox_api_unknown) {
 		err = ixgbevf_negotiate_api_version(hw, api[idx]);

@@ -1356,7 +1356,7 @@ static void ixgbevf_negotiate_api(struct ixgbevf_adapter *adapter)
 		idx++;
 	}
 
-	spin_unlock(&adapter->mbx_lock);
+	spin_unlock_bh(&adapter->mbx_lock);
 }
 
 static void ixgbevf_up_complete(struct ixgbevf_adapter *adapter)

@@ -1397,7 +1397,7 @@ static void ixgbevf_up_complete(struct ixgbevf_adapter *adapter)
 
 	ixgbevf_configure_msix(adapter);
 
-	spin_lock(&adapter->mbx_lock);
+	spin_lock_bh(&adapter->mbx_lock);
 
 	if (hw->mac.ops.set_rar) {
 		if (is_valid_ether_addr(hw->mac.addr))

@@ -1406,7 +1406,7 @@ static void ixgbevf_up_complete(struct ixgbevf_adapter *adapter)
 			hw->mac.ops.set_rar(hw, 0, hw->mac.perm_addr, 0);
 	}
 
-	spin_unlock(&adapter->mbx_lock);
+	spin_unlock_bh(&adapter->mbx_lock);
 
 	clear_bit(__IXGBEVF_DOWN, &adapter->state);
 	ixgbevf_napi_enable_all(adapter);

@@ -1430,12 +1430,12 @@ static int ixgbevf_reset_queues(struct ixgbevf_adapter *adapter)
 	unsigned int num_rx_queues = 1;
 	int err, i;
 
-	spin_lock(&adapter->mbx_lock);
+	spin_lock_bh(&adapter->mbx_lock);
 
 	/* fetch queue configuration from the PF */
 	err = ixgbevf_get_queues(hw, &num_tcs, &def_q);
 
-	spin_unlock(&adapter->mbx_lock);
+	spin_unlock_bh(&adapter->mbx_lock);
 
 	if (err)
 		return err;

@@ -1694,14 +1694,14 @@ void ixgbevf_reset(struct ixgbevf_adapter *adapter)
 	struct ixgbe_hw *hw = &adapter->hw;
 	struct net_device *netdev = adapter->netdev;
 
-	spin_lock(&adapter->mbx_lock);
+	spin_lock_bh(&adapter->mbx_lock);
 
 	if (hw->mac.ops.reset_hw(hw))
 		hw_dbg(hw, "PF still resetting\n");
 	else
 		hw->mac.ops.init_hw(hw);
 
-	spin_unlock(&adapter->mbx_lock);
+	spin_unlock_bh(&adapter->mbx_lock);
 
 	if (is_valid_ether_addr(adapter->hw.mac.addr)) {
 		memcpy(netdev->dev_addr, adapter->hw.mac.addr,

@@ -2195,12 +2195,12 @@ static void ixgbevf_watchdog_task(struct work_struct *work)
 	if (hw->mac.ops.check_link) {
 		s32 need_reset;
 
-		spin_lock(&adapter->mbx_lock);
+		spin_lock_bh(&adapter->mbx_lock);
 
 		need_reset = hw->mac.ops.check_link(hw, &link_speed,
 						    &link_up, false);
 
-		spin_unlock(&adapter->mbx_lock);
+		spin_unlock_bh(&adapter->mbx_lock);
 
 		if (need_reset) {
 			adapter->link_up = link_up;

@@ -2468,12 +2468,12 @@ static int ixgbevf_setup_queues(struct ixgbevf_adapter *adapter)
 	unsigned int num_rx_queues = 1;
 	int err, i;
 
-	spin_lock(&adapter->mbx_lock);
+	spin_lock_bh(&adapter->mbx_lock);
 
 	/* fetch queue configuration from the PF */
 	err = ixgbevf_get_queues(hw, &num_tcs, &def_q);
 
-	spin_unlock(&adapter->mbx_lock);
+	spin_unlock_bh(&adapter->mbx_lock);
 
 	if (err)
 		return err;

@@ -3047,12 +3047,12 @@ static int ixgbevf_set_mac(struct net_device *netdev, void *p)
 	memcpy(netdev->dev_addr, addr->sa_data, netdev->addr_len);
 	memcpy(hw->mac.addr, addr->sa_data, netdev->addr_len);
 
-	spin_lock(&adapter->mbx_lock);
+	spin_lock_bh(&adapter->mbx_lock);
 
 	if (hw->mac.ops.set_rar)
 		hw->mac.ops.set_rar(hw, 0, hw->mac.addr, 0);
 
-	spin_unlock(&adapter->mbx_lock);
+	spin_unlock_bh(&adapter->mbx_lock);
 
 	return 0;
 }

-- 
1.7.11.7

From: Greg Rose <redacted>

Signed-off-by: Greg Rose <redacted>
Tested-by: Sibai Li <redacted>
Signed-off-by: Jeff Kirsher <redacted>
---
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 846ac51..07d7eab 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c

@@ -58,7 +58,7 @@ const char ixgbevf_driver_name[] = "ixgbevf";
 static const char ixgbevf_driver_string[] =
 	"Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver";
 
-#define DRV_VERSION "2.6.0-k"
+#define DRV_VERSION "2.7.12-k"
 const char ixgbevf_driver_version[] = DRV_VERSION;
 static char ixgbevf_copyright[] =
 	"Copyright (c) 2009 - 2012 Intel Corporation.";

-- 
1.7.11.7

On Tue, 2012-10-23 at 03:24 -0700, Jeff Kirsher wrote:

From: Jesse Brandeburg <redacted>

Add an official link which is designed to guide the user to the appropriate
support resource (be it community, OEM, Intel phone, Intel email, etc)

Add the current e1000 maintainer to the list of Intel maintainers.

Hi Jeff.

I think it's unwise to have 10 named maintainers for all
the intel ethernet drivers if there are specialists
maintainers.

Maybe it'd be better to break out these sub-maintainers
into specific driver sections with you as the overall
maintainer.

Maybe add an internal exploder to get all the various
maintainers on a list if everyone really looks at all
patches to intel drivers.

Something like:

INTEL ETHERNET DRIVERS
M:	Jeff Kirsher [off-list ref]
M:	Intel Linux Support [off-list ref]
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net.git
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git
S:	Supported
F:	drivers/net/ethernet/intel/

INTEL ETHERNET E1000 DRIVER
M:	Tushar Dave [off-list ref]
S:	Supported
F:	drivers/net/ethernet/intel/e1000/
F:	Documentation/networking/e1000.txt

etc...

This is a HW requirement. Although a buffer as short as 1 byte is allowed,
the total length of packet before, padding and CRC insertion, must be at
least 17 bytes.  So pad all small packets manually up to 17 bytes before
delivering them to HW.

Where do such very short packets come from?
The shortest one I know of have:
 6 bytes dest-mac
 6 bytes src-mac
 2 bytes length
 3 bytes llc header (eg reflect request).
17 bytes total.

	David

On 10/23/2012 08:25 AM, David Laight wrote:

quoted

This is a HW requirement. Although a buffer as short as 1 byte is allowed,
the total length of packet before, padding and CRC insertion, must be at
least 17 bytes.  So pad all small packets manually up to 17 bytes before
delivering them to HW.

Where do such very short packets come from?
The shortest one I know of have:
 6 bytes dest-mac
 6 bytes src-mac
 2 bytes length
 3 bytes llc header (eg reflect request).
17 bytes total.

	David

This mostly has to do with security fuzz testers sending raw packets at
the interface trying to see what can cause it to hang.  As far as I know
nothing from the stack will be that small, but we still have to support
raw packets that size.

Thanks,

Alex

From: Jeff Kirsher <redacted>
Date: Tue, 23 Oct 2012 03:24:39 -0700

This series contains updates to e1000e, igb, ixgbevf and MAINTAINERS.

The following are changes since commit 598e74f32c6dd4b3dd0ed382c889be07a7c6cbc0:
  Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next
and are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master

Pulled, thanks Jeff.

On Tue, 2012-10-23 at 06:25 -0700, Joe Perches wrote:

On Tue, 2012-10-23 at 03:24 -0700, Jeff Kirsher wrote:

quoted

From: Jesse Brandeburg <redacted>

Add an official link which is designed to guide the user to the appropriate
support resource (be it community, OEM, Intel phone, Intel email, etc)

Add the current e1000 maintainer to the list of Intel maintainers.

Hi Jeff.

I think it's unwise to have 10 named maintainers for all
the intel ethernet drivers if there are specialists
maintainers.

Maybe it'd be better to break out these sub-maintainers
into specific driver sections with you as the overall
maintainer.

Maybe add an internal exploder to get all the various
maintainers on a list if everyone really looks at all
patches to intel drivers.

Something like:

INTEL ETHERNET DRIVERS
M:	Jeff Kirsher [off-list ref]
M:	Intel Linux Support [off-list ref]
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net.git
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git
S:	Supported
F:	drivers/net/ethernet/intel/

INTEL ETHERNET E1000 DRIVER
M:	Tushar Dave [off-list ref]
S:	Supported
F:	drivers/net/ethernet/intel/e1000/
F:	Documentation/networking/e1000.txt

etc...

I understand where your coming from and this has been been something
that I have been trying to find a "reasonable" solution, which is harder
to do than one would expect.

We do have developers like Bruce Allan who maintains e1000e and Carolyn
Wyborny who maintains igb and Don Skidmore (and others) who maintain
ixgbe.  The problem we did not want to fall into by pigeon holing
developers in maintaining a driver.  Developers like John, Jesse, Alex,
and Tushar work on all of our drivers.  Jesse tends to focus on
performance related matters, where as Tushar responds to customer issues
on any driver and does the root cause and fix for the issues.

So how do we go about giving this spider web of complex coverage to some
clear concise coverage in the MAINTAINERS?

For now, the solution was to list all the developers actively working on
the kernel drivers since anyone of them can work on pretty much anyone
of our drivers.

If you have some ideas which may help resolve the issues, I am open to
suggestions.

On Tue, 2012-10-23 at 21:32 -0700, Jeff Kirsher wrote:

On Tue, 2012-10-23 at 06:25 -0700, Joe Perches wrote:

quoted

On Tue, 2012-10-23 at 03:24 -0700, Jeff Kirsher wrote:

quoted

quoted

Add the current e1000 maintainer to the list of Intel maintainers.

quoted

Maybe add an internal exploder to get all the various
maintainers on a list if everyone really looks at all
patches to intel drivers.

quoted

INTEL ETHERNET DRIVERS
M:	Jeff Kirsher [off-list ref]
M:	Intel Linux Support [off-list ref]
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net.git
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git
S:	Supported
F:	drivers/net/ethernet/intel/

I understand where your coming from and this has been been something
that I have been trying to find a "reasonable" solution, which is harder
to do than one would expect.

[]

So how do we go about giving this spider web of complex coverage to some
clear concise coverage in the MAINTAINERS?

[]

If you have some ideas which may help resolve the issues, I am open to
suggestions.

It's great that they all work on all intel drivers, but it seems
that you are the nominal maintainer and they are all developers
that might work on anything but nothing in particular.

I think an internal exploder email address would work well.

On Tue, 2012-10-23 at 21:52 -0700, Joe Perches wrote:

On Tue, 2012-10-23 at 21:32 -0700, Jeff Kirsher wrote:

quoted

On Tue, 2012-10-23 at 06:25 -0700, Joe Perches wrote:

quoted

On Tue, 2012-10-23 at 03:24 -0700, Jeff Kirsher wrote:

quoted

quoted

quoted

Add the current e1000 maintainer to the list of Intel maintainers.

quoted

quoted

Maybe add an internal exploder to get all the various
maintainers on a list if everyone really looks at all
patches to intel drivers.

quoted

quoted

INTEL ETHERNET DRIVERS
M:	Jeff Kirsher [off-list ref]
M:	Intel Linux Support [off-list ref]
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net.git
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git
S:	Supported
F:	drivers/net/ethernet/intel/

quoted

I understand where your coming from and this has been been something
that I have been trying to find a "reasonable" solution, which is harder
to do than one would expect.

[]

quoted

So how do we go about giving this spider web of complex coverage to some
clear concise coverage in the MAINTAINERS?

[]

quoted

If you have some ideas which may help resolve the issues, I am open to
suggestions.

It's great that they all work on all intel drivers, but it seems
that you are the nominal maintainer and they are all developers
that might work on anything but nothing in particular.

I think an internal exploder email address would work well.

That sounds good, I will discuss it with guys and figure it out.
Thanks!

On 10/23/2012 09:32 PM, Jeff Kirsher wrote:

So how do we go about giving this spider web of complex coverage to some
clear concise coverage in the MAINTAINERS?

I happen to like seeing "real" names.  Is it possible to leverage email conventions to allow a comment of sorts with each email:

INTEL ETHERNET DRIVERS (e100/e1000/e1000e/igb/igbvf/ixgb/ixgbe/ixgbevf)
M:      Jeff Kirsher (den mother) [off-list ref]
M:      Jesse Brandeburg (performance focus) [off-list ref]
M:      Bruce Allan (e1000e focus) [off-list ref]
M:      Carolyn Wyborny (igb focus) [off-list ref]
M:      Don Skidmore (omnibus) [off-list ref]
M:      Greg Rose (omnibus) [off-list ref]
M:      Peter P Waskiewicz Jr (omnibus) [off-list ref]
M:      Alex Duyck (omnibus) [off-list ref]
M:      John Ronciak (omnibus) [off-list ref]
M:      Tushar Dave (omnibus and rca) [off-list ref]

perhaps "any" or "all" rather than omnibus if that is too much a fifty-cent word.  Everyone is still in one place, but with some indication of specialization/generalization.  If the parenthesis form cannot be used, (I've not seen it elsewhere in MAINTAINERS) then perhaps the quoted form.

rick jones

(And yes, "den mother" was meant as a bit of levity :)