Re: [PATCH v3 net-next 2/2] net: dsa: tag_8021q: Restore bridge VLANs when enabling vlan_filtering

[Vivien Didelot <vivien.didelot@gmail.com>]

Hi Vladimir,

On Fri, 30 Aug 2019 03:53:25 +0300, Vladimir Oltean <olteanv@gmail.com> wrote:
> The bridge core assumes that enabling/disabling vlan_filtering will
> translate into the simple toggling of a flag for switchdev drivers.
> 
> That is clearly not the case for sja1105, which alters the VLAN table
> and the pvids in order to obtain port separation in standalone mode.
> 
> There are 2 parts to the issue.
> 
> First, tag_8021q changes the pvid to a unique per-port rx_vid for frame
> identification. But we need to disable tag_8021q when vlan_filtering
> kicks in, and at that point, the VLAN configured as pvid will have to be
> removed from the filtering table of the ports. With an invalid pvid, the
> ports will drop all traffic.  Since the bridge will not call any vlan
> operation through switchdev after enabling vlan_filtering, we need to
> ensure we're in a functional state ourselves. Hence read the pvid that
> the bridge is aware of, and program that into our ports.
> 
> Secondly, tag_8021q uses the 1024-3071 range privately in
> vlan_filtering=0 mode. Had the user installed one of these VLANs during
> a previous vlan_filtering=1 session, then upon the next tag_8021q
> cleanup for vlan_filtering to kick in again, VLANs in that range will
> get deleted unconditionally, hence breaking user expectation. So when
> deleting the VLANs, check if the bridge had knowledge about them, and if
> it did, re-apply the settings. Wrap this logic inside a
> dsa_8021q_vid_apply helper function to reduce code duplication.
> 
> Signed-off-by: Vladimir Oltean <olteanv@gmail.com>

I have no complaint with this series:

Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>


Thanks for sending smaller pieces like this one btw,

	Vivien