This commit is toxic, if possible I hope it can be reverted and reworked with a new patch.
First, the patch introduced backward incompatible changes to bnxt_en VF driver that is causing issue when interoperating with the old PF driver without this commit. In that event, VF probing fails from within the VM: [ 5.660331] Broadcom NetXtreme-C/E driver bnxt_en v1.9.1 [ 5.663653] bnxt_en 0000:00:03.0 (unnamed net_device) (uninitialized): hwrm req_type 0xf seq id 0x6 error 0x4 [ 5.665804] bnxt_en 0000:00:03.0 (unnamed net_device) (uninitialized): VF MAC address 00:01:02:03:04:05 not approved by the PF [ 5.668268] bnxt_en 0000:00:03.0: Unable to initialize mac address. [ 5.670974] bnxt_en: probe of 0000:00:03.0 failed with error -99 Second, this commit contains driver changes to both PF and VF side, and incorrectly assumes that both PF and VF can/should be updated at the same time to resolve the original issue (zero VF MAC address in 'ip link show') it tried to address. In fact that is not warranted. A potential warranted fix is for VF driver to ignore what bnxt_approve_mac() may return when it got a valid MAC address from the firmware. The only purpose for the bnxt_approve_mac call for this case is a best-effort attempt to inform PF of the MAC address, instead of failing the VF driver probe when talking to an old PF driver. Canonical reported a similar issue a few days back due to the same cause. https://www.spinics.net/lists/netdev/msg521428.html Regards, -Siwei On Tue, May 8, 2018 at 12:18 AM, Michael Chan <michael.c...@broadcom.com> wrote: > The current code already forwards the VF MAC address to the PF, except > in one case. If the VF driver gets a valid MAC address from the firmware > during probe time, it will not forward the MAC address to the PF, > incorrectly assuming that the PF already knows the MAC address. This > causes "ip link show" to show zero VF MAC addresses for this case. > > This assumption is not correct. Newer firmware remembers the VF MAC > address last used by the VF and provides it to the VF driver during > probe. So we need to always forward the VF MAC address to the PF. > > The forwarded MAC address may now be the PF assigned MAC address and so we > need to make sure we approve it for this case. > > Signed-off-by: Michael Chan <michael.c...@broadcom.com> > --- > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +- > drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 3 ++- > 2 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c > b/drivers/net/ethernet/broadcom/bnxt/bnxt.c > index cd3ab78..dfa0839 100644 > --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c > +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c > @@ -8678,8 +8678,8 @@ static int bnxt_init_mac_addr(struct bnxt *bp) > memcpy(bp->dev->dev_addr, vf->mac_addr, ETH_ALEN); > } else { > eth_hw_addr_random(bp->dev); > - rc = bnxt_approve_mac(bp, bp->dev->dev_addr); > } > + rc = bnxt_approve_mac(bp, bp->dev->dev_addr); > #endif > } > return rc; > diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c > b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c > index cc21d87..a649108 100644 > --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c > +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c > @@ -923,7 +923,8 @@ static int bnxt_vf_configure_mac(struct bnxt *bp, struct > bnxt_vf_info *vf) > if (req->enables & > cpu_to_le32(FUNC_VF_CFG_REQ_ENABLES_DFLT_MAC_ADDR)) { > if (is_valid_ether_addr(req->dflt_mac_addr) && > ((vf->flags & BNXT_VF_TRUST) || > - (!is_valid_ether_addr(vf->mac_addr)))) { > + !is_valid_ether_addr(vf->mac_addr) || > + ether_addr_equal(req->dflt_mac_addr, vf->mac_addr))) { > ether_addr_copy(vf->vf_mac_addr, req->dflt_mac_addr); > return bnxt_hwrm_exec_fwd_resp(bp, vf, msg_size); > } > -- > 1.8.3.1 >
