Comment 37 for bug 1616107

------- Comment From <email address hidden> 2016-12-02 12:48 EDT-------
I found the root of the problem in the bnx2x driver. If the interface is down when it is slaved to the bridge it returns -EFAULT when attempting to add a vid.

tatic int bnx2x_vlan_rx_add_vid(struct net_device *dev, __be16 proto, u16 vid)
{
struct bnx2x *bp = netdev_priv(dev);
struct bnx2x_vlan_entry *vlan;
bool hw = false;
int rc = 0;

if (!netif_running(bp->dev)) {
DP(NETIF_MSG_IFUP,
"Ignoring VLAN configuration the interface is down\n");
return -EFAULT;
}
......

This has been corrected in the commit: a02cc9d3cc9f98905df214d4a57e5918473260ea

From a02cc9d3cc9f98905df214d4a57e5918473260ea Mon Sep 17 00:00:00 2001
From: Michal Schmidt <email address hidden>
Date: Fri, 3 Jun 2016 15:32:18 +0200
Subject: [PATCH] bnx2x: allow adding VLANs while interface is down

Since implementing VLAN filtering in commit 05cc5a39ddb74
("bnx2x: add vlan filtering offload") bnx2x refuses to add a VLAN while
the interface is down:

# ip link add link enp3s0f0 enp3s0f0_10 type vlan id 10
RTNETLINK answers: Bad address

and in dmesg (with bnx2x.debug=0x20):
bnx2x: [bnx2x_vlan_rx_add_vid:12941(enp3s0f0)]Ignoring VLAN
configuration the interface is down

Other drivers have no problem with this.
Fix this peculiar behavior in the following way:
- Accept requests to add/kill VID regardless of the device state.
Maintain the requested list of VIDs in the bp->vlan_reg list.
- If the device is up, try to configure the VID list into the hardware.
If we run out of VLAN credits or encounter a failure configuring an
entry, fall back to accepting all VLANs.
If we successfully configure all entries from the list, turn the
fallback off.
- Use the same code for reconfiguring VLANs during NIC load.

Signed-off-by: Michal Schmidt <email address hidden>
Acked-by: Yuval Mintz <email address hidden>
Signed-off-by: David S. Miller <email address hidden>

-------------------------------------------------------------------------------------------------------------------------
I applied the patch to a 4.4.24 kernel; and it corrected the issue.

As a workaround simply bringing the interface up (ifconfig <interface> up> ) before adding it to the bridge.