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

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

[Jeff Kirsher]

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

[net-next 1/8] e1000e: Minimum packet size must be 17 bytes

[Jeff Kirsher]

From: Tushar Dave <tushar.n.dave@intel.com>

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 <tushar.n.dave@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 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

[net-next 2/8] maintainers: update with official intel support link, new maintainer

[Jeff Kirsher]

From: Jesse Brandeburg <jesse.brandeburg@intel.com>

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 <jesse.brandeburg@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 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

[net-next 3/8] igb: Update get cable length function for i210/i211

[Jeff Kirsher]

From: Carolyn Wyborny <carolyn.wyborny@intel.com>

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 <carolyn.wyborny@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 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

[net-next 4/8] igb: Update version

[Jeff Kirsher]

From: Carolyn Wyborny <carolyn.wyborny@intel.com>

This patch updates the igb driver version to 4.0.17.

Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 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

[net-next 5/8] ixgbevf: make netif_napi_add and netif_napi_del symmetric

[Jeff Kirsher]

From: John Fastabend <john.r.fastabend@intel.com>

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 <john.r.fastabend@intel.com>
Acked-by: Greg Rose <gregory.v.rose@intel.com>
Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 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

[net-next 6/8] ixgbevf: Check for error on dma_map_single call

[Jeff Kirsher]

From: Greg Rose <gregory.v.rose@intel.com>

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 <gregory.v.rose@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 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

[net-next 7/8] ixgbevf: fix softirq-safe to unsafe splat on internal mbx_lock

[Jeff Kirsher]

From: John Fastabend <john.r.fastabend@intel.com>

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 <john.r.fastabend@intel.com>
Acked-by: Greg Rose <gregory.v.rose@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 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

[net-next 8/8] ixgbevf: Update version string

[Jeff Kirsher]

From: Greg Rose <gregory.v.rose@intel.com>

Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 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

Re: [net-next 2/8] maintainers: update with official intel support link, new maintainer

[Joe Perches]

On Tue, 2012-10-23 at 03:24 -0700, Jeff Kirsher wrote:
> From: Jesse Brandeburg <jesse.brandeburg@intel.com>
> 
> 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 <jeffrey.t.kirsher@intel.com>
M:	Intel Linux Support <linux.drivers@intel.com>
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 <tushar.n.dave@intel.com>
S:	Supported
F:	drivers/net/ethernet/intel/e1000/
F:	Documentation/networking/e1000.txt

etc...

RE: [net-next 1/8] e1000e: Minimum packet size must be 17 bytes

[David Laight]

> 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

Re: [net-next 1/8] e1000e: Minimum packet size must be 17 bytes

[Alexander Duyck]

On 10/23/2012 08:25 AM, David Laight wrote:
>> 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

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

[David Miller]

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
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.

Re: [net-next 2/8] maintainers: update with official intel support link, new maintainer

[Jeff Kirsher]

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

On Tue, 2012-10-23 at 06:25 -0700, Joe Perches wrote:
> On Tue, 2012-10-23 at 03:24 -0700, Jeff Kirsher wrote:
> > From: Jesse Brandeburg <jesse.brandeburg@intel.com>
> > 
> > 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 <jeffrey.t.kirsher@intel.com>
> M:	Intel Linux Support <linux.drivers@intel.com>
> 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 <tushar.n.dave@intel.com>
> 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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [net-next 2/8] maintainers: update with official intel support link, new maintainer

[Joe Perches]

On Tue, 2012-10-23 at 21:32 -0700, Jeff Kirsher wrote:
> On Tue, 2012-10-23 at 06:25 -0700, Joe Perches wrote:
> > On Tue, 2012-10-23 at 03:24 -0700, Jeff Kirsher wrote:

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

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

> > INTEL ETHERNET DRIVERS
> > M:	Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > M:	Intel Linux Support <linux.drivers@intel.com>
> > 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.

Re: [net-next 2/8] maintainers: update with official intel support link, new maintainer

[Jeff Kirsher]

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

On Tue, 2012-10-23 at 21:52 -0700, Joe Perches wrote:
> On Tue, 2012-10-23 at 21:32 -0700, Jeff Kirsher wrote:
> > On Tue, 2012-10-23 at 06:25 -0700, Joe Perches wrote:
> > > On Tue, 2012-10-23 at 03:24 -0700, Jeff Kirsher wrote:
> 
> > > > Add the current e1000 maintainer to the list of Intel maintainers.
> 
> > > Maybe add an internal exploder to get all the various
> > > maintainers on a list if everyone really looks at all
> > > patches to intel drivers.
> 
> > > INTEL ETHERNET DRIVERS
> > > M:	Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > > M:	Intel Linux Support <linux.drivers@intel.com>
> > > 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.
> 
That sounds good, I will discuss it with guys and figure it out.
Thanks!

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [net-next 2/8] maintainers: update with official intel support link, new maintainer

[Rick Jones]

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) <jeffrey.t.kirsher@intel.com>
M:      Jesse Brandeburg (performance focus) <jesse.brandeburg@intel.com>
M:      Bruce Allan (e1000e focus) <bruce.w.allan@intel.com>
M:      Carolyn Wyborny (igb focus) <carolyn.wyborny@intel.com>
M:      Don Skidmore (omnibus) <donald.c.skidmore@intel.com>
M:      Greg Rose (omnibus) <gregory.v.rose@intel.com>
M:      Peter P Waskiewicz Jr (omnibus) <peter.p.waskiewicz.jr@intel.com>
M:      Alex Duyck (omnibus) <alexander.h.duyck@intel.com>
M:      John Ronciak (omnibus) <john.ronciak@intel.com>
M:      Tushar Dave (omnibus and rca) <tushar.n.dave@intel.com>

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 :)