diff mbox series

igbvf: Regard vf reset nack as success

Message ID 20221122092707.30981-1-akihiko.odaki@daynix.com
State New
Headers
Series igbvf: Regard vf reset nack as success |

Commit Message

Akihiko Odaki Nov. 22, 2022, 9:27 a.m. UTC 
  vf reset nack actually represents the reset operation itself is
performed but no address is not assigned. Therefore, e1000_reset_hw_vf
should fill the "perm_addr" with the zero address and return success on
such an occassion. This prevents its callers in netdev.c from saying PF
still resetting, and instead allows them to correctly report that no
address is assigned.

Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
---
 drivers/net/ethernet/intel/igbvf/vf.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

Comments

Paul Menzel Nov. 22, 2022, 2:17 p.m. UTC | #1 
Dear Akihiko,


Thank you for your patch.


Am 22.11.22 um 10:27 schrieb Akihiko Odaki:
> vf reset nack actually represents the reset operation itself is
> performed but no address is not assigned. Therefore, e1000_reset_hw_vf

Is … no … not assigned … intentional?

> should fill the "perm_addr" with the zero address and return success on
> such an occassion. This prevents its callers in netdev.c from saying PF

occasion

> still resetting, and instead allows them to correctly report that no
> address is assigned.

In what environment do you hit the problem?

[…]


Kind regards,

Paul
Akihiko Odaki Nov. 22, 2022, 3:28 p.m. UTC | #2 
Hi,

On 2022/11/22 23:17, Paul Menzel wrote:
> Dear Akihiko,
> 
> 
> Thank you for your patch.
> 
> 
> Am 22.11.22 um 10:27 schrieb Akihiko Odaki:
>> vf reset nack actually represents the reset operation itself is
>> performed but no address is not assigned. Therefore, e1000_reset_hw_vf
> 
> Is … no … not assigned … intentional?
> 
>> should fill the "perm_addr" with the zero address and return success on
>> such an occassion. This prevents its callers in netdev.c from saying PF
> 
> occasion

I have just sent v2 with the message fixed.

> 
>> still resetting, and instead allows them to correctly report that no
>> address is assigned.
> 
> In what environment do you hit the problem?

I found this bug when I was developing a QEMU patch to emulate 82576.

Regards,
Akihiko Odaki

> 
> […]
> 
> 
> Kind regards,
> 
> Paul
diff mbox series

Patch

diff --git a/drivers/net/ethernet/intel/igbvf/vf.c b/drivers/net/ethernet/intel/igbvf/vf.c
index b8ba3f94c363..2691ae2a8002 100644
--- a/drivers/net/ethernet/intel/igbvf/vf.c
+++ b/drivers/net/ethernet/intel/igbvf/vf.c
@@ -1,6 +1,8 @@ 
 // SPDX-License-Identifier: GPL-2.0
 /* Copyright(c) 2009 - 2018 Intel Corporation. */
 
+#include <linux/etherdevice.h>
+
 #include "vf.h"
 
 static s32 e1000_check_for_link_vf(struct e1000_hw *hw);
@@ -131,11 +133,18 @@  static s32 e1000_reset_hw_vf(struct e1000_hw *hw)
 		/* set our "perm_addr" based on info provided by PF */
 		ret_val = mbx->ops.read_posted(hw, msgbuf, 3);
 		if (!ret_val) {
-			if (msgbuf[0] == (E1000_VF_RESET |
-					  E1000_VT_MSGTYPE_ACK))
+			switch (msgbuf[0]) {
+			case E1000_VF_RESET | E1000_VT_MSGTYPE_ACK:
 				memcpy(hw->mac.perm_addr, addr, ETH_ALEN);
-			else
+				break;
+
+			case E1000_VF_RESET | E1000_VT_MSGTYPE_NACK:
+				eth_zero_addr(hw->mac.perm_addr);
+				break;
+
+			default:
 				ret_val = -E1000_ERR_MAC_INIT;
+			}
 		}
 	}