From: Kurt Kanzenbach <kurt@linutronix.de>
To: Vladimir Oltean <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org
Cc: Florian Fainelli <f.fainelli@gmail.com>,
Andrew Lunn <andrew@lunn.ch>,
Vivien Didelot <vivien.didelot@gmail.com>,
Hauke Mehrtens <hauke@hauke-m.de>,
Woojung Huh <woojung.huh@microchip.com>,
UNGLinuxDriver@microchip.com, Sean Wang <sean.wang@mediatek.com>,
Landen Chao <Landen.Chao@mediatek.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Claudiu Manoil <claudiu.manoil@nxp.com>,
Linus Walleij <linus.walleij@linaro.org>,
Russell King <rmk+kernel@armlinux.org.uk>,
Oleksij Rempel <linux@rempel-privat.de>
Subject: Re: [PATCH net-next] net: dsa: set configure_vlan_while_not_filtering to true by default
Date: Fri, 15 Jan 2021 08:11:33 +0100 [thread overview]
Message-ID: <87o8hq4qu2.fsf@kurt> (raw)
In-Reply-To: <20210114173426.2731780-1-olteanv@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2667 bytes --]
On Thu Jan 14 2021, Vladimir Oltean wrote:
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
>
> As explained in commit 54a0ed0df496 ("net: dsa: provide an option for
> drivers to always receive bridge VLANs"), DSA has historically been
> skipping VLAN switchdev operations when the bridge wasn't in
> vlan_filtering mode, but the reason why it was doing that has never been
> clear. So the configure_vlan_while_not_filtering option is there merely
> to preserve functionality for existing drivers. It isn't some behavior
> that drivers should opt into. Ideally, when all drivers leave this flag
> set, we can delete the dsa_port_skip_vlan_configuration() function.
>
> New drivers always seem to omit setting this flag, for some reason. So
> let's reverse the logic: the DSA core sets it by default to true before
> the .setup() callback, and legacy drivers can turn it off. This way, new
> drivers get the new behavior by default, unless they explicitly set the
> flag to false, which is more obvious during review.
>
> Remove the assignment from drivers which were setting it to true, and
> add the assignment to false for the drivers that didn't previously have
> it. This way, it should be easier to see how many we have left.
>
> The following drivers: lan9303, mv88e6060 were skipped from setting this
> flag to false, because they didn't have any VLAN offload ops in the
> first place.
>
> The Broadcom Starfighter 2 driver calls the common b53_switch_alloc and
> therefore also inherits the configure_vlan_while_not_filtering=true
> behavior.
>
> Also, print a message through netlink extack every time a VLAN has been
> skipped. This is mildly annoying on purpose, so that (a) it is at least
> clear that VLANs are being skipped - the legacy behavior in itself is
> confusing, and the extack should be much more difficult to miss, unlike
> kernel logs - and (b) people have one more incentive to convert to the
> new behavior.
>
> No behavior change except for the added prints is intended at this time.
>
> $ ip link add br0 type bridge vlan_filtering 0
> $ ip link set sw0p2 master br0
> [ 60.315148] br0: port 1(sw0p2) entered blocking state
> [ 60.320350] br0: port 1(sw0p2) entered disabled state
> [ 60.327839] device sw0p2 entered promiscuous mode
> [ 60.334905] br0: port 1(sw0p2) entered blocking state
> [ 60.340142] br0: port 1(sw0p2) entered forwarding state
> Warning: dsa_core: skipping configuration of VLAN. # This was the pvid
> $ bridge vlan add dev sw0p2 vid 100
> Warning: dsa_core: skipping configuration of VLAN.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2021-01-15 7:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-14 17:34 [PATCH net-next] net: dsa: set configure_vlan_while_not_filtering to true by default Vladimir Oltean
2021-01-15 7:11 ` Kurt Kanzenbach [this message]
2021-01-15 16:49 ` Florian Fainelli
2021-01-15 23:03 ` Jakub Kicinski
2021-01-15 23:12 ` Vladimir Oltean
2021-01-15 23:14 ` 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=87o8hq4qu2.fsf@kurt \
--to=kurt@linutronix.de \
--cc=Landen.Chao@mediatek.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew@lunn.ch \
--cc=claudiu.manoil@nxp.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=hauke@hauke-m.de \
--cc=kuba@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux@rempel-privat.de \
--cc=matthias.bgg@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=rmk+kernel@armlinux.org.uk \
--cc=sean.wang@mediatek.com \
--cc=vivien.didelot@gmail.com \
--cc=woojung.huh@microchip.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.