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

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;
+			}
 		}
 	}
 
-- 
2.38.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

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