On 27. juli 2017 15:31, Andrew Lunn wrote:
I think you are over-simplifying here. Say i have a layer 2 VPN and i
bridge port 1 and the VPN? The software bridge still wants to do STP
on port 1, in order to solve loops.
Problem is that the mainline lan9303_separate_ports() does its
work by
> >I think you are over-simplifying here. Say i have a layer 2 VPN and i
> >bridge port 1 and the VPN? The software bridge still wants to do STP
> >on port 1, in order to solve loops.
> >
>
> Problem is that the mainline lan9303_separate_ports() does its
> work by setting port 1 & 2 in STP
On 26. juli 2017 19:24, Andrew Lunn wrote:
Hi Egil
+/* forward special tagged packets from port 0 to port 1 *or* port 2 */
+static int lan9303_setup_tagging(struct lan9303 *chip)
+{
+ int ret;
Blank line please.
+ /* enable defining the destination port via special VLAN
Hi Egil,
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Egil-Hjelmeland/net-dsa-lan9303-unicast-offload-fdb-mdb-STP/20170727-074246
config: x86_64-randconfig-x000-201730 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
Hi Egil
> +/* forward special tagged packets from port 0 to port 1 *or* port 2 */
> +static int lan9303_setup_tagging(struct lan9303 *chip)
> +{
> + int ret;
Blank line please.
> + /* enable defining the destination port via special VLAN tagging
> + * for port 0
> + */
> +
When both user ports are joined to the same bridge, the normal
HW MAC learning is enabled. This means that unicast traffic is forwarded
in HW. Support for STP is also added.
If one of the user ports leave the bridge,
the ports goes back to the initial separated operation.
Added brigde methods
