@@ -1346,6 +1346,12 @@ static int dsa_slave_vlan_rx_add_vid(struct net_device *dev, __be16 proto,
/* User port... */
ret = dsa_port_vlan_add(dp, &vlan, &extack);
if (ret) {
+ if (ret == -EOPNOTSUPP)
+ /* Driver allows the configuration, but is not
+ * offloading it, which is fine by us.
+ */
+ goto add_to_master;
+
if (extack._msg)
netdev_err(dev, "%s\n", extack._msg);
return ret;
@@ -1360,6 +1366,7 @@ static int dsa_slave_vlan_rx_add_vid(struct net_device *dev, __be16 proto,
return ret;
}
+add_to_master:
return vlan_vid_add(master, proto, vid);
}
@@ -1379,7 +1386,7 @@ static int dsa_slave_vlan_rx_kill_vid(struct net_device *dev, __be16 proto,
* ports which can be members of this VLAN as well.
*/
err = dsa_port_vlan_del(dp, &vlan);
- if (err)
+ if (err && err != -EOPNOTSUPP)
return err;
vlan_vid_del(master, proto, vid);
The dsa_slave_vlan_rx_{add,kill}_vid ndos are required for hardware that can not control VLAN filtering per port, rather it is a device global setting, in order to support VLAN uppers on non-bridged ports. For hardware that can control VLAN filtering per port, it is perfectly fine to fallback to software VLANs in this scenario. So, make sure that this "error" does not leave the DSA layer as vlan_add_vid does not know the meaning of it. The blamed commit removed this exemption by not advertising the feature if the driver did not implement VLAN offloading. But as we know see, the assumption that if a driver supports VLAN offloading, it will always use it, does not hold in certain edge cases. Fixes: 9b236d2a69da ("net: dsa: Advertise the VLAN offload netdev ability only if switch supports it") Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> --- net/dsa/slave.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)