From: Florian Fainelli <f.fainelli@gmail.com>
To: Vladimir Oltean <olteanv@gmail.com>,
vivien.didelot@gmail.com, andrew@lunn.ch, idosch@idosch.org,
roopa@cumulusnetworks.com, nikolay@cumulusnetworks.com,
davem@davemloft.net
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH net-next 5/6] net: dsa: Allow proper internal use of VLANs
Date: Mon, 19 Aug 2019 20:20:02 -0700 [thread overview]
Message-ID: <cd365947-a057-a915-8e5d-0a3f1b43b5da@gmail.com> (raw)
In-Reply-To: <20190820000002.9776-6-olteanv@gmail.com>
On 8/19/2019 5:00 PM, Vladimir Oltean wrote:
> Below commit:
>
> commit 2ea7a679ca2abd251c1ec03f20508619707e1749
> Author: Andrew Lunn <andrew@lunn.ch>
> Date: Tue Nov 7 00:04:24 2017 +0100
>
> net: dsa: Don't add vlans when vlan filtering is disabled
>
> The software bridge can be build with vlan filtering support
> included. However, by default it is turned off. In its turned off
> state, it still passes VLANs via switchev, even though they are not to
> be used. Don't pass these VLANs to the hardware. Only do so when vlan
> filtering is enabled.
>
> This fixes at least one corner case. There are still issues in other
> corners, such as when vlan_filtering is later enabled.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> stubs out SWITCHDEV_OBJ_ID_PORT_VLAN objects notified by the bridge core
> to DSA drivers when vlan_filtering is 0.
>
> This is generally a good thing, because it allows dsa_8021q to make
> private use of VLANs in that mode.
>
> So it makes sense to move the check for the bridge presence and
> vlan_filtering setting one layer above. We don't want calls from
> dsa_8021q to be prevented by this, only from the bridge core.
>
> Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
next prev parent reply other threads:[~2019-08-20 3:20 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-19 23:59 [PATCH net-next 0/6] Dynamic toggling of vlan_filtering for SJA1105 DSA Vladimir Oltean
2019-08-19 23:59 ` [PATCH net-next 1/6] net: dsa: tag_8021q: Future-proof the reserved fields in the custom VID Vladimir Oltean
2019-08-20 3:16 ` Florian Fainelli
2019-08-19 23:59 ` [PATCH net-next 2/6] net: bridge: Populate the pvid flag in br_vlan_get_info Vladimir Oltean
2019-08-20 0:12 ` Nikolay Aleksandrov
2019-08-19 23:59 ` [PATCH net-next 3/6] net: dsa: Delete the VID from the upstream port as well Vladimir Oltean
2019-08-20 5:51 ` Vivien Didelot
2019-08-20 9:54 ` Vladimir Oltean
2019-08-20 17:52 ` Vivien Didelot
2019-08-20 19:40 ` Florian Fainelli
2019-08-20 20:40 ` Vladimir Oltean
2019-08-20 20:58 ` Vivien Didelot
2019-08-20 21:02 ` Vladimir Oltean
2019-08-20 21:36 ` Vivien Didelot
2019-08-20 22:09 ` Vladimir Oltean
2019-08-21 3:30 ` Vivien Didelot
2019-08-21 9:51 ` Vladimir Oltean
2019-08-20 0:00 ` [PATCH net-next 4/6] net: dsa: Don't program the VLAN as pvid on the upstream port Vladimir Oltean
2019-08-20 3:15 ` Florian Fainelli
2019-08-20 12:09 ` Vladimir Oltean
2019-08-20 22:43 ` Florian Fainelli
2019-08-20 6:07 ` Vivien Didelot
2019-08-20 10:22 ` Vladimir Oltean
2019-08-20 0:00 ` [PATCH net-next 5/6] net: dsa: Allow proper internal use of VLANs Vladimir Oltean
2019-08-20 3:20 ` Florian Fainelli [this message]
2019-08-20 0:00 ` [PATCH net-next 6/6] net: dsa: tag_8021q: Restore bridge pvid when enabling vlan_filtering Vladimir Oltean
2019-08-20 3:32 ` Florian Fainelli
2019-08-20 10:28 ` Vladimir Oltean
2019-08-20 17:36 ` Florian Fainelli
2019-08-20 23:24 ` Florian Fainelli
2019-08-20 8:04 ` [PATCH net-next 0/6] Dynamic toggling of vlan_filtering for SJA1105 DSA Vivien Didelot
2019-08-20 10:18 ` Vladimir Oltean
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cd365947-a057-a915-8e5d-0a3f1b43b5da@gmail.com \
--to=f.fainelli@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=idosch@idosch.org \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=olteanv@gmail.com \
--cc=roopa@cumulusnetworks.com \
--cc=vivien.didelot@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).