Hi Florian, On Fri, 31 May 2019 09:34:03 -0700, Florian Fainelli <f.faine...@gmail.com> wrote: > On 5/31/19 7:37 AM, Andrew Lunn wrote: > >> I'm not sure that I like the semantic of it, because the driver can > >> actually > >> support VID 0 per-se, only the kernel does not use VLAN 0. Thus I would > >> avoid > >> calling the port_vlan_del() ops for VID 0, directly into the upper DSA > >> layer. > >> > >> Florian, Andrew, wouldn't the following patch be more adequate? > >> > >> diff --git a/net/dsa/slave.c b/net/dsa/slave.c > >> index 1e2ae9d59b88..80f228258a92 100644 > >> --- a/net/dsa/slave.c > >> +++ b/net/dsa/slave.c > >> @@ -1063,6 +1063,10 @@ static int dsa_slave_vlan_rx_kill_vid(struct > >> net_device *dev, __be16 proto, > >> struct bridge_vlan_info info; > >> int ret; > >> > >> + /* VID 0 has a special meaning and is never programmed in > >> hardware */ > >> + if (!vid) > >> + return 0; > >> + > >> /* Check for a possible bridge VLAN entry now since there is no > >> * need to emulate the switchdev prepare + commit phase. > >> */ > > > > Hi Vivien > > > > If we put this in rx_kill_vid, we should probably have something > > similar in rx_add_vid, just in case the kernel does start using VID 0. > > We use the prepare/commit model in the rx_add_vid() path so we deal with > -EOPNOTSUPP, that was caught fairly early on by Heiner when I added > programming of VLAN filtering through rx_{add,kill}_vid. > > Nikita's patcha s it stands is correct and would make both > mv88e6xxx_port_check_hw_vlan() and mv88e6xxx_vtu_get() consistent.
OK, I'll double check if I can simplify the management of VID 0 in mv88e6xxx to match what other switches do. In the meantime, Nikita's approach is consistent. Thank you, Vivien