recent fm10k VLAN fixes

PATCH New Jacob Keller 2 participants 13 messages Dec 1, 2017 – Jan 9, 2018

Subsystems (2)

Network drivers Intel Ethernet

lore

Share & tools

lore

Jacob Keller

author

2017-12-01 19:00 UTC #0 lore raw

cover recent fm10k VLAN fixes

This series contains recent fixes to fm10k, mostly related to VLAN handling.

Jacob Keller (3):
fm10k: cleanup unnecessary parenthesis in fm10k_iov.c
fm10k: stop adding VLAN 0 to the VLAN table
fm10k: don't assume VLAN 1 is enabled

Ngai-Mint Kwan (3):
fm10k: fix "failed to kill vid" message for VF
fm10k: correct typo in fm10k_pf.c
fm10k: clarify action when updating the VLAN table

 drivers/net/ethernet/intel/fm10k/fm10k_iov.c    |  4 ++--
 drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 29 +++++++++++++++----------
 drivers/net/ethernet/intel/fm10k/fm10k_pf.c     |  2 +-
 3 files changed, 21 insertions(+), 14 deletions(-)

Signature · 1 line

2.15.0

Jacob Keller

author

2017-12-01 19:00 UTC #1 lore raw

PATCH 1/6 fm10k: cleanup unnecessary parenthesis in fm10k_iov.c

This fixes a few warnings found by checkpatch.pl --strict

Signed-off-by Jacob Keller <[email protected]>

---
 drivers/net/ethernet/intel/fm10k/fm10k_iov.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/net/ethernet/intel/fm10k/fm10k_iov.c +2 -2

index ea3ab24265ee..760cfa52d02c 100644
@@ -353,7 +353,7 @@ int fm10k_iov_resume(struct pci_dev *pdev)
 		struct fm10k_vf_info *vf_info = &iov_data->vf_info[i];
 
 		/* allocate all but the last GLORT to the VFs */
-		if (i == ((~hw->mac.dglort_map) >> FM10K_DGLORTMAP_MASK_SHIFT))
+		if (i == (~hw->mac.dglort_map >> FM10K_DGLORTMAP_MASK_SHIFT))
 			break;
 
 		/* assign GLORT to VF, and restrict it to multicast */

@@ -511,7 +511,7 @@ int fm10k_iov_configure(struct pci_dev *pdev, int num_vfs)
 		return err;
 
 	/* allocate VFs if not already allocated */
-	if (num_vfs && (num_vfs != current_vfs)) {
+	if (num_vfs && num_vfs != current_vfs) {
 		/* Disable completer abort error reporting as
 		 * the VFs can trigger this any time they read a queue
 		 * that they don't own.

Signature · 1 line

2.15.0

Singh

2018-01-09 19:46 UTC #2 lore raw

PATCH 1/6 fm10k: cleanup unnecessary parenthesis in fm10k_iov.c

Quoted 46 lines

-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, December 1, 2017 11:00 AM
To: Intel Wired LAN <[email protected]>
Subject: [Intel-wired-lan] [PATCH 1/6] fm10k: cleanup unnecessary parenthesis in fm10k_iov.c
This fixes a few warnings found by checkpatch.pl --strict
Signed-off-by Jacob Keller <[email protected]>
---
 drivers/net/ethernet/intel/fm10k/fm10k_iov.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/intel/fm10k/fm10k_iov.c +1 -1
index ea3ab24265ee..760cfa52d02c 100644
@@ -353,7 +353,7 @@ int fm10k_iov_resume(struct pci_dev *pdev)
 		struct fm10k_vf_info *vf_info = &iov_data->vf_info[i];
 
 		/* allocate all but the last GLORT to the VFs */
-		if (i == ((~hw->mac.dglort_map) >>
 FM10K_DGLORTMAP_MASK_SHIFT))
+		if (i == (~hw->mac.dglort_map >>
 FM10K_DGLORTMAP_MASK_SHIFT))
 			break;
drivers/net/ethernet/intel/fm10k/fm10k_iov.c +1 -1
 		/* assign GLORT to VF, and restrict it to multicast */
@@ -511,7 +511,7 @@ int fm10k_iov_configure(struct pci_dev *pdev, int
 num_vfs)
 		return err;
 
 	/* allocate VFs if not already allocated */
-	if (num_vfs && (num_vfs != current_vfs)) {
+	if (num_vfs && num_vfs != current_vfs) {
 		/* Disable completer abort error reporting as
 		 * the VFs can trigger this any time they read a queue
* that they don't own.
--
2.15.0

Quoted 4 lines

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan at osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

Tested-by Krishneil Singh <[email protected]>

Jacob Keller

author

2017-12-01 19:00 UTC #3 lore raw

PATCH 2/6 fm10k: fix "failed to kill vid" message for VF

In reply to Jacob Keller

From: Ngai-Mint Kwan <[email protected]>

When a VF is under PF VLAN assignment:

ip link set <pf> vf <#> vlan <vid>

This will remove all previous entries in the VLAN table including those generated by VLAN interfaces created on the VF. The issue arises when the VF is under PF VLAN assignment and one or more of these VLAN interfaces of the VF are deleted. When deleting these VLAN interfaces, the following message will be generated in "dmesg":

failed to kill vid 0081/<vid> for device <vf>

This is due to the fact that "ndo_vlan_rx_kill_vid" exits with an error. The handler for this ndo is "fm10k_update_vid". Any calls to this function while under PF VLAN management will exit prematurely and, thus, it will generate the failure message.

Additionally, since "fm10k_update_vid" exits prematurely, none of the VLAN update is performed. So, even though the actual VLAN interfaces of the VF will be deleted, the active_vlans bitmask is not cleared. When the VF is no longer under PF VLAN assignment, the driver mistakenly restores the previous entries of the VLAN table based on an unsynchronized list of active VLANs.

The solution to this issue involves checking the VLAN update action type before exiting "fm10k_update_vid". If the VLAN update action type is to "add", this action will not be permitted while the VF is under PF VLAN assignment and the VLAN update is abandoned like before.

However, if the VLAN update action type is to "kill", then we need to also clear the active_vlans bitmask. However, we don't need to actually queue any messages to the PF, because the MAC and VLAN tables have already been cleared, and the PF would silently ignore these requests anyways.

Signed-off-by Ngai-Mint Kwan <[email protected]>

Signed-off-by Jacob Keller <[email protected]>

---
 drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

drivers/net/ethernet/intel/fm10k/fm10k_netdev.c +12 -2

index 4b5272f13d40..f8e2d1804a17 100644
@@ -934,8 +934,12 @@ static int fm10k_update_vid(struct net_device *netdev, u16 vid, bool set)
 	if (vid >= VLAN_N_VID)
 		return -EINVAL;
 
-	/* Verify we have permission to add VLANs */
-	if (hw->mac.vlan_override)
+	/* Verify that we have permission to add VLANs. If this is a request
+	 * to remove a VLAN, we still want to allow the user to remove the
+	 * VLAN device. In that case, we need to clear the bit in the
+	 * active_vlans bitmask.
+	 */
+	if (set && hw->mac.vlan_override)
 		return -EACCES;
 
 	/* update active_vlans bitmask */

@@ -954,6 +958,12 @@ static int fm10k_update_vid(struct net_device *netdev, u16 vid, bool set)
 			rx_ring->vid &= ~FM10K_VLAN_CLEAR;
 	}
 
+	/* If our VLAN has been overridden, there is no reason to send VLAN
+	 * removal requests as they will be silently ignored.
+	 */
+	if (hw->mac.vlan_override)
+		return 0;
+
 	/* Do not remove default VLAN ID related entries from VLAN and MAC
 	 * tables
 	 */

Signature · 1 line

2.15.0

Singh

2018-01-09 19:47 UTC #4 lore raw

PATCH 2/6 fm10k: fix "failed to kill vid" message for VF

Quoted 91 lines

-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, December 1, 2017 11:00 AM
To: Intel Wired LAN <[email protected]>
Cc: Kwan, Ngai-mint <[email protected]>
Subject: [Intel-wired-lan] [PATCH 2/6] fm10k: fix "failed to kill vid" message for VF
From: Ngai-Mint Kwan <[email protected]>
When a VF is under PF VLAN assignment:
ip link set <pf> vf <#> vlan <vid>
This will remove all previous entries in the VLAN table including those generated by VLAN interfaces created on the VF. The issue arises when the VF is under PF VLAN assignment and one or more of these VLAN interfaces of the VF are deleted. When deleting these VLAN interfaces, the following message will be generated in "dmesg":
failed to kill vid 0081/<vid> for device <vf>
This is due to the fact that "ndo_vlan_rx_kill_vid" exits with an error. The handler for this ndo is "fm10k_update_vid". Any calls to this function while under PF VLAN management will exit prematurely and, thus, it will generate the failure message.
Additionally, since "fm10k_update_vid" exits prematurely, none of the VLAN update is performed. So, even though the actual VLAN interfaces of the VF will be deleted, the active_vlans bitmask is not cleared. When the VF is no longer under PF VLAN assignment, the driver mistakenly restores the previous entries of the VLAN table based on an unsynchronized list of active VLANs.
The solution to this issue involves checking the VLAN update action type before exiting "fm10k_update_vid". If the VLAN update action type is to "add", this action will not be permitted while the VF is under PF VLAN assignment and the VLAN update is abandoned like before.
However, if the VLAN update action type is to "kill", then we need to also clear the active_vlans bitmask. However, we don't need to actually queue any messages to the PF, because the MAC and VLAN tables have already been cleared, and the PF would silently ignore these requests anyways.
Signed-off-by Ngai-Mint Kwan <[email protected]>
Signed-off-by Jacob Keller <[email protected]>
---
 drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)
drivers/net/ethernet/intel/fm10k/fm10k_netdev.c +6 -2
index 4b5272f13d40..f8e2d1804a17 100644
@@ -934,8 +934,12 @@ static int fm10k_update_vid(struct net_device
 *netdev, u16 vid, bool set)
 	if (vid >= VLAN_N_VID)
 		return -EINVAL;
 
-	/* Verify we have permission to add VLANs */
-	if (hw->mac.vlan_override)
+	/* Verify that we have permission to add VLANs. If this is a request
+	 * to remove a VLAN, we still want to allow the user to remove the
+	 * VLAN device. In that case, we need to clear the bit in the
+	 * active_vlans bitmask.
+	 */
+	if (set && hw->mac.vlan_override)
 		return -EACCES;
 
drivers/net/ethernet/intel/fm10k/fm10k_netdev.c +6 -0
 	/* update active_vlans bitmask */
@@ -954,6 +958,12 @@ static int fm10k_update_vid(struct net_device
 *netdev, u16 vid, bool set)
 			rx_ring->vid &= ~FM10K_VLAN_CLEAR;
 	}
 
+	/* If our VLAN has been overridden, there is no reason to send VLAN
+	 * removal requests as they will be silently ignored.
+	 */
+	if (hw->mac.vlan_override)
+		return 0;
+
 	/* Do not remove default VLAN ID related entries from VLAN and MAC
 	 * tables
*/
--
2.15.0

Quoted 4 lines

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan at osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

Tested-by Krishneil Singh <[email protected]>

Jacob Keller

author

2017-12-01 19:00 UTC #5 lore raw

PATCH 3/6 fm10k: stop adding VLAN 0 to the VLAN table

In reply to Jacob Keller

Currently, when the driver loads, it sends a request to add VLAN 0 to the VLAN table. For the PF, this is honored, and VLAN 0 is indeed set. For the VF, this request is silently converted into a request for the default VLAN as defined by either the switch vid or the PF vid.

This results in the odd behavior that the VLAN table doesn't appear consistent between the PF and the VF.

Furthermore, setting a MAC filter with VLAN 0 is generally considered an invalid configuration by the switch, and since commit 856dfd69e84f ("fm10k: Fix multicast mode synch issues", 2016-03-03) we've had code which prevents us from ever sending such a request.

Since there's not really a good reason to keep VLAN 0 in the VLAN table, stop requesting it in fm10k_restore_rx_state().

This might seem to indicate that we would no longer properly configure the MAC and VLAN tables for the default vid. However, due to the way that fm10k_find_next_vlan() behaves, it will always return the default_vid as enabled.

Signed-off-by Jacob Keller <[email protected]>

---
 drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 3 ---
 1 file changed, 3 deletions(-)

drivers/net/ethernet/intel/fm10k/fm10k_netdev.c +0 -3

index f8e2d1804a17..d79bff7c23f7 100644
@@ -1221,9 +1221,6 @@ void fm10k_restore_rx_state(struct fm10k_intfc *interface)
 	fm10k_queue_vlan_request(interface, FM10K_VLAN_ALL, 0,
 				 xcast_mode == FM10K_XCAST_MODE_PROMISC);
 
-	/* Add filter for VLAN 0 */
-	fm10k_queue_vlan_request(interface, 0, 0, true);
-
 	/* update table with current entries */
 	for (vid = hw->mac.default_vid ? fm10k_find_next_vlan(interface, 0) : 1;
 	     vid < VLAN_N_VID;

Signature · 1 line

2.15.0

Singh

2018-01-09 19:48 UTC #6 lore raw

PATCH 3/6 fm10k: stop adding VLAN 0 to the VLAN table

Quoted 56 lines

-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, December 1, 2017 11:00 AM
To: Intel Wired LAN <[email protected]>
Subject: [Intel-wired-lan] [PATCH 3/6] fm10k: stop adding VLAN 0 to the VLAN table
Currently, when the driver loads, it sends a request to add VLAN 0 to the VLAN table. For the PF, this is honored, and VLAN 0 is indeed set. For the VF, this request is silently converted into a request for the default VLAN as defined by either the switch vid or the PF vid.
This results in the odd behavior that the VLAN table doesn't appear consistent between the PF and the VF.
Furthermore, setting a MAC filter with VLAN 0 is generally considered an invalid configuration by the switch, and since commit 856dfd69e84f ("fm10k: Fix multicast mode synch issues", 2016-03-03) we've had code which prevents us from ever sending such a request.
Since there's not really a good reason to keep VLAN 0 in the VLAN table, stop requesting it in fm10k_restore_rx_state().
This might seem to indicate that we would no longer properly configure the MAC and VLAN tables for the default vid. However, due to the way that fm10k_find_next_vlan() behaves, it will always return the default_vid as enabled.
Signed-off-by Jacob Keller <[email protected]>
---
 drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 3 ---
 1 file changed, 3 deletions(-)
drivers/net/ethernet/intel/fm10k/fm10k_netdev.c +0 -3
index f8e2d1804a17..d79bff7c23f7 100644
@@ -1221,9 +1221,6 @@ void fm10k_restore_rx_state(struct fm10k_intfc
 *interface)
 	fm10k_queue_vlan_request(interface, FM10K_VLAN_ALL, 0,
 				 xcast_mode ==
 FM10K_XCAST_MODE_PROMISC);
 
-	/* Add filter for VLAN 0 */
-	fm10k_queue_vlan_request(interface, 0, 0, true);
-
 	/* update table with current entries */
for (vid = hw->mac.default_vid ? fm10k_find_next_vlan(interface, 0) :
1;
vid < VLAN_N_VID;
--
2.15.0

Quoted 4 lines

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan at osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

Tested-by Krishneil Singh <[email protected]>

Jacob Keller

author

2017-12-01 19:00 UTC #7 lore raw

PATCH 4/6 fm10k: don't assume VLAN 1 is enabled

In reply to Jacob Keller

Since commit 856dfd69e84f ("fm10k: Fix multicast mode synch issues", 2016-03-03) we've incorrectly assumed that VLAN 1 is enabled when the default VID is not set.

This occurs because we check the default_vid and if it's zero, start several loops over the active_vlans bitmask at 1, instead of checking to ensure that that bit is active.

This happened because of commit d9ff3ee8efe9 ("fm10k: Add support for VLAN 0 w/o default VLAN", 2014-08-07) which mistakenly assumed that we should send requests for MAC and VLAN filters with VLAN 0 when the default_vid isn't set.

However, the switch generally considers this an invalid configuration, so the only time we'd have a default_vid of 0 is when the switch is down.

Instead, lets just not request any filters for the default_vid if it's not yet been assigned.

Signed-off-by Jacob Keller <[email protected]>

---
 drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

drivers/net/ethernet/intel/fm10k/fm10k_netdev.c +3 -5

index d79bff7c23f7..ec91eabbb723 100644
@@ -1050,14 +1050,13 @@ static int __fm10k_uc_sync(struct net_device *dev,
 			   const unsigned char *addr, bool sync)
 {
 	struct fm10k_intfc *interface = netdev_priv(dev);
-	struct fm10k_hw *hw = &interface->hw;
 	u16 vid, glort = interface->glort;
 	s32 err;
 
 	if (!is_valid_ether_addr(addr))
 		return -EADDRNOTAVAIL;
 
-	for (vid = hw->mac.default_vid ? fm10k_find_next_vlan(interface, 0) : 1;
+	for (vid = fm10k_find_next_vlan(interface, 0);
 	     vid < VLAN_N_VID;
 	     vid = fm10k_find_next_vlan(interface, vid)) {
 		err = fm10k_queue_mac_request(interface, glort,

@@ -1116,14 +1115,13 @@ static int __fm10k_mc_sync(struct net_device *dev,
 			   const unsigned char *addr, bool sync)
 {
 	struct fm10k_intfc *interface = netdev_priv(dev);
-	struct fm10k_hw *hw = &interface->hw;
 	u16 vid, glort = interface->glort;
 	s32 err;
 
 	if (!is_multicast_ether_addr(addr))
 		return -EADDRNOTAVAIL;
 
-	for (vid = hw->mac.default_vid ? fm10k_find_next_vlan(interface, 0) : 1;
+	for (vid = fm10k_find_next_vlan(interface, 0);
 	     vid < VLAN_N_VID;
 	     vid = fm10k_find_next_vlan(interface, vid)) {
 		err = fm10k_queue_mac_request(interface, glort,

@@ -1222,7 +1220,7 @@ void fm10k_restore_rx_state(struct fm10k_intfc *interface)
 				 xcast_mode == FM10K_XCAST_MODE_PROMISC);
 
 	/* update table with current entries */
-	for (vid = hw->mac.default_vid ? fm10k_find_next_vlan(interface, 0) : 1;
+	for (vid = fm10k_find_next_vlan(interface, 0);
 	     vid < VLAN_N_VID;
 	     vid = fm10k_find_next_vlan(interface, vid)) {
 		fm10k_queue_vlan_request(interface, vid, 0, true);

Signature · 1 line

2.15.0

Singh

2018-01-09 19:49 UTC #8 lore raw

PATCH 4/6 fm10k: don't assume VLAN 1 is enabled

Quoted 89 lines

-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, December 1, 2017 11:00 AM
To: Intel Wired LAN <[email protected]>
Subject: [Intel-wired-lan] [PATCH 4/6] fm10k: don't assume VLAN 1 is enabled
Since commit 856dfd69e84f ("fm10k: Fix multicast mode synch issues", 2016-03-03) we've incorrectly assumed that VLAN 1 is enabled when the default VID is not set.
This occurs because we check the default_vid and if it's zero, start several loops over the active_vlans bitmask at 1, instead of checking to ensure that that bit is active.
This happened because of commit d9ff3ee8efe9 ("fm10k: Add support for VLAN 0 w/o default VLAN", 2014-08-07) which mistakenly assumed that we should send requests for MAC and VLAN filters with VLAN 0 when the default_vid isn't set.
However, the switch generally considers this an invalid configuration, so the only time we'd have a default_vid of 0 is when the switch is down.
Instead, lets just not request any filters for the default_vid if it's not yet been assigned.
Signed-off-by Jacob Keller <[email protected]>
---
 drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)
drivers/net/ethernet/intel/fm10k/fm10k_netdev.c +1 -2
index d79bff7c23f7..ec91eabbb723 100644
@@ -1050,14 +1050,13 @@ static int __fm10k_uc_sync(struct net_device
 *dev,
 			   const unsigned char *addr, bool sync)
 {
 	struct fm10k_intfc *interface = netdev_priv(dev);
-	struct fm10k_hw *hw = &interface->hw;
 	u16 vid, glort = interface->glort;
 	s32 err;
 
 	if (!is_valid_ether_addr(addr))
 		return -EADDRNOTAVAIL;
 
-	for (vid = hw->mac.default_vid ? fm10k_find_next_vlan(interface, 0) :
 1;
+	for (vid = fm10k_find_next_vlan(interface, 0);
 	     vid < VLAN_N_VID;
drivers/net/ethernet/intel/fm10k/fm10k_netdev.c +1 -2
 	     vid = fm10k_find_next_vlan(interface, vid)) {
 		err = fm10k_queue_mac_request(interface, glort,
@@ -1116,14 +1115,13 @@ static int __fm10k_mc_sync(struct net_device
 *dev,
 			   const unsigned char *addr, bool sync)
 {
 	struct fm10k_intfc *interface = netdev_priv(dev);
-	struct fm10k_hw *hw = &interface->hw;
 	u16 vid, glort = interface->glort;
 	s32 err;
 
 	if (!is_multicast_ether_addr(addr))
 		return -EADDRNOTAVAIL;
 
-	for (vid = hw->mac.default_vid ? fm10k_find_next_vlan(interface, 0) :
 1;
+	for (vid = fm10k_find_next_vlan(interface, 0);
 	     vid < VLAN_N_VID;
drivers/net/ethernet/intel/fm10k/fm10k_netdev.c +1 -1
 	     vid = fm10k_find_next_vlan(interface, vid)) {
 		err = fm10k_queue_mac_request(interface, glort,
@@ -1222,7 +1220,7 @@ void fm10k_restore_rx_state(struct fm10k_intfc
 *interface)
 				 xcast_mode ==
 FM10K_XCAST_MODE_PROMISC);
 
 	/* update table with current entries */
-	for (vid = hw->mac.default_vid ? fm10k_find_next_vlan(interface, 0) :
 1;
+	for (vid = fm10k_find_next_vlan(interface, 0);
drivers/net/ethernet/intel/fm10k/fm10k_netdev.c +0 -1
 	     vid < VLAN_N_VID;
 	     vid = fm10k_find_next_vlan(interface, vid)) {
 		fm10k_queue_vlan_request(interface, vid, 0, true);
--
2.15.0

Quoted 4 lines

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan at osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

Tested-by Krishneil Singh <[email protected]>

Jacob Keller

author

2017-12-01 19:00 UTC #9 lore raw

PATCH 5/6 fm10k: correct typo in fm10k_pf.c

In reply to Jacob Keller

From: Ngai-Mint Kwan <[email protected]>

Signed-off-by Ngai-Mint Kwan <[email protected]>

---
 drivers/net/ethernet/intel/fm10k/fm10k_pf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/ethernet/intel/fm10k/fm10k_pf.c +1 -1

index 425d814aed4d..d6406fc31ffb 100644
@@ -866,7 +866,7 @@ static s32 fm10k_iov_assign_default_mac_vlan_pf(struct fm10k_hw *hw,
 	/* Determine correct default VLAN ID. The FM10K_VLAN_OVERRIDE bit is
 	 * used here to indicate to the VF that it will not have privilege to
 	 * write VLAN_TABLE. All policy is enforced on the PF but this allows
-	 * the VF to correctly report errors to userspace rqeuests.
+	 * the VF to correctly report errors to userspace requests.
 	 */
 	if (vf_info->pf_vid)
 		vf_vid = vf_info->pf_vid | FM10K_VLAN_OVERRIDE;

Signature · 1 line

2.15.0

Singh

2018-01-09 19:49 UTC #10 lore raw

PATCH 5/6 fm10k: correct typo in fm10k_pf.c

Quoted 35 lines

-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, December 1, 2017 11:00 AM
To: Intel Wired LAN <[email protected]>
Cc: Kwan, Ngai-mint <[email protected]>
Subject: [Intel-wired-lan] [PATCH 5/6] fm10k: correct typo in fm10k_pf.c
From: Ngai-Mint Kwan <[email protected]>
Signed-off-by Ngai-Mint Kwan <[email protected]>
---
 drivers/net/ethernet/intel/fm10k/fm10k_pf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/intel/fm10k/fm10k_pf.c +0 -0
index 425d814aed4d..d6406fc31ffb 100644
@@ -866,7 +866,7 @@ static s32
 fm10k_iov_assign_default_mac_vlan_pf(struct fm10k_hw *hw,
 	/* Determine correct default VLAN ID. The FM10K_VLAN_OVERRIDE
bit is
drivers/net/ethernet/intel/fm10k/fm10k_pf.c +1 -2
 	 * used here to indicate to the VF that it will not have privilege to
 	 * write VLAN_TABLE. All policy is enforced on the PF but this allows
-	 * the VF to correctly report errors to userspace rqeuests.
+	 * the VF to correctly report errors to userspace requests.
 	 */
 	if (vf_info->pf_vid)
 		vf_vid = vf_info->pf_vid | FM10K_VLAN_OVERRIDE;
--
2.15.0

Quoted 4 lines

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan at osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

Tested-by Krishneil Singh <[email protected]>

Jacob Keller

author

2017-12-01 19:00 UTC #11 lore raw

PATCH 6/6 fm10k: clarify action when updating the VLAN table

In reply to Jacob Keller

From: Ngai-Mint Kwan <[email protected]>

Clarify the comment for when entering promiscuous mode that we update the VLAN table. Add a comment distinguishing the case where we're exiting promiscuous mode and need to clear the entire VLAN table.

Signed-off-by Ngai-Mint Kwan <[email protected]>

Signed-off-by Jacob Keller <[email protected]>

---
 drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/net/ethernet/intel/fm10k/fm10k_netdev.c +3 -1

index ec91eabbb723..f1cfa1a1586a 100644
@@ -1165,10 +1165,12 @@ static void fm10k_set_rx_mode(struct net_device *dev)
 
 	/* update xcast mode first, but only if it changed */
 	if (interface->xcast_mode != xcast_mode) {
-		/* update VLAN table */
+		/* update VLAN table when entering promiscuous mode */
 		if (xcast_mode == FM10K_XCAST_MODE_PROMISC)
 			fm10k_queue_vlan_request(interface, FM10K_VLAN_ALL,
 						 0, true);
+
+		/* clear VLAN table when exiting promiscuous mode */
 		if (interface->xcast_mode == FM10K_XCAST_MODE_PROMISC)
 			fm10k_clear_unused_vlans(interface);

Signature · 1 line

2.15.0

Singh

2018-01-09 19:50 UTC #12 lore raw

PATCH 6/6 fm10k: clarify action when updating the VLAN table

Quoted 45 lines

-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On Behalf Of Jacob Keller
Sent: Friday, December 1, 2017 11:00 AM
To: Intel Wired LAN <[email protected]>
Cc: Kwan, Ngai-mint <[email protected]>; Jacob Keller <[email protected]>
Subject: [Intel-wired-lan] [PATCH 6/6] fm10k: clarify action when updating the VLAN table
From: Ngai-Mint Kwan <[email protected]>
Clarify the comment for when entering promiscuous mode that we update the VLAN table. Add a comment distinguishing the case where we're exiting promiscuous mode and need to clear the entire VLAN table.
Signed-off-by Ngai-Mint Kwan <[email protected]>
Signed-off-by Jacob Keller <[email protected]>
---
 drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/ethernet/intel/fm10k/fm10k_netdev.c +3 -1
index ec91eabbb723..f1cfa1a1586a 100644
@@ -1165,10 +1165,12 @@ static void fm10k_set_rx_mode(struct net_device
 *dev)
 
 	/* update xcast mode first, but only if it changed */
 	if (interface->xcast_mode != xcast_mode) {
-		/* update VLAN table */
+		/* update VLAN table when entering promiscuous mode */
 		if (xcast_mode == FM10K_XCAST_MODE_PROMISC)
 			fm10k_queue_vlan_request(interface,
 FM10K_VLAN_ALL,
 						 0, true);
+
+		/* clear VLAN table when exiting promiscuous mode */
 		if (interface->xcast_mode == FM10K_XCAST_MODE_PROMISC)
fm10k_clear_unused_vlans(interface);

Quoted 7 lines

--
2.15.0
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan at osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

Tested-by Krishneil Singh <[email protected]>