Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 2 Nov 2020 17:10:39 -0800
From:   Jakub Kicinski <kuba@kernel.org>
To:     Vladimir Oltean <vladimir.oltean@nxp.com>
Cc:     Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
        Claudiu Manoil <claudiu.manoil@nxp.com>,
        Alexandre Belloni <alexandre.belloni@bootlin.com>,
        Andrew Lunn <andrew@lunn.ch>,
        Vivien Didelot <vivien.didelot@gmail.com>,
        Florian Fainelli <f.fainelli@gmail.com>,
        "David S. Miller" <davem@davemloft.net>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 0/7] VLAN improvements for Ocelot switch
Message-ID: <20201102171039.654adb36@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
In-Reply-To: <20201031102916.667619-1-vladimir.oltean@nxp.com>
References: <20201031102916.667619-1-vladimir.oltean@nxp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Sat, 31 Oct 2020 12:29:09 +0200 Vladimir Oltean wrote:
> The main reason why I started this work is that deleting the bridge mdb
> entries fails when the bridge is deleted, as described here:
> https://lore.kernel.org/netdev/20201015173355.564934-1-vladimir.oltean@nxp.com/
> 
> In short, that happens because the bridge mdb entries are added with a
> vid of 1, but deletion is attempted with a vid of 0. So the deletion
> code fails to find the mdb entries.
> 
> The solution is to make ocelot use a pvid of 0 when it is under a bridge
> with vlan_filtering 0. When vlan_filtering is 1, the pvid of the bridge
> is what is programmed into the hardware.
> 
> The patch series also uncovers more bugs and does some more cleanup, but
> the above is the main idea behind it.

Applied, thanks!